You are not logged in.
A few months ago I posted this topic: https://bbs.archlinux.org/viewtopic.php?id=251089
I solved the issue by downgrading the linux kernel and manually enabling the vfat module with modprobe, and then upgrading.
I'm forced to do that every time kernel is updated. Yesterday I updated, and I specially tested if the problem's come again - after kernel update I called modprobe vfat and I got this:
modprobe: FATAL: Module vfat not found in directory /lib/modules/5.4.8-arch1-1
I have not rebooted yet - but I know how to fix it - downgrade to the previous version -> modprobe vfat -> upgrade to the actual version -> reboot. But honestly I'm tired.
Any help on how to enlighten my system will be appreciated.
Last edited by maru (2020-02-11 10:35:42)
Offline
The problem is the same as it was in the previous thread, your boot partition was not mounted when you did your system upgrade. This is clear from the version number in the error message.
The solution is the same as in the previous thread: fix your system so that your boot partition is properly mounted. This is either a problem with your fstab, or you have some other process deliberately unmounting the boot partition after boot up is complete. Occasionally people will advise unmounting the boot partition as some sort of unspecified security measure - but it will lead to exactly the probelm you are facing.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
The problem is the same as it was in the previous thread, your boot partition was not mounted when you did your system upgrade. This is clear from the version number in the error message.
The solution is the same as in the previous thread: fix your system so that your boot partition is properly mounted. This is either a problem with your fstab, or you have some other process deliberately unmounting the boot partition after boot up is complete. Occasionally people will advise unmounting the boot partition as some sort of unspecified security measure - but it will lead to exactly the probelm you are facing.
Thanks for the reply.
I honestly don't know what you mean by "boot partition is not properly mounted" as lsblk returns me this:
sda 8:0 0 223.6G 0 disk
|-sda1 8:1 0 55G 0 part /
|-sda2 8:2 0 954M 0 part /boot
`-sda3 8:3 0 139.7G 0 part /home
It looks like it's mounted.
Please, also see my /etc/fstab:
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda1 UUID=830d4321-e872-45ca-86af-abb56830e153
LABEL=Arch / ext4 discard,rw,relatime 0 1
# /dev/sda2 UUID=564B-6478
/dev/sda2 /boot vfat discard,rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
# /dev/sda3 UUID=0322a2bc-e9a6-4bf0-ab3b-677db092ce2a
LABEL=Home /home ext4 discard,rw,relatime 0 2
I want to solve the issue - so if you need more detail I can provide. Currently I left here what you were referencing to.
Offline
Then your conclusions are wrong. If that is and was indeed the case before the update then your kernel will have been written correctly. If you try to modprobe vfat after the update, that is going to fail - expectably - because you (resp. the update) replaced the module. However at this point a simple reboot without a downgrade should be sufficient.
In general don't use /dev/sda2 in your fstab, that's unstable and not guaranteed use the UUID instead. I'm also not sure whether discarding is a good idea on a FAT partition and it might lead to corruption, so it's likely safer to omit that.
Last edited by V1del (2020-01-16 14:26:58)
Offline
modprobe: FATAL: Module vfat not found in directory /lib/modules/5.4.8-arch1-1
I have not rebooted yet
Pacman won't allow two versions of a package to be installed, so the old modules get removed before the new modules are installed.
But honestly I'm tired.
Try [AUR] kernel-modules-hook. YMMV.
Tired of missing modules when updating the kernel?
--
saint_abroad
Offline
You have a lot of mount options to your boot partition. Is there a reason for them, or where did you get that list? The remount-ro on error stands out to me. I'm not familiar with how that option works, but if your boot partition is (even occasionally) remounted as ro, that would definitely explain your symptoms. I'd prefer to deal with any error and get to the root of the problem rather than mask it by remounting ro which leads to new (and initially mysterious) errors.
I'd bet that option is the source of your ongoing issues.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
You have a lot of mount options to your boot partition. Is there a reason for them, or where did you get that list? The remount-ro on error stands out to me. I'm not familiar with how that option works, but if your boot partition is (even occasionally) remounted as ro, that would definitely explain your symptoms. I'd prefer to deal with any error and get to the root of the problem rather than mask it by remounting ro which leads to new (and initially mysterious) errors.
I'd bet that option is the source of your ongoing issues.
If I remember correctly, I tried to run swap partition support in my system earlier, and the problem came in a few weeks after the attempt.
However, I replaced /dev/sda2 with UUID, removed discard option (no changes there were), then removed "errors=remount-ro" and it worked well, boot now has no issues.
No idea what that option means, but something tells me it sets the boot partition to be read-only or something like that, which has something to do with the issues I experienced.
Last edited by maru (2020-01-16 17:15:30)
Offline
No idea what that option means
If there are any errors then the filesystem will be remounted read-only. So have you checked the /boot partition for errors?
# fsck.vfat /dev/sda2
I think the option does make sense for a FAT-formatted partition, it will limit the extent of any damage. Just removing the option might not actually fix your problem if the filesystem is already damaged.
Offline
maru wrote:No idea what that option means
If there are any errors then the filesystem will be remounted read-only. So have you checked the /boot partition for errors?
# fsck.vfat /dev/sda2
I think the option does make sense for a FAT-formatted partition, it will limit the extent of any damage. Just removing the option might not actually fix your problem if the filesystem is already damaged.
I don't know what errors there could be, and how to check the partition for errors? The error itself was that the vfat module for some reason wasn't loading at boot time because it wasn't found in new kernel modules' directory so that's why I guess boot partition wasn't able to mount.
Last edited by maru (2020-01-16 20:39:33)
Offline
I don't know what errors there could be, and how to check the partition for errors?
From post 8
fsck.vfat /dev/sda2
I honestly don't know what you mean by "boot partition is not properly mounted" as lsblk returns me this
lsblk shows you what block devices are hooked to the machine, not what's mounted.
Offline
I honestly don't know what you mean by "boot partition is not properly mounted" as lsblk returns me this
lsblk shows you what block devices are hooked to the machine, not what's mounted.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
...
|-sda2 8:2 0 954M 0 part /boot
So the mountpoint field showing /boot does not mean it was mounted to /boot when lslk was executed?
Offline
I don't know what errors there could be, and how to check the partition for errors?
He showed you how to check in the post you replied to: use fsck.
The error itself was that the vfat module for some reason wasn't loading at boot time because it wasn't found in new kernel modules' directory so that's why I guess boot partition wasn't able to mount.
Yes and no. That is the error you are dealing with in this thread. But the only reason this problem existed was because your boot partition was (at least on some occasions in the past) mounted read-only. Or at least this is the inference we are working on. It is a very sound, plausible, and highly parsimonious inference.
But this leaves the question of why the boot partition was mounted read only. The option listed in your fstab means that it will be mounted read only if some other error occurs. So there was some yet-unspecified error which resulted in boot being mounted read-only which in turn resulted in the main symptoms at the start of this thread.
The yet-unspecified error is what we should search for now - and fsck is good way to look for this.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
No idea what that option means
There's not been said enough about this, read 'man mount' and absorb the 'default' option, and after that read the whole thing..
For instance on the boot partition you can remove a few options by just setting 'default'
Also, discard is an option, but, you may not even want to set it, also read that part in the manual.
Offline
from my own /etc/fstab :
UUID=B19D-6501 /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
I'm not 100% sure but think the mount options were added by genfstab -U /mnt >> /mnt/etc/fstab during installation (dec 2018) .
(I use refind-efi with /boot on root partition , the ESP rarely needs changes. )
Last edited by Lone_Wolf (2020-01-17 11:45:11)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
@Lone_Wolf, I don't use refind, but I bet you have read the manual, you too can remove some by using 'default'.
For instance 'iocharset=iso8859-1', that's a default...
genfstab is a helper tool, you can create your own fstab the way you like it.
edit: I think you can replace that whole line by just setting 'defaults', though, don't hold me accountable check the manual
Last edited by qinohe (2020-01-17 14:54:21)
Offline
The options are applied automatically by the kernel if a FAT partition is mounted without arguments or an fstab line:
empty@E485:~ $ sudo mount /dev/nvme0n1p1 /mnt
empty@E485:~ $ grep mnt /proc/self/mounts
/dev/nvme0n1p1 /mnt vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
empty@E485:~ $
So I think the defauls option would have the same effect.
Anyway, we're getting a bit diverted here
Offline
Yes, the default options would have the same effect. I'll take the blame on questioning that option: I was not familiar with it. But that option is the proximate cause of the issue. The root cause is whatever is resulting in the error triggering the readonly remount - and that's where we should focus now rather than on the mount options.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
It almost sounds like your bootloader is loading the kernel from the root partition instead of the /boot partition.
Offline
Is your system using EFI? If it's not, why you would use vfat instead of ext4 for the /boot partition or have a /boot partition at all?
Last edited by paulkerry (2020-01-17 21:38:20)
Offline
The issue solved itself after some time. It appeared only one time a few days ago, but then everything I needed is just rebooting.
Thanks.
Offline