[Merge Request] Patch: add btrfs support to 'manjaro-chroot -a'

Manjaro Development Dev Tools
1

As of Manjaro 25.0.0 “Zetar”, we are now using btrfs as the default filesystem option in calamares, and there have already been several requests from members — both directly, as in the Manjaro-Chroot on BTRFS thread, and as off-the-cuff questions elsewhere on the forum — regarding support for btrfs autodetection in manjaro-chroot.

I do not have a GitLab account, nor do I aspire to create one, but if either @philm, @Yochanan or @linux-aarhus were to be so kind as to merge this, then I’m sure a lot of people with broken systems due to an interrupted update would be a lot happier. :wink:

Patch follows below. :point_down:

@@ -14,7 +14,8 @@
 }
 
 parse_fstab(){
-    echo $(perl -ane 'printf("%s:%s\n", @F[0,1]) if $F[0] =~ m#^UUID=#;' $1/etc/fstab)
+    [ -d "$1/@" ] && fstab="/@/etc/fstab" || fstab="/etc/fstab"
+    echo $(perl -ane 'printf("%s:%s\n", @F[0,1]) if $F[0] =~ m#^UUID=#;' $1${fstab})
 # 	perl -ane 'printf("%s:%s\n", @F[0,1]) if $F[0] =~ m#^/dev#;' $1/etc/fstab
 # 	perl -ane 'printf("%s:%s\n", @F[0,1]) if $F[0] =~ m#^LABEL=#;' $1/etc/fstab
 }

Rationale: By default, calamares will create a btrfs filesystem with a dedicated subvolume called “@” for the root directory of the system. This is not the actual filesystem root — which remains “/” — but it is the subvolume that gets set up by calamares to house the operating system’s root directory. Therefore, with this setup, the file /etc/fstab of the installed system is not actually to be found in the filesystem’s root directory /, but rather under the @ subvolume, at /@/.

In the event that the user has set @ itself as the default subvolume that gets mounted when no other subvolume is specified as a mount option, then my patch will still work, because then the @ subvolume itself won’t be visible as a subvolume, given that it will itself be the one mounted as “/” , and then /etc/fstab will be right under the default mountpoint, just as in the case of ext4 or another traditional filesystem.

:vulcan_salute:

8 Likes
2

Which file did you patch?

2 Likes
3

Oops, I accidentally deleted the link from my opening post in the edit. I will add it again. It’s this one… :point_down:

Perhaps worthy also of pinging our beloved Manjaro spin doctors (:face_with_hand_over_mouth:), @Jim.B and @DeLinuxCo. :wink:

1 Like
4

Thanks Frede. :wink: :beers: :beers: :beers:

5

Thanks for linking me in and asking my 2c.

I have a love hate relationship with btrfs. I love to hate it. This goes back a few years where it was near impossible to mount and edit files in a btrfs partition and make changes to it to fix problems, this may have changed.

While btrfs may have some fantastic features, its still under heavy development to my knowledge. At least for stable installs I much prefer ext4. Its a tried and true file system that is rock solid. Snapshots can be made with other software like timeshift. All of the SbK spins have it and timeshift-autosnap installed to avoid lasting issues from a bad upgrade.

6

I can assure you that this has changed, given my experiences of the past week — see this thread.

Everything is still under development, or else it would be obsolete. :stuck_out_tongue:

Again, see this thread. which will tell you how the only ext4 partition I had — but alas it was also a very important one, because it held the kernel and grub — got damaged, either by a process with a broken pipe, or by the fact that I gave it a filesystem label with gparted. I wouldn’t call that “rock solid”. :wink:

btrfs on the other hand has already survived several unexpected power outages here without any damage at all, because it is self-healing.

Well, that’s an interesting point, because even though virtually everyone here uses btrfs for its ability to make snapshots, I don’t use snapshots, and I even doubt whether I would be able to create any usable filesystem rollback setup without much tinkering.

I prefer real, physical backups on a separate medium — with timeshift, indeed — and I am using btrfs for very different reasons, i.e. because it uses B-trees, because it’s copy-on-write, because it supports transparent inline compression, because it maintains checksums on both the metadata and the data, and because it has subvolumes which largely behave as independent partitions — with their own specific mount options — while they still share the total amount of free space with the other subvolumes on the device.

I’ll spare you the left-and-right scrolling and instead show you my /etc/fstab as a screenshot. Then you can see for yourself what I’m talking about. :stuck_out_tongue:

:point_down:

KWrite
KWrite1920×1080 245 KB

1 Like
7

Thanks for addressing those points. In the end Manjaro moved to btrfs as the default already, this thread is about adding support to tools to help people with issues. As long as those tools keep support for people who choose not to use btrfs during the OS install (like me) I think its a good idea.

1 Like
8

Yes, all my patch does is add a conditional check to see whether the filesystem to be chrooted into is btrfs or a more traditional filesystem, and in the case of btrfs, it then modifies the path to the /etc/fstab file, so that it can be read by /usr/bin/mount. If it’s not btrfs, then nothing changes. :wink:

3 Likes