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.
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).
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
# @/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
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 /]$ 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.
done
### 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' {
savedefault
load_video
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?
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
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?
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.
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:
It is not necessary. You can use backup to move @_subvolume and @home_subvolume to a new disk.
Besides
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.
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
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.
P