The object is to display a logically arranged "tree" diagram of subvolumes and snapshots. Seems like it would have some value.
https://github.com/CopOnTheRun/btrview
https://github.com/CopOnTheRun/btrview
-
Hi, author of the btrview here! Please note btrview is still very much under active development, and I do have plans to package this as a .deb eventually (that's how (k)ubuntu people are installing stuff still right?), but I've got to learn more about the process before that will happen so it might take a minute. In the meantime I'm happy to answer any questions, listen to features requests, or field any bugs people may have with this project! -
Author in the house! hehe
Really, welcome to KFN!Using Kubuntu Linux since March 23, 2007
"It is a capital mistake to theorize before one has data." - Sherlock Holmes
Comment
-
Yeah, we are still "deb" people, lol. Welcome to the forum!Originally posted by CopOnTheRun View PostComment
-
OK, so I got around to installing and trying it out this morning.
It took me an hour to figure out that I was using python 3.10 and btrview requires 3.11. Since I'm using KDEneon based on Ubuntu 22.04 there were some hurdles to setting python 3.11 as default after installing it.
Finally, I was able to use it. First run at it gave me a ton of errors but hinted that I need to be root to use it. Running the command with "sudo" results in "command not found" - duh, since I installed it as myself. Finally, after installing it as root user, it ran:
You can see my setup isn't very complex, but from what I've seen on Reddit, many users have a very complex btrfs usage scheme. Heck, I'm so old school I still have a swap partition, LOL.Code:stuart@office:~$ sudo btrview root Subvolume Tree: Snapshot Tree: <FS_TREE> on: /subvol @KDEneon_home on: /home ├── @grub ├── @KDEneon_home_backup ├── @KDEneon_home on: /home ├── @KDEneon_home_backup-new ├── @KDEneon2024 ├── @KDEneon_home_daily_6 ├── @KDEneon2024_home ├── @KDEneon_home_daily_5 ├── @KDEneon on: / ├── @KDEneon_home_daily_4 ├── @KDEneon_backup ├── @KDEneon_home_daily_3 ├── @KDEneon_home_backup ├── @KDEneon_home_daily_2 ├── @KDEneon_backup-new ├── @KDEneon_home_daily_1 ├── @KDEneon_home_backup-new └── @KDEneon_home_daily_0 ├── @kubuntu2404 @KDEneon on: / ├── @kubuntu2404home ├── @KDEneon_backup ├── @kubuntu2404swap ├── @KDEneon_backup-new ├── @KDEneon_daily_6 ├── @KDEneon_daily_6 ├── @KDEneon_home_daily_6 ├── @KDEneon_daily_5 ├── @KDEneon_daily_5 ├── @KDEneon_daily_4 ├── @KDEneon_home_daily_5 ├── @KDEneon_daily_3 ├── @KDEneon_daily_4 ├── @KDEneon_daily_2 ├── @KDEneon_home_daily_4 ├── @KDEneon_daily_1 ├── @KDEneon_daily_3 └── @KDEneon_daily_0 ├── @KDEneon_home_daily_3 <FS_TREE> on: /subvol ├── @KDEneon_daily_2 @grub ├── @KDEneon_home_daily_2 @KDEneon2024 ├── @KDEneon_daily_1 @KDEneon2024_home ├── @KDEneon_home_daily_1 @kubuntu2404 ├── @KDEneon_daily_0 @kubuntu2404home └── @KDEneon_home_daily_0 @kubuntu2404swap Comment
-
I went back and mounted ALL my btrfs file systems (most are not mounted by default) and ran it again:
Code:stuart@office:~$ sudo btrview root Subvolume Tree: Snapshot Tree: <FS_TREE> on: /subvol @KDEneon_home on: /home ├── @grub ├── @KDEneon_home_backup ├── @KDEneon_home on: /home ├── @KDEneon_home_backup-new ├── @KDEneon2024 ├── @KDEneon_home_daily_6 ├── @KDEneon2024_home ├── @KDEneon_home_daily_5 ├── @KDEneon on: / ├── @KDEneon_home_daily_4 ├── @KDEneon_backup ├── @KDEneon_home_daily_3 ├── @KDEneon_home_backup ├── @KDEneon_home_daily_2 ├── @KDEneon_backup-new ├── @KDEneon_home_daily_1 ├── @KDEneon_home_backup-new └── @KDEneon_home_daily_0 ├── @kubuntu2404 @KDEneon on: / ├── @kubuntu2404home ├── @KDEneon_backup ├── @kubuntu2404swap ├── @KDEneon_backup-new ├── @KDEneon_daily_6 ├── @KDEneon_daily_6 ├── @KDEneon_home_daily_6 ├── @KDEneon_daily_5 ├── @KDEneon_daily_5 ├── @KDEneon_daily_4 ├── @KDEneon_home_daily_5 ├── @KDEneon_daily_3 ├── @KDEneon_daily_4 ├── @KDEneon_daily_2 ├── @KDEneon_home_daily_4 ├── @KDEneon_daily_1 ├── @KDEneon_daily_3 └── @KDEneon_daily_0 ├── @KDEneon_home_daily_3 <FS_TREE> on: /subvol ├── @KDEneon_daily_2 @grub ├── @KDEneon_home_daily_2 @KDEneon2024 ├── @KDEneon_daily_1 @KDEneon2024_home ├── @KDEneon_home_daily_1 @kubuntu2404 ├── @KDEneon_daily_0 @kubuntu2404home └── @KDEneon_home_daily_0 @kubuntu2404swap blade2 Subvolume Tree: Snapshot Tree: <FS_TREE> on: /mnt/blade2 <FS_TREE> on: /mnt/blade2 990pro2 Subvolume Tree: Snapshot Tree: <FS_TREE> on: /mnt/990pro2 <FS_TREE> on: /mnt/990pro2 sdb2 Subvolume Tree: Snapshot Tree: <FS_TREE> on: /mnt/sdb2 <FS_TREE> on: /mnt/sdb2 ├── @grub_ro @grub_ro ├── @KDEneon_backup @KDEneon_backup ├── @KDEneon_home_backup @KDEneon_home_backup └── @_ro @_ro root_backup Subvolume Tree: Snapshot Tree: <FS_TREE> on: /mnt/root_backup @grub ├── @grub └── @grub ├── @Ubuntu_Server_2204 <FS_TREE> on: /mnt/root_backup ├── @Kubuntu2004 @Ubuntu_Server_2204 ├── @_ro @Kubuntu2004 ├── @grub_ro @_ro ├── @grub @grub_ro ├── @KDEneon_backup @KDEneon_backup └── @KDEneon_home_backup @KDEneon_home_backup storage Subvolume Tree: Snapshot Tree: <FS_TREE> on: /mnt/storage <FS_TREE> on: /mnt/storage └── @music └── @music Last edited by oshunluvr; Apr 20, 2024, 07:28 AM.Comment
-
OT:
Well, so do I.Originally posted by oshunluvr View Post
AFAIK the kernel developers still recommend a swap partition over a swap file, although I am too stupid to say why they do.Last edited by Schwarzer Kater; Apr 21, 2024, 06:35 PM.Debian KDE & LXQt • Kubuntu & Lubuntu • openSUSE KDE • Windows • macOS X
Desktop: Lenovo ThinkCentre M75s • Laptop: Apple MacBook Pro 13" • and others
get rid of Snap script (20.04 +) • reinstall Snap for release-upgrade script (20.04 +)
install traditional Firefox script (22.04 +) • install traditional Thunderbird script (24.04)Comment
-
Hmpf sez youOriginally posted by oshunluvr View Post
I only have one because neon's installer defaults to it, for hibernation purposes. So it was yuuuge. I just never bothered to remove it and add a swap file last time I did a clean install. Or was it because I thought that swap files didn't work with btrfs? It has been too long.Originally posted by oshunluvr View PostComment
-
Just figured out installing python3.11 and making it default broke apt.
Fixed it with: sudo ln -s /usr/lib/python3/dist-packages/apt_pkg.cpython-310-x86_64-linux-gnu.so /usr/lib/python3.11/apt_pkg.so
I might be rolling back if I find too many other breakages.Comment
-
I use a swap partition because I multi-boot. Seemed simpler to just have a swap partition to share. I don't hibernate ever because this desktop machine is on 24/7 mostly.Originally posted by claydoh View Post
I suppose I could change to a swapfile in a subvolume and share it that way as well, but not worth re-partitioning over at this pointComment
-
This makes the output more "fun":
clear && sudo btrview 2>&1 | dialog --progressbox 80 140
Run that in a Konsole window...Comment
-
As someone who has used btrfs subvolume list a lot, I think I'll be reaching for btrview often.
When I saw that it's python with a dependency, past experience (see xkcd) had me reaching for a venv, and for those on 22.04 and Neon that might be best, but on 23.10 I think it simplest to install python3-treelib using apt, then git cloning btrview to my home directory and running it with sudo from there giving the whole path.Regards, John LittleComment
-
So the Python3.11 change over to my KDEneon install broke too many things to be worth the effort to continue fixing all of them. So I rolled my KDEneon install back to the day before and instead I launched my Kubuntu 24.04 and 23.10 VMs to look at their Python3 default versions. 23.10 had 3.11 and 24.04 had 3.12, so I stuck with 23.10 - made a VM snapshot, upgraded all the packages and installed btrview there. The process:
sudo apt install pip
sudo pip install btrview
At this point I encountered an error:
error: externally-managed-environment
The text in the error message wanted me to create a virtual python environment. Rather than learning how to do that, I just renamed the file:
/usr/lib/python3.11/EXTERNALLY-MANAGED
to
EXTERNALLY_MANAGED-dead
Then "sudo pip install btrview" worked seamlessly
I had no snapshots on this VM so I made a couple to test it out.
Note that since btrview uses the "btrfs" command it requires sudo access to run. If you install it as your user with "pip install btrview" (no "sudo") it does not work.
Fun upgrade: Since this VM will be my testing ground for this application as it develops, I decided to make it easier to run by not having to use "sudo" and enter a password every time.
First I created a file in /etc/sudoers.d/ to allow my user to run it without having to type in the password.
sudo visudo -f /etc/sudoers.d/btrview
in this file I added this line:
USERNAME HOSTNAME=(root) NOPASSWD: /usr/local/bin/btrview
and saved it (obviously, one would enter your actual user name and host name). Now my user did not need a password to run btrview but I still needed to enter "sudo btrview".
Next. I edited my user's bashrc file and added this alias:
alias btrview='sudo btrview'
Logging out and back in, now I just type "btrview" and see the output.Comment
-
You can also pass the flag --break-system-packages to ignore the warning just once instead of permanently ignoring it.Originally posted by oshunluvr
I'm attempting to troubleshoot another user who has this same problem but is on a fedora machine. Is the secure_path variable set in your /etc/sudoers file? It is commented out by default in the distribution I'm using and I can't think of why else the $PATH variable would be changing.Originally posted by oshunluvrComment
-
There's reasons that they've deliberately broken things by throwing that error. An install's Python set up can become a mess easily. It might work for a while then descend into dependency hell later when some python package updates.error: externally-managed-environment
I recommend not applying the change to turn off the error. We have to rely on the APT packagers keeping their end of things under control, and IMO it's a good idea to pay attention when they push out such drastic breakage.
If you're into Python, you'll likely know about this and will naturally use a venv or conda or some virtualization approach. Until btrview makes it into APT (aka .debs) I think it's simpler to git clone the package, especially since it needs to run with sudo. My earlier reply could have spelled things out more clearly:- sudo apt install python3-treelib python3-rich btrfs-progs
- git clone https://github.com/CopOnTheRun/btrview.git
Then to run it:- cd btrview
- sudo python -m btrview
Regards, John LittleComment
Comment