1

I have a few disks on my a server (for RAID) and a few boot partitions to test various distros. At some time I had a recent (10 buster) Debian 32 bit and a recent (10 buster) Debian 64 bits, and for some reasons, I decided to move the Debian 64 bits to a lower partition (with dd, setting up a new UUID and updating it in that partition's /etc/fstab), and then I installed a recent (20.1 Ulyssa) Linux Mint Cinnamon on the partition where Debian I moved was before. I didn't expect it to pose problems, because installing Linux Mint would run update-grub and take my new but partition for Debian 64, however, at that time, my Debian 64 bits stopped working. Indicating it couldn't find the root partition.

There are a few comments to do about that: the Debian installation process is quite nice in warning me that there might be non UEFI partitions which might not work any-more if I try to install grub in UEFI mode (and proposes to start in BIOS compatibility mode) -) which Mint doesn't seem to care much about. and so mint configured my grub in UEFI mode. However, the strange thing is that it stopped my Debian 64 from working, but not my Debian 32.

I must admit that the grub process has never been clear to me, but what I don't understand, is that trying to re-install and update grub from my Debian 32 didn't solve the problem, and trying to find a file with the failing UUID, in /etc & /boot (including subdirectories), on both partitions (Debian 32 & 64). Finally i solved the problem by editing the grub command line of my Debian 64 at boot, and then, by reinstalling and updating grub from my Debian 64.

However, what I really would like to understand, is where this UUID was stored (why i couldn't find it), and why I couldn't solve this problem from my Debian 32 partition.

EDIT: To make myself clear: I was able to boot by replacing the root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx by root=/dev/sdxx by editing the kernel parameters during from the grub menu during boot and initrd was NOT modified in the subsequent grub restoration process. However, I wasn't able to find this UUID value (neither xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx nor xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx), in any uncompressed file in /etc & /boot.

EDIT2: Ok... What I was looking for was in /boot/grub/grub.cfg (thanks to Archemar), but I didn't find it because I fumbled my regular expression in the search in

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e' 

grep regexps don't recognise ?. I should have used {0,1} instead... :'(

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e' 

However, it doen't explain why it didn't work when I reinstalled and reconfigured grub from my debian 32 partition. would by chance the recognition of other linux partitions, be based on parsing the /boot/grub/grub.cfg in those partitions ??? :-o

2
  • Arg, shame on me : I fumbled my regular expression in the search in find /boot /etc -type f -print0 | xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e' (grep regexps don't recognise ?. I should have used \{0,1\} instead... I'm going to hide myself in the dark... :'(
    – Camion
    Commented Jun 5, 2021 at 11:15
  • However, it doen't explain why it didn't work when I reinstalled and reconfigured grub from my debian 32 partition. would by chance the recognition of other linux partitions, be based on parsing the /boot/grub/grub.cfg in those partitions ???
    – Camion
    Commented Jun 5, 2021 at 11:35

1 Answer 1

1

I encountered similar problem in vmware moving boot+system disk from a 800Gb disk to 16Gb, simply copying partition and file (from 800Gb disk to 16Gb) , and dropping 800Gb disk would be insufficient (kernel boot OK but fail to locate /'s UUID). (and sadly in this case vmware's snapshot wasn't usefull as rollback safeguard)

  • mount points are in /etc/fstab but there are 2 fstab
  • plain fstab is in /etc
  • secret /etc/fstab is in initrd.gz (or the like) in /boot partition of booting disk, this fstab hold UUID pointing to / (root FS) of the OS.

Either rebuild initrd if you have booted from this OS.

Or if you have booted from another OS, initrd.gz is a gziped cpio, "simply" extract fstab file, edit it, and put it back in initrd.gz.

2
  • 1
    In Debian and related distributions, there is a update-initramfs tool which will do this with a single sudo update-initramfs -u command. Also note that the initramfs file (initrd.gz in this answer) can be a series of one or more cpio files (gzipped or not) concatenated together: e.g. if you see only a kernel/x86/microcode/ directory within the initramfs file, you are seeing only the first cpio file in the series.
    – telcoM
    Commented Jun 5, 2021 at 6:23
  • I don't think it is that for two reasons : 1/ I solved the problem yesterday by changing my command line before re-installing and updating grub. However, my boot/initrd.img-4.19.0-16-amd64 is older than that and has not been modified. and 2/ Then problem was in my kernel parameters line and not in any fstab (I was able to boot by replacing the UUID parameter by the device name (/dev/sdxx).
    – Camion
    Commented Jun 5, 2021 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .