The source HDD is a 750G drive with 512B logical and physical sectors. The target HDD is also 750G but has 512B logical sectors but 4096B physical sectors. I want to do a full cloning and tried it with GNU ddrescue. The session ran and didn’t indicate any errors, but the target drive isn’t bootable. The assumption is the difference in the size of the physical sectors ruined the clone attempt.
The cloning is to move everything off an old, failing HDD to a fresh, ready for infant mortality drive.
The reason for that may be a different one than that the data wasn’t copied 1:1.
Booting from drives with a physical sector size of 4096 Bytes may not be possible on any PC (especially if it’s an older one).
Further you should tell a bit more about the way you tried to boot from the new drive (i.e. the one with the physical sector size of 4096 Bytes).
Did you, for example, unplug the old drive and replace it whith the new drive during boot ?
How did you mount partitions from your old drive ?
I meant:
Using e.g. the partitioner of YaST you can set fstab options for how to mount a partition/drive,
e.g. by
If the respective entry isn’t the same for your new drive,
then this would explain your problem.
The more I read about 4Kn or Advanced Format drives, the more I wonder if the Hitachi’s logical/physical 512B/512B layout vs the WD’s 512B/4096B layout is, in fact, a problem. That is, it appears the WD’s firmware makes it appear, to the world beyond the drive, that this is still a 512B-sized device. As far as I can see, the real problem is getting a partition started at the correct place (a cylinder number evenly divisible by 8 - e.g., cylinder 64) - performance suffers as a result of poor placement.
Or maybe it really does matter after all?
Yes, 4k may be a problem.
On the other hand, am I writing chinese ?
Please post the contents of your /etc/fstab of your old failing hard disk !
Or perhaps the contents of the copy of that from your new clone of that.
The contents of my /etc/fstab are
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part6 / ext3 acl,user_xattr 1 1
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part5 swap swap defaults 0 0
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part8 /home ext3 acl,user_xattr 1 2
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part9 /home121 ext3 user,noauto,acl,user_xattr 0 0
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part7 /sys121 ext3 noauto,acl,user_xattr 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part3 /windows/C ntfs-3g ro,noauto,users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part4 /windows/D ntfs-3g locale=de_DE.UTF-8 0 0
/dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN3220F33TJJDE-part1 /windows/reserviert ntfs-3g ro,noauto,users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
It’s a little chewed up, but here’s /etc/fstab
/dev/system/swap swap swap defaults 0 0
/dev/system/root / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-Hitachi_HDS721075CLA332_JP2740HP04Y2NH-part1 /boot ext4 acl,user_xattr 1 2
/dev/system/home /home ext4 acl,user_xattr 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/disk/by-id/ata-WDC_WD7500BPKX-22HPJT0_WD-WX41A93N7736-part1 /tmp ext4 acl,user_xattr 1 2
The real stunner in all of this is the last line. Why, why, why does a non-existant device show up as providing a home for /tmp???
What does it take to put the real location for /tmp (on the Hitachi drive) in the fstab? Unless I miss my guess (and my batting average on guesses is abysmal), this is what keeps the original system on the Hitach drive from booting up completely.
The Hitachi drive contents are relatively old. That is, they were generated when 12.1 was fresh. The layout was done by the installer. I don’t recall any particular input into the partitioning process. I just sat back and watched the process happen.
The new (target or WD) drive was basically taken back to zero. That is, all partitions were deleted. Anything that’s on the new drive came from ddrescue’s cloning of the old (source or Hitachi) drive.
Just to be on the same page the boot start it just never complete right??
Are you sure you are looking at the drive file and not the cd/dvd file?
You need to mount the root partition from the drive then look at the /et/fstab on that partition
You will need to edit that file any way to point to the new device
Also I think you need to do a chroot and remake grub and perhaps do an initd
The device names have changed and you have to adjust for that.
If you can see and mount the partitions then the clone probably worked
Right - it gets through the process for a couple of minutes and then stops, leaving the machine in emergency mode.
Are you sure you are looking at the drive file and not the cd/dvd file?
The only physical HDD of any sort present is the old, source Hitachi HDD. No sticks, no CD’s, no DVD’s, no net boots, just the one HDD.
You need to mount the root partition from the drive then look at the /et/fstab on that partition
Yep. Got there. See post #6 above.
You will need to edit that file any way to point to the new device
If the startup log is to be believed, I need to take the new device (seen in the last line of the fstab from the old device) out of the fstab.
Also I think you need to do a chroot and remake grub and perhaps do an initd
Perhaps on the new, target drive.
WAIT! NEWS FLASH!
Thanks to the above questions, I ran dmesg, with the idea of capturing all the info from the startup. My next thought was to pipe the output to a temporary file, trim it down with emacs, and write it to a stick, and post that stuff here. Hmmm… temporary file… hmmm… speaking of temporary files, I wonder what happens when I do “dir /tmp”?
In fact, /dev/sda’s (the old Hitachi HDD) /tmp exists and the directory is easily listed. Which says /dev/sda has a functional tmp directory tree.
The problem is a very simple one: /dev/sda’s /etc/fstab is broken. It wants to mount the /tmp tree from a drive that doesn’t exist! Going through /etc/fstab again:
/dev/system/swap swap swap defaults 0 0
/dev/system/root / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-Hitachi_HDS721075CLA332_JP2740HP04Y2NH-part1 /boot ext4 acl,user_xattr 1 2
/dev/system/home /home ext4 acl,user_xattr 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/disk/by-id/ata-WDC_WD7500BPKX-22HPJT0_WD-WX41A93N7736-part1 /tmp ext4 acl,user_xattr 1 2
This line:/dev/disk/by-id/ata-WDC_WD7500BPKX-22HPJT0_WD-WX41A93N7736-part1 /tmp ext4 acl,user_xattr 1 2 should be changed to mount the /tmp on the Hitachi HDD. Remember that, at the moment, the WD HDD does not exist. It is physically disconnected from the desktop box.
The device names have changed and you have to adjust for that.
If you can see and mount the partitions then the clone probably worked
I see that vaguely. First off, I need to address the issue listed above. The best place to follow that up is the Need to fix broken LVM2 volume thread.
Once that’s done, I’ll address the business of cloning the two “same but different” drives with their same size and different physical sector sizes.
On 2014-01-23 04:46, RBEmerson wrote:
>
> gogalthorp;2618639 Wrote:
>> You will need to edit that file any way to point to the new device
> If the startup log is to be believed, I need to take the new device
> (seen in the last line of the fstab_from_the-old-device) out of the
> fstab.
Correct.
I can not imagine how that line got there.
>
>> Also I think you need to do a chroot and remake grub and perhaps do an
>> initd
> Perhaps on the new, target drive.
Yes.
> WAIT! NEWS FLASH!
> The problem is a very simple one: /dev/sda’s /etc/fstab is broken. It
> wants to mount the /tmp tree from a drive that doesn’t exist! Going
> through /etc/fstab again:
Right.
> This
> line:-/dev/disk/by-id/ata-WDC_WD7500BPKX-22HPJT0_WD-WX41A93N7736-part1
> /tmp ext4 acl,user_xattr 1 2- should be
> changed to mount the /tmp on the Hitachi HDD. Remember that, at the
> moment, the_WD_HDD_does_not_exist. It is physically disconnected from
> the desktop box.
Right.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
At this point, I think it’s best to deal with the fstab issue in the Need to fix… thread. There’s no question the Hitachi HDD’s fstab is broken. I need (make that have) to know how to correct the problem, so I can at least use the source HDD again.
I have a hazy idea about how this happened (tied to filling the source HDD with a file in /tmp, and having a clone of the filesystem, while it’s active on the source, on the target HDD) but, for now, it’s mostly a good topic for discussion with tapas and wine… [/grin]
In an effort to hold off topic drift, here is the statement leading to the question I’d like answered:
How do I clone the source drive on the target drive when their logical block sizes are the same, but their physical block sizes are 512B and 4096B (source, target HDD’s)?
Tricky 
If the drive is 512/4K then it should be ok the drive should look to the system as 512 but that actually block is 4K the drive handles the differences.
But assming 4K/4k then AFAIK you have to do a file by file copy (ie cp or rsync) rather than a clone.
On 2014-01-23 19:06, gogalthorp wrote:
>
> Tricky
>
> If the drive is 512/4K then it should be ok the drive should look to the
> system as 512 but that actually block is 4K the drive handles the
> differences.
>
> But assming 4K/4k then AFAIK you have to do a file by file copy (ie cp
> or rsync) rather than a clone.
Yes, I said that at some point. A byte by byte clone from a 0.5KiB block
disk to another with 4KiB block (an image) is not possible, AFAIK.
Instead one has to create target partitions and copy files. Later one
has to install grub. Ah, and edit fstab and grub config files. Ah, plus
recreate initrd. Anything else I forget?
However, is it possible to do a byte by byte clone if the target is, as
in this case, 0.5KiB logical and 4KiB physical blocks (hybrid)? Should
it work? :-?
Would clonezilla cope properly with this case? :-?
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Hi RBEmerson,
[quote="“RBEmerson,post:12,topic:97468”]
In an effort to hold off topic drift, here is the statement leading to the question I’d like answered:
How do I clone the source drive on the target drive when their logical block sizes are the same, but their physical block sizes are 512B and 4096B (source, target HDD’s)?[/QUOTE]
hey, slowly, point by point.
This isn’t the call center of some hardware or maybe software company,
and it isn’t even sure that you’re always told the truth there.
Your question about 512 Bytes vs. 4096 Bytes sector size isn’t that easy.
4096 Bytes as sector size are quite new, and there probably are only few who really gathered much experience with that.
On the other hand, I thought that you already made a clone of your failing hard disk !
See your first post (which you just cited):
From your above postings it appears that your /etc/fstab probably is broken on the original (failing) hard disk already
(if it was the /etc/fstab from the right device).
So for the clone, it will - and must - be broken just the same.
Just having made a clone copy apparently,
you don’t seem to have to loose that much, except for the clone of your failing disk
(which already is something, if there’s important data on it, which you should backup on other devices).
A first - important - test of your clone would be:
Unplug your failing Hitachi disk, plug your WD disk with the clone instead,
boot from a Linux live system, as gparted, Parted Magic, openSUSE live, or whatever,
and see if the partition(s) on the clone are seen by the respective partitionning tools
(like gparted, this one runs from the command line).
Good luck
Mike
I meant `parted’, parted can be called from the command line.
only quickly skimmed through the thread (and while I risk injecting unnecessary noise), my top of the head thoughts are: reinstall grub (stage 1 sector info is hard coded) and UUID info in the grub.cfg will need to be updated.
Taking a few messages in, I hope, chronological order…
The source (AKA Hitachi) HDD is definitely a 512/512 device. The target (AKA WD) HDD is definitely 512/4096. It’s my understanding the WD firmware handles the business of making the 4096 seem to be a 512 device when it’s needed (to be backwards compatible?).
I think the key here is whether both HDD’s appear to be logical 512B devices, regardless of the physical size. Assuming the WD firmware does what I want to happen, the difference in physical sizes becomes moot. It’s the difference between what I want and what really happens that’s at issue. [/smile]
That 512/4096 drives are something new - got that.
ddrescue didn’t list any errors. AFAIK, that only means that ddrescue didn’t receive any signs of problems from the source or target HDD’s. I have no idea how ddrescue verifies its work. I hope that it does, but this is all new stuff to me. Which is why I’m asking for experienced help.
After doing the cloning, I disconnected the source drive and I tried to boot up the target drive. BIOS didn’t even see anything to boot from. It did see the HDD among the list of devices connected to the system, but as a device that could be booted? Nothing.
IIRC, using a live system (on a DVD), I tried to look at the target HDD and found two partitions. 70Mb (for /boot?) and a 690+Gb LVM2 partition. I do not know a way to look inside the LVM system to find out if the data inside is accessible or readable.
There may very well be a process that takes whatever was written to the target HDD and renders the disk bootable. I assumed that cloning would bring across to the target HDD whatever made the source drive bootable. Clearly that assumption is wrong.
To reiterate the two key questions: can I clone two 750G drives, where one has 512/512 sectors and the other has 512/4096 sectors? And, if the cloning does work, what do I need to do to make the target HDD bootable?