Confusing Problem switching to BTRFS

I was attempting to get my BTRFS file system working with timeshift and thought I was doing well but I think that I am now having difficulties updating the boot partition with the new manjaro location possible. I’m not sure which commands I need to run next to see where I have gone wrong?

I have booted into a live image from my USB of Manjaro KDE.
I tried to use this to restore my UEFI but I couldn’t find ‘manjaro-chroot -a’ it says that it couldn’t find it.

I’m not quite sure how to progress checking which files need to be updated to be able to boot back into Manjaro?

moved to #support:installation
Also: please do not post screenshots of terminal output and/or text files - copy and paste and use propper formatting (</> button).


Hello @P1000 :slight_smile:

So many pictures of text HELP :crazy_face:

sudo mount /dev/sdYN /mnt
sudo btrfs subvolume create /mnt/@ 
sudo btrfs subvolume create /mnt/@home

Move root files/folders to @ and home to @home .

Edit fstab:

UUID=<long-number> /     btrfs subvol=@,defaults,noatime      0 1
UUID=<long-number> /home btrfs subvol=@home,defaults,noatime  0 1

(this format is compatible with timeshift)

1 Like

Don´t you need to make the new subvolume “@” the default for booting ?

1 Like

Ah good, I was a bit confused at what had happened to the ‘@’ folders in the tutorial that I was attempting to follow so that makes much more sense now. Does the ‘bootloader’ know to look in the @/etc/fstab file by default to check for the mount points or do I need now to do something more as well before it will boot?
Thanks to everyone for the help so far :slight_smile:

# @/etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=F737-3F51                            /boot/efi      vfat    umask=0077 0 2
#UUID=199cfdfe-c9a4-4ce6-92e3-1a3b5b9208c6 /              ext4    defaults,noatime 0 1
#UUID=e95a3243-1f62-4a24-a6c5-d0afdb300761 /              btrfs    defaults,noatime 0 1
UUID=e95a3243-1f62-4a24-a6c5-d0afdb300761 /     btrfs subvol=@,defaults,noatime      0 1
UUID=e95a3243-1f62-4a24-a6c5-d0afdb300761 /home btrfs subvol=@home,defaults,noatime  0 1
[manjaro@manjaro mnt]$ blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p1: UUID="F737-3F51" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ESP" PARTUUID="084fbd1c-b903-439c-9e65-ab24be908bbf"
/dev/nvme0n1p2: LABEL="Manjaro" UUID="e95a3243-1f62-4a24-a6c5-d0afdb300761" UUID_SUB="c34e8ebe-7ced-4c2a-9f84-e1f0186d4188" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="35b1e786-bc62-e948-ac6e-02d61e2624bc"
/dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="VTOYEFI" LABEL="VTOYEFI" UUID="D501-3947" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="VTOYEFI" PARTUUID="6807e59c-f6a5-4619-9ac7-db8f0718da5e"
/dev/sdb1: LABEL="Ventoy Boot USB" UUID="4E21-0000" BLOCK_SIZE="512" TYPE="exfat" PTTYPE="dos" PARTLABEL="Ventoy" PARTUUID="f50f8692-bf28-4f17-a4ef-2199ef64c5a7"
/dev/nvme2n1p2: LABEL="ExtraHomeFiles" UUID="7c204b7c-980e-457e-a12f-023981edb48d" UUID_SUB="07229f51-ba2d-42c8-82bc-394df968e6f7" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="52f90aea-8f8d-ef44-aa83-83fa79159ea0"
/dev/nvme2n1p1: LABEL="Backups(Timeshift RSYNC)" UUID="cacec9be-17c6-46e4-82ff-8a2c84730980" UUID_SUB="30e25b5f-26e8-43d2-b5e5-d51a4579f74f" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="c5aa6223-44f6-e942-8b49-76a143b9597c"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/mapper/ventoy: BLOCK_SIZE="2048" UUID="2021-06-14-15-26-14-00" LABEL="MANJARO_KDEM_2107" TYPE="iso9660" PTTYPE="dos"
/dev/nvme1n1p1: LABEL="238GB" UUID="e37474f0-5c2e-453e-996f-71877061771e" UUID_SUB="871c0e0c-a3e7-44c9-a3cb-d1f1bad9d57c" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="c03a64c7-cf43-3446-8d90-1fb242299db7"
/dev/sda1: LABEL="Elements (External Hard Drive)" BLOCK_SIZE="512" UUID="5C7E35087E34DD08" TYPE="ntfs" PARTLABEL="Elements" PARTUUID="6cef7a2c-332f-4216-9a1e-f5512aad6068"
/dev/loop3: TYPE="squashfs"

I also read that the kernels might not have installed properly but I believe that should be fins in this case as I appear to have some in the mounted boot directory at mnt/@

[manjaro@manjaro @]$ ls -lh /boot | egrep "initramfs|vmlinuz|linux"
-rw-r--r-- 1 root root  29M Aug  8 03:43 initramfs-5.10-x86_64-fallback.img
-rw-r--r-- 1 root root 7.1M Aug  8 03:43 initramfs-5.10-x86_64.img
-rw-r--r-- 1 root root   22 Jul 26 07:17 linux510-x86_64.kver
-rw-r--r-- 1 root root 9.0M Aug  8 03:43 vmlinuz-5.10-x86_64

Good so far :slight_smile:

To install grub mount it:

sudo umount -R /mnt
sudo mount -o subvol=@ -U <UUID> /mnt
sudo mount -o subvol=@home -U <UUID> /mnt/home
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
manjaro-chroot /mnt /bin/bash

then you are on chroot. Now you can reinstall grub:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
grub-mkconfig -o /boot/grub/grub.cfg

Ah, excellent! That makes sense

[manjaro@manjaro /]$ sudo mount -o subvol=@ -U e95a3243-1f62-4a24-a6c5-d0afdb300761 /mnt
[manjaro@manjaro /]$ sudo mount -o subvol=@home -U e95a3243-1f62-4a24-a6c5-d0afdb300761 /mnt/home
[manjaro@manjaro /]$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
[manjaro@manjaro /]$ manjaro-chroot /mnt /bin/bash
[manjaro /]# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.
[manjaro /]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.4-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.4-x86_64.img
Found initrd fallback image: /boot/initramfs-5.4-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-e95a3243-1f62-4a24-a6c5-d0afdb300761' {
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root e95a3243-1f62-4a24-a6c5-d0afdb300761
	linux	/@/boot/vmlinuz-5.10-x86_64 root=UUID=e95a3243-1f62-4a24-a6c5-d0afdb300761 rw rootflags=subvol=@  quiet udev.log_priority=3
	initrd	/@/boot/amd-ucode.img /@/boot/initramfs-5.10-x86_64.img

Now that grub is setup hopefully I can try rebooting into the nvme Manjaro partition. If that works I believe I will still need to add a subvolume to my backup nvme so that Timeshift can use it?

Should work…

I think you got a wrong idea of subvolumes and timeshift. Timeshift is designed for system recovery (something like the one on windows) where you have states and you can recover it backwards and forward if needed (@home should not be included here). By saying this, it makes no sense to save the data on a “backup partition”. It have to be on the same partition. You will not benefit from btrfs features, if you choose another partition as destination. Then it would be better to stay on ext4 :wink:

Oh sorry, I meant another partition on another nvme drive.

Unfortunately when I reboot I get a similar error where it can’t find anything to boot into.

On attempt to boot into the Manjaro partition in UEFI it loads this error message:

error: sparse file not allowed 
press any key to continue

mount: /new_root: unknown filesystem type 'btrfs'
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ]# _

Is it possible that I haven’t regestered my subvolumes correctly?

Looks like btrfs-progs is not installed on your local installation :grinning_face_with_smiling_eyes:

Ah okay, so do I need to chroot into the partition and then pamac install btrfs-progs?

1 Like

I want to expand on it. I don’t use Timeshift so I am not familiar with its features. Certainly it can do snapshots, that are like snapshots in Windows. But snapshots are not backup. Proper backups are always on another drive (not partition). You need backups in case your system drive gets damaged.
For example I do snapshots before every major change in my system or settings and I want to make sure that if I do something wrong I will be able to revert to previous state within seconds.
I do backup once upon a time, usually after every major system update - this may differ for rollings systems and for other release cycle distributions like Ubuntu.
Technically backups in BTRFS are also snapshots but of diffrent kind and to call something backup another drive must be used. In BTRFS partitions are not important, all thinking about BTRFS is focused on subvolumes.

I recommend reading about BTRFS on Kubuntu forum

By the way, doing clean BTRFS install seems to me much better solution than converting.

1 Like

Agree that a backup should be done on a second HDD, but system files are not so important, since you can reinstall it, and a good place to save and restore those system files is the same partition. Maybe you can cherry-pick some needed configs there, but in general all really important configs and files are on /home. If the drive dies, then /home is save and a reinstall is necessary anyway on another drive.

Therefore I suggest always to backup the data of /home on a second drive and system backups can stay on the same for quick revert, especially on btrfs. Maybe this was not clear enough.

Just additionally, because you said snapshots are not backups:

  1. A backup contains all important data.
  2. Snapshots are frozen states of this backup.
1 Like

It is not necessary. You can use backup to move @_subvolume and @home_subvolume to a new disk.


For quick revert are snapshots. Snapshots are kept on the same hard disk as system.

I would define a backup as a copy on separate disk you keep in case of disaster. And I recommend to keep a backup of @_subvolume in case you do something with your system that it becomes so messed up that you can’t even use your snapshot. It may happen. Reverting system from backup is still much faster than reinstall.

Snapshots are frozen states of whatever subvolume you want to snapshot.

You don’t do snapshots of backups but of current state of your system and settings. Backups are on separate disk. This may be confusing for people who are used to thinking in terms of partitions. In case of windows or ext4 you could have another disk always attached as separate partition. In case of BTRFS partitions are not important because you can have a system on single disk with only one partition and have as many subvolumes on it as you like. As far as I know you can also merge two separate disk (and partitions) and have one subvolume on them.

Of course it is up to user to decide of what and when they want to make snapshots and backups.

I strongly recommend to take time and become familiar not only with how Timeshift works but also how to use snapshots and backups without Timeshift. It can be a valuable lesson and this you can gain a very useful practical knowledge of BTRFS, knowledge about what is going on behind Timeshift, in other words how Timeshift works.

Ah ok understand now… send/receive (cp) the subvolume on the second drive. But the “reflink” feature works only on the same partition. That’s the cause why I do snapshots (backups of the system) on then same drive. But well, if the drive is not dead, then this is a good method to move the system to a new drive. :+1:

ok then a 2 pass backup solution. One on the same drive and then one on the second drive… Yeah maybe more secure, but could be time intensiv, if you get often upgrades of the system.

Yeah, one could say it is similar to the bind option where you can bind a folder to a another, but not the same.

mount -o bind /first/folder /second/folder
mount --bind /first/folder /second/folder

:100: But not everyone has the time for it, so the easy solution is still timeshift for the beginning.

I unfortunately am still not able to boot into this. Hopefully I can restore from a backup. To do a clean install can I use the normal Manjaro installer to create a @home layout?
I know Manjaro Architect had an option for this but I believe it isn’t currently being maintained.

As I remember, if you create a btrfs partition and set the mountpoint / there, it will create automatically 2 subvolumes: @ and @home.

1 Like

In manual partitioning do I neeed to format the partition with mount point ‘/’ then? @megavolt