|
Hello,
I have a question that I suspect comes from the way rescue mode auto RAID assembly and grub restoration work.
I received unofficial BIOS files from Gigabyte with new versions of Intel ME and CPU microcode. After upgrade, several Stretch machines no longer boot. (Fresh installation works without any problem.)
I booted from USB in rescue mode, did auto-assembly of RAID arrays, mounted /boot/efi and rewrote grub.
This made it possible to boot, but /dev/md2 was removed from fstab. I also for the first time noticed that there is an additional /dev/md2p1 entry when running blkid (although not in fstab).
Now /dev/md2 has a PTUUID of PTTYPE="gpt" and /dev/md2p1 has a UUID of TYPE="ext4" with a PARTUUID.
Manual mount of /dev/md2 works, but the machine won't boot if I add an fstab entry with the /dev/md2 PTUUID. With the /dev/md2p1 UUID in fstab it is mounted at startup and the machine boots.
mdadm refers to the volume as /dev/md2. (I don't use lvm.)
I don't know if this is actually a problem, but I would very much like to understand what happened. Should I / could I restore the system so that the volume is only referred to as /dev/md2?
Thank you in advance and best regards
Niclas
|