LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-26-2024, 06:52 PM   #1
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
[Experimental] Slackware rootfs on a multi-device bcachefs


Disclaimer: bcachefs is a recent addition to the Linux kernel and still in experimental stages. For a stable production machine, you should use something well proven, like ext4. bcachefs on a "multi-device pool" also requires manually editing Slackware's init scripts, bootloaders, and initrd. If you want to experiment with bcachefs, feel free, but expect to be on the bleeding edge. I'm just here to document my experience so far, for myself and anyone else who's interested and following bcachefs development. I'm not recommending anyone else to follow me.

Intro: I picked up some new HDD's and wanted to give the new bcachefs filesystem a test run in something with a bit more complexity to it. The plan is to use a pool of 3 x 4TB HDD's, and a 500GB M2 NVME SSD in a bcachefs formatted "pool" of drives. The idea being to use the NVME disk to cache read/writes for the larger pool of drives, and then take advantage of bcachefs features like compression, replication, and encryption.

Note: While Slackware-current now has bcachefs built into the kernel and bcachefs-tools to work with the format, bootloaders are a different matter, particularly when using a multi-disk pool of drives and the format it uses to specify the root "disk". For now the only viable way to use bcachefs as the rootfs seems to be by loading the latest kernel with an initrd, and performing the mount command from there. This kernel and initrd should be on another partition type that the bootloader can read from, e.g. an ext4 formatted /boot, or efi partition with elilo might work (untested). In my case I added the drives to an existing Slackware-15.0 system to "dual boot" with Slackware-current installed onto bcachefs. My plan is to continue managing the grub bootloader from Slackware-15.0, so I kept using Slackware-15.0's /boot directory to store the kernel and initrd for loading the Slackware-current on the bcachefs install.

Pre-Work:
1. Backup Slackware-15.0 files, prepare 15.0's fstab for removal of old storage disks, and ensure all mounts are done via LABEL in case the added disks change device node numbering.

2. Prepare a slackware64-current installer iso usb in order to test and use the added bcachefs-tools from the installer.

3. Shutdown, remove old disks, install new disks, reboot into installer usb.

Formatting the bcachefs drives with the Slackware installer:

After booting with the slackware64-current installation dvd/iso, 'lsblk' reports the following:
Code:
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   3.6T  0 disk 
sdb           8:16   0   3.6T  0 disk 
sdc           8:32   0   3.6T  0 disk 
sdd           8:48   0 232.9G  0 disk 
|-sdd1        8:49   0   500M  0 part 
|-sdd2        8:50   0    16G  0 part 
`-sdd3        8:51   0 216.4G  0 part 
sde           8:64   1   7.5G  0 disk 
|-sde1        8:65   1   4.1G  0 part 
`-sde2        8:66   1   1.4M  0 part 
nvme1n1     259:0    0 238.5G  0 disk 
|-nvme1n1p1 259:1    0   260M  0 part 
|-nvme1n1p2 259:2    0    16M  0 part 
|-nvme1n1p3 259:3    0 237.2G  0 part 
`-nvme1n1p4 259:4    0  1000M  0 part 
nvme0n1     259:5    0 465.8G  0 disk
So the 3 x 4TB drives are sda, sdb, sdc, and the nvme drive is nvme0n1.

With that information, I used the following command to create the bcachefs system:
Code:
# bcachefs format --compression=lz4 \
--encrypted \
--replicas=2 \
--label=ssd.ssd1 /dev/nvme0n1 \
--label=hdd.hdd1 /dev/sda \
--label=hdd.hdd2 /dev/sdb \
--label=hdd.hdd3 /dev/sdc \
--foreground_target=ssd \
--promote_target=ssd \
--background_target=hdd
Note: I added encryption, so bcachefs format prompted for a password after entering the above command.

Next mount the bcachefs formatted disks onto /mnt so we can proceed with the setup program:
Code:
mount -t bcachefs /dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc /mnt
Note: If the bcachefs mount is encrypted, it will prompt for the passphrase to mount the drives onto mnt/.

Once mounted, start the installer with 'setup'.

Slackware's installer will "Scan for target partitions", but not find the bcachefs formatted disks. However, the bcachefs disks are already mounted on mnt/ from the previous command so once the installer starts, select "TARGET" and then just select continue. The installer will continue onward to select the source media and install to the mounted bcachefs in the /mnt location.

With a full install selected, the installer completed in several minutes.

Notes: I skipped making a swap partition; I will try adding a swapfile after installation if I find the need. For now it is suspending/resuming fine without, and the machine has 32G of RAM. I also skipped adding lilo/elilo bootloaders, since I am going to continue using grub from Slackware 15.0 as the bootloader.

Once the installer is finished, drop back to the shell and chroot into /mnt to make an initrd and patch the rc.S and rc.6 scripts:
Code:
chroot /mnt
Note: If you're fresh out of the installer, the bind mounts for dev, proc, and sys are all still in place so the above chroot is all thats needed to chroot into the fresh system.

Once in the /mnt chroot, generate an initrd. While bcachefs is built into the kernel, mounting it with a multi-device path cant be done from grub, so were going to need the initrd anyway so we can properly mount the rootfs. Using an initrd with usb keyboard drivers will also be required to enter in passwords to unlock the encrypted bcachefs drive.

Note that to unlock an encrypted bcachefs drive we have to include the bcachefs binary in the initrd. This can be built into the chroot by copying it over the initrd-tree and building the initrd without the '-c' switch. We also have to modify the 'init' script in the initrd to allow unlocking the bcachefs encrypted disks, otherwise they will fail to unlock at boot and panic the kernel. If you skip encryption then these steps are not necessary.
Code:
install -m755 /sbin/bcachefs /boot/initrd-tree/sbin
Code:
--- init	2024-05-26 16:56:42.065995648 -0500
+++ init.new	2024-05-26 16:56:21.321996461 -0500
@@ -322,6 +322,13 @@
   # Switch to real root partition:
   /sbin/udevadm settle --timeout=10
   echo 0x0100 > /proc/sys/kernel/real-root-dev
+
+  # Unlock bcachefs disks if they are encrypted:
+  if [ "$ROOTFS" = "bcachefs" ]; then
+    BCACHEFSDISK1=$(echo $ROOTDEV | cut -d: -f1)
+    /sbin/bcachefs unlock $BCACHEFSDISK1
+    # Wait a second for disks to unlock before mounting:
+    sleep 1
+  fi
+
   mount -o ro${ROOTFLAGS:+,$ROOTFLAGS} -t $ROOTFS $ROOTDEV /mnt
   
   if [ ! -r /mnt/sbin/init ]; then
Note: mkinitrd_command_generator.sh fails over trying to determine the filesystem type for the mkinitrd command when using a multi-device bcachefs (the drives are in a ':' delimited list and an individual drive must be separated out of this list to test what filesystem is in use with way the script is written).

I used the following command, after fixing up mkinitrd_command_generator.sh's output:
Code:
mkinitrd -k 6.9.1 -f bcachefs -r /dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:bcachefs -u -o /boot/initrd.gz
While still in the chroot, we need to fix /etc/rc.d/rc.S, otherwise Slackware on bcachefs will fail to boot when it attempts to fsck the rootfs and fails at that. I made the following edit to use bcachefs's "fsck on mount" feature:
Code:
--- rc.S	2024-05-26 15:38:18.187973829 -0500
+++ rc.S.new	2024-05-26 15:37:41.617975328 -0500
@@ -204,6 +204,10 @@
   if grep -q ' / f2fs ' /proc/mounts ; then
     echo "Remounting root device with read-write enabled."
     /sbin/mount -w -v -n -o remount /
+  # bcachefs can fsck itself at mount time:
+  elif grep -q ' / bcachefs ' /proc/mounts ; then
+    echo "Remounting root bcachefs device(s) with read-write enabled."
+    /sbin/mount -o remount,rw,fsck,fix_errors /
   elif [ ! $READWRITE = yes ]; then
     # Check the root filesystem:
     RETVAL=0
The shutdown script also needs a tweak for bcachefs because it fails to remount read-only and complains about the -n option:
Code:
--- rc.6	2024-05-26 17:40:54.138996139 -0500
+++ rc.6.new	2024-05-26 17:40:34.883996929 -0500
@@ -291,8 +291,10 @@
   # In spite of this, it seems that a JFS root partition will always be checked
   # (and found to be clean) at boot:
   /bin/sync
-  echo "Remounting root filesystem read-only:"
-  /bin/mount -v -n -o remount,ro /
+  if ! grep -q ' / bcachefs ' /proc/mounts ; then
+    echo "Remounting root filesystem read-only:"
+    /bin/mount -v -n -o remount,ro /
+  fi
 fi
 
 # This never hurts:
The last thing left to do is get a copy of the kernel and it's matching initrd over to the /boot directory for grub. Since I'm dual booting from slackware-15.0, I mounted the slackware-15.0 disk at a temporary mount point, then copied the initrd.gz and kernel to the slackware-15.0's /boot directory with custom names to separate it from slackware-15.0's existing kernels and initrd:
Code:
mount /dev/sdd3 /mnt/tmp
cp /boot/initrd.gz /mnt/tmp/boot/initrd-testing.gz
cp /boot/vmlinuz-generic-6.9.1 /mnt/tmp/boot/
Exit the chroot and reboot the machine back into Slackware 15.0 to configure the bootloader. I used grub and have my own symlinking scheme to track kernels and initrds, so this part will differ for others. The general steps are:

1. Get grub to associate the new kernel and initrd from the bcachefs system, then run:
Code:
grub-mkconfig -o /boot/grub/grub.cfg
2. Edit the newly created /boot/grub/grub.cfg file, filling in the proper root device and rootfstype on the kernel command line with the following:
Code:
echo	'Loading Linux testing ...'
linux /boot/vmlinuz-testing root=/dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc rootfstype=bcachefs
echo 'Loading initial ramdisk ...'
initrd /boot/initrd-testing
Note: I use symlinks for my kernels and initrds. In any case, the boot entry that correlates to kernel of the bcachefs system and its initrd should be entered similar to the above.

Remember to not overwrite this boot entry. Make backups and be able to remake this change if grub is updated from slackware-15.0.

Reboot and select the testing kernel from grub, this will mount the bcachefs multi-device root and boot the system from there, using the modified rc.S script. Shutdowns should also be clean with the modified rc.6 code. With encryption used, I had to enter my password twice: Once to mount the read-only rootfs from the initrd, and a second time when the rootfs remounts read-write from rc.S.

Here's a couple interesting outputs from the running bcachefs system:
Code:
$ df -h
Filesystem                               Size  Used Avail Use% Mounted on
tmpfs                                     32M  1.7M   31M   6% /run
devtmpfs                                 8.0M     0  8.0M   0% /dev
/dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc   11T   21G   11T   1% /
none                                     192K   69K  119K  37% /sys/firmware/efi/efivars
tmpfs                                     16G     0   16G   0% /dev/shm
cgroup_root                              8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs                                    3.2G     0  3.2G   0% /run/user/0
tmpfs                                    3.2G     0  3.2G   0% /run/user/1000
Code:
lsblk --fs
NAME        FSTYPE   FSVER            LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda         bcachefs 1.7                                    f088d57e-2004-4366-829b-90ca9fd0c848                
sdb         bcachefs 1.7                                    f088d57e-2004-4366-829b-90ca9fd0c848                
sdc         bcachefs 1.7                                    f088d57e-2004-4366-829b-90ca9fd0c848                
sdd                                                                                                             
├─sdd1      vfat     FAT32            slack-efi             A109-5E2F                                           
├─sdd2      swap     1                slack-15-swap         3800b55f-5d00-4b8e-8fda-a92fed1f22ce                
└─sdd3      ext4     1.0              slack-15-rootfs       693d27b0-7c59-4291-a478-2a6f5d0c7a85                
sde         iso9660  Joliet Extension Slackware-current DVD 2024-05-24-13-16-00-31                              
├─sde1      iso9660  Joliet Extension Slackware-current DVD 2024-05-24-13-16-00-31                              
└─sde2      vfat     FAT12                                  C84C-EB11                                           
nvme1n1                                                                                                         
├─nvme1n1p1 vfat     FAT32            SYSTEM                A25D-26C4                                           
├─nvme1n1p2                                                                                                     
├─nvme1n1p3 ntfs                      Windows               9E6C5FE26C5FB42D                                    
└─nvme1n1p4 ntfs                      WinRE_DRV             2AA4602FA45FFBA7                                    
nvme0n1     bcachefs 1.7                                    f088d57e-2004-4366-829b-90ca9fd0c848   10.3T     0% /
With all that, the system is up and running for now. I'll be testing builds and running software on current with this install, so I'll see how the rootfs holds up I guess.

Cheers,

Bob

Last edited by 0XBF; 05-28-2024 at 07:54 AM.
 
Old 05-27-2024, 02:16 AM   #2
Mark Pettit
Member
 
Registered: Dec 2008
Location: Cape Town, South Africa
Distribution: Slackware 15.0
Posts: 625

Rep: Reputation: 301Reputation: 301Reputation: 301Reputation: 301
Now where would you ever see an Ubuntu user doing stuff like that :-) Nice effort Bob.
 
Old 05-27-2024, 06:58 AM   #3
rizitis
Member
 
Registered: Mar 2009
Location: Greece,Crete
Distribution: Slackware64-current, Slint
Posts: 722
Blog Entries: 2

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
@0XBF great work!
I started playing with bcachefs before 10 days but i dont have available hardware to check and stopped, also I had no idea for mkinitrd S.script etc...
But wrote 2 patches for the installer also a bash script to use it chrooting if installer failed, for when i will have hardware avaliable...
Attach them here if you or anyone want to hack them...
Attached Files
File Type: txt SeTpartitions.patch.txt (2.6 KB, 4 views)
File Type: txt setup.patch.txt (1.5 KB, 2 views)
File Type: txt make_bcachefs.sh.txt (7.2 KB, 7 views)
 
Old 05-27-2024, 02:34 PM   #4
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Leinster, IE
Distribution: Slackware, NetBSD
Posts: 2,205

Rep: Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781Reputation: 1781
Excellent work. I will be returning to this thread for sure.
 
Old 05-27-2024, 04:22 PM   #5
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,079

Rep: Reputation: Disabled
Congrats Bob!

What interest me much is the differences with btrfs, used by default in Slint in auto-partitioning mode

Having read superficially https://bcachefs.org/bcachefs-princi...-operation.pdf l understand that the main features of bcachefs lacking in btrfs are the encryption of the file system itself and the devices targets. The practical benefits of the devices targets and the durability claimed by the aforementioned document need a lot of time to be verified of course.

In Slint the encryption is done at the device level using LUKS. Not sure which is better. With btrfs the user can set the compression level, I did not see this mentioned for bcachefs, and swapfiles are allowed in btrfs but not in bcachefs (yet).

As bcachefs is new there is no driver for Grub yet as you know, hence the need for a partition for /boot.

So while btrfs looks indeed interesting, I am not in a hurry to adopt it

This notwithstanding thanks for opening the way.

Last edited by Didier Spaier; 05-27-2024 at 04:26 PM.
 
Old 05-27-2024, 05:29 PM   #6
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,560

Rep: Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601Reputation: 8601
Quote:
Originally Posted by Didier Spaier View Post
With btrfs the user can set the compression level, I did not see this mentioned for bcachefs,
It's not well documented (but who am I to complain), but you can set a level from 1 - 15 by appending it to the compression type. A 0 means the default for that type.
Code:
bcachefs set-option --compression=zstd:11 /dev/somevolume
 
2 members found this post helpful.
Old 05-27-2024, 05:40 PM   #7
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Original Poster
Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
Yeah the documentation isn't great so far, other than that tex/pdf manual and the man page for bcachefs (which I just noticed some errors in as well so I'll have to get around to sending an email off or making a git issue/pr). The multi-device rootfs bit had very little to go on, but it was a rainy weekend so I tried both an unencrypted and encrypted install and made some headway.

Correct that there are no grub drivers for bcachefs, which is going to be a limitation for many. There is a "bug report" for grub to add bcachefs support since 2019 here: https://savannah.gnu.org/bugs/?55801 No activity on that either...

Its why I started the thread with the disclaimer, and its bound to have changes going forward as well since theres lots of "this will be added in the future" in the documentation.

Last edited by 0XBF; 05-27-2024 at 07:08 PM. Reason: Edit: man page error was already fixed upstream, just not in this release.
 
Old 05-27-2024, 05:46 PM   #8
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Original Poster
Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
subvolumes & snapshots

bcachefs has the ability to create subvolumes and snapshots from subvolumes to "roll back" filesystems to snapshots.

First target will be the /home directory. I moved it to a temporary name, then created a subvolume with the same name and put home's contents back.
Code:
mv /home /home-tmp
bcachefs subvolume create /home
mv /home-tmp/* /home/
Next I create a /snapshots directory and create the first baseline snapshot of the /home subvolume:
Code:
mkdir /snapshots
bcachefs subvolume snapshot /home /snapshots/home-snapshot-$(date +%d-%m-%y)
Which creates the date stamped snapshot (i.e. another subvolume) in the /snapshots directory:
Code:
ls /snapshots
home-snapshot-27-05-24
Funnily enough, I accidentally clobbered this text file as I was writing it with a 1> redirect of that ls output instead of 1>>, so I got to test out the snapshot tool immediately. I found the backed up copy of the file in the /home snapshot I took a minute before. I also noticed the /home snapshot had permissions preserved and my user could only access my files in the snapshot directory.

Note that snapshots are used on subvolumes, which is why I converted /home to a subvolume in the first place. I ended up doing the same for /root and had to convert it to a subvolume as well.

So far seems pretty straight forward and would be easy to script I suppose.

Last edited by 0XBF; 05-27-2024 at 05:48 PM.
 
2 members found this post helpful.
Old 05-27-2024, 08:04 PM   #9
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Original Poster
Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
Quote:
Originally Posted by volkerdi View Post
It's not well documented (but who am I to complain), but you can set a level from 1 - 15 by appending it to the compression type. A 0 means the default for that type.
Code:
bcachefs set-option --compression=zstd:11 /dev/somevolume
Found that info here: https://bcachefs.org/Compression/

Also a couple other points on compression after poking around:

The bcachefs options can also be adjusted later using the /sys/fs/bcachefs/<UUID>/options interface. I tried the following and it stuck after a reboot:
Code:
echo lz4:7 > /sys/fs/bcachefs/f088d57e-2004-4366-829b-90ca9fd0c848/options/compression
Theres also some compression stats and other stats tracked in the sysfs interface. E.g:
Code:
cat /sys/fs/bcachefs/f088d57e-2004-4366-829b-90ca9fd0c848/compression_stats 
type              compressed    uncompressed     average extent size
none                1.46 GiB        1.46 GiB                5.98 KiB
lz4_old                  0 B             0 B                     0 B
gzip                     0 B             0 B                     0 B
lz4                 8.98 GiB        18.7 GiB                38.9 KiB
zstd                     0 B             0 B                     0 B
incompressible      3.02 GiB        3.02 GiB                11.6 KiB
6963 compressed & incompressible extents
I guess I was using the "default" until I change that to 7/15. Not sure what the default was, since I cant find it documented and I didn't poke too hard into the source.
 
Old 05-28-2024, 05:43 AM   #10
rizitis
Member
 
Registered: Mar 2009
Location: Greece,Crete
Distribution: Slackware64-current, Slint
Posts: 722
Blog Entries: 2

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
typically default compression lvls are:
gzip:6
lz4:1
zstd:3

Last edited by rizitis; 05-28-2024 at 05:46 AM.
 
Old 05-28-2024, 05:49 AM   #11
rizitis
Member
 
Registered: Mar 2009
Location: Greece,Crete
Distribution: Slackware64-current, Slint
Posts: 722
Blog Entries: 2

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
Quote:
Originally Posted by volkerdi View Post
It's not well documented (but who am I to complain), but you can set a level from 1 - 15 by appending it to the compression type. A 0 means the default for that type.
Code:
bcachefs set-option --compression=zstd:11 /dev/somevolume
we can check the default like this:
Code:
echo zstd:0 > /sys/fs/bcachefs/<UUID>/options/compression
sleep 60  
cat /sys/fs/bcachefs/<UUID>/compression_stats
Code:
echo zstd:3 > /sys/fs/bcachefs/<UUID>/options/compression
sleep 60  
cat /sys/fs/bcachefs/<UUID>/compression_stats
 
1 members found this post helpful.
Old 05-28-2024, 07:44 AM   #12
Mark Pettit
Member
 
Registered: Dec 2008
Location: Cape Town, South Africa
Distribution: Slackware 15.0
Posts: 625

Rep: Reputation: 301Reputation: 301Reputation: 301Reputation: 301
mv /home /home-tmp
bcachefs subvolume create /home
mv /home-tmp/* /home/


Um - I have a suspicion that the last command will still leave all files starting with a dot (.) behind. Maybe I'm wrong.
 
Old 05-28-2024, 07:48 AM   #13
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Original Poster
Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
Quote:
Originally Posted by Mark Pettit View Post
Um - I have a suspicion that the last command will still leave all files starting with a dot (.) behind. Maybe I'm wrong.
I had to move dotfiles for /root, but /home just contains more directories for the couple test users I made, with dot files below that. I also cleaned up the "empty" *-tmp directories with rmdir to make sure they were actually empty before cleanup.

It worked fine because after the migration I fired up a DE with my user account and all my custom settings were still kept.
 
Old 05-28-2024, 08:35 AM   #14
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Original Poster
Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
I've rebooted this system many times over the last few days and two times now I've had a situation where the bcachefs system fails to mount after unlocking in the initrd. It complains something about invalid bcachefs superblock layer and invalid number '00000000-0000-0000-0000-000000000000', and then would work fine and report no errors on the next reboot. I've added a "sleep 1" delay between the unlock and mount steps for bcachefs to see if it just needs a second for all the disks to be ready to mount and so far all has been fine (also made the edit in post #1 to show that). I'll post again if I notice any more issues around that.

I've also noticed that blkid in the initrd rescue shell doesn't list UUIDs for my bcachefs disks (or show my bcachefs disks at all), while the version of blkid on the rootfs works fine, so something is amiss there.

I've tried to use the "bcachefs mount" command from the initrd in my tests too, but so far that fails and I can only use the kernel drivers and mount command to get the disks mounted so far. "bcachefs mount" uses the uuid shared across the drives for mounting so the two problems might be related and maybe I'm missing a piece in the initrd. When I try to use the "bcachefs mount" command from the initrd, it scans all disks except for the bcachefs ones, and then ends with the error:
Code:
ERROR - bcachefs::commands::cmd_mount: Fatal error: No such device or address (os error 6)
Meanwhile if I boot with the slackware64-current usb installer, I can mount the bcachefs disks with the same command, except it scans all the disks including the bcachefs ones, and ends with entering in the password and mounting them properly.

Last edited by 0XBF; 05-28-2024 at 01:51 PM. Reason: specifically its the bcachefs disks that dont show uuids in the initrd
 
1 members found this post helpful.
Old 05-28-2024, 06:37 PM   #15
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 806

Original Poster
Rep: Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934Reputation: 934
Quote:
Originally Posted by 0XBF View Post
I've tried to use the "bcachefs mount" command from the initrd in my tests too, but so far that fails and I can only use the kernel drivers and mount command to get the disks mounted so far. "bcachefs mount" uses the uuid shared across the drives for mounting so the two problems might be related and maybe I'm missing a piece in the initrd. When I try to use the "bcachefs mount" command from the initrd, it scans all disks except for the bcachefs ones, and then ends with the error:
Code:
ERROR - bcachefs::commands::cmd_mount: Fatal error: No such device or address (os error 6)
This error has something to do the way 'bcachefs mount' asks for the passphrase to unlock the encrypted drives. By default the 'bcachefs mount' command uses the ask method for its passphrase. From the man page:
Code:
-k, --key-location=(fail | wait | ask)
                       Where the password would be loaded from. (default: ask).
                       fail    don't ask for password, fail if filesystem is encrypted.
                       wait    wait for password to become available before mounting.
                       ask     prompt the user for password.
For whatever reason, the 'ask' method is broken in the initrd and returns that "os error 6" message. If I switch it to 'wait' and do a separate unlock command before that, then it works without problem. E.g: the following steps work:
Code:
bcachefs unlock /dev/nvme0n1 # Note: any drive from the pool can be specified to unlock
[asks for passphrase]
bcachefs mount -k wait /dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc /mnt
That 'bcachefs mount' command can also work with UUID=<UUID>, which I tested.

The 'blkid' from busybox still cannot show my bcachefs formatted drives though, while copying over the blkid from slackware-current to the initrd does work. In any case it doesn't seem to matter if blkid works or not, as long as the UUID is correctly passed to 'bcachefs mount' it works. However, I still use the original mount command from the initrd's init script, which works fine once the bcachefs drives are unlocked.

It would seem that a multi-drive setup without the encryption is less hassle, though I'm pretty happy with the way things are running with the setup from post #1. I'll have to make a new -current installer to try the updated installer with bcachefs detection and see about updating the steps in post #1 as needed.
 
  


Reply

Tags
bcachefs, rootfs, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Devs of bcachefs try to get filesystem into Linux again LXer Syndicated Linux News 0 03-18-2022 09:36 PM
bcachefs file system - install bcachefs-tools - any successful installs on CentOS 7? Sum1 CentOS 0 07-28-2019 07:45 PM
LXer: Firefox Quantum, Bcachefs, Ubuntu, Devuan 2.0 LXer Syndicated Linux News 0 05-10-2018 11:42 PM
New Linux filesystem: bcachefs - a general purpose COW filesystem jeremy Linux - News 1 08-21-2015 12:19 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:31 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration