Re: [gentoo-user] [SOLVED] fsck.fat 4.1 - File system couldn't be fixed [SOLVED]

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 7111 bytes --]

On Sunday, 13 December 2020 07:42:11 GMT thelma@sys-concept.com wrote:
> On 12/12/2020 11:00 PM, Victor Ivanov wrote:
> > On 13/12/2020 03:07, thelma@sys-concept.com wrote:
> >> if you have UEFI system most likely your "boot" partition is some form
> >> of "vfat"
> > 
> > I strongly disagree with this statement. Most Linux distributions,
> > including Gentoo, advise (or outright default to) having your /boot
> > partition either separate, or having /boot as part of your root
> > filesystem. And this is very sensible indeed.
> > 
> > Personally, I would even go further by saying that /boot should be
> > journaled (e.g. ext4). Most distros do that by default.

Pre-UEFI /boot on a single partition/filesystem used to be formatted as ext2, 
primarily because /boot is a small fs in size, is written to only occasionally 
and unless it happened to crash while writing to it not much benefit would be 
had by adding the journal of ext3/ext4, while adding a fs overhead for the 
journal and making write operations last longer.

VFAT is more fragile than ext2 (in my anecdotal experience) and in addition it 
does not support symlinks (or hard links).  This creates a problem for some 
boot managers, e.g. GRUB.

So, for Linux on conventional installations (Legacy BIOS + separate /boot fs + 
spinning disk setups) ext2 is a valid fs choice.  When /boot is part of the / 
block device, then the fs type for /boot would necessarily be whatever is 
chosen for the / partition, as long as the boot manager has the corresponding 
driver to be able to load it.

With the move from spinning disks to SSDs and problem of block size write 
amplifications cropped up.  Last I looked (on 5.4.80-gentoo-r1) it seems ext2 
still does not support TRIM, while FAT does:

/usr/src/linux $ grep -lr FITRIM fs/ | cut -d/ -f2 | sort | uniq | xargs echo
btrfs compat_ioctl.c ecryptfs ext4 f2fs fat gfs2 hpfs jfs nilfs2 ocfs2 xfs

So, on spinning disks with a legacy BIOS the /boot partition can be on ext2.

On SSDs it makes sense to have /boot on a fs which supports TRIM, e.g. any of 
the above fs.


> > A UEFI set-up only requires the EFI system partition to be vfat. It does
> > not require the kernel or the ramdisk to be on it. GRUB2 can be
> > configured to install only its own EFI-related files on the EFI system
> > partition, then reading the kernel and the grub config file from your
> > /boot partition:
> > 
> >   # grub-install --efi-directory=/path/to/efi --boot-directory=/boot/efi
> > /dev/[nvme...|sd...]
> > 
> > You do not need CSM enabled for this.

Right, on UEFI MoBos the ESP partition used by the UEFI firmware to locate and 
run *.EFI executables must be FAT32.  Such .EFI executables stored on the ESP 
may be OS boot managers/loaders, or other UEFI compatible applications.  The 
boot manager loaded by UEFI is then left to its own mechanisms (boot loader 
and fs drivers) to load whatever fs the kernel image resides on.

NOTE:  The UEFI firmware can boot natively linux kernel images without 
chainloading some 3rd party Boot Manager's .EFI executable like GRUB, rEFInd, 
syslinux, etc., as long as the EFI stub support has been enabled in the linux 
kernel and 'root=PARTUUID=...' has been added in the built-in kernel command 
line entry.


> > Unfortunately, sometimes guides put the EFI partition mount point to be
> > a directory within the /boot directory (e.g. /boot/efi) which itself can
> > be the mount point for the boot partition. This can lead to people
> > formatting both as vfat or indeed using the EFI partition itself in lieu
> > of a separate /boot partition. I am not suggesting this is what happened
> > in your case, but I have seen it happen.

If /boot/efi is a directory (it should be according to the UEFI spec) then as 
far as I know directories cannot be formatted with a fs.


> > Now if you use a different boot loader (e.g. rEFInd) it is up to that
> > bootloader to have relevant support for the filesystem that your /boot
> > partition is using.
> > 
> >> fsck.fat 4.1 (2017-01-24) open: no such file or directory
> >> 
> >> There is a similar related bug filed about it (but I don't know why is
> >> it marked resolved)
> >> https://bugs.gentoo.org/306119
> > 
> > I don't think this issue is related wrt the root cause. But
> > force-checking for filesystem errors certainly revealed the issue for
> > your case: you don't have the fsck.fat binary in your initramfs. As a
> > result, the filesystem checking process fails, the boot process is
> > interrupted prematurely, and you're dropped into a shell to investigate.
> > This is normal behaviour when an error occurs before the boot process
> > switches to the real root.
> > 
> > One option is to disable filesystem checking for vfat - like you did,
> > another is to make sure that the mkfs.fat binary is included in the
> > ramdisk image. I am not sure how the latter would be best achieved with
> > genkernel, perhaps others can advise on this.
> > 
> > - Victor

I have two UEFI systems which boot fine with an ESP formatted as VFAT and 
mounted under /boot.  They could have been mounted under /boot/EFI, or /boot/
EFI/Gentoo, as an alternative too.  The UEFI spec requires each OS loader 
image to be in a directory under \EFI\<OS loader>.

The difference is I do not have a dump directive to back up the /boot fs, 
unlike Thelma/Joseph in my fstab.  My typical fstab entry looks like this:

/dev/sda1   /boot    vfat       noauto,noatime,discard   0 2

and the systems boot fine with it.

The EFI Compatibility Support Module (CSM) still initialises hardware on the 
MoBo using the UEFI firmware, then loads this CSM emulation module to access 
device paths for legacy OSs which are not compatible with UEFI.  So, it is an 
additional firmware layer which does not make much sense to use on modern 
MoBos running modern OS systems.  I doubt there are many on this list who 
still boot WinXP natively on their PCs.  ;-)


> You are absolutely correct. I'm an old timer, before there was no need
> for initramfs.

Unless you have a special need for initramfs, e.g. separate /usr partition, 
adding a block device encryption layer, or some other drivers necessary to 
access/mount the device with the / partition, you can install and run gentoo 
without initramfs.


> One of my 10-year old system is still running /boot with ext2; never had
> a problem.
> HD is making noise and they system was running 24/7.  But it is slowly
> failing, might be HD or memory.

You can use sys-apps/smartmontools and run some tests followed by 'smartctl -a 
/dev/....' to find out if the disk reports imminent failure.


> I was following the Gentoo handbook, maybe I didn't read it correctly
> and/or miss the information on alternative setting.  I didn't see any
> explanation that I need to have support for "fsck.fat".
> I better stay away from any "vfat" format on boot partition, and I don't
> see a reason to have initramfs (another complexity).

Gentoo is thankfully flexible enough to allow you to make your own choices on 
configuring your system.  Whatever works for you best is a valid choice to 
make.  :-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]