Le 10/05/2018 à 23:30, Niclas Arndt a écrit :
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.)
What happened at boot time ?
I doubt that all you describe below is related to a motherboard firmware
upgrade.
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).
Neither a BIOS upgrade nor Debian installer's rescue mode modify fstab.
Now /dev/md2 has a PTUUID of PTTYPE="gpt" and
/dev/md2p1 has a UUID of TYPE="ext4" with a PARTUUID.
It seems to indicate that the RAID array /dev/md2 has a GPT partition
table defining a partition md2p1 containing an ext4 filesystem. This is
not the usual setup, but software RAID has supported partitioned arrays
for a long time.
Can you post the output of "fdisk -l" or "parted -l" ?
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.
It is extremely surprising that mounting /dev/md2 works because
according to the above, /dev/md2 contains a partition table, not a
filesystem.
Also, the filesystem should be identified in fstab with its UUID or
label because a RAID device name is not stable.
mdadm refers to the volume as /dev/md2. (I don't use lvm.)
mdadm manages only RAID arrays, not partitions inside an array. It just
marks the array as partitioned and the kernel handles the partition
table as it does with any other partitioned block device.
