[opensuse-factory] cloning a hard drive with YaST
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. I've tried rsync, that didn't do it properly. 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/. YaST in 11.2 Alpha0 doesn't now have an entry for cloning a system that I can identify. What's recommended? 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
Gentle readers, 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. Before the kernel update, both systems worked flawlessly on the video side. 1st. System: Manufacturer: Hewlett-Packard Product Name: HP Compaq dc5750 Microtower 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200] 01:05.1 Display controller: ATI Technologies Inc Radeon Xpress Series (RS482) used at work 2nd. System: Asrock K7S41GX Radeon 9550 used at home In both situations, the display blacked out, but the system remained responsive - I could login remotely and issue a reboot sequence. Both systems got the kernel modules built fresh from scratch. Since kernel 2.6.27.19-3.2-default or kernel 2.6.27.19-3.2-pae is planned for SLES 11, it would be great, if it were compatible... Yours sincerely Christoph-Erdmann Pfeiler -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- 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 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
2009/3/9 Christoph-Erdmann Pfeiler <Christoph-Erdmann.Pfeiler@gmx.de>:
Gentle readers,
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.
Before the kernel update, both systems worked flawlessly on the video side.
1st. System: Manufacturer: Hewlett-Packard Product Name: HP Compaq dc5750 Microtower
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200] 01:05.1 Display controller: ATI Technologies Inc Radeon Xpress Series (RS482)
In the last driver version the X200 do'nt appear supported: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/catalyst_9...
used at work
2nd. System: Asrock K7S41GX Radeon 9550
used at home
You can download the latest driver from: http://support.amd.com/la/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.37&lang=English I'm using the 9.2 beta version, and with opensuse 11.1 kernel 2.6.27.19-3.2-pae, with my Radeon HD4670, it works fine. Regards -- 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 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm1AHkACgkQtTMYHG2NR9VX5wCdEvs2YwFKccZjBhjGe8JkVrwd GhsAn0thxZwDSM05Qi0fR2kbKOd9KWs5 =5tzB -----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. pecked at the keyboard and 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.
I agree that rsync is the better way to go. I also agree that /etc/fstab will need to be adjusted manually. Also make sure you set the proper partition bootable. Another copy method you could try is dd. -- Ken Schneider SuSe since Version 5.2, June 1998 -- 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
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 -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
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
Sid Boyce wrote:
Peter Poeml 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
On Mon, Mar 09, 2009 at 01:35:19PM +0000, Sid Boyce wrote: 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
This worked:- dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror When dd completed, I did "xfs_admin -U generate /dev/sdc1" to change the uuid, then xfs_repair and I can now mount /dev/sdc1. Altered /etc/fstab and /boot/grub/menu.lst. Hoping to boot up on it tomorrow - may be some grub work still needed. Ordered new hardware to fix the floating point exception problem. 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
Greg Freemyer wrote:
dd if=/dev/sda of=/dev/sdc bs=1G conv=noerror
Please note, never use noerror without also using sync.
That I didn't know. I shall see what happens in the current state. 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
-----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
On Tue, Mar 10, 2009 at 12:05 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----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 :-?
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. 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 With sync, you get: 98+2 records in 100+0 records out. 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. Greg
- -- 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
-- 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 Content-ID: <alpine.LSU.2.00.0903101448121.9084@nimrodel.valinor> 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
On Tue, Mar 10, 2009 at 9:52 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.00.0903101448121.9084@nimrodel.valinor>
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 -- 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
Greg Freemyer wrote:
On Tue, Mar 10, 2009 at 9:52 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.00.0903101448121.9084@nimrodel.valinor>
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
The best method for recovering your drive image, I know of, is dd_rhelp from the ddrescue package. It is a script which uses dd_rescue to recover as much data as possible, I have even recovered working images from bad video dvds using it. Go to (if you have ddrescue installed of course) file:///usr/share/doc/packages/ddrescue/README.dd_rhelp for a detailed explanation of how it works. Regards Dave P -- 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
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. -- 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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm3plsACgkQtTMYHG2NR9WHMACffQOdIPkCPylGrp1vRXQ5lyLx cUgAniBh9LzQR6qrvv5/3oDwvbz9auzi =Mpi2 -----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 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:
Content-ID: <alpine.LSU.2.00.0903101448121.9084@nimrodel.valinor>
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. I can't remember what exactly I got, just that rsync failed somewhere during the process. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-03-10 at 11:29 -0000, Sid Boyce wrote:
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.
I believe an error of the kind we are thinking would make the output completely useless, not repairable. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm2bxAACgkQtTMYHG2NR9UC8ACeNilZAK9FOMyLdU5EWjarjNB2 VyMAnR0alslGsZXPNj08mTHEM7a82GUJ =U9pI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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. I've tried rsync, that didn't do it properly. 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/. YaST in 11.2 Alpha0 doesn't now have an entry for cloning a system that I can identify. What's recommended? Regards Sid.
I normally copy, or clone, if you like, a disk like this: 1. Boot from a Live openSUSE 2. Check to make sure which is which! 3. For example cp /dev/sda /dev/sdb The whole device will be cloned, MBR, partition table, partitions, all data on them, just everything. If the target is bigger, there will be free unpartitioned space in the end of it. You may do what ever you like with it a bit later. Now, the clone will have an exact copy of the original disk's fstab, too. As you are using disk IDs there, they need to changed. While you are running the live system , open YaST > System > Partitioner Make mount points like newdisk and olddisk and mount the disks to those. Now the live system will have its fstab where the old disk as well as the new disk will have their own IDs. Take the new disk's ID from the Live system's fstab, and correct that to the one that is on the actual disk. (The one on the new disk has the old disk's ID, since it's a copy of the old disk's one, this needs to be changed.) Also correct the /boot/grub/menu.lst on the new disk with the new ID And the /boot/grub/device.map. Now you should be back in business. Vahis -- http://waxborg.servepics.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (10)
-
Carlos E. R. -
Christoph-Erdmann Pfeiler -
Dave Plater -
Greg Freemyer -
Juan Erbes -
Ken Schneider - openSUSE -
Peter Poeml -
Richard (MQ) -
Sid Boyce -
Vahis