kernel panic with clonned disk

SkyTod · 2014-12-04 09:55:15

Hey,

I have an old hard drive with pretty old software for server needs and I decided to change hard drive. I bought new one. Ran the following:

dd if=/dev/sda of=/dev/sdb bs=512 conv=noerror,sync

Rebooted to load from sdb, GRUB loads without troubles, but got the kernel panic:

...
Mounting root filesystem
mount: error 6 mounting ext3
pivotroot: pivot_root(/sysroot./sysroot/initrd) failed: 2
umount /initrd/proc failed: 2
Freeing unsed kernel memory: 116k freed
Kernel panic: No init  found. Try passing init= option to kernel.

What's wrong with my dd?! What did I wrong?! What the different between these tow hard disks? Because my original hard drive loads well.

graysky · 2014-12-04 10:45:14

I wouldn't use dd myself. I recommend that you partition the new drive to your liking, then simply rsync over the old hdd to the new one. If you have multiple partitions to mirror, you can do them one at a time or if you have a more simplified setup in the new drive, simply mount them up and sync over as you see fit. Remember to update your bootloader if using a different layout or uuids as well as your fstab.

SkyTod · 2014-12-04 10:54:56

graysky wrote:

I wouldn't use dd myself.

Why? It's recommended way according to the wiki.

graysky wrote:

Remember to update your bootloader if using a different layout or uuids as well as your fstab.

See here:

This will clone the entire drive, including MBR (and therefore bootloader), all partitions, UUIDs, and data.

Is it a mistake in the article?

Last edited by SkyTod (2014-12-04 10:55:26)

graysky · 2014-12-04 11:29:54

The wiki recommends several things that I disagree with... My suggestion is just one way to do things. You have the freedom to select an alternative if you wish. As you have already done so, and ran into problems, I offered up an alternative. Do as you wish.

null · 2014-12-04 11:52:32

Was the sda drive mounted writable and was this the os you used for dd? - Try a live usb system with unmounted sda.

For the uuids: compare blkid output and fstab.

SkyTod · 2014-12-04 12:10:40

graysky wrote:

The wiki recommends several things that I disagree with... My suggestion is just one way to do things. You have the freedom to select an alternative if you wish. As you have already done so, and ran into problems, I offered up an alternative. Do as you wish.

Thank you for that, can you share some step-by-step manual?

null wrote:

Was the sda drive mounted writable and was this the os you used for dd? - Try a live usb system with unmounted sda.

First time I tried my archlinux, then my LiveCD (some minor linux build) with unmounted both sd* - the same result.

null wrote:

For the uuids: compare blkid output and fstab.

Do you mean /etc/fstab? How can I compare blkid?

SkyTod · 2014-12-04 13:46:42

Just checked. There are no /etc/blkid.tabs, no differences in fstabs.

null · 2014-12-04 23:02:45

The command blkid will give you a list of blockdevices and their uuid. Compare those to the uuids you've got in your /etc/fstab file. If this is still unclear post the output/content of the command/file.

SkyTod · 2014-12-05 09:47:25

null wrote:

The command blkid will give you a list of blockdevices and their uuid.

There is no blkid on my LiveCD, is there any other tools?

Spider.007 · 2014-12-05 12:39:09

blkid is provided by util-linux, you can install that on your livecd. Alternatively; simply execute ls /dev/disk/by-uuid/

SkyTod · 2014-12-05 12:58:52

Okay, my fstabs:

/dev/hda2               /                       ext3    defaults        1 1
/dev/hda1               /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /proc                   proc    defaults        0 0
/dev/hda5               swap                    swap    defaults        0 0
/dev/cdrom              /mnt/cdrom              udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0                /mnt/floppy             auto    noauto,owner,kudzu 0 0

ls /dev/disk/by-uuid/

/dev/disk/by-uuid/FEE0-AD1E

/dev/disk/by-uuid/9340cd5c-f738-11da-9b27-fbc3f2afcb6d

/dev/disk/by-uuid/2cfa08ec-f738-11da-8e32-bbd5b9627316

Last edited by SkyTod (2014-12-05 12:59:45)

Spider.007 · 2014-12-05 13:38:36

It seems re-running grub-install on the new disk might fix this (you can do this from the livecd). I'd also re-run `mkinitcpio`

Last edited by Spider.007 (2014-12-05 13:39:53)

null · 2014-12-05 13:42:08

Yeah. You should replace the /dev/hda* entries with the uuid of the corresponding device. If you ls -l /dev/disk/by-uuid it should also show which uuid belongs to the harddrives (it's just a link in the folder).
The entries have to look like:

UUID="UUID of your root device"             /                       ext3    defaults        1 1

https://wiki.archlinux.org/index.php/Fstab#UUIDs

SkyTod · 2014-12-05 14:09:15

My fdisk -l:

Disk /dev/sda: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x08820881

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           6       48163+  83  Linux
/dev/sda2   *           7        1281    10241437+  83  Linux
/dev/sda3            1282        1330      393592+   f  W95 Ext'd (LBA)
/dev/sda5            1282        1330      393561   82  Linux swap / Solaris

Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x08820881

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1           6       48163+  83  Linux
/dev/sdb2   *           7        1281    10241437+  83  Linux
/dev/sdb3            1282        1330      393592+   f  W95 Ext'd (LBA)
/dev/sdb5            1282        1330      393561   82  Linux swap / Solaris

Disk /dev/sdc: 4016 MB, 4016046080 bytes
255 heads, 63 sectors/track, 488 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00681f73

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1         489     3921888+   c  W95 FAT32 (LBA)
Partition 1 has different physical/logical endings:
     phys=(487, 254, 63) logical=(488, 65, 25)

and my ls -l /dev/disk/by-uuid:

total 0
lrwxrwxrwx 1 root root 10 2014-12-05 14:44 2cfa08ec-f738-11da-8e32-bbd5b9627316 -> ../../sda2
lrwxrwxrwx 1 root root 10 2014-12-05 14:44 9340cd5c-f738-11da-9b27-fbc3f2afcb6d -> ../../sda1
lrwxrwxrwx 1 root root 10 2014-12-05 14:42 FEE0-AD1E -> ../../sdc1

There is no sdb*, so it's a problem, yeah?

Spider.007 · 2014-12-05 15:01:41

If you still have the original disk in your system you obviously have a conflict; since the UUID is the same for both disks. Do you want to keep the original (40G) drive? Because otherwise I'd temporarily disconnect it

SkyTod · 2014-12-05 15:28:58

Spider.007 wrote:

since the UUID is the same for both disks.

Right, that's the reason. However I updated fstab with UUID= and it boots with kernel panic anyway. I don't really have a clue why it happens. Isn't it able to find ext3 driver?

Spider.007 · 2014-12-05 17:19:25

Did you:

Spider.007 wrote:

It seems re-running grub-install on the new disk might fix this (you can do this from the livecd). I'd also re-run `mkinitcpio`

? Also; I still think two disks are not gonna help your boot process so I'd disconnect the old disk.

SkyTod · 2014-12-05 18:00:27

Spider.007 wrote:

Did you:
Spider.007 wrote:
It seems re-running grub-install on the new disk might fix this (you can do this from the livecd). I'd also re-run `mkinitcpio`
? Also; I still think two disks are not gonna help your boot process so I'd disconnect the old disk.

I disconnected it of course. There is no way to run it because my LiveCD provides zsh, thus I can't chroot to my bash. :-/

graysky · 2014-12-05 18:59:05

If you give up, I recommend the rsync or tar method...

graysky wrote:

I wouldn't use dd myself. I recommend that you partition the new drive to your liking, then simply rsync over the old hdd to the new one. If you have multiple partitions to mirror, you can do them one at a time or if you have a more simplified setup in the new drive, simply mount them up and sync over as you see fit. Remember to update your bootloader if using a different layout or uuids as well as your fstab.

SkyTod · 2014-12-05 19:33:59

I never used rsync before and don't trust disk operations with unknown tools myself, is there accurate article somewhere?

graysky · 2014-12-05 19:40:18

You can find something in google I'll bet... use tar if you don't wanna try rsync.

Spider.007 · 2014-12-06 10:26:52

SkyTod wrote:

Spider.007 wrote:
Did you:
Spider.007 wrote:
It seems re-running grub-install on the new disk might fix this (you can do this from the livecd). I'd also re-run `mkinitcpio`
? Also; I still think two disks are not gonna help your boot process so I'd disconnect the old disk.
I disconnected it of course. There is no way to run it because my LiveCD provides zsh, thus I can't chroot to my bash. :-/

Why don't you use the arch-iso; it provides arch-chroot which works even better? And I've never heard of zsh not being able to chroot, I'm pretty sure that should work just fine. Are you running chroot $DIR instead of chroot $DIR /bin/bash?

ANOKNUSA · 2014-12-06 14:10:04

Spider.0007 wrote:

There is no way to run it because my LiveCD provides zsh, thus I can't chroot to my bash. :-/

I get the feeling the OP has some aliases and/or plugins they've become dependent on. arch-chroot defaults to bash in sh-compatibility mode; one can always just run bash inside the chroot.

SkyTod wrote:

I never used rsync before and don't trust disk operations with unknown tools myself, is there accurate article somewhere?

rsync won't destroy data (unless you explicitly tell it to), won't alter any disk or partition information (like a UUID) and there's plenty of easy-to-find and easy-to-understand info about it. It's been widely used for nearly twenty years.

Arch Linux

#1 2014-12-04 09:55:15

kernel panic with clonned disk

#2 2014-12-04 10:45:14

Re: kernel panic with clonned disk

#3 2014-12-04 10:54:56

Re: kernel panic with clonned disk

#4 2014-12-04 11:29:54

Re: kernel panic with clonned disk

#5 2014-12-04 11:52:32

Re: kernel panic with clonned disk

#6 2014-12-04 12:10:40

Re: kernel panic with clonned disk

#7 2014-12-04 13:46:42

Re: kernel panic with clonned disk

#8 2014-12-04 23:02:45

Re: kernel panic with clonned disk

#9 2014-12-05 09:47:25

Re: kernel panic with clonned disk

#10 2014-12-05 12:39:09

Re: kernel panic with clonned disk

#11 2014-12-05 12:58:52

Re: kernel panic with clonned disk

#12 2014-12-05 13:38:36

Re: kernel panic with clonned disk

#13 2014-12-05 13:42:08

Re: kernel panic with clonned disk

#14 2014-12-05 14:09:15

Re: kernel panic with clonned disk

#15 2014-12-05 15:01:41

Re: kernel panic with clonned disk

#16 2014-12-05 15:28:58

Re: kernel panic with clonned disk

#17 2014-12-05 17:19:25

Re: kernel panic with clonned disk

#18 2014-12-05 18:00:27

Re: kernel panic with clonned disk

#19 2014-12-05 18:59:05

Re: kernel panic with clonned disk

#20 2014-12-05 19:33:59

Re: kernel panic with clonned disk

#21 2014-12-05 19:40:18

Re: kernel panic with clonned disk

#22 2014-12-06 10:26:52

Re: kernel panic with clonned disk

#23 2014-12-06 14:10:04

Re: kernel panic with clonned disk

Board footer