Luks/Lvm after dd duplication
Using the simplest dd command I duplicated my HDD (with combined Luks/Lvm encryption) to another one with the same capacity but from another maker.
Now I cannot reach a password prompt while booting from this new HDD.
It is connected via SATA/USB converter.
First three modules - mbcache, jbd, ext3 from initrd are loaded but there is error saying that:
mounting /dev/cryptvg/root on /mnt failed: No such file or directory....
At this point there is simple shell available but I cannot properly use fdisk nor cryptsetup - both cannot see any /dev/sda* device.
How can I fix that ?
Booting from pendrive with latest Slackware gives me possibility to enter my Luks password to this HDD and chroot later to the real data on it.
Reissuing mkinitrd with lilo after chrooting does not help as I thought it would.
What else could be broken during dd copying ?
When you boot with pendrive, to which device is your new HDD attached: /dev/sda1 or another?
It could be that your HDD is not recognized as the same /dev/sd* as your previous HDD was recognised.
Pendrive gets /dev/sdb1 and /dev/sdb2.
When booting from this HDD itself there are no /dev/sda* nor /dev/sdb* devices assigned at all.
Seems like mkinitrd issued from this new HDD (exactly the same long command that worked on older HDD) lacks something vital. Lilo, of course, was executed too.
Maybe some modules at start-up are not loaded ?
1. When booted FROM SLACKWARE PENDRIVE, fdisk gives me this info about NEW HDD:
/dev/sda1 * 1 1111 8924076 83 Linux
/dev/sda3 * 1 30401 235271925 83 Linux
what is the about same as OLD HDD booting properly.
It is connected via Sata/Usb interface only because there's no way to connect it directly - it cannot fit into the slot designed for 9mm thick discs as it has "weird" 12mm.
One curiosity - invoking fdisk at 1st time gives me en error stating there's no /dev/sda* devices. Running fdisk 2nd time seconds later seems working well with proper device recognition.
2. When booted from NEW HDD itself there's no devices /dev/sda* assigned at all. From shell I can invoke fdisk or cryptsetup, but without devices no further progress can be made. Quite opposite to OLD HDD proper booting action :-(
Seems like simple dd disc copying did not duplicate all functionality with regard to booting/Luks/Lvm behaviour.
NEW HDD = Fujitsu 250GB, OLD HDD = Samsung 250GB.
I'm assuming /dev/sda1 would be your /boot partition.
As I requested in my previous post, please post /etc/fstab because according to the error message, it seems that the boot process wants to mount your root partition to /mnt.
It will also not hurt if you post the content of /etc/lilo.conf so that we have a full picture of how the boot process should happen.
/dev/cryptvg/swap swap swap defaults 0 0
/dev/cryptvg/root / ext3 defaults 1 1
/dev/cryptvg/home /home ext3 defaults 1 2
/dev/sda1 /boot ext3 defaults 1 2
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
# LILO configuration file
# generated by 'liloconfig'
# Start LILO global section
boot = /dev/sda
timeout = 50
# VESA framebuffer console @ 1024x768x256
vga = 773
# Linux bootable partition config begins
image = /boot/vmlinuz
initrd = /boot/initrd.gz
root = /dev/cryptvg/root
label = Linux
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
Your configuration files look OK to me.
Also to check further, is there a way for you to get the log of the boot process (ex: dmesg) so you can post it.
Another idea because you have a SATA/USB interface:
Maybe some kernel modules (ex: USB) are not loaded by the initrd.gz image file during the boot.
You can check that idea by trying to boot with a huge kernel on your new HDD. If it works, then you need to identify which modules need to be loaded (for ex, by comparing 'lsmod' results when booting with error and when booting with pendrive) and rebuild the initrd.gz image accordingly.
I appreciate that it is very unlikely, but it is possible to boot with the Huge Kernel?
Your idea seems to be right so I must identify proper lacking module.
Or to try huge kernel.
At first I must check all readmes/howtos from Pat.
Maybe the doors are already open :-) ?
|All times are GMT -5. The time now is 11:58 PM.|