-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 07:50 +0100, Christoph-Erdmann Pfeiler wrote:

I've observed the phenomenon "kernel 2.6.27.19-3.2-default breaks ATI Proprietary Linux Driver-8.582" on two different systems.

Both are running SuSE 11.1 with current kernel update.

However, this list is for the "factory" version, ie, the next 11.2. The 11.1 version is not handled here. Try the normal list instead. However, if you saw the problem on two systems, you could write a bugzilla. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1AVIACgkQtTMYHG2NR9VzcQCfdBnKGav49irLpjmAAZwy7vw5 nx4AoIQB3xFY3QIfz4zThmkwm/wRrnl+ =zYkv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. wrote:

On Monday, 2009-03-09 at 04:03 -0000, Sid Boyce wrote:

...

Problem, I have a xfs 1TB hard drive with badblocks (/dev/sda1) and would like to clone it to another 1TB drive (/dev/sdc1), /dev/sdc is already partitioned and mkfs.xfs run.

With xfs you could use xfsdump and xfsrestore.

...

I've tried rsync, that didn't do it properly.

Why not?

...

Next I copied all the data across, but it gets confused on boot with the different namings in /dev/disk/by-id/ and what was copied across in /etc/fstab and the stuff in /etc/grub/.

Well, those you will have to adjust manually, there is no way around it that I know of.

...

YaST in 11.2 Alpha0 doesn't now have an entry for cloning a system that I can identify. What's recommended?

rsync.

-- Cheers, Carlos E. R.

I have a suspicion that the badblocks on the source drive is causing a problem. When I used dd, I perhaps should have used the "noerror" option then do xfs_repair. Thanks, guys, I shall have another look. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Peter Poeml wrote:

On Mon, Mar 09, 2009 at 01:35:19PM +0000, Sid Boyce wrote:

...

I have a suspicion that the badblocks on the source drive is causing a problem. When I used dd, I perhaps should have used the "noerror" option then do xfs_repair. Thanks, guys, I shall have another look. Regards Sid.

For disks with bad blocks, you usually want to use 'ddrescue' instead of dd. It tries harder to get what's readable, doesn't give up and doesn't need manual intervention as dd.

(rsync to grab files, ddrescue to grab a (broken) disk image for further processing)

Peter

I think I have a hardware problem elsewhere - CPU/memory, dd_rescue fails with a floating point exception. # dd_rescue /dev/sda /dev/sdc -b 1G -A dd_rescue: (info): ipos: 0.0k, opos: 0.0k, xferd: 0.0k errs: 0, errxfer: 0.0k, succxfer: 0.0k +curr.rate: 0kB/s, avg.rate: 0kB/s, avg.load: 0.0% Floating point exception # tail /var/log/messages Mar 9 16:03:11 tindog smartd[32275]: Device: /dev/sda [SAT], 1 Currently unreadable (pending) sectors Mar 9 16:03:11 tindog smartd[32275]: Device: /dev/sda [SAT], 1 Offline uncorrectable sectors Mar 9 16:03:11 tindog smartd[32275]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 66 to 65 Mar 9 16:03:11 tindog smartd[32275]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 109 to 108 Mar 9 16:14:13 tindog kernel: dd_rescue[26757] trap divide error ip:402918 sp:7fff5787c640 error:0 in dd_rescue[400000+6000] Mar 9 16:16:35 tindog kernel: dd_rescue[26855] trap divide error ip:402918 sp:7fff64f3d720 error:0 in dd_rescue[400000+6000] Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror

Please note, never use noerror without also using sync. -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-03-09 at 23:26 -0400, Greg Freemyer wrote:

...

dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror

Please note, never use noerror without also using sync.

Why? I'm curious. I can make a guess, but I'm not sure, it is not mentioned in the manual: noerror continue after read errors sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs Do you mean, that without "sync", the output would just skip the remaining bytes of a block after an error, meaning the output would simply be "smaller", with pieces missing? Because, as Sid did an 'xfs_repair' on the result, it means either there was no error, or that the gaps were filled :-? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm15wMACgkQtTMYHG2NR9WBSwCdFrwL0udyMZWf51d73LPDsR51 MjgAniyEViB6Jgm9nCCxuX8Vt+T65IPF =cuMo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: On Tuesday, 2009-03-10 at 06:45 -0400, Greg Freemyer wrote:

On Tue, Mar 10, 2009 at 12:05 AM, Carlos E. R.

...

On Monday, 2009-03-09 at 23:26 -0400, Greg Freemyer wrote:

...

...

dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror

Please note, never use noerror without also using sync.

Why? I'm curious. I can make a guess, but I'm not sure, it is not mentioned in the manual:

...

Look at the output of a dd run.

dd if=/dev/zero of=/dev/null count=100 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.000172439 s, 297 MB/s

The first 100 says 100 blocks read without error. the first zero is 0 failed blocks failed to read.

The second 100 is the blocks written without error, and the second 0 is the failed block writes.

Aha, ok...

If you don't use sync and there are 2 errors I believe you get:

98+2 records in 98+0 records out.

i.e The failed blocks are not replicated in the destination at all

I see... I don't know how to confirm this, though. It could be: 98+2 records out instead. :-? I wonder why they don't document this in the manual.

With sync, you get: 98+2 records in 100+0 records out.

I suppose it is too late to know what Sid got.

I'm not sure what the exact output block has in it but at least part of it is zero filled. I always use a 4k block size to align my userspace behavior with the kernels normal page size.

Yes, that part is clear. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm2cI4ACgkQtTMYHG2NR9Vh6QCeNOtGS+BCdEgYH9QMrcCCzzzz pcEAniIP8WQINsiMoTc8nbxkvDY4P3el =QSM5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Greg Freemyer wrote:

On Tue, Mar 10, 2009 at 9:52 AM, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Content-ID:

On Tuesday, 2009-03-10 at 06:45 -0400, Greg Freemyer wrote:

...

On Tue, Mar 10, 2009 at 12:05 AM, Carlos E. R.

...

On Monday, 2009-03-09 at 23:26 -0400, Greg Freemyer wrote:

...

...

dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror Please note, never use noerror without also using sync. Why? I'm curious. I can make a guess, but I'm not sure, it is not mentioned in the manual: ...

...

Look at the output of a dd run.

dd if=/dev/zero of=/dev/null count=100 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.000172439 s, 297 MB/s

The first 100 says 100 blocks read without error. the first zero is 0 failed blocks failed to read.

The second 100 is the blocks written without error, and the second 0 is the failed block writes. Aha, ok...

...

If you don't use sync and there are 2 errors I believe you get:

98+2 records in 98+0 records out.

i.e The failed blocks are not replicated in the destination at all I see... I don't know how to confirm this, though. It could be:

98+2 records out

instead. :-?

I wonder why they don't document this in the manual.

If you're really curious, hdparm can create and recover bad blocks on your media. (I think it needs a IDE/SATA hdd to work).

see hdparm --make-bad-sector and --repair-sector

When it creates them it uses a ATA diagnostic write to cause the per sector crc to be bad, then on read you get a media error.

(ie on disk sectors are bigger than 512 bytes. Part of the overhead is a crc used to verify the media has not failed.)

Not sure how it does the fix side, but you are not supposed to permanently loose the sector, thus it is more or less safe to test with.

I would use a drive that does not have critical data. And I assume hdparm will be counting sectors from the beginning of the drive, not the partition.

Greg

I can give that a try when I have the new drive booted. At the moment I'm waiting for a new motherboard and memory as there is a hardware problem, especially noticeable during a kernel build, make && make modules_install a number of times gets it built and it boots. Odd problems appear elsewhere also. kernel/cgroup.c:3242: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. make[1]: *** [kernel/cgroup.o] Error 1 make: *** [kernel] Error 2 make: *** Waiting for unfinished jobs.... CC mm/mmap.o CC mm/mprotect.o # zypper ref File size limit exceeded It also failed last night and ran clean later as did zypper dup. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Sid,

I can give that a try when I have the new drive booted. At the moment I'm waiting for a new motherboard and memory as there is a hardware problem, especially noticeable during a kernel build, make && make modules_install a number of times gets it built and it boots. Odd problems appear elsewhere also.

You have tried a new PSU (or a swap from another system) _before_ condemning the mobo...? My experience of faults like this is that the PSU is often the culprit (and cheap and easy to swap!) -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Sid Boyce wrote:

Richard (MQ) wrote:

...

Sid,

...

I can give that a try when I have the new drive booted. At the moment I'm waiting for a new motherboard and memory as there is a hardware problem, especially noticeable during a kernel build, make && make modules_install a number of times gets it built and it boots. Odd problems appear elsewhere also. You have tried a new PSU (or a swap from another system) _before_ condemning the mobo...?

My experience of faults like this is that the PSU is often the culprit (and cheap and easy to swap!)

The PSU was tested out on another box with similar hardware and extra cards. I have had a number of PSU's fail, some within a few months of new. An upgrade was on the cards anyway and all the bits including a 600W PSU were delivered 20 minutes ago. Regards Sid.

New PSU, same problem, so it's CPU/Mem/Motherboard hardware problem as suspected. I can play with those bits when I have the new bits installed. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. wrote:

On Tuesday, 2009-03-10 at 10:03 -0400, Greg Freemyer wrote:

...

...

If you're really curious, hdparm can create and recover bad blocks on your media. (I think it needs a IDE/SATA hdd to work).

...

see hdparm --make-bad-sector and --repair-sector

Interesting...

...

When it creates them it uses a ATA diagnostic write to cause the per sector crc to be bad, then on read you get a media error.

...

(ie on disk sectors are bigger than 512 bytes. Part of the overhead is a crc used to verify the media has not failed.)

...

Not sure how it does the fix side, but you are not supposed to permanently loose the sector, thus it is more or less safe to test with.

...

I would use a drive that does not have critical data. And I assume hdparm will be counting sectors from the beginning of the drive, not the partition.

I'm interested, but not so much as to try with a disk that is in actual use >:-)

I'll save this for possible future reference.

-- Cheers, Carlos E. R.

The manpage says DANGEROUS, so this is something to try when I'm absolutely sure I have everything on the new hard drive though I have vital stuff backed up to 3 other boxes. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. wrote:

On Monday, 2009-03-09 at 23:26 -0400, Greg Freemyer wrote:

...

...

dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror

...

Please note, never use noerror without also using sync.

Why? I'm curious. I can make a guess, but I'm not sure, it is not mentioned in the manual:

noerror continue after read errors

sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs

Do you mean, that without "sync", the output would just skip the remaining bytes of a block after an error, meaning the output would simply be "smaller", with pieces missing?

Because, as Sid did an 'xfs_repair' on the result, it means either there was no error, or that the gaps were filled :-?

-- Cheers, Carlos E. R.

May be sync would have fixed the errors, however "xfs_repair -L /dev/sdc1" needed to be run to remove the old journal and clean up the errors. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org