Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#53356 - UEFI: will not boot with 0x41 Dirty bit set on the EFI /boot vfat partition; mkfs.vfat -a wipes EFI

Attached to Project: Arch Linux
Opened by Ceriel Jacobs (cj1) - Friday, 17 March 2017, 23:13 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 18 March 2017, 01:31 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: When an UEFI system with FAT EFI boot partition is incorrectly shut down, the dirty bit is set. Even after having added fsck.vfat to mkinitcpio (23), the system is unable to repair the FAT partition and boot hangs.

Additional info:
# fsck.vfat /dev/sdb1
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 2
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 3
/dev/sdb1: 17 files, 10125/261628 clusters


Additional issue: fsck.vfat -a /dev/sdb1
fsck.fat 4.1 (2017-01-24)
will erase all files from the EFI boot partition.

fsck.vfat -a seems to answer 1) and 2) (rendering the system unbootable)
fsck.vfat -a should answer 1) and 3).

Steps to reproduce:
Set UEFI boot, set EFI FAT dirty bit and have an incorrect MBR. Then reboot.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 18 March 2017, 01:31 GMT
Reason for closing:  Not a bug
Comment by Doug Newgard (Scimmia) - Saturday, 18 March 2017, 00:14 GMT
Wait, what does "an incorrect MBR" mean?

Edit: I saw your wiki suggestion, too, and it makes zero sense. Nothing happens with the ESP in the initramfs.
Comment by Ceriel Jacobs (cj1) - Saturday, 18 March 2017, 00:33 GMT
Correction: an incorrect MBR -> have a mismatch in the boot sector and its backup.

Addition: This "differences between boot sector and its backup." was there since started using this USB drive copy (dd) of an earlier installed Arch Linux system. That has never been an issue. The issue started with a power failure. The new error introduced with that is the "0x41: Dirty bit is set". Since then the Arch Linux installation no longer boots (via UEFI).

The issue here is not in the initramfs, but after. The emergency recovery brings me nicely to initramfs (with the fsck.vfat tool missing) because it can't/won't progress further. My guess is that /etc/fstab is processed there.

@Scimmia What makes zero sense?
Comment by Doug Newgard (Scimmia) - Saturday, 18 March 2017, 00:39 GMT
When, exactly, does it stop, and what does it say?
Comment by Ceriel Jacobs (cj1) - Saturday, 18 March 2017, 01:27 GMT
Just after:

:: running hook [udev]
:: Triggering uevents...


mount: unknown filesystem type 'vfat'
Your are now being dropped into an emergency shell.
Comment by Doug Newgard (Scimmia) - Saturday, 18 March 2017, 01:31 GMT
Which mean that it's either trying to mount it from the initramfs, which should never happen, or that the kernel can't find it's modules, likely because of filesystem corruption or booting the wrong kernel. Neither is a bug.

Loading...