Hello,
I've been trying to clone an existing debian-testing install on a new laptop, using the following guide: https://dev.to/nikvdp/how-to-easily-clo ... chine-2pbl
After completing the instructions and updating /etc/fstab to match the new UUIDs, I started the computer, the GRUB screen looked fine, but during initialisation I first got the following error:
mdadm: cannot find arrays or config... (can't exactly remember the exact message..)
Then I tried to repair the boot from chroot with update-initramfs, grub-install and update-grub, but it got worse. Now I get:
fsck: fsck.vfat not found; ignore /dev/sda1
mount: mounting /dev/sda1 on /root failed: No such device
Failed to mount /dev/sda1 as root file system.
And I get the (initramfs) prompt.
Somehow, it seems like it tries to boot on sda1 which is my efi partition, instead of sda2 which is root. So far, I have tried to:
-Repair the boot using update-initramfs -u, install-grub /dev/sda and grub-update, both from a debian-live usb using bind mount and chroot, and from rescue mode (rescue/enable=true) with a root shell. No errors when executing the scripts, but it doesn't solve the problem.
-Type 'root=/dev/sda2', then 'exit' in the initramfs prompt. Doesn't work the first time, causes kernel panic when I try again.
-In /etc/fstab, replace UUIDs with corresponding "/dev/sdX", then relaunch update-initramfs etc. Still the same result.
What bothers me is that the Grub config looks alright. Right UUIDs (checked with blkid), right (hdX,gptX), etc. So I'm suspecting that update-initramfs does something weird, somehow flags /dev/sda1 as root on the image, which screws the boot process (since it is the command that got me there in the first place...) ?
Does someone have any idea how to solve this mess ?
thanks
[Solved] Cannot boot after cloning install on a new laptop: tries to mount wrong partition
-
- Posts: 2
- Joined: 2024-08-02 20:59
- Has thanked: 1 time
[Solved] Cannot boot after cloning install on a new laptop: tries to mount wrong partition
Last edited by petroblues on 2024-08-02 23:56, edited 1 time in total.
-
- Debian Developer
- Posts: 624
- Joined: 2022-07-12 14:10
- Has thanked: 2 times
- Been thanked: 125 times
Re: Cannot boot after cloning install on a new laptop: tries to mount wrong partition
I would use force update-initramfs to generate a completely new initramfs. Also, inspect the generated initramfs with unmkinitramfs and search for references to your old drive.
Btw, using "tar" to copy files like that won't preserve file ACLs. If you compare the output of with the original and the supposed "clone" you can see that you have lost file permissions.
Btw, using "tar" to copy files like that won't preserve file ACLs. If you compare the output of
Code: Select all
getfacl /var/log/journal/
-
- Posts: 2
- Joined: 2024-08-02 20:59
- Has thanked: 1 time
Re: Cannot boot after cloning install on a new laptop: tries to mount wrong partition
Thanks for the tips ! I did try to recreate a new initramfs with update-initramfs -dk all, then update-initramfs -c but it didn't work either. I'll keep in mind the unmkinitramfs command though, I didn't know you could inspect the initramfs.
Finally I solved it by reformatting the drive, re-partitioning and re-extracting the whole archives, updating etc.fstab, grub-install and upgrade-grub (and NO update-initramfs) and somehow it worked this time !
Just had to reinstall lightdm which was causing problem at startup.
About the ACLs, the getfacl command you suggested did produce similar results on both computers. I guess that ACLs compatibility was added to TAR at some point. Only quirk noticed so far is mandb throwing some permission errors relative to var/cache during apt installs, but otherwise everything seems to work.
Finally I solved it by reformatting the drive, re-partitioning and re-extracting the whole archives, updating etc.fstab, grub-install and upgrade-grub (and NO update-initramfs) and somehow it worked this time !
Just had to reinstall lightdm which was causing problem at startup.
About the ACLs, the getfacl command you suggested did produce similar results on both computers. I guess that ACLs compatibility was added to TAR at some point. Only quirk noticed so far is mandb throwing some permission errors relative to var/cache during apt installs, but otherwise everything seems to work.