mount: unknown file system type "vfat" during boot - after update

millz · 2014-03-11 13:44:00

Hey Guys,

I got an critical issue with my arch installation. After my last update (pacman -Syu) a couple of hours ago, I got trouble with my booting sequence. After the reboot I read the message: "Failed to mount /boot/efi". You see the full message here: http://imgur.com/q4TSRYW

My System was working perfect for a lot of weeks now, but after this recent update, this issue can not be solved by myself. It is something about the kernel and the boot sequence. But googling and searching the forum just helped to find this out. No solution . Maybe you guys can help me to figure out a proper solution? would be quiet nice.

Thanks in advance.

millz

ps: "Unbekannter Dateisystemtyp vfat" means "unknown file system type vfat"

brain0 · 2014-03-11 13:49:36

This should be in some FAQ. Obviously, your /boot partition or bootloader is not configured properly. Thus, during update, the new kernel is installed, but not to the place where your bootloader looks for it. Thus, you boot the old kernel, but your hard drive only has the new modules.

Your inability to mount vfat partitions is only one of many failures that you will see until you fix this.

WorMzy · 2014-03-11 14:00:43

It might be advisable for people on EFI systems to add vfat to their MODULES array in mkinitcpio.conf, so that when this happens, they can still mount their ESP and sync the correct kernel+initrd.

@OP: The easiest way to fix this is to downgrade your linux package to whichever version you're inadvertently booting with (uname -r will tell you which), then mount your ESP, then update the linux package again and ensure that the kernel and initrd are copied to the right place for your bootloader/manger.

brain0 · 2014-03-11 16:58:36

WorMzy wrote:

ensure that the kernel and initrd are copied to the right place for your bootloader/manger.

If this requires any extra copying, your setup is broken anyway.

WorMzy · 2014-03-11 17:49:30

True, so OP should fix that once they have their ESP mounted, or else they'll find themselves in the same situation next time there's a kernel update.

mrunion · 2014-03-11 17:57:13

brain0 wrote:

WorMzy wrote:
ensure that the kernel and initrd are copied to the right place for your bootloader/manger.
If this requires any extra copying, your setup is broken anyway.

I consider my setup "broken" because I have to copy my rebuilt kernel, et. al. myself every time I upgrade. And if I forget, the OP's issue happens to me.

But it does seem to me that the script(s) required to make things "auto copy" are just as "hackish" as having to remember to do the copying anyway. Also, when I installed my original UEFI stuff over a year ago, it seems that /boot/efi/EFI/arch was the "recommended" place for the kernel, et. al. Now it seems that this information has changed. Should I go back and rework that stuff now that things seemed to have stabilized more WRT EFI?

jasonwryan · 2014-03-11 18:03:06

mrunion wrote:

Also, when I installed my original UEFI stuff over a year ago, it seems that /boot/efi/EFI/arch was the "recommended" place for the kernel, et. al. Now it seems that this information has changed. Should I go back and rework that stuff now that things seemed to have stabilized more WRT EFI?

This is what I did. Once gummiboot supported an ESP on /boot I moved it to avoid having to use the service file to copy the kernel and initrd across (that just seemed so fragile). It took about five minutes, all up.

WonderWoofy · 2014-03-11 19:33:05

I switched from having the ESP mounted at /boot to having it at /boot/efi. I did this because I use btrfs and in order to successfully roll back the rootfs (which I have actually never needed...) it would require that the kernel and initramfs be snapshotted with the rest of the rootfs. So I use the systemd.path and systemd.service to copy everything into place. It actually seems pretty reliable.

But I also have rEFInd set up as a backup boot manager. So I can go from my normal gummiboot to rEFInd, which I have set up with a couple manual boot stanzas to be able to read the kernel and initramfs off the btrfs filesystem. So even in the event that the copy mechanism does fail, I can always boot with this method to fix things.

Now that I am thinking about all this, maybe I should go back to mounting it at /boot. I have never had to use either of the fallback solutions that I have set up, and I also have the archiso set up to be booted in a loopback with grub-efi. That makes three fallbacks... which is probably two more than I need.

Edit: splling

Last edited by WonderWoofy (2014-03-11 19:34:24)

mrunion · 2014-03-11 20:15:02

OK. I may try that next weekend (can't this one because of previous commitments). I use rEFInd, but it seems most use Gummiboot. I thought about using SysLinux, but I don't know about that move. I want some way to boot my Kernel in case there is a problem with rEFInd and the ESP boot loader causing hangs again. I was only bitten that way once, but once was enough!

Anyway, I've got a bit 'o work to do on my booting it seems. I assume it's as easy as(tm):

Move boot mount from /boot/efi/EFI/arch to /boot
Update any mount info wherever it may be (fstab, boot entries in config(s), etc.)

Last edited by mrunion (2014-03-11 20:17:01)

WonderWoofy · 2014-03-11 20:32:28

mrunion wrote:

Move boot mount from /boot/efi/EFI/arch to /boot

Wait... you are mounting at /boot/efi/EFI/arch? I think the idea is to actually mount the ESP at /boot/efi, then from the $ESP, you would keep the kernel in $ESP/EFI/arch.

But mounting the ESP at /boot will definitely make things much simpler. It will just write the kernel and initramfs to the default places, which will also be at the top of the ESP's filesystem.

I have also heard of people mounting the ESP somewhere entirely non-standard (if there is a real 'standard'), then bind mounting $ESP/EFI/arch to /boot. This seems to make a lot of sense to me, but I am not sure where I would put the ESP...

WorMzy · 2014-03-11 20:46:23

WonderWoofy wrote:

I have also heard of people mounting the ESP somewhere entirely non-standard (if there is a real 'standard'), then bind mounting $ESP/EFI/arch to /boot. This seems to make a lot of sense to me, but I am not sure where I would put the ESP...

That's pretty much what I do.

UUID=DA2E-688C              /mnt/efi         vfat defaults         0 2
/mnt/efi/EFI/arch           /boot            none bind             0 0

Works for me.

millz · 2014-03-12 00:04:59

Hey guys,

i'm still a bit unsure about what to do. Booting /dev/sda1 somewhere isn't working, due to the missing vfat module - even after adding it to the modules array in mkinitcpio.conf and creating the frames by typing "mkinitcpio -p linux". After restarting the machine, I got faced with the same message:

[FAILED] Failed to mount /boot/efi
See 'systemctl status boot-efi.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
Welcome to emergency mode! After logging in, type "journal -xb" to view systemlogs, "systemctl reboot", "systemctl default" to try again to boo into default mode.
Give root password for maintanance
(or press Control-D to continue: _

I tried them all. Allways facing this error. The maintanance mode even has no ethernet connection, so i can not connect the web . To fix it as soon as possible, it would be fine to fix it "hackish". Just saving the commands in scripts as proposed by mrunion. This is my productive machine :-(.

Thanks!

~millz

WonderWoofy · 2014-03-12 00:14:38

Your running kernel is not the same as what is installed by pacman. So whatever kernel version you have on the ESP that is being booted, does not match the modules in /usr/lib/modules.

You need to fix that.

millz · 2014-03-12 10:40:32

Hey Guys,

i downgraded my Kernel to 3.12. This works for the moment. Nevertheless, I've to fix the EFI-booting issue asap.
Reinstalling grub by using gummiboot has not solved this issue. Therefore, I need some more effort and time, I don't have right now. this is probably a project for the weekend .

Insofar, this post is going to be continued. Just mentioned here: I'm still lacking of some specific internal details to understand the procedure right and get this issue instantly solved by myself.
What I got: the kernel modules installed in the system mismatch the kernel modules in the booting sequence (uname -r differs to /usr/lib/modules). Just need to figure out how to solve this.

all the best. keep in touch. thanks!

mrunion · 2014-03-12 22:55:16

OK, I grabbed a few minutes. Here is a quick request for a sanity check.

My fstab:

# /dev/sda7
UUID=153a2874-ad30-4251-9031-2bdaa993a11b	/         	ext4      	rw,relatime,data=ordered	0 1

# /dev/sda6
UUID=7249-22CA      	/boot/efi 	vfat      	noatime	0 2

Now, I would add/change:

# /dev/sda6
# old line
#UUID=7249-22CA      	/boot/efi 	vfat      	noatime	0 2
UUID=7249-22CA      	/mnt/efi 	vfat      	noatime	0 2

/mnt/efi/EFI/arch           /boot            none bind             0 0

to fstab, correct?

I am using rEFInd, so my refind_linux.conf can stay:

root=/dev/sda7 rw rootfstype=ext4 systemd.unit=graphical.target acpi_osi=Linux acpi_backlight=vendor rcutree.rcu_idle_gp_delay=1

correct?

Is that about right?

(Thanks in advance! I'm kinda paranoid about messing with things that are working.)

Last edited by mrunion (2014-03-12 23:22:50)

WorMzy · 2014-03-12 23:33:53

Assuming that your ESP has the same layout you've described (e.g. $ESP/EFI/arch is where your kernel+initrd is), that should work.

Make sure that /mnt/efi exists (I'm not sure if systemd still creates directories if the mount point doesn't exist any more).

Your refind-linux.conf entry is a bit lacking.. Here's mine for comparison:

"Boot with defaults"    "root=PARTUUID=7dd88669-b5d3-4ec8-ab21-d59dfdc3f8fe rootfstype=btrfs rootflags=subvol=__active rw quiet initrd=/EFI/arch/initramfs-linux-mainline.img"

mrunion · 2014-03-13 00:00:40

Thanks, WorMzy. I have made a few changes. I will now attempt to reboot.......(GASP!)

mrunion · 2014-03-13 00:08:37

....and back!

Reboot was successful! Thanks all!

(Now, maybe I'll try SysLinux.......hmmmmm.)

Arch Linux

#1 2014-03-11 13:44:00

mount: unknown file system type "vfat" during boot - after update

#2 2014-03-11 13:49:36

Re: mount: unknown file system type "vfat" during boot - after update

#3 2014-03-11 14:00:43

Re: mount: unknown file system type "vfat" during boot - after update

#4 2014-03-11 16:58:36

Re: mount: unknown file system type "vfat" during boot - after update

#5 2014-03-11 17:49:30

Re: mount: unknown file system type "vfat" during boot - after update

#6 2014-03-11 17:57:13

Re: mount: unknown file system type "vfat" during boot - after update

#7 2014-03-11 18:03:06

Re: mount: unknown file system type "vfat" during boot - after update

#8 2014-03-11 19:33:05

Re: mount: unknown file system type "vfat" during boot - after update

#9 2014-03-11 20:15:02

Re: mount: unknown file system type "vfat" during boot - after update

#10 2014-03-11 20:32:28

Re: mount: unknown file system type "vfat" during boot - after update

#11 2014-03-11 20:46:23

Re: mount: unknown file system type "vfat" during boot - after update

#12 2014-03-12 00:04:59

Re: mount: unknown file system type "vfat" during boot - after update

#13 2014-03-12 00:14:38

Re: mount: unknown file system type "vfat" during boot - after update

#14 2014-03-12 10:40:32

Re: mount: unknown file system type "vfat" during boot - after update

#15 2014-03-12 22:55:16

Re: mount: unknown file system type "vfat" during boot - after update

#16 2014-03-12 23:33:53

Re: mount: unknown file system type "vfat" during boot - after update

#17 2014-03-13 00:00:40

Re: mount: unknown file system type "vfat" during boot - after update

#18 2014-03-13 00:08:37

Re: mount: unknown file system type "vfat" during boot - after update

Board footer