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

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

[thelma]

I wipe the /boot, reinstall kernel, initframes, grub.
The system boots, I can login as root but X is not running,
the command is displaying:  "(none) /#"

When I try to start the network I get:
fsck.fat 4.1 (2017-01-24) open: no such file or directory
Filesystems couldn't be fixed
ERROR: fsck failed to start

It seems to me "/" file system mount in "read only" mode.
When I try to emerge anything I get: /var/log/emerge.log Read-only file
system.

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

[Jack]

On 12/11/20 4:36 PM, thelma@sys-concept.com wrote:
> I wipe the /boot, reinstall kernel, initframes, grub.
> The system boots, I can login as root but X is not running,
> the command is displaying:  "(none) /#"
>
> When I try to start the network I get:
> fsck.fat 4.1 (2017-01-24) open: no such file or directory
> Filesystems couldn't be fixed
> ERROR: fsck failed to start
>
> It seems to me "/" file system mount in "read only" mode.
> When I try to emerge anything I get: /var/log/emerge.log Read-only file
> system.

I fell like I'm shooting at a moving target.  Are you using genkernel or 
not?  Are you using grub or rEFInd?  Is there any interesting error in 
dmesg?  Is initframes hopefully just a typo for initramfs?  When 
booting, can you see what the boot  mgr is doing or trying to do?

You say X is not running -  are you using (or trying to use) a display 
manager?  You might be better off starting without one, and using a 
command line login before adding the complexity of X.

I'll guess the "none" is the hostname as part of your shell prompt.  You 
can "fix" that by setting a hostname for the PC.

Are you sure that fsck message has anything to do with starting the 
network?  It looks like fsck can't find the open command, so there may 
be something more wrong than just a read-only /.

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

[thelma]

On 12/11/2020 03:06 PM, Jack wrote:
> On 12/11/20 4:36 PM, thelma@sys-concept.com wrote:
>> I wipe the /boot, reinstall kernel, initframes, grub.
>> The system boots, I can login as root but X is not running,
>> the command is displaying:  "(none) /#"
>>
>> When I try to start the network I get:
>> fsck.fat 4.1 (2017-01-24) open: no such file or directory
>> Filesystems couldn't be fixed
>> ERROR: fsck failed to start
>>
>> It seems to me "/" file system mount in "read only" mode.
>> When I try to emerge anything I get: /var/log/emerge.log Read-only file
>> system.
> 
> I fell like I'm shooting at a moving target.  Are you using genkernel or
> not?  Are you using grub or rEFInd?  Is there any interesting error in
> dmesg?  Is initframes hopefully just a typo for initramfs?  When
> booting, can you see what the boot  mgr is doing or trying to do?
> 
> You say X is not running -  are you using (or trying to use) a display
> manager?  You might be better off starting without one, and using a
> command line login before adding the complexity of X.
> 
> I'll guess the "none" is the hostname as part of your shell prompt.  You
> can "fix" that by setting a hostname for the PC.
> 
> Are you sure that fsck message has anything to do with starting the
> network?  It looks like fsck can't find the open command, so there may
> be something more wrong than just a read-only /.

I'm using now linux-5.4.72-gentoo, grub only. Install boot loader from
scratch.
I only use genkernel to install initframes:

genkernel --install --kernel-config=/usr/src/linux/.config initramfs

No, errors during startup in dmesg.  So I have very little to go by.
Trying  "touch 1.txt"
Read-only file system.

I'm using slim, but I can deal with X later on.
Something happen to this system and I can not fix it, it is a brand new
installation, but not reliable :-/

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

[Michael]

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

On Friday, 11 December 2020 22:29:12 GMT thelma@sys-concept.com wrote:
> On 12/11/2020 03:06 PM, Jack wrote:
> > On 12/11/20 4:36 PM, thelma@sys-concept.com wrote:
> >> I wipe the /boot, reinstall kernel, initframes, grub.
> >> The system boots, I can login as root but X is not running,
> >> the command is displaying:  "(none) /#"
> >> 
> >> When I try to start the network I get:
> >> fsck.fat 4.1 (2017-01-24) open: no such file or directory
> >> Filesystems couldn't be fixed
> >> ERROR: fsck failed to start
> >> 
> >> It seems to me "/" file system mount in "read only" mode.
> >> When I try to emerge anything I get: /var/log/emerge.log Read-only file
> >> system.
> > 
> > I fell like I'm shooting at a moving target.  Are you using genkernel or
> > not?  Are you using grub or rEFInd?  Is there any interesting error in
> > dmesg?  Is initframes hopefully just a typo for initramfs?  When
> > booting, can you see what the boot  mgr is doing or trying to do?
> > 
> > You say X is not running -  are you using (or trying to use) a display
> > manager?  You might be better off starting without one, and using a
> > command line login before adding the complexity of X.
> > 
> > I'll guess the "none" is the hostname as part of your shell prompt.  You
> > can "fix" that by setting a hostname for the PC.
> > 
> > Are you sure that fsck message has anything to do with starting the
> > network?  It looks like fsck can't find the open command, so there may
> > be something more wrong than just a read-only /.
> 
> I'm using now linux-5.4.72-gentoo, grub only. Install boot loader from
> scratch.
> I only use genkernel to install initframes:
> 
> genkernel --install --kernel-config=/usr/src/linux/.config initramfs
> 
> No, errors during startup in dmesg.  So I have very little to go by.
> Trying  "touch 1.txt"
> Read-only file system.
> 
> I'm using slim, but I can deal with X later on.
> Something happen to this system and I can not fix it, it is a brand new
> installation, but not reliable :-/

When you "wiped /boot" did you reformat the partition?  If yes, did you 
recreate a filesystem label with the same name as used in your /etc/fstab?

Is this a brand new kernel image + initramfs, or a kernel image which you have 
used at least once before to boot this machine successfully?

Does dmesg show the drive being recognised, corresponding drivers being 
loaded, partitions and filesystems recognised?

Does syslog show any relevant errors?

Does 'mount' or 'findmnt' show all your partitions?

Are they mounted as rw?

These are just some steps you could follow to find out at what stage a problem 
may have occurred and what to check/fix to get it booting successfully.

PS.  These days there are precompiled kernels + initramfs available to get a 
system booting quickly, like sys-kernel/gentoo-kernel-bin, before you finesse 
a slimmer kernel manually later on - should you ever wish to roll your own by 
hand.

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

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

[thelma]

On 12/11/2020 04:50 PM, Michael wrote:
> On Friday, 11 December 2020 22:29:12 GMT thelma@sys-concept.com wrote:
>> On 12/11/2020 03:06 PM, Jack wrote:
>>> On 12/11/20 4:36 PM, thelma@sys-concept.com wrote:
>>>> I wipe the /boot, reinstall kernel, initframes, grub.
>>>> The system boots, I can login as root but X is not running,
>>>> the command is displaying:  "(none) /#"
>>>>
>>>> When I try to start the network I get:
>>>> fsck.fat 4.1 (2017-01-24) open: no such file or directory
>>>> Filesystems couldn't be fixed
>>>> ERROR: fsck failed to start
[snip]
>>>
>>> Are you sure that fsck message has anything to do with starting the
>>> network?  It looks like fsck can't find the open command, so there may
>>> be something more wrong than just a read-only /.
>>
>> I'm using now linux-5.4.72-gentoo, grub only. Install boot loader from
>> scratch.
>> I only use genkernel to install initframes:
>>
>> genkernel --install --kernel-config=/usr/src/linux/.config initramfs
>>
>> No, errors during startup in dmesg.  So I have very little to go by.
>> Trying  "touch 1.txt"
>> Read-only file system.
>>
>> I'm using slim, but I can deal with X later on.
>> Something happen to this system and I can not fix it, it is a brand new
>> installation, but not reliable :-/
> 
> When you "wiped /boot" did you reformat the partition?  If yes, did you 
> recreate a filesystem label with the same name as used in your /etc/fstab?

No, I did not reformat the /boot partition. I just cd to /boot and run:
rm -r *

> Is this a brand new kernel image + initramfs, or a kernel image which you have 
> used at least once before to boot this machine successfully?

Yes, this machine is new but I run it for a over 10-days, configured
most of the programs and it was running without much problems.
Yesterday, I decided to check some parameters in kernel .config so I run:
 genkernel --menuconfig all

* Gentoo Linux Genkernel; Version 4.1.2
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --kernel-config=/proc/config.gz all

* Working with Linux kernel 5.4.72-gentoo-x86_64 for x86_64
* Using kernel config file '/proc/config.gz' ...
*
* Note: The version above is subject to change (depends on config and
status of kernel sources).

* kernel: >> Initializing ...
*         >> Running 'make clean' ...
*         >> --mrproper is set; Making 'make mrproper' ...
*         >> Will ignore kernel config from '/proc/config.gz'
*            in favor of already existing but different kernel config
*            found in '/usr/src/linux/.config' ...
*         >> Running 'make oldconfig' ...
*         >> Compiling 5.4.72-gentoo-x86_64 bzImage ...


When I exit it it started to compile the kernel (it did not finish) I
pressed
"CTRL-C" (interrupted).
I didn't know then, but running genkernel --menuconfig all
takes configuration from:
/etc/kernels/kernel-config-5.4.72-gentoo-x86_64

not from: /usr/src/linux/.config

However, NO FILE HAD CHANGED IN /boot
But this this is the moment, I couldn't boot correctly.

So after several tries I wipe the /boot, I downloaded standard kernel
linux-5.4.72-gentoo run as usual:
make && make modules_install
make install
genkernel --install --kernel-config=/usr/src/linux/.config initramfs
grub-install --target=x86_64-efi --efi-directory=/boot
grub-mkconfig -o /boot/grub/grub.cfg

But nothing had changed. So I tired newer kernel: 5.4.80-gentoo-r1-x86_64
But this time I run (without interruptions):
 genkernel --menuconfig all
grub-mkconfig -o /boot/grub/grub.cfg

And again nothing changed, root "/" still mounts "ro"

findmnt
TARGET                        SOURCE         FSTYPE   OPTIONS
/                             /dev/nvme0n1p4 ext4     ro,relatime

Normally it should be:
findmnt
TARGET                       SOURCE      FSTYPE      OPTIONS
/                            /dev/sda4   ext4        rw,noatime,data=ordered

> Does dmesg show the drive being recognised, corresponding drivers being 
> loaded, partitions and filesystems recognised?

cat dmesg  |grep error
doesn't show any errors

> Does syslog show any relevant errors?

Kernel log, nor error entry either.

> Does 'mount' or 'findmnt' show all your partitions?

Yes, they are all "rw" except the "/" partition  /dev/nvme0n1p4

> Are they mounted as rw?
> 
> These are just some steps you could follow to find out at what stage a problem 
> may have occurred and what to check/fix to get it booting successfully.
> 
> PS.  These days there are precompiled kernels + initramfs available to get a 
> system booting quickly, like sys-kernel/gentoo-kernel-bin, before you finesse 
> a slimmer kernel manually later on - should you ever wish to roll your own by 
> hand.

I'll try to boot GParted and see what comes up.

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

[Dan Egli]

Actually, you have an error or two below.

On 12/11/2020 6:16 PM, thelma@sys-concept.com wrote:
> No, I did not reformat the /boot partition. I just cd to /boot and run:
> rm -r *
Probably better to wipe the file system. But you talk about moving away 
from EFI in another thread, so we'll just say that should this happen 
again, you should wipe with mkfs.<fstype> instead of just rm -r.
>
> Yes, this machine is new but I run it for a over 10-days, configured
> most of the programs and it was running without much problems.
> Yesterday, I decided to check some parameters in kernel .config so I run:
>   genkernel --menuconfig all
>
Next time, just do this:

cd /usr/src/linux
make menconfig (or nconfig)

> * Gentoo Linux Genkernel; Version 4.1.2
> * Using genkernel configuration from '/etc/genkernel.conf' ...
> * Running with options: --kernel-config=/proc/config.gz all
>
> * Working with Linux kernel 5.4.72-gentoo-x86_64 for x86_64
> * Using kernel config file '/proc/config.gz' ...
> *
> * Note: The version above is subject to change (depends on config and
> status of kernel sources).
>
> * kernel: >> Initializing ...
> *         >> Running 'make clean' ...
> *         >> --mrproper is set; Making 'make mrproper' ...
> *         >> Will ignore kernel config from '/proc/config.gz'
> *            in favor of already existing but different kernel config
> *            found in '/usr/src/linux/.config' ...
> *
So you are wrong below. As you can see above, genkernel IS using 
/usr/src/linux/.config. I'm not 100% certain, but I THINK genkernel will 
compare the config files, and prefer the .config if it is present.
>           >> Running 'make oldconfig' ...
> *         >> Compiling 5.4.72-gentoo-x86_64 bzImage ...
>
>
> When I exit it it started to compile the kernel (it did not finish) I
> pressed
> "CTRL-C" (interrupted).
> I didn't know then, but running genkernel --menuconfig all
> takes configuration from:
> /etc/kernels/kernel-config-5.4.72-gentoo-x86_64
>
> not from: /usr/src/linux/.config
No, unless /etc/kernels/kernel-config-<whatever> is NEWER than .config, 
and maybe not even then. See above.
> However, NO FILE HAD CHANGED IN /boot
> But this this is the moment, I couldn't boot correctly.
What was the boot error?
> make && make modules_install
> make install
> genkernel --install --kernel-config=/usr/src/linux/.config initramfs
> grub-install --target=x86_64-efi --efi-directory=/boot
> grub-mkconfig -o /boot/grub/grub.cfg
>
> But nothing had changed. So I tired newer kernel: 5.4.80-gentoo-r1-x86_64
> But this time I run (without interruptions):
>   genkernel --menuconfig all
> grub-mkconfig -o /boot/grub/grub.cfg
>
> And again nothing changed, root "/" still mounts "ro"
>
> findmnt
> TARGET                        SOURCE         FSTYPE   OPTIONS
> /                             /dev/nvme0n1p4 ext4     ro,relatime
>
> Normally it should be:
> findmnt
> TARGET                       SOURCE      FSTYPE      OPTIONS
> /                            /dev/sda4   ext4        rw,noatime,data=ordered
Looks like it's not getting to the root remount stage. The kernel will 
almost always boot in ro mode. So you're probably getting stuck in the 
emergency shell. Can you see your device in /dev?
>> Does dmesg show the drive being recognised, corresponding drivers being
>> loaded, partitions and filesystems recognised?
> cat dmesg  |grep error
> doesn't show any errors
>
What's the last 10 or so lines from dmesg when it fails to boot and goes 
to what I'm guessing is the emergency shell?
> I'll try to boot GParted and see what comes up.


I don't think gparted is your answer. Sounds to me like something is 
causing it to fail in the changeover from your initrd to the actual 
drive. If that's the case I bet your partitions are fine. Can you show 
us the last 10-15 lines printed on the screen before you get stuck?

-- 
Dan Egli
 From my Test Server

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

[thelma]

On 12/12/2020 12:32 AM, Dan Egli wrote:
> Actually, you have an error or two below.
> 
> On 12/11/2020 6:16 PM, thelma@sys-concept.com wrote:
>> No, I did not reformat the /boot partition. I just cd to /boot and run:
>> rm -r *
> Probably better to wipe the file system. But you talk about moving away
> from EFI in another thread, so we'll just say that should this happen
> again, you should wipe with mkfs.<fstype> instead of just rm -r.
>>
>> Yes, this machine is new but I run it for a over 10-days, configured
>> most of the programs and it was running without much problems.
>> Yesterday, I decided to check some parameters in kernel .config so I run:
>>   genkernel --menuconfig all
>>
> Next time, just do this:
> 
> cd /usr/src/linux
> make menconfig (or nconfig)
> 
>> * Gentoo Linux Genkernel; Version 4.1.2
>> * Using genkernel configuration from '/etc/genkernel.conf' ...
>> * Running with options: --kernel-config=/proc/config.gz all
>>
>> * Working with Linux kernel 5.4.72-gentoo-x86_64 for x86_64
>> * Using kernel config file '/proc/config.gz' ...
>> *
>> * Note: The version above is subject to change (depends on config and
>> status of kernel sources).
>>
>> * kernel: >> Initializing ...
>> *         >> Running 'make clean' ...
>> *         >> --mrproper is set; Making 'make mrproper' ...
>> *         >> Will ignore kernel config from '/proc/config.gz'
>> *            in favor of already existing but different kernel config
>> *            found in '/usr/src/linux/.config' ...
>> *
> So you are wrong below. As you can see above, genkernel IS using
> /usr/src/linux/.config. I'm not 100% certain, but I THINK genkernel will
> compare the config files, and prefer the .config if it is present.
>>           >> Running 'make oldconfig' ...
>> *         >> Compiling 5.4.72-gentoo-x86_64 bzImage ...
>>
>>
>> When I exit it it started to compile the kernel (it did not finish) I
>> pressed
>> "CTRL-C" (interrupted).
>> I didn't know then, but running genkernel --menuconfig all
>> takes configuration from:
>> /etc/kernels/kernel-config-5.4.72-gentoo-x86_64
>>
>> not from: /usr/src/linux/.config
> No, unless /etc/kernels/kernel-config-<whatever> is NEWER than .config,
> and maybe not even then. See above.
>> However, NO FILE HAD CHANGED IN /boot
>> But this this is the moment, I couldn't boot correctly.
> What was the boot error?
>> make && make modules_install
>> make install
>> genkernel --install --kernel-config=/usr/src/linux/.config initramfs
>> grub-install --target=x86_64-efi --efi-directory=/boot
>> grub-mkconfig -o /boot/grub/grub.cfg
>>
>> But nothing had changed. So I tired newer kernel: 5.4.80-gentoo-r1-x86_64
>> But this time I run (without interruptions):
>>   genkernel --menuconfig all
>> grub-mkconfig -o /boot/grub/grub.cfg
>>
>> And again nothing changed, root "/" still mounts "ro"
>>
>> findmnt
>> TARGET                        SOURCE         FSTYPE   OPTIONS
>> /                             /dev/nvme0n1p4 ext4     ro,relatime
>>
>> Normally it should be:
>> findmnt
>> TARGET                       SOURCE      FSTYPE      OPTIONS
>> /                            /dev/sda4   ext4       
>> rw,noatime,data=ordered
> Looks like it's not getting to the root remount stage. The kernel will
> almost always boot in ro mode. So you're probably getting stuck in the
> emergency shell. Can you see your device in /dev?
>>> Does dmesg show the drive being recognised, corresponding drivers being
>>> loaded, partitions and filesystems recognised?
>> cat dmesg  |grep error
>> doesn't show any errors
>>
> What's the last 10 or so lines from dmesg when it fails to boot and goes
> to what I'm guessing is the emergency shell?
>> I'll try to boot GParted and see what comes up.
> 
> 
> I don't think gparted is your answer. Sounds to me like something is
> causing it to fail in the changeover from your initrd to the actual
> drive. If that's the case I bet your partitions are fine. Can you show
> us the last 10-15 lines printed on the screen before you get stuck?

The last 10-15 lines are not showing much but there is more (I'm
retyping it from the screen) dmesg: (why the line BOOT_IMAGE is Read Only)

Kernel command line: BOOT_IMAGE=/vmlinuz-5.7.72-gentoo
root=UUID=d3229... ro

platform regulatory.0: Direct firmware load for regulatory.db failed
with error -2
cfg80211: failed to load regulatory.db
nvme mvme0: missing or invalid SUBNQN field


usb 3-4: config 1 has an invalid interface number: 2 but nax is 1
usb 3-4: config 1 has no interface number 1

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

[Dan Egli]

Hmmm, looks like a missing or corrupted firmware file is failing to 
load. Observe:

On 12/12/2020 11:48 AM, thelma@sys-concept.com wrote:
>
> platform regulatory.0: Direct firmware load for regulatory.db failed
> with error -2
> cfg80211: failed to load regulatory.db
> nvme mvme0: missing or invalid SUBNQN field
>
I'd say, off my head, that your regulatory.db file has gotten corrupted. 
I'd suggest booting from a rescue CD, chrooting into your main 
partition, and reinstalling your firmware. It mentions the wireless, of 
course (cfg80211) but also it looks like either the firmware or the 
driver for your nvme system has gotten corrupted. It's obviously 
present, but it's complaining about missing information. You may want to 
go ahead and re-compile the kernel and the modules.If you're using 
genkernel I'd even go so far as to suggest a mrproper. Just to ensure 
that EVERYTHING is cleaned out. Then let genkernel rebuild everything. 
Another option, although one I dislike for _purely ascetic_ reasons, 
would be to just grab the gentoo-kernel-bin package. That's a 
precompiled kernel with a lot of stuff enabled as modules. It could very 
well be helpful in getting your system back on it's feet.

-- 

Dan Egli
 From my Test Server

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

[thelma]

On 12/12/2020 12:25 PM, Dan Egli wrote:
> Hmmm, looks like a missing or corrupted firmware file is failing to
> load. Observe:
> 
> On 12/12/2020 11:48 AM, thelma@sys-concept.com wrote:
>>
>> platform regulatory.0: Direct firmware load for regulatory.db failed
>> with error -2
>> cfg80211: failed to load regulatory.db
>> nvme mvme0: missing or invalid SUBNQN field
>>
> I'd say, off my head, that your regulatory.db file has gotten corrupted.
> I'd suggest booting from a rescue CD, chrooting into your main
> partition, and reinstalling your firmware. It mentions the wireless, of
> course (cfg80211) but also it looks like either the firmware or the
> driver for your nvme system has gotten corrupted. It's obviously
> present, but it's complaining about missing information. You may want to
> go ahead and re-compile the kernel and the modules.If you're using
> genkernel I'd even go so far as to suggest a mrproper. Just to ensure
> that EVERYTHING is cleaned out. Then let genkernel rebuild everything.
> Another option, although one I dislike for _purely ascetic_ reasons,
> would be to just grab the gentoo-kernel-bin package. That's a
> precompiled kernel with a lot of stuff enabled as modules. It could very
> well be helpful in getting your system back on it's feet.

 I took care of this error, it was about cfg80211 enable wireless
support (which I don't have) so I disable it in .config.
But  when I generate initframes I'm getting a warning:

genkernel --install --kernel-config=/usr/src/linux/.config initramfs

* WARNING... WARNING... WARNING...
* Additional kernel parameters that *may* be required to boot properly:
*
* With support for several ext* filesystems available, it may be needed to
* add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot parameters.

Which grub file I edit to add support for "rootfstype=ext4" ?

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

[Dan Egli]

You want to add it to the default command line in /etc/default/grub, if 
it's needed. Frankly, as long as you have ext4 support built in to your 
kernel (not a module) then I don't think you need it. I've gotten 
similar warnings on my machines and they've never had a problem loading 
the root FS.  Oh, and it's not initframes, it is INIT RAM FS (no spaces, 
of course). For Initial Ram Filesystem. :)

On 12/12/2020 12:47 PM, thelma@sys-concept.com wrote:
> I took care of this error, it was about cfg80211 enable wireless
> support (which I don't have) so I disable it in .config.
> But  when I generate initframes I'm getting a warning:
>
> genkernel --install --kernel-config=/usr/src/linux/.config initramfs
>
> * WARNING... WARNING... WARNING...
> * Additional kernel parameters that *may* be required to boot properly:
> *
> * With support for several ext* filesystems available, it may be needed to
> * add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot parameters.
>
> Which grub file I edit to add support for "rootfstype=ext4" ?
>
-- 
Dan Egli
 From my Test Server

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

[thelma]

On 12/12/2020 12:32 AM, Dan Egli wrote:
> Actually, you have an error or two below.
> 
> On 12/11/2020 6:16 PM, thelma@sys-concept.com wrote:
>> No, I did not reformat the /boot partition. I just cd to /boot and run:
>> rm -r *
> Probably better to wipe the file system. But you talk about moving away
> from EFI in another thread, so we'll just say that should this happen
> again, you should wipe with mkfs.<fstype> instead of just rm -r.
>>
>> Yes, this machine is new but I run it for a over 10-days, configured
>> most of the programs and it was running without much problems.
>> Yesterday, I decided to check some parameters in kernel .config so I run:
>>   genkernel --menuconfig all
>>
> Next time, just do this:
> 
> cd /usr/src/linux
> make menconfig (or nconfig)
> 
>> * Gentoo Linux Genkernel; Version 4.1.2
>> * Using genkernel configuration from '/etc/genkernel.conf' ...
>> * Running with options: --kernel-config=/proc/config.gz all
>>
>> * Working with Linux kernel 5.4.72-gentoo-x86_64 for x86_64
>> * Using kernel config file '/proc/config.gz' ...
>> *
>> * Note: The version above is subject to change (depends on config and
>> status of kernel sources).
>>
>> * kernel: >> Initializing ...
>> *         >> Running 'make clean' ...
>> *         >> --mrproper is set; Making 'make mrproper' ...
>> *         >> Will ignore kernel config from '/proc/config.gz'
>> *            in favor of already existing but different kernel config
>> *            found in '/usr/src/linux/.config' ...
>> *
> So you are wrong below. As you can see above, genkernel IS using
> /usr/src/linux/.config. I'm not 100% certain, but I THINK genkernel will
> compare the config files, and prefer the .config if it is present.
>>           >> Running 'make oldconfig' ...
>> *         >> Compiling 5.4.72-gentoo-x86_64 bzImage ...
>>
>>
>> When I exit it it started to compile the kernel (it did not finish) I
>> pressed
>> "CTRL-C" (interrupted).
>> I didn't know then, but running genkernel --menuconfig all
>> takes configuration from:
>> /etc/kernels/kernel-config-5.4.72-gentoo-x86_64
>>
>> not from: /usr/src/linux/.config
> No, unless /etc/kernels/kernel-config-<whatever> is NEWER than .config,
> and maybe not even then. See above.
>> However, NO FILE HAD CHANGED IN /boot
>> But this this is the moment, I couldn't boot correctly.
> What was the boot error?
>> make && make modules_install
>> make install
>> genkernel --install --kernel-config=/usr/src/linux/.config initramfs
>> grub-install --target=x86_64-efi --efi-directory=/boot
>> grub-mkconfig -o /boot/grub/grub.cfg
>>
>> But nothing had changed. So I tired newer kernel: 5.4.80-gentoo-r1-x86_64
>> But this time I run (without interruptions):
>>   genkernel --menuconfig all
>> grub-mkconfig -o /boot/grub/grub.cfg
>>
>> And again nothing changed, root "/" still mounts "ro"
>>
>> findmnt
>> TARGET                        SOURCE         FSTYPE   OPTIONS
>> /                             /dev/nvme0n1p4 ext4     ro,relatime
>>
>> Normally it should be:
>> findmnt
>> TARGET                       SOURCE      FSTYPE      OPTIONS
>> /                            /dev/sda4   ext4       
>> rw,noatime,data=ordered
> Looks like it's not getting to the root remount stage. The kernel will
> almost always boot in ro mode. So you're probably getting stuck in the
> emergency shell. Can you see your device in /dev?

Yes, I can see /dev/nvme0n1p4 (this is root partition)
brw-rw---- root disk  /dev/nvme0n1p4

>>> Does dmesg show the drive being recognised, corresponding drivers being
>>> loaded, partitions and filesystems recognised?
>> cat dmesg  |grep error
>> doesn't show any errors

No, no errors in dmesg

>>
> What's the last 10 or so lines from dmesg when it fails to boot and goes
> to what I'm guessing is the emergency shell?
>> I'll try to boot GParted and see what comes up.
> 
> 
> I don't think gparted is your answer. Sounds to me like something is
> causing it to fail in the changeover from your initrd to the actual
> drive. If that's the case I bet your partitions are fine. Can you show
> us the last 10-15 lines printed on the screen before you get stuck?

In dmesg, I see some lines at the end like:

findsf (728) used greatest stack depth: 14048 bytes left
EXT4-fs (nvme0n1p4): mounted filesystem with ordered data mode. Opts: (null)
findsf (728) used greatest stack depth: 13896 bytes left
awk (735)  used greatest stack depth: 13000 bytes left
udevd (682) used greatest stack depth: 13792 bytes left

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

[Tamer Higazi]

Take systemrescuecd and fix your partitions.

Let's see what might be the result.....


best, Tamer

On 12/11/20 10:36 PM, thelma@sys-concept.com wrote:
> I wipe the /boot, reinstall kernel, initframes, grub.
> The system boots, I can login as root but X is not running,
> the command is displaying:  "(none) /#"
>
> When I try to start the network I get:
> fsck.fat 4.1 (2017-01-24) open: no such file or directory
> Filesystems couldn't be fixed
> ERROR: fsck failed to start
>
> It seems to me "/" file system mount in "read only" mode.
> When I try to emerge anything I get: /var/log/emerge.log Read-only file
> system.
>
>

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

[thelma]

How to to fix it?  I can bootstrap from USB but what command to run it?

On 12/12/2020 03:59 AM, Tamer Higazi wrote:
> Take systemrescuecd and fix your partitions.
> 
> Let's see what might be the result.....
> 
> 
> best, Tamer
> 
> On 12/11/20 10:36 PM, thelma@sys-concept.com wrote:
>> I wipe the /boot, reinstall kernel, initframes, grub.
>> The system boots, I can login as root but X is not running,
>> the command is displaying:  "(none) /#"
>>
>> When I try to start the network I get:
>> fsck.fat 4.1 (2017-01-24) open: no such file or directory
>> Filesystems couldn't be fixed
>> ERROR: fsck failed to start
>>
>> It seems to me "/" file system mount in "read only" mode.
>> When I try to emerge anything I get: /var/log/emerge.log Read-only file
>> system.
>>
>>
> 
> 

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

[Dan Egli]

If you have a rescue cd, then you do just what I see you've already 
done. run fsck against the file sytem and let it fix any errors. As to 
being in read only mode, HOPEFULLY that's fixed, but if not you can try 
manually remounting your filesystem: mount / -o remount,rw

On 12/12/2020 12:49 PM, thelma@sys-concept.com wrote:
> How to to fix it?  I can bootstrap from USB but what command to run it?
>
> On 12/12/2020 03:59 AM, Tamer Higazi wrote:
>> Take systemrescuecd and fix your partitions.
>>
>> Let's see what might be the result.....
>>
>>
>> best, Tamer
>>
>> On 12/11/20 10:36 PM, thelma@sys-concept.com wrote:
>>> I wipe the /boot, reinstall kernel, initframes, grub.
>>> The system boots, I can login as root but X is not running,
>>> the command is displaying:  "(none) /#"
>>>
>>> When I try to start the network I get:
>>> fsck.fat 4.1 (2017-01-24) open: no such file or directory
>>> Filesystems couldn't be fixed
>>> ERROR: fsck failed to start
>>>
>>> It seems to me "/" file system mount in "read only" mode.
>>> When I try to emerge anything I get: /var/log/emerge.log Read-only file
>>> system.
>>>
>>>
>>
-- 
Dan Egli
 From my Test Server

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

[Neil Bothwick]

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

On Fri, 11 Dec 2020 14:36:51 -0700, thelma@sys-concept.com wrote:

> I wipe the /boot, reinstall kernel, initframes, grub.
> The system boots, I can login as root but X is not running,
> the command is displaying:  "(none) /#"
> 
> When I try to start the network I get:
> fsck.fat 4.1 (2017-01-24) open: no such file or directory
> Filesystems couldn't be fixed
> ERROR: fsck failed to start
> 
> It seems to me "/" file system mount in "read only" mode.
> When I try to emerge anything I get: /var/log/emerge.log Read-only file
> system.

Have you actually booted fully? This looks like the situation when
mounting root fails and the initramfs drops you to a console? Does mount
show that you partitions from fstab have mounted?


-- 
Neil Bothwick

Why is bra singular and pants plural?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[thelma]

On 12/12/2020 03:40 PM, Neil Bothwick wrote:
> On Fri, 11 Dec 2020 14:36:51 -0700, thelma@sys-concept.com wrote:
> 
>> I wipe the /boot, reinstall kernel, initframes, grub.
>> The system boots, I can login as root but X is not running,
>> the command is displaying:  "(none) /#"
>>
>> When I try to start the network I get:
>> fsck.fat 4.1 (2017-01-24) open: no such file or directory
>> Filesystems couldn't be fixed
>> ERROR: fsck failed to start
>>
>> It seems to me "/" file system mount in "read only" mode.
>> When I try to emerge anything I get: /var/log/emerge.log Read-only file
>> system.
> 
> Have you actually booted fully? This looks like the situation when
> mounting root fails and the initramfs drops you to a console? Does mount
> show that you partitions from fstab have mounted?

A lot of folks get hurt over this bug, I'm supersized that nobody
reported it yet that fsck.fat 4.1 has bugs.

Symptoms:
One day you end up with command line login:

(none) login:

Your root file system will be mounted as RO and only way to access your
system is to boot-strap it.

Recompiling anything (emerge -e system) will not help.
The screen output fly by so fast that you need to have a high speed
camera to catch the scrolling line.
What help me is  in "/" running:
touch forcefsck

It will force the system to run a check on all file systems in fstab.
This will slow down the system, so you will notice that error message:

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

SOLUTION (workaround):

if you have UEFI system most likely your "boot" partition is some form
of "vfat"
if you have in fstab:

LABEL=boot		/boot		vfat		noauto,noatime	1 2

Change it to:
LABEL=boot		/boot		vfat		noauto,noatime	0 0

The force check of vfat system will skip and your system will boot normally.

My permanent solution will be to go back to old reliable "ext2 as boot".
 Most newer BIOS system have CSM (compatibility support module under
Boot menu) turning it ON will allow the boot partition to be in "ext2",
it will avoid future problems with "fsck.fat"

Running "boot" in ext2 I don't need "initramfs" either.

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

[Victor Ivanov]

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.

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.

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.

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

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

[thelma]

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.
> 
> 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.
> 
> 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.
> 
> 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

You are absolutely correct. I'm an old timer, before there was no need
for 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.

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-user] How to config nullmailer

[bobwxc]

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

Recently,  I  typed  'mailq'  and  found  some  mail  have  not  been  sending.

So  I  want  to  install  a  MTA,  then  found  that  the  system have  already

installed  nullmailer,  but  it  did  not  work,  and  the  config  file  at  /etc/nullmailer/

is  empty.  Besides,  wiki  is  useless.




How  to  config  this one,  or  I  should  replace  it  with  postfix?




bobwxc

==============

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEX0aJURYJKwYBBAHaRw8BAQdASLmtsBXRo9ZbNOKisvEuvK8pTGNcsNgFsLU5

fcuEnd20G3ctY2hyb21lYm9vayAody1jaHJvbWVib29rKYiWBBMWCAA+FiEEeUf5

B4zw9YQZtU5OABzGqG8YykcFAl9GiVECGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYC

AwECHgECF4AACgkQABzGqG8YykfF7QEAtdrAplwKcMnSBuxSQPRAQ+RvVaXt8sUc

lVhtNSPukBABALWtY4J6deiihXG5o1zijsF85fucNiDTVLveIfSs+HYKuDgEX0aJ

URIKKwYBBAGXVQEFAQEHQMcsqz2UMo1KjOi/dlismg6RUdf/mM5YcnqTR7PDGI59

AwEIB4h+BBgWCAAmFiEEeUf5B4zw9YQZtU5OABzGqG8YykcFAl9GiVECGwwFCQlm

AYAACgkQABzGqG8YykcjqAD9Ffss3s6H/xiKdQ7IlcNlFNNKbTZjimxKOcVRO6eA

r98A/0cWQxd4i7LWDHRu5ixbG0qT3WXipq+t22RpOqLM0IYO

=TyBA

-----END PGP PUBLIC KEY BLOCK-----






[-- Attachment #2: Type: text/html, Size: 1888 bytes --]

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

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 1500 bytes --]

On 13/12/2020 07:42, thelma@sys-concept.com wrote:
> 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).
> 
No worries at all, despite my using Gentoo for the better part of a 
decade I too sometimes do something silly without realising. And you're 
right that this part of the guidebook could be improved to make some 
clarifications.

In any case, I've looked at the fstab on one of my machines and I do 
have dump/pass set to "0 2" for the EFI partition (which is of course 
vfat). I changed that to "1 2" to match your previous setup, though I 
was sceptical if that would make any difference. I created a /forcefsck 
file and managed to reboot just fine which suggests that either:

1) my ramdisk has fsck.fat bundled; or
2) was able to use the binary from the root partition after it was 
mounted read-only

[I could check explicitly, but I'm feeling a bit lazy]

Out of curiosity, do you have the "sys-fs/dosfstools" package installed?

This is the package that provides the fsck.fat binary. It's not a 
dependency of commonly installed system packages so unless you install 
it manually it's probably missing which might explain why fsck is 
exiting with an error code.

- Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[thelma]

On 12/13/2020 06:33 AM, Victor Ivanov wrote:
[snip]
> 
> Out of curiosity, do you have the "sys-fs/dosfstools" package installed?
> 
> This is the package that provides the fsck.fat binary. It's not a
> dependency of commonly installed system packages so unless you install
> it manually it's probably missing which might explain why fsck is
> exiting with an error code.
> 
> - Victor

Yes, I had this packaged installed, but it did not help. I got hit by
this bug.  I'm surprised that it hasn't been discovered earlier.

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

[Michael]

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

On Monday, 14 December 2020 06:07:40 GMT thelma@sys-concept.com wrote:
> On 12/13/2020 06:33 AM, Victor Ivanov wrote:
> [snip]
> 
> > Out of curiosity, do you have the "sys-fs/dosfstools" package installed?
> > 
> > This is the package that provides the fsck.fat binary. It's not a
> > dependency of commonly installed system packages so unless you install
> > it manually it's probably missing which might explain why fsck is
> > exiting with an error code.
> > 
> > - Victor
> 
> Yes, I had this packaged installed, but it did not help. I got hit by
> this bug.  I'm surprised that it hasn't been discovered earlier.

We don't know for sure this was either a fsck bug, or a corrupt ESP vfat fs.  
We know some kernel couldn't complete its booting process.  There could be 
many other extraneous reasons for it, like missing kernel drivers, missing 
firmware, incomplete initramfs (if one was being used at the time).

There's a difference between troubleshooting a problem patiently until the 
root cause is established and resolved, Vs trying different things as fast as 
possible to boot a system.  Reverting to old(er) working paradigms, e.g. 
legacy BIOS and /boot with ext2 fs is not a solution to the original problem, 
proof of a bug with fsck, proof of a corrupt VFAT, or unsuitability of using 
an ESP.  However, it soon got the PC booting again, so at least it satisfied 
that objective (booting, sooner).  :-)

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

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

[Michael]

[-- 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 --]

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

[Neil Bothwick]

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

On Sun, 13 Dec 2020 14:17:18 +0000, Michael wrote:

> 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.  :-)

Whatever works for most other people is a good choice if you may need
support in the future :)


-- 
Neil Bothwick

"Energize!" said Picard and the pink bunny appeared...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 4175 bytes --]

On 13/12/2020 14:17, Michael wrote:
> 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.
> ...
> 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.

Well, I don't dispute the validity of ext2 as a choice. Or any other 
filesystem that the bootloader can read really - that's a perfectly 
valid statement.

I was merely 'going further' as a suggestion purely in the sense that in 
this day and age there's hardly any reason to not be using a journaled 
filesystem even for /boot.

As you say, /boot is written to rarely so the overhead of a journal is 
negligible and for all intents and purposes can be ignored completely. 
Disk space itself these days is really not a concern at all (unless on a 
really really archaic machine) - let alone for a small boot partition - 
so that too can be ignored as a contributing factor. Data integrity, on 
the other hand, is far more critical. I have had ext2 fail on me during 
a system crash when updating a kernel back in the days a number of 
times, so I personally did away with ext2 as a /boot filesystem about 
15y ago. Not surprisingly most distros will default to ext3/4 for /boot 
as well. But ultimately, we are free to decide ourselves.

>>> 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.

Well.. naturally, this isn't what I meant :)

But you can have your boot fs (e.g. vfat/ext[2/3/4]) mounted under 
"/boot" and your EFS partition (vfat) mounted under "/boot/efi". The 
actual EFI directory that you speak of would then be under 
"/boot/efi/EFI". I used this as an example but, naturally, one can use 
any mount point that suits and it doesn't have to be under /boot.

For the sake of the example, perhaps a better choice of naming would 
have been "/boot/efs".

 > 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.

Absolutely! I actually love this aspect about UEFI. It's a brilliant 
idea, but for some reason I always found it somewhat fiddly. Perhaps the 
lack of being able to alter the kernel command line prior to booting has 
put me off. Though I have to admit, I too am susceptible to "old habits 
die hard" and have always stuck to chainloading GRUB and never really 
thought much about it :)

 > 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.:-)

This! When people ask why I go through all the pain of using Gentoo and 
literally seeing myself getting older in the mirror while waiting for 
packages to compile (or portage to finish resolving dependencies) I 
always give this as my first argument - you can do whatever you want 
with this distro, it's that flexible... And we all love Gentoo for it


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Neil Bothwick]

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

On Sun, 13 Dec 2020 15:02:10 +0000, Victor Ivanov wrote:

> > 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.  
> 
> Absolutely! I actually love this aspect about UEFI. It's a brilliant 
> idea, but for some reason I always found it somewhat fiddly. Perhaps
> the lack of being able to alter the kernel command line prior to
> booting has put me off. Though I have to admit, I too am susceptible to
> "old habits die hard" and have always stuck to chainloading GRUB and
> never really thought much about it :)

You can use a minimal boot manager to be able to change kernel parameters
with UEFI.


-- 
Neil Bothwick

Nostalgia isn't what it used to be.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Thomas Mueller]

Excerpt from Michael:

> 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.

Is it necessary for the ESP to be FAT32, as opposed to FAT16 or FAT12?

What happens if the ESP is formatted FAT12 or FAT16?

In some cases, ESP might be small enough that FAT32 would not be appropriate, especially when there is only one OS installation on the disk.

That would be the case on many MS-Windows or Mac computers, and also other OSes when installed on a USB stick.

Tom

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

[Michael]

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

On Monday, 14 December 2020 05:41:46 GMT Thomas Mueller wrote:
> Excerpt from Michael:
> > 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.
> 
> Is it necessary for the ESP to be FAT32, as opposed to FAT16 or FAT12?

Looking again at the UEFI firmware specification it states "... encompasses 
FAT32 for a system partition, and FAT12 or FAT16 for removable media" and that 
the "variant of EFI FAT to use is defined by the size of the media".

So, there is no *must use FAT32* as such in the specification, although it can 
be inferred from the way it is written that a system partition, defined as "a 
contiguous grouping of sectors on the disk", will use FAT32.  On removable 
devices (diskettes) the partition is defined to be the entire media and space 
limitations apply.  Other removable devices may have more space and a call 
will be made accordingly.  I suppose if you have an ESP no larger than 16 MiB 
(4K clusters) and you can fit all your boot manager/OS loader files in there, 
you would use FAT12.


> What happens if the ESP is formatted FAT12 or FAT16?

I expect it would/should be read by the UEFI firmware and is suitable for 
space limited systems.  Most PC installations have GBs of space on their 
disks, so avoiding FAT32 wouldn't make much sense.


> In some cases, ESP might be small enough that FAT32 would not be
> appropriate, especially when there is only one OS installation on the disk.
> 
> That would be the case on many MS-Windows or Mac computers, and also other
> OSes when installed on a USB stick.
> 
> Tom

Right, but a USB stick is probably considered "removable media" and its space 
could be deemed as limited.

I loosely recall AppleMac boot partitions being ~200MB and MSWindows ~300MB, 
but don't have a machine to hand to check right now.  For most use cases even 
with multiple OSs installed, that's probably enough space to fit FAT32. 

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

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

[Wols Lists]

On 14/12/20 05:41, Thomas Mueller wrote:
> Excerpt from Michael:
> 
>> 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.
> 
> Is it necessary for the ESP to be FAT32, as opposed to FAT16 or FAT12?
> 
> What happens if the ESP is formatted FAT12 or FAT16?
> 
I think the spec actually says it must comply with a specific version of
the FAT definition. Not sure which version, but that does specify all
three FAT layouts, so all three are acceptable. Look at mjg's blog for
more detail, I guess.

That protects against updates to the spec making incompatible changes,
but doesn't protect against clueless manufacturers not following the
spec - "works with Windows" is so often the de-facto spec.

Cheers,
Wol