"Select BTRFS system disk with root subvolume (@)" error

Hello,

Related to the issues I reported in this thread


something seems to have gone wrong with my btrfs-based root partition. When I mount the disk from another environment, I don't see a /@ directory, I just see a typical *nix root (/bin, /dev, /etc, and so on).

If I run btrfs subvolume list I can see snapshots, and I can mount some snapshots using btrfs subvolume set-default (only some; others produce an error).

But if I run snapper list it only shows the current snapshot.

@Librewish recommended I try timeshift instead of Snapper. I did, and when I try to set it up to perform btrfs snapshots it gives the error I used as the title of this post, Select BTRFS system disk with root subvolume (@), which seems consistent with my not being able to see /@ when I mount the disk.

I also get errors when I run btrfs check; I pasted those into the earlier post in the link above.

It seems like the filesystem has become corrupted in some way. I'm able to boot to it for now but snapshots aren't working and I'd like to fix it. Does anyone have any ideas?

how did you install previously on btrfs.
calamares or architect?

@Thad

I read in your other post about this problem, that you are able to boot snapshot 29.

Simply mv @/whateverpathto/29 to @

Command would look like this :

  1. sudo mv @ bad
  2. sudo mv bad/pathto/29 @
  3. reboot normally

What it does is it rename snapshot 29 to @

If you want to avoid future problems .... sudo btrfs subvolume snapshot / to /path of saving ... way easier never had problem with snapshot or btrfs in 5 years !

Exemples of mv : easy mv

Good luck

Maybe run the mount command you use and then ls /mnt and the full terminal output.
Usually the top subvolume / should be the default subvolume.
sudo mount -o subvol=/ /dev/sda1 /mnt
sudo btrfs subvolume set-default /mnt

Thanks for the responses and sorry for the delay getting back to you.

@Librewish I originally installed with Calamares.

@loup The trouble is that I'm not able to see @ at all. Even when I mount the disk from another environment, I don't see the @ directory; I just see the root filesystem. The btrfs hierarchy must be there in some form, because I reference 29 when I boot from grub, but I'm not able to see it when I mount the disk.

@eugen-b That's a thought. It's been awhile since I tried booting from another environment (I haven't rebooted much since I got it working again; I'm concerned I might break something and not be able to get back in again) but the next time I get a chance I'll try that and report back.

Please post the output of the first
comand I gave

Thanks, I am seeing an @ now.

[manjaro@manjaro ~]$ sudo mount -o subvol=/ /dev/sda3 /mnt
[manjaro@manjaro ~]$ sudo btrfs subvolume set-default /mnt
[manjaro@manjaro ~]$ ls /mnt
@
[manjaro@manjaro ~]$ ls /mnt/@
bin                 dev   lib    opt   rootfs-pkgs.txt  srv  usr
boot                etc   lib64  proc  run              sys  var
desktopfs-pkgs.txt  home  mnt    root  sbin             tmp

So that's something, anyway. But I'm not seeing @snapshots or any obvious way to re-enable snapshots.

Edit: I reread my boot command and found them; they're in @/.snapshots. Will see where I can go from there and report back.

Edit 2: After I found @/.snapshots, I started by trying the suggestion by @loup :

sudo mv @ bad
sudo mv bad/.snapshots/29 @

and then rebooted, but I couldn't get it to boot.

So I booted to the memory stick again. I reversed the move:

sudo mv @ bad/.snapshots/29
sudo mv bad @

and then I tried to set 29 as the default subvolume but got an error:

[manjaro@manjaro ~]$ sudo btrfs subvolume set-default /mnt/@/.snapshots/29
ERROR: Not a Btrfs subvolume: Invalid argument

And when I try to boot to snapshot 29 like I was before, I get

BTRFS error (device sda3): '@/.snapshots/29/snapshot is not a valid subvolume

Is it possible that performing the mv on .snapshots/29 caused it to no longer be recognized as a valid snapshot? And if so, how do I fix it?

That's a pretty superficial analysis.
From what I see in your terminal output, it doesn't look like you intalled your system in any supported Manjaro way, neither by Calamares, nor by Manjaro Architect. Is it even Manjaro at all?

But you applied some major changes after the installation. Snapper is not set as an option in Manjaro's Calamares. It is therefore not supported and barely anybody in the community uses it. If you want to use it you need to lear to do it on your own.

You also run commands I didn't ask you to run. I only asked to run commands which help to gain system information. Maybe @loup can help you now. The problem is if you use Snapper, don't use the mv command unless mentioned in the Snapper documentation.

Please, from now on refer to the Snapper manual how to roll back the system to a snapshot. Because unlike you suspected initially everything is there (@ and .snapshots), they now only need to rolled back according to the documentation.

PS: Try to install grub-btrfs on the installed system. (Haha, you would ask how? There is a way called manjaro-chroot.) Maybe you will "get it to boot" then.

Here I give the link to the applicable Snapper documentetion in the Arch Wiki and describe how to use it

That's a pretty superficial analysis.

I apologize. I was finishing my post in a hurry because I needed to get to bed so I could get to work in the morning.

From what I see in your terminal output, it doesn't look like you intalled your system in any supported Manjaro way, neither by Calamares, nor by Manjaro Architect. Is it even Manjaro at all?

Respectfully, you're mistaken. I installed using Calamares, as I said. I used the Manjaro KDE boot USB.

But you applied some major changes after the installation. Snapper is not set as an option in Manjaro's Calamares. It is therefore not supported and barely anybody in the community uses it. If you want to use it you need to lear to do it on your own.

Respectfully, that is why I am asking questions on a newbie forum: because I am new to Manjaro and I am trying to learn.

Snapper was recommended to me by another user, in another thread, also in the newbie forum. If you are suggesting that I should not have listened to advice provided to me by users on this forum, then what would you suggest?

Please, from now on refer to the Snapper manual how to roll back the system to a snapshot. Because unlike you suspected initially everything is there (@ and .snapshots), they now only need to rolled back according to the documentation.

I have looked at the Snapper documentation. I would not be asking for help if I had not looked at the documentation. As you can see by looking at this thread and the previous thread on the subject, I have been grappling with this problem since December.

I'm new to Manjaro but I'm not new to Linux. I've been a Linux user for 20 years. I started on Slackware, moved to Gentoo, and I've used a number of other distros in the years since. I've used btrfs before (including with Snapper, on OpenSUSE) but have never had a problem like this. I've looked at the docs. I've read them and reread them, over and over again, since this problem started in December. Clearly you think I've missed something; that may be so, but it is not due to carelessness or lack of trying.

Here's the description of the newbie forum, the one where we're having this conversation:

Unsure where to post? Entirely new to Manjaro? Need step-by-step instructions or a little gentle hand-holding instead of a short answer? If yes to any of these, post here.

I am here because I need step-by-step instructions or a little gentle hand-holding. If you're not interested in providing those things, that's fair enough; you're not under any obligation to help me. But if I wanted a condescending response instead of actual help, I would have gone with Arch.

PS: Try to install grub-btrfs on the installed system. (Haha, you would ask how? There is a way called manjaro-chroot .) Maybe you will "get it to boot" then.

Yes, I've used manjaro-chroot. I went over that in the previous thread, which I linked at the beginning of this one. I don't see any need for a haha.

I appreciate your help earlier in the thread. I don't see as there's any need to be rude and insulting. Everybody has to start somewhere. I'm confused and I'm overwhelmed and I'm not too proud to admit it. I expect you've had days like that too -- and hopefully somebody had a more sympathetic response than "haha."

Why haven't you simply read my next post which probably contains the solution for your problem?

Please, don't expect the same level of gentleness from me as I have for users who don't have any Linux experience.

Running btrfs subvolume snapshot gives me the same "Not a Btrfs subvolume: Invalid argument" error that I got from running btrfs subvolume set-default. Here are the results I get when I run the commands you provided in the other thread:

[manjaro@manjaro ~]$ sudo mount -o subvol=/ /dev/sda3 /mnt
[manjaro@manjaro ~]$ sudo btrfs subvolume snapshot /mnt/@ /mnt/@bad
Create a snapshot of '/mnt/@' in '/mnt/@bad'
[manjaro@manjaro ~]$ sudo btrfs subvolume delete /mnt/@/var/lib/machines
ERROR: Could not statfs: No such file or directory
[manjaro@manjaro ~]$ sudo btrfs subvolume delete /mnt/@/var/lib/portables
ERROR: Could not statfs: No such file or directory
[manjaro@manjaro ~]$ sudo btrfs subvolume delete /mnt/@
Delete subvolume (no-commit): '/mnt/@'
ERROR: Could not destroy subvolume/snapshot: Directory not empty

From there, I'm not quite sure where you're suggesting I restore the snapshot from. There are no snapshots under @bad; the @bad/.snapshots directory exists but there's nothing in it.

If I try to restore from @/.snapshots/ then I get the same error I reported upthread:

[manjaro@manjaro ~]$ sudo btrfs subvolume snapshot /mnt/@/.snapshots/29/snapshot /mnt/@
ERROR: Not a Btrfs subvolume: Invalid argument

The command works on other snapshots. For example:

[manjaro@manjaro ~]$ sudo btrfs subvolume snapshot /mnt/@/.snapshots/4672/snapshot /mnt/@
Create a snapshot of '/mnt/@/.snapshots/4672/snapshot' in '/mnt/@/snapshot'

Unfortunately, that doesn't do me any good; as I mentioned in my previous thread, the only snapshot that was working correctly was snapshot 29; if I try to boot from any of the others, I get a series of errors, beginning with Failed to start Load Kernel Modules, and then it dumps me to a "Give root password for maintenance" prompt.

As I mentioned in my previous post, I didn't start getting the "not a valid subvolume" errors until after I tried

sudo mv @ bad
sudo mv bad/.snapshots/29 @

as somebody suggested upthread. Judging by your post, I guess I shouldn't have used mv for that, I should have used btrfs subvolume snapshot. Is it possible that using mv to move the snapshot, and then to move it back, caused the "Not a Btrfs subvolume" error I'm getting now, or is that just a coincidence?

If you have any suggestions on how to troubleshoot (and, hopefully, fix) the "Not a Btrfs subvolume" error, please let me know. In the meantime, I'll do some searching and see if I can come up with anything.

The error message might have given a hint to look what other subvolumes might be inside of @.
If I were at your computer it would be easier.
I would ask you to install this package from AUR https://aur.archlinux.org/packages/btrfs-list-git
Then mount the partition with subvol=/ again and run
sudo btrfs-list --show-all /mnt
and post the output, please.
If you are able to find on your own what other subvolumes are in @ then you can delete them with btrfs sv del command as I showed, then delete @ and snapshot 29 to @.

Here's the output from btrfs-list. I'll take a look at deleting the other snapshots and snapshotting 29 to @; I'll let you know if I run into any issues.

NAME                                ID     GEN    CGEN                                 UUID     TYPE     EXCL  MOUNTPOINT
d19c87c1                             -       -       -                                    -       fs   34.45G (single, 17.55G free)
   [main]                            5       -       -                                    -  mainvol       -  /mnt
   @                               257 1146523       7 7416d47d-dcb8-194f-8174-b6276530d8a7   subvol       -  
      @/.snapshots/3938/snapshot  4256 1089078 1031034 c30cfa85-79a1-6646-bd9d-885d1821c48d   rosnap       -  
      @/.snapshots/4216/snapshot  4534 1044065 1044065 1bc632f8-1737-b644-ad96-4df9c4ba2deb   rosnap       -  
      @/.snapshots/4217/snapshot  4535 1044066 1044066 28aef108-14b1-bd45-b1b6-991d917f75cc   rosnap       -  
      @/.snapshots/4219/snapshot  4539 1044186 1044186 419a730d-4b70-bf4c-898c-4e16cf2ed13d   rosnap       -  
      @/.snapshots/4220/snapshot  4544 1044265 1044263 19b67da3-f8b7-e844-91b9-d32b53c5ada6   rosnap       -  
      @/.snapshots/4285/snapshot  4609 1061360 1061360 eb37eec1-9e04-3442-a0ef-90066861e108   rosnap       -  
      @/.snapshots/4286/snapshot  4610 1061362 1061361 bac7c179-0a3d-004f-ab9d-04c71e64c747   rosnap       -  
      @/.snapshots/4345/snapshot  4669 1067183 1067182 16343ee4-4712-cf44-83d2-20c33c171a13   rosnap       -  
      @/.snapshots/4346/snapshot  4670 1067184 1067183 9672c603-bf14-2e44-ac53-400536147791   rosnap       -  
      @/.snapshots/4347/snapshot  4671 1067186 1067185 0d5405bb-a1f3-c94d-8c79-9874ed957881   rosnap       -  
      @/.snapshots/4348/snapshot  4672 1117769 1067186 88339470-b9aa-4f46-b984-cfe8da33e651     snap       -  
      @/.snapshots/4447/snapshot  4772 1075415 1075414 47778562-5e54-7148-9c62-ef2adce41e02   rosnap       -  
      @/.snapshots/4471/snapshot  4796 1077010 1077009 04a03382-1b1f-c446-87ba-1e6cab0fae10   rosnap       -  
      @/.snapshots/4495/snapshot  4820 1077929 1077928 9cd4925d-4a76-3c44-b077-1bf0d7adc0e8   rosnap       -  
      @/.snapshots/4519/snapshot  4844 1079021 1079020 c8bfa14a-67b5-944d-a7a1-74fc7a3e400f   rosnap       -  
      @/.snapshots/4543/snapshot  4868 1080216 1080215 4d26325f-e803-c148-ac7b-08cc3deb5c10   rosnap       -  
      @/.snapshots/4567/snapshot  4892 1081106 1081105 3e995c7b-18c9-1b4b-a792-5039c55fb5c7   rosnap       -  
      @/.snapshots/4591/snapshot  4916 1081945 1081944 5e51acda-adea-9743-b9bc-6cb464346c35   rosnap       -  
      @/.snapshots/4615/snapshot  4940 1083598 1083597 4c26fa15-d811-f54a-8ce4-f836f68e681b   rosnap       -  
      @/.snapshots/4629/snapshot  4954 1084218 1084217 37a61736-1a81-0d4b-b7ca-e3b6496c4ca6   rosnap       -  
      @/.snapshots/4630/snapshot  4955 1084219 1084218 feac3076-a629-a443-9286-71c359622a8f   rosnap       -  
      @/.snapshots/4641/snapshot  4967 1084931 1084931 15bbcfe0-1c4f-cc4a-a57b-0ac2096d2c99   rosnap       -  
      @/.snapshots/4659/snapshot  4985 1089076 1085658 4316a1bf-0e84-a44c-8b1f-31e36a681a0e   rosnap       -  
      @/.snapshots/4660/snapshot  4986 1085731 1085731 b8ead82f-be65-5c40-b03a-877871595148   rosnap       -  
      @/.snapshots/4661/snapshot  4987 1085783 1085783 419df7f7-4ca8-ed48-9306-170608443f4c   rosnap       -  
      @/.snapshots/4662/snapshot  4988 1089151 1085824 911ecbd2-c41a-4c45-b1ac-9292eb987678   rosnap       -  
      @/.snapshots/4663/snapshot  4989 1088141 1088140 dc6d9c65-a648-ff48-9cb4-70c4ff4f0a9c   rosnap       -  
      @/.snapshots/4664/snapshot  4990 1088457 1088456 c364ec75-f51f-374b-86ba-e5b6d1dbe0bb   rosnap       -  
      @/.snapshots/4665/snapshot  4991 1088483 1088482 49e36a33-6135-9449-875e-c91c4b4929e1   rosnap       -  
      @/.snapshots/4666/snapshot  4992 1088508 1088507 d5d453f2-8676-184e-87af-df358d847d73   rosnap       -  
      @/.snapshots/4667/snapshot  4993 1088532 1088531 06b06229-9c86-c944-91e8-5162d4ed69d9   rosnap       -  
      @/.snapshots/4668/snapshot  4994 1088555 1088554 08e85247-768d-c54c-bf52-f0332d0d0cba   rosnap       -  
      @/.snapshots/4669/snapshot  4995 1088577 1088576 38002ad9-5beb-2f4e-9da6-f9363e3df5ff   rosnap       -  
      @/.snapshots/4670/snapshot  4996 1088604 1088603 7dfda68a-63c9-fd42-b78e-54ae073bf026   rosnap       -  
      @/.snapshots/4671/snapshot  4997 1089060 1088626 0412f510-d34e-1441-911c-56b8724b7799   rosnap       -  
      @/.snapshots/4672/snapshot  4998 1146521 1088650 f2c0033f-4427-f040-bc38-74f956421e66   rosnap       -  
         @/snapshot               5001 1146521 1146521 e56b1f67-e333-744b-a822-b33785a11319     snap       -  
      @bad                        5000 1146519 1146519 f0a786d6-6ef4-3346-878a-99941f19140e     snap       -  
   @/.snapshots                    266 1146528      85 6ce4eff8-add2-5744-8cf3-833380e2e99e   subvol       -  

Okay, at this point I've successfully deleted @, but I'm still not able to restore 29.

29 was under @/.snapshots/29/snapshot. It's not there anymore, since I deleted @; however, I did make a copy to another directory first. (Since snapshotting it didn't work.)

But if I try to restore from the copy, I still get the same error.

[manjaro@manjaro mnt]$ sudo btrfs subvolume snapshot /mnt/_old29snapshot /mnt/@
ERROR: Not a Btrfs subvolume: Invalid argument

Any other ideas?

At this point I'm thinking that my best call may be to give up on fixing this and start over with a clean install. (My /home is a separate partition so hopefully I can keep it as-is and just reinstall / and /boot.)

Where do you see @/.snapshots/29/snapshot in the list??
It is not there, therefore you can't make a snapshot of it.

Yes, that's what I've been saying.

It was recognized as a valid snapshot a week ago. It hasn't been since I did that mv. I've been trying to figure out what happened, why it isn't working anymore, whether using mv to move it to @ and then back was what caused it to break or if that's just a coincidence, and how I can get it working again.

I understand that btrfs is not recognizing it as a valid subvolume; that's why it's giving "not a valid subvolume" errors. I've been trying to determine how it got that way and how to fix it.

I think it's probably time I gave up on trying to fix the issue; I'm going to go ahead and try a clean install. Thanks for your help.

Edit to add: Clean install was mostly successful (I'm still having some grub issues; I'll do some research and, if I still can't figure out how to fix them, I'll start a new thread).

I don't know what the proper forum protocol is here; should I mark this as "solution"? I don't know if I'd call it a solution so much as just giving up and starting over.

Sorry that we weren't able to figure it all out.
I would seriously suggest not to use Snapper again. @Librewish now also recommends Timeshift.
It's not solved, so no need to mark it as solved.

Forum kindly sponsored by