cannot chroot into /mnt

[timid ice]

I'm following the guide for getting systemd to boot other disks. I use btrfs.
The guide tells to mount the system's mountpoint, which I'm assuming would be /dev/sdb2 /mnt, which is for my system(non-EFI) partition.
However, when I try to do arch-chroot /mnt, I am told:

dmesg(1) may have more information after failed mount system call.```
I check what is inside /mnt with ls, and I see a folder(?) called `@`. It contains /proc, but when I try to chroot into it, I am told:
```==> WARNING: /mnt/@ is not a mountpoint. This may have undesirable side effects.```
It does chroot, but I'm not sure if I should just keep going from there.

[split solar]

@ is a commonly used name for a top-level subvolume that contains the root and its directory structure. you can check if it's actually a subvolume, btrfs subvolume list /mnt. If you want to mount that you need to specify it as a mount option (e.g. mount -o subvol=@ /dev/sdb2 /mnt), or set it as the default to mount when mounting the filesystem (e.g. btrfs subvolume set-default 256 /mnt). that's documented here on the wiki: https://wiki.archlinux.org/title/Btrfs#Mounting_subvolumes.

[timid ice]

running btrfs subvolume list /mnt returned the following:

ID 257 gen 924 top level 5 path @.snapshots
ID 258 gen 1063 top level 5 path @home
ID 259 gen 1067 top level 5 path @log
ID 260 gen 1067 top level 5 path @pkg
ID 261 gen 15 top level 256 path @/var/lib/portables
ID 252 gen 15 top level 256 path @/var/lib/machines```

Now, I'm assuming @ should be mounted in this case? @home indeed is just /home

Hey, I chrooted this time with no errors! Should I still set my default to @ when mounting, or would that break systemd?

[ivory creek]

what guide?

[timid ice]

https://wiki.archlinux.org/title/Systemd-boot#UEFI_Shells_or_other_EFI_applications

[split solar]

yeah, that layout is pretty similar to mine. with that you'd want these mounts in your fstab:

UUID=<UUID>       /               btrfs           subvol=@       0 0

UUID=<UUID>       /home           btrfs           subvol=@home   0 0

UUID=<UUID>       /.snapshots     btrfs           [email protected]    0 0

UUID=<UUID>       /var/log        btrfs           subvol=@log   0 0

UUID=<UUID>       /var/cache/pacman/pkg  btrfs    subvol=@pkg    0 0

note: the first line doesn't matter unless you specify more options, but still good to include for explicitness

[timid ice]

ok

[split solar]

yes, it's a good idea to set @ (subvolid=256) as the default. that way you don't need to specify a kernel parameter for the kernel to mount it

[timid ice]

alright

i do gotta head to sleep rn though, it's nearly midnight where i live rn

so uh

thanks for your help and

see you tomorrow?

[split solar]

do note that you will need to give the mount option subvolid=5 to access the true root of the drive. (you usually don't need to access it like this, but if you want to rename subvols, make new top-level subvols, you'll need to keep that in mind)

[timid ice]

thanks man i really appreciate it

[split solar]

of course! good night

[timid ice]

thanks!

[silent gate]

as far as I can tell you can’t set the name @ as the default

you can only set the specific subvolume currently sitting at @ as the default, via the subvolume ID

it’s a subtle distinction but this makes rollbacks a bit harder to do

[split solar]

Yup you’re right, I skimmed the man page earlier and misread how to set it, and didn’t test it out. thanks, I updated so OP can reference tomorrow

[south spire]

fleuriafluoride received a thank you cookie!

[split solar]

it would probably error trying to set it to @ anyway

[silent gate]

yup, I just tried it on my own system

me personally I avoid having to specify the subvolume in the command line with a bit of a hack

I use a systemd initramfs, so I just put

[Mount]
Options=subvol=@

in /usr/local/lib/systemd/system/sysroot.mount.d/subvol.conf

and then had mkinitcpio include that in

[split solar]

Oh that’s interesting 🤔

I might try that out tomorrow, heading to bed