[SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

WebReflection · 2015-07-21 12:22:55

I am not sure what happens between two days ago and today/yesterday evening but genfstab keeps generating wrong /etf/fstab files ( 4 different machines out of 4 )

The script I use to install ArchLinux is the same since long time but yesterday I had to make all loglevel visible and notice that after installing the boot was always blocked and was going to emergency mode.

Once into emergency mode all I had to do was

genfstab -U -p / > /etc/fstab

rebooting and problem solved. However, I do the exact same in the installation script and it never failed but today? Before running arch-root it generates fstab with wrong disks UIDs and even once inside arch-chroot with all things working nice it creates wrong UIDs.

Only after a reboot post installation it generates the right /etc/fstab

I am not sure I've explained myself properly, but I wonder if there has been some change to either arch-chroot, genfstab, or pacstrap so that all I am missing maybe is just a flag.

Thanks in advance for any sort of help

Last edited by WebReflection (2015-07-27 07:23:04)

WorMzy · 2015-07-21 12:27:56

WebReflection wrote:

Once into emergency mode all I had to do was
genfstab -U -p / > /etc/fstab
rebooting and problem solved. However, I do the exact same in the installation script

You don't want to genfstab for / in the installation media, you should be using /mnt (assuming that is where the new root is mounted).

WebReflection · 2015-07-21 12:34:13

the script has bene working for almost a year now without problems and it does indeed what you said.

pacstrap archibold base sudo networkmanager syslinux gptfdisk arch-install-scripts intel-ucode
genfstab -U -p archibold > archibold/etc/fstab

where archibold is the mounting point.

If I check archibold/etc/fstab will contain UIDs that will not be valid once I reboot the machine.

What am I missing? Why suddenly doesn't work anymore? The project has been up and live for a while and worked on many platforms already. Same platforms now are failing and AFAICT I haven't changed that bit.

Thanks

WebReflection · 2015-07-21 12:41:28

P.S. forgot to mention: of course the script also removes the path from the generated fstab then the configuration is OK but UIDs are wrong and it won't boot regularly until I regenerate same way from the re-booted system.

Head_on_a_Stick · 2015-07-21 20:39:10

Beginner's Guide wrote:

The fstab file should always be checked after generating it, and edited in case of errors.

https://wiki.archlinux.org/index.php/Be … e_an_fstab

WebReflection · 2015-07-21 21:09:04

I know that, but the script, once again, has been working for almost a year now without problems.

last 2 days, without changing it, is unable to work on the very same hardware it worked before numerous times.

I've checked `arch-install-scripts` package ( genfstab ) and doesn't seem a possible cause, does anyone know if something changed in the way arch-chroot works recently?

Thanks

Last edited by WebReflection (2015-07-21 21:10:42)

Trilby · 2015-07-21 22:48:05

WebReflection wrote:

P.S. forgot to mention: of course the script also removes the path ...

So your script exploits genfstab to do something it wasn't meant to do, and now that genfstab stop doing that thing it wasn't supposed to do you think it's a problem? If you actually want help, share the code of this script. Right now were just guessing, and worse yet were guessing about things that you a forgetting to mention.

WebReflection · 2015-07-22 10:37:27

the project: http://archibold.io/
is on github: https://github.com/WebReflection/archibold.io
and this is the part that always worked before: https://github.com/WebReflection/archib … #L405-L411

the issue I have is that UID are different when I arch-chroot and to fix the issue I just need to reboot with the installed, but not bootstrapping, ArchLinux, go in emergency mode, and do what I've mentioned already

genfstab -U -p / > /etc/fstab

The script has been used to successfully install numerous platforms without a glitch and it's not just me using it.
https://twitter.com/Kambfhase/status/622769776021127168

The code is not beautiful or organized or anything, it's an installer helper that has been working for almost a year now.

Last 2 days genfstab started generating, within the archchroot environment, files with the wrong UID and moving that part outside or inside the archchroot space hasn't changed a bit.

But most important: I have asked if anyone knows if something changed to archchroot or genfstab recently, 'cause only recently I had problems.

If NO is the answer, which is OK, maybe it's a problem that comes indirectly from something else ... or maybe I use the July dual ISO version but when I update packages I bring in something different that recognizes UIDs differeently?

Did I say the only problem I have is about wrong UIDs ?

I might re-install the whole thing in another machine that used to work and post those differences in terms of genfstab, maybe that helps more ( it's just not exactly a 2 minutes tasks .. )

Regards

Trilby · 2015-07-22 11:07:28

That script needs a lot of improvement. In a couple minute perusal, I see a partial upgrade, several useless uses of cat, and a ill-advised and completely unnecessary (but likely benign) sed command modifying the genfstab output. Further it appends to the default fstab rather than creating a new one ~~- this could be the problem.~~

Hmm ... I just noticed that this is your own script. Sorry, I was under the impression this was someone elses tool you were using. Just the same, this is so full of kludges and bad ideas it's nearly impossible to figure out what the real issue is. Does genfstab used as advised work as expected?

(edit: toned down the snarkiness)

Last edited by Trilby (2015-07-22 21:22:40)

Raynman · 2015-07-22 12:28:02

You seem very focused on genfstab, treating it as some black box. It is also a script that you can inspect (including changes in the git web interface) and it doesn't pull these UUIDs out of a hat. You can also use lsblk or whatever to check UUIDs and see if they somehow change after a reboot. Maybe forget the script for a second, try a basic install step-by-step.

WebReflection · 2015-07-22 20:44:24

Raynman wrote:

You seem very focused on genfstab, treating it as some black box.

Actually I've checked the repository and realized no updated were made recently so I have excluded it, regardless (the ugly, ridiculous, don't use it and yada-yada mentioned already ) the script has been worked so I've asked if there was any change in the critical path which is genfstab and archchroot.

I haven't found time today to create those two diffs but I will for the sake of understanding,in case somebody else will have similar problems.

To Trilby, all I can say I have hand crafted that pile of poo out of researches and researches in this forum and Arch Linux documentation. It worked and the reason I use the generated fstab is because ArchLinux dual ISO boots properly and always recognized, 'till 3 days ago, the rigth UIDs for those hard drive.

The script does cleanups via sed so yeah, it looks ugly ... my OS, my wife OS, my friends OS, people on the internet, the Intel Compute Stick, as well as Gizmo 2 board and my old MacMini used that installer and are working today without problems.

You should check the helper for packages and AUR too, that's even more ridiculous

https://github.com/WebReflection/archib … /archibold

Best Regards

Trilby · 2015-07-22 20:55:18

Those cleanups via sed are not needed - in fact if the one for the fstab does anything at all, something is very wrong. When you pass the -p flag to genfstab the paths generated are relative to that mountpoint. So when you run `genfstab -p archibold` the resulting fstab will not contain 'archibold' - so your sed to remove it is superfluous. Genfstab is used in the beginner's guide and install guide - and there is no need to remove the mount point from the generated file.

WebReflection · 2015-07-22 21:13:32

Trilby wrote:

something is very wrong. When you pass the -p flag to genfstab the paths generated are relative to that mountpoint.

a replace that doesn't replace harms less than a missed replace. I am not sure those are needed, but I needed those at some point. Doing actually nothing, cannot be the reason I have problems right now, right?

Please bear in mind I'm not a Linux/Bash expert but I am, after all, a programmer ( like, you know, 15 years and counting )

Trilby wrote:

So when you run `genfstab -p archibold` the resulting fstab will not contain 'archibold' - so your sed to remove it is superfluous. Genfstab is used in the beginner's guide and install guide - and there is no need to remove the mount point from the generated file.

This is something I've learned right now thanks to you ( but really, I put that in 'cause it was needed at some point but thanks for pointing that out, maybe I should just drop that part ) but for what I can tell that was not the problem... I have to post those different genfstab modifying the script so it creates a snapshot I can post here and maybe this thread will have better results.

If you think I should change, at this point, the topic, I won't mind doing it since apparently genfstab is not the problem.

Best Regards

edit: I've changed the thread topic

Last edited by WebReflection (2015-07-22 21:17:03)

Trilby · 2015-07-22 21:26:46

Thanks for focusing on the issue rather than my snarky tone - though that leaves me to realize that my tone was uncalled for. My appologies. I've slightly revised my earlier post. But it does remain that that script does a lot of things in a very odd way - and frequently taking the long way around. You are right that the sed command is harmless - but as a general principle, having many useless but otherwise harmless steps just means there are more places for something to go wrong, or more places for an error to be missed.

Simplify this as much as possible first. Then the source of the error will likely be much easier to find. While I see many things that strike me as odd in your script, nothing jumps out as a potential cause of the issue you are facing in this thread. But as there are so many oddities and sufficient complexity, this is not suprising - nothing can jump out as a problem. So what is the minimal script you can create that will replicate the problem?

WebReflection · 2015-07-22 21:44:27

I will change the script in a way I can compare ( diff ) the generated /etc/fstab with the one I need to re-generate after. I will also snapshot lsblk or fdisk -l at installation time and compare with same result after it breakes.

I am afraid I am traveling tomorrow so this might be on for a little while but I will do come back with results and see if the cause was my ugly script or something else.

I've also found already cases where this re-generation of the /etc/fstab was needed ( other forums ) but I don't like unresolved cases so let's see if I'll end up, at least, helping others with similar potential issues.

I'll be back soon.

Best Regards

mauritiusdadd · 2015-07-23 09:16:47

Trilby wrote:

When you pass the -p flag to genfstab the paths generated are relative to that mountpoint.

Actually the -p flag is only used to exclude the pseudofs mounts and the paths generated should always be relative to the mountpoint specified.

So when you run `genfstab -p archibold` the resulting fstab will not contain 'archibold' - so your sed to remove it is superfluous.

That's not always true, if the mountpoint name ends with a / then the path generated for the root mountpoint is an absolute path: for example, let's assume that /dev/sda1 is the boot partition and /dev/sda2 is the root partition:

mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot

genfstab /mnt generates the correct fstab

genfstab /mnt
# UUID=47b16691-bc7f-4147-8157-b21b4b87e58d
/dev/sda2           	/         	ext4      	rw,relatime,discard,data=ordered	0 1

# UUID=2dee380a-179b-4356-9005-b53fb9f5c409
/dev/sda1           	/boot     	ext2      	rw,relatime	0 2

on the contrary genfstab /mnt/ generates a wrong fstab

genfstab /mnt/
# UUID=47b16691-bc7f-4147-8157-b21b4b87e58d
/dev/sda2           	/mnt         	ext4      	rw,relatime,discard,data=ordered	0 1

# UUID=2dee380a-179b-4356-9005-b53fb9f5c409
/dev/sda1           	/boot     	ext2      	rw,relatime	0 2

WebReflection · 2015-07-26 12:50:47

as promised, I've managed to find some time to better investigate what happens during the installation. Here the summary, if you are interested ( and the TL;DR version is that genfstab saves wrong UIDs in some EFI confguration )

Not a new "problem"
I asked if anyone knew about some change to genfstab, turned out my good old Asus Netbook with EFI 64 capable BIOS went up smooth without problems. Devices I've realized had problems with the EFI configuration suggested in the UEFI page related to efibootmgr

My Dell XPS 13 as well as Intel Compute Stick ( the one with 2GB and 32GB disk, 'cause the Ubuntu one with 1GB of RAM and 8GB of disk didn't have same problem ) were probably affected by this issue. For my dell I avoided EFI and used legacy boot and I haven't tried this ( 'cause you know, I use this PC daily ) but I can confirm on Intel Compute Stick generated UUID are wrong at installation time.

some myth-busting
Analyzing step after step my installer and what it was doing I can confirm these points:

the first cat after pacstrap is an empty file but it brings in the fewsh new created /etc/fstab comments with info
```
# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
```
the generated fstab with -U and -p flags creates fstab with paths absolute but fully resolved to the archibold directory ( instead of just / I have, as example, /root/archibold ) .. .so the replacement is necessary for my automation
using genfstab from outside arch-chroot and inside arch-chroot generates completely different fstab and the latter one won't work at all 'cause it does not use UUIDs

List of generated fstab
After the pacstrap, using

genfstab -U -p ./archibold

it creates this file

# /dev/mmcblk0p3
UUID=74478693-a216-40bc-83e5-7766c32c26a9	/root/archibold	ext4      	rw,relatime,data=ordered	0 1

# /dev/mmcblk0p1
UUID=4A26-45BD      	/root/archibold/boot/EFI	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2

# /dev/mmcblk0p2
UUID=8f63e150-8f80-4d2f-a0cd-732ccd2ed4ff	none      	swap      	defaults  	0 0

After replacing, the file will be like:

# /dev/mmcblk0p3
UUID=74478693-a216-40bc-83e5-7766c32c26a9	/	ext4      	rw,relatime,data=ordered	0 1

# /dev/mmcblk0p1
UUID=4A26-45BD      	/boot/EFI	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2

# /dev/mmcblk0p2
UUID=8f63e150-8f80-4d2f-a0cd-732ccd2ed4ff	none      	swap      	defaults  	0 0

If I generate with the same procedure and without replacing anything the fstab from within arch-chroot I have:

# /dev/mmcblk0p3
/dev/mmcblk0p3      	/         	ext4      	rw,relatime,data=ordered	0 1

# /dev/mmcblk0p1
/dev/mmcblk0p1      	/boot/EFI 	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2

# efivarfs
efivarfs            	/sys/firmware/efi/efivars	efivarfs  	rw,nosuid,nodev,noexec,relatime	0 0

# /etc/resolv.conf/etc/resolv.conf
/etc/resolv.conf/etc/resolv.conf	/etc/resolv.conf	none      	rw,relatime,bind	0 0

# /dev/mmcblk0p2
/dev/mmcblk0p2      	none      	swap      	defaults  	0 0

which won't work neither.

After reboot and login into emergency mode
Repeating the exact same procedure

genfstab -U -p /

will produce the following file

# /dev/mmcblk0p3
UUID=d3be21e1-71e6-4ed4-a69b-e27fb487dec5	/         	ext4      	rw,relatime,data=ordered	0 1

# efivarfs
efivarfs            	/sys/firmware/efi/efivars	efivarfs  	rw,nosuid,nodev,noexec,relatime	0 0

# /dev/mmcblk0p2
UUID=840e5bfb-9e72-48fd-b182-0e20e0c7e8b8	none      	swap      	defaults  	0 0

While one might think the problem could be in the efivars part, I can confirm even commenting that out the system will simply bootstrap without problems.

As Summary: I've got 2 problems!
After this testing I can confirm for sure in order to have a proper automation to install without a glitch my little system like I've done for almost a year now, and on different platforms, I have two problems I don't know how to solve:

how can I tell genfstab to find out UUIDs like it does after booting when these are clearly different and the only UUIDs that will work?
how can I understand if an EFI bios will work specifying the EFI folder, like I've usually done, instead of efivarfs ?

Specially latter point, if I comment out efivarfs it's OK but if I bring in the details of the /boot/EFI folder it won't even try to start at all ( direct emergency mode )

Thanks in advance to anyone that might have a clue on how to solve this issue.

[edit]
as alternative/workaround ... how can I tell a script to execute ASAP at the next boot ? in every case I've seen that Syslinux is initialized regardless, so if I could run a script only once at the very first boot, I might

genfstab -U -p > /etc/fstab

there directly and solve the issue. Thoughts or hints appreciated.

Last edited by WebReflection (2015-07-26 13:09:13)

Head_on_a_Stick · 2015-07-26 14:48:02

Have you tried not using an fstab at all?

empty@Arch ~ % cat /etc/fstab
cat: /etc/fstab: No such file or directory

http://www.freedesktop.org/software/sys … rator.html

This would only work on machines with single system disks (ie, root & $ESP on the same disk) using a GUID partition table.

WebReflection · 2015-07-26 19:20:50

I just removed

/etc/fstab

and it booted without a problem, I didn't know there was such magic behavior when gpt was used to create an EFI ready disk, this is pretty awesome!

I am reinstalling both the stick and the "legacy" good old Netbook to see how that goes, removing completely the usage of genfstab which is indeed ideal so I don't have to triple checks UUIDs , paths, and stuff ... will come back with results, let's hope that is it!

Thank You so far

WebReflection · 2015-07-26 23:03:13

OK ... tested without /etc/fstab and I've got other issues now.

/dev/sda1 not mounted, which is the main bummer, because if I update linux, as example, all images will inevitably end up in /boot but if files are in the EFI folder this won't upgrade a thing. I have the installer companion script that usually moves automatically those files once generated, but how can I know where to mount at runtime the current /dev/diskX that booted through the EFI ???
the Intel Sstick shows an image, the good old Netbook doesn't show the splash anymore. They both load but the splash for some reason doesn't work on the Asus. Even using /etc/fstab doesn't solve the issue, it seems that something messed up the ability to show images at boot time. Sounds like a regression, but like I've said it's not so relevant as a problem, the previous one is a blocker

I might add a script via systemd that generates the /etcfstab and remove itself from systemd after first boot, but I really would like to avoid going too hacky with this already messed procedure.

Thanks in advance for any sort of advice.

[edit]
I am probably solving the issue avoiding genfstab when UEFI is used and adding via systemctl a simple task that will mount the EFI folder at bootstrap so it can work as it was doing before. If anyone knows any reason to not do it, or any way to mount the EFI at runtime, please let me know, otherwise I'll mark as solved tomorrow evening.
Best Regards

Last edited by WebReflection (2015-07-26 23:56:00)

WebReflection · 2015-07-27 07:21:38

OK, I'll flag this as [SOLVED] since using the installer to create the systemd entry to automount the EFI directly to /boot works even better than having to move manually around files after linux updates. Win/Win at the end, thanks everyone for helping with this, at least now I have a better understanding of the minimal needed circus to "boot UEFI right"

In case you are wondering about the Asus, and why it doesn't show the image ... I think it's simply a matter of different resolution at boot time, and since Syslinux vesamenu is quite strict about background resolution and the image resolution, I've decided that I just don't care since more modern devices will show it just fine.

If anyone knows how to retrieve the initial boot resolution thought, I'd like to give it a try and see if changing it will just work or not.

Best Regards

[edit]
hwinfo --framebuffer was returning too many options, I've tried 800 x 600 and it's now showing it as soon as it boots ( before was using 1366 x 768 and working through the fstab file ... ¯\_(ツ)_/¯ )
In case you are interested

archibold resplash 800 600

is all I had to do to make it work. I am happy person again. Thanks

Last edited by WebReflection (2015-07-27 15:55:29)

Arch Linux

#1 2015-07-21 12:22:55

[SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#2 2015-07-21 12:27:56

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#3 2015-07-21 12:34:13

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#4 2015-07-21 12:41:28

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#5 2015-07-21 20:39:10

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#6 2015-07-21 21:09:04

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#7 2015-07-21 22:48:05

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#8 2015-07-22 10:37:27

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#9 2015-07-22 11:07:28

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#10 2015-07-22 12:28:02

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#11 2015-07-22 20:44:24

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#12 2015-07-22 20:55:18

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#13 2015-07-22 21:13:32

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#14 2015-07-22 21:26:46

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#15 2015-07-22 21:44:27

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#16 2015-07-23 09:16:47

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#17 2015-07-26 12:50:47

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#18 2015-07-26 14:48:02

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#19 2015-07-26 19:20:50

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#20 2015-07-26 23:03:13

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

#21 2015-07-27 07:21:38

Re: [SOLVED] /etc/fstab w/ wrong UUIDs (was genfstab problems/shenanigans)

Board footer