[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Auto-assembled SW RAID in rescue mode

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.

Reply to: