Does the commented lines at the start of fstab matter?

General system Newbie
1

I messed up my fstab so grabbed a live usb and did a genfstab again
But as according to arch wiki, it says to use genfstab >> /mnt/etc/fstab
which puts the contents at the end of the file
I overwrite the whole file with genfstab > /mnt/etc/fstab

Now I know commented lines usually don’t matter but I had an example in mind where shebangs are used in script files which essentially is a comment as well but they do matter.

So, just to calm my ocd, does the commented two lines at the start of fstab which are these, matter?

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

Or it would have no impact whatsoever to not have them or delete them?

2

The comments don’t matter in /etc/fstab

As a side note, if you use btrfs, you should remove the subvolid= that genfstab creates.

3

Even the comments at the start of the fstab file which I highlighted in the post above?
subvolid, any reason for that?

4

Yes.

Yes, genfstab pulls in both subvol= and subvolid=. There is no reason to have both.

More importantly, subvolid can change. For example, when you restore a snapshot. This will result in some unexpected behavior in that case. It is generally better to use only subvol=.

5

I forgot to mention, I’m running arch linux because of the coredumps in eos.

So far no coredumps yet.

And, I’m running with dracut and exactly the same packages, apart from eos specific packages which are found in the eos repo.

What could be the reason of core dumps in EOS only when I’m running the same packages apart from the eos ones?
Also I have exactly the same aur packages.
I made a list of packages while I was running eos which i then installed on arch.

6

Well I restored a snapshot before posting this, and as a matter of fact the subvolume ids are the same and haven’t changed.
Any reason for why it hasn’t changed?

7

btw, i just did
sudo btrfs sub show /

Name: 			@
UUID: 			c1144e8f-34ae-8f42-a5cf-200ecb1d3045
Parent UUID: 		a2569469-2e97-b842-a44d-d8d9897e0cf5
Received UUID: 		-
Creation time: 		2023-08-12 15:14:06 +0500
Subvolume ID: 		264
Generation: 		920
Gen at creation: 	167
Parent ID: 		5
Top level ID: 		5
Flags: 			-
Send transid: 		0
Send time: 		2023-08-12 15:14:06 +0500
Receive transid: 	0
Receive time: 		-
Snapshot(s):

Here’s the output, it says that it has a parent subvol.
Why’s that so? Did I mess up in recovering from a timeshfit snapshot?

8

The subvolid’s stay with the subvol generally. Although, I suppose it depends on what method you used to restore it.

Really, I would need to see it before and after.

Also, have you rebooted or are you still looking at the old subvol?

9

Yeah I have rebooted I did it today a few hours ago.
Here are these for you to look at.
The btrfs subvolume list /@ output from now

➜  ~ sudo btrfs subvolume list /
[sudo] password for v3n0m:
ID 256 gen 167 top level 5 path timeshift-btrfs/snapshots/2023-08-12_15-14-06/@
ID 257 gen 940 top level 5 path @home
ID 258 gen 940 top level 5 path @log
ID 259 gen 11 top level 5 path @swap
ID 260 gen 813 top level 5 path @cache
ID 261 gen 20 top level 256 path timeshift-btrfs/snapshots/2023-08-12_15-14-06/@/var/lib/portables
ID 262 gen 21 top level 256 path timeshift-btrfs/snapshots/2023-08-12_15-14-06/@/var/lib/machines
ID 263 gen 169 top level 5 path timeshift-btrfs/snapshots/2023-08-12_15-02-40/@
ID 264 gen 940 top level 5 path @

My /etc/fstab which was recovered by timeshift snapshot.

# /dev/mapper/part
UUID=5031f411-1ff1-43ca-88db-f07c05e27109	/         	btrfs     	rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=256,subvol=/@	0 0

# /dev/mapper/part
UUID=5031f411-1ff1-43ca-88db-f07c05e27109	/home     	btrfs     	rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/@home	0 0

# /dev/mapper/part
UUID=5031f411-1ff1-43ca-88db-f07c05e27109	/swap     	btrfs     	rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=259,subvol=/@swap	0 0

# /dev/mapper/part
UUID=5031f411-1ff1-43ca-88db-f07c05e27109	/var/cache	btrfs     	rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=260,subvol=/@cache	0 0

# /dev/mapper/part
UUID=5031f411-1ff1-43ca-88db-f07c05e27109	/var/log  	btrfs     	rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=258,subvol=/@log	0 0

# /dev/nvme0n1p1
UUID=6C74-0313      	/efi      	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/nvme0n1p2
UUID=6fc96e87-6466-42ca-806d-9e9f3921af38	/boot     	ext4      	rw,relatime	0 2
10

Well I just noticed the @ subvol has a different id.
Well, the subvolid has changed.
Do I need to reinstall archlinux? As I its been a few hours since I restored and installed some stuff afterwards.

Or just removing the subvolids now would be appropriate?

11

Exactly.

What does findmnt / show?

12

➜ ~ findmnt /
TARGET
SOURCE FSTYPE OPTIONS
/ /dev/mapper/luks-1c939035-5ace-42cf-a56f-9e79ae8aa60f[/@] btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvolid=264,subvol=/@

13

I just searched archwiki and it says that the restored system won’t boot, I didn’t had any boot problems after restoring does that mean no issue now or do I have to do it all again and freaking reinstall the system.

14

That looks fine. Just remove the subvolid’s from /etc/fstab.

15

This is what archwiki says

It is preferable to mount using subvol=/path/to/subvolume, rather than the subvolid, as the subvolid may change when restoring #Snapshots, requiring a change of mount configuration, or else the system will not boot.

Btw, I had rebooted like 10 times after restoring the snapshot. I don’t know if it would have caused problems in the other boots. lol

16

Were you talking about other problems i.e not related to system booting up?
Or it was just that system won’t boot after recovering a snapshot.

17

It isn’t definitively true that the system won’t boot in that situation. There are more variables than that. More often, the system will boot onto the old subvol instead of the one you restored.

In your case it seems to be OK, at least in the output you showed me so you should just be able to remove the subvolid’s from /etc/fstab

18

The catch here is that how can I be sure that for the past 9 boots which I did after restoring the snapshot was the system booting into the correct subvol and not just this time?
This is a thing that can’t be answered.

19

I suppose there is no way you can be 100% confident. However, it seems likely that the system would behave in a deterministic manner.

EDIT: I suppose you could check the timestamps in that subvol and see if any files have been touched since the restore.

20

That’s true as well. Maybe, specifiying the subvol takes precedence over subvolid?
Have you looked onto that?