If grml-debootstrap detects an existing FAT filesystem on the EFI partition, it doesn't modify/re-create it: | EFI partition /dev/nvme0n1p2 seems to have a FAT filesystem, not modifying. The underlying check is execution of `fsck.vfat -bn $DEVICE`. Now with fsck.fat from dosfstools v4.1-2 as present in Debian/buster we got: | root@grml ~ # fsck.vfat -bn /dev/nvme0n1p2 | fsck.fat 4.1 (2017-01-24) | 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. | Automatically removing dirty bit. | There are differences between boot sector and its backup. | This is mostly harmless. Differences: (offset:original/backup) | 0:00/eb, 82:00/46, 83:00/41, 84:00/54, 85:00/33, 86:00/32, 87:00/20 | , 88:00/20, 89:00/20, 510:00/55, 511:00/aa | Not automatically fixing this. | Leaving filesystem unchanged. | 1 root@grml ~ # Now with dosfstools v4.2-1 as present in Debian/bullseye, this might become: | root@grml ~ # fsck.vfat -bn /dev/nvme0n1p2 | fsck.fat 4.2 (2021-01-31) | There are differences between boot sector and its backup. | This is mostly harmless. Differences: (offset:original/backup) | 0:00/eb, 65:01/00, 82:00/46, 83:00/41, 84:00/54, 85:00/33, 86:00/32 | , 87:00/20, 88:00/20, 89:00/20, 510:00/55, 511:00/aa | Not automatically fixing this. In such situations we end up with an incomplete/broken EFI partition, which breaks within our efivarfs post-script: | Mounting /dev/nvme0n1p2 on /boot/efi | mount: /boot/efi: wrong fs type, bad option, bad superblock on /dev/nvme0n1p2, missing codepage or helper program, or other error. | ESC[31;01m-> Failed (rc=1)ESC[0m | ESC[32;01m*ESC[0m Removing chroot-script again | ESC[32;01m*ESC[0m Executing post-script /etc/debootstrap/post-scripts//efivarfs | Executing /etc/debootstrap/post-scripts//efivarfs | Mounting /dev (via bind mount) | Mounting /boot/efi | mount: /boot/efi: special device UUID= does not exist. Change-Id: I46939b4e191982a84792f3aca27c6cc415dbdaf4mr10.1.1
parent
9ec2c3d459
commit
3073c27a40
Loading…
Reference in new issue