[SOLVED] Failed to mount /boot ... unknown filesystem vfat

Midnight Sun · 2015-03-13 22:45:50

Hi everybody,

Thanks for looking.

I have one boot partition, three linux OS partitions (called Black, White and Grey), and one home partition. I use gummiboot EFI.
The boot process allows me to chose one of the OS partitions and mounts it at / , with boot at /boot , and home at /home.
Before i do a pacman -Syu I use fsarchiver to copy the current OS partition (black) to the backup partition (White), then I edit the UUID, hostname, and fstab on the backup to avoid confusion. That way if the upgrade has a problem I can still boot my system as before. I use the Grey OS for fiddling about and breaking things. I've used this set-up for ages without problems.

Recently I backed-up Black to White, and did a pacman -Syu on Black, all worked fine straight away. But when I went to boot Grey I found a problem, and the backup OS White has the same problem...
I get the boot error "Failed to mount /boot", and if I do systemctl status boot.mount i get "Mount: Unknown filesystem vfat".
I can boot Black, but if I try to boot White or Grey all I can do is boot into Emergency Mode.

While searching the forums for some ideas I discovered that when booted into the upgraded Black uname -a and pacman -Qi linux both give the same answer: linux 3.18.6-1
but when booted into emergency mode pacman -Qi linux gives linux 3.17.6-1, but uname -a gives linux 3.18.6-1

I tried pacman -Syu while booted into Grey in Emergency Mode, but there is no network... "ping: Unknown host www.google.com" , and ip link doesn't show my ethernet device, only "LO: loopback"

Does anybody have any ideas about...

Why Mount can't mount the vfat filesystem.
How I can restart the ethernet to access the internet.
Why uname and pacman differ on the version of linux.
If I'm looking in the right direction to solve this problem at all.
Any other suggestions.

Any advice much appreciated.
Rich.

Last edited by Midnight Sun (2015-03-14 22:25:54)

jasonwryan · 2015-03-13 22:55:08

You'll need to chroot into Grey and White, ensure /boot is mounted (which it wasn't during your last kernel upgrade), rerun the upgrade or reinstall the kernel and make sure the initrd is regenerated and then all of your modules (including vfat and whatever ethernet one is required) will be available to the new kernel.

Midnight Sun · 2015-03-13 23:06:13

Oh fantastic. Thanks for the response.

So... I need to boot Black, then mount Grey (then White) to a tempory point, say /mnt/Grey and mount boot at /mnt/Grey/boot, then chroot to /mnt/Grey ?

Then I can do pacman -Syu to upgrade the OS, but will that make sure the initrd is regenerated, or is that a seperate thing?

I'll look up initrd.

Thanks jasonwryan

jasonwryan · 2015-03-13 23:18:09

You just need to reinstall linux (that way the correct modules for that kernel will be available), the post install script will run mkinitcpio, just make sure it is all tidy before exiting the chroot.

You could also use pacstrap on the mounted filesystem, I suppose.

Midnight Sun · 2015-03-14 11:34:47

I'm a bit confused now.

When you say "reinstall linux", I don't want to do anything that changes the White or Grey OSs. The point of having them is that they are different to OS Black.

When you say "/boot wasn't mounted in my last kernel upgrade", I don't understand how Black is booting then.

Also, White and Grey were able to mount the vfat filesystem before, and they haven't changed, so what has changed must be in the boot partition. Right?

I'm reading about gummiboot and UEFI bootloaders/managers... there is lots to read!

I'm wondering, do the old kernels in White and Grey need to each have their own initramfs to match. If so I have probably overwritten it when I upgraded Black. Does that make sense?

Spider.007 · 2015-03-14 12:46:10

jasonwryan meant the linux package

Midnight Sun · 2015-03-14 14:06:49

Hi Spider.007

The thing is I don't want to upgrade the package on White or Grey, I want to continue to boot the old version.

I'm wondering if I should use mkinitcpio to create a /boot/initramfs-linux-Grey.img for the 3.17.6-1 kernel using:

# mkinitcpio -g /boot/initramfs-linux-Grey.img -k 3.17.6-1-ARCH

see the wiki entry here

Don't understand how it works fully, but I'm assuming when I try to boot Grey or White the initramfs it finds in the boot partition refers to the new kernel, and doesn't work with the old kernel.

Anybody got any thoughts on this?
or am I talking rubbish?

nagaseiori · 2015-03-14 14:39:32

When you updated Black you probably overwrote the kernel for Grey and White. You would either have to use different boot partitions or rename your kernel.

Midnight Sun · 2015-03-14 15:36:47

Is the whole kernel kept in /boot ?

If so then I definitely overwrote it, but then why doesn't it work for White and Grey as well as Black.

If the kernel is not in /boot then White and Grey would have been unaffected as they were not mounted when I upgraded Black.

I don't understand why White and Grey can't mount the vfat partition. They could before the upgrade and Black can after the upgrade. So if they didn't get upgraded they should still be able to, and if they did get upgraded they should be able to now just like Black?

I've tried booting Grey using the fallback initramfs-linux-fallback.img which has a wider set of hooks, but that makes no difference.

The boot error message says "Mount: unknown filesystem vfat", if mount depends on the kernal for that it shouldn't make any difference as both the old and new kernels have been able to mount the vfat filesystem.

I'm lost..... don't know where to start looking.

Head_on_a_Stick · 2015-03-14 16:11:58

From all three systems, post the output of:

lsblk -f

EDIT: Nevermind; I should have read more carefully -- see the post below.

Last edited by Head_on_a_Stick (2015-03-14 16:21:12)

nagaseiori · 2015-03-14 16:19:08

Yes, the kernel is in /boot. When you updated to a newer version on Black, it overwrote the kernel for Grey and White. It can't mount the vfat partition because the modules (which are stored in /usr/lib on each system) are out of sync with the kernel version.

ewaller · 2015-03-14 17:41:50

You can extend your model to include the kernel. When you copy white to black you need to also, in /boot/, copy the white kernel and white initrd (initramfs-linux.img, vmlinuz-linux) to a 'black' version of those files. Adjust your bootloader configuration to pick up those black versions when you boot black.

Midnight Sun · 2015-03-14 17:56:34

Thanks nagaseiori.

That is very clear and fits all the questions I have.

So, like you said before, I need "to use different boot partitions or rename your kernel".

When you say "rename your kernel", do you mean have three versions of vmlinuz-linux in /boot, each with different names, eg-

vmlinuz-linux-Black
vmlinuz-linux-White
vmlinuz-linux-Grey

And then each entry in the boot list would refer to a different / partition and kernel pair.

I am looking into kernel installation and pacman.

Is it practical to work from my Black OS, mount the Grey OS partition to /mnt, mount /boot to it, chroot to /mnt and use pacman to install the old kernel under a new name?

Thanks again.

Midnight Sun · 2015-03-14 18:09:09

Thanks ewaller,

Yes I see know.

So if I had that set up and I did a pacman -Syu while booted into one of the systems it would only affect that OS and that OS's relevant files in /boot

But on kernel updates would pacman expect a file called /boot/vmlinuz-linux ?

ewaller · 2015-03-14 18:34:09

Midnight Sun wrote:

But on kernel updates would pacman expect a file called /boot/vmlinuz-linux ?

A kernel update will create vmlinuz-linux, but won't care if there was not a file by that name already in existence. If there is none, it will create it. If there is one, it will overwrite it.

Midnight Sun · 2015-03-14 19:30:53

Thanks ewaller,

In that case here is my plan...

Back-up all partitions (you never know)

Boot into the Arch live CD

Mount Grey partition at /mnt/Grey

Mount boot partition at /mnt/Grey/boot

Rename all the files in /mnt/Grey/boot so they can be used later for the Black OS

chroot into /mnt/Grey

Use pacman -U /mnt/Grey/var/cache/pacman/pkg/linux-3.17.6-1-x86_64.pkg.tar.xz to install the old 3.17.6-1 kernel

Rename new files in /mnt/Grey/boot to differentiate between Black and Grey

Edit entries in boot list to connect right files and OSs

Exit chroot and shutdown

Reboot

ewaller · 2015-03-14 19:49:36

That looks correct.

Midnight Sun · 2015-03-14 22:08:48

Worked perfectly!
Such a huge relief!

I created directories Black, White, and Grey to separate the boot files. Then I added /black, or white or grey, to the entries in the boot list.

A very frustrating day (I had other work to do) turned into a very satisfying day. I learned a lot, and gained in confidence: always thought of kernal files as too dangerous to touch.

Thanks to everyone that helped, and for your very clear answers to my faily ignorant questions.
I hope one day I can help someone else in a similar way.

Cheers,
Rich.

ewaller · 2015-03-14 23:02:53

Midnight Sun wrote:

I learned a lot, and gained in confidence: always thought of kernal files as too dangerous to touch.

Great!

As an aside... I came here from Gentoo. One of the things about Gentoo is that you come to find that kernels, although intimidating, are not all that difficult. When you have time, you might try building a kernel. Maybe even try using it This system has a custom kernel with all of the drivers I need for this system built in so I don't need an initrd to boot it. It lives along side the stock kernel, and which kernel I use is selected at boot time. If you have a spare system and you want to really (really) want to learn about how to put a kernel together, install Gentoo sometime. It is an eye opener. The Gentoo handbook, although the penultimate guide for Linux distos is, without a doubt, the best guide on how to build a kernel.

Last edited by ewaller (2015-03-14 23:03:06)

Arch Linux

#1 2015-03-13 22:45:50

[SOLVED] Failed to mount /boot ... unknown filesystem vfat

#2 2015-03-13 22:55:08

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#3 2015-03-13 23:06:13

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#4 2015-03-13 23:18:09

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#5 2015-03-14 11:34:47

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#6 2015-03-14 12:46:10

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#7 2015-03-14 14:06:49

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#8 2015-03-14 14:39:32

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#9 2015-03-14 15:36:47

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#10 2015-03-14 16:11:58

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#11 2015-03-14 16:19:08

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#12 2015-03-14 17:41:50

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#13 2015-03-14 17:56:34

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#14 2015-03-14 18:09:09

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#15 2015-03-14 18:34:09

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#16 2015-03-14 19:30:53

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#17 2015-03-14 19:49:36

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#18 2015-03-14 22:08:48

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

#19 2015-03-14 23:02:53

Re: [SOLVED] Failed to mount /boot ... unknown filesystem vfat

Board footer