[SOLVED] Need help setting up multi-boot with btrfs

[Schwarzer Kater]

Thank you.
The "while" loops are running for a purpose: to wait for a specific input (e.g: "Y" or "N"). They are exited when certain things have been done after that input.
There are several ways to do this in a Bash script, this one seems to be actually quite common, works fine for my purpose and has been syntactically and logically tested lots of times (and as simple as my code is I don't think that there can be any unforeseen side effects). Other solutions I had in mind for this are more complicated to maintain for me.

[TwoFistedJustice]

Feel free to do so (they are more meant for other people than for myself, but it is convenient to have them) - and removing snapd etc. is not irreversible (at least for the stuff that is installed by default), that's what the "reinstall Snap (for release-upgrade)" script is for.
Programming always has been more a hardship than a joy for me, and I would be glad if you told me something that can be improved (code- or language-wise).

I'm just learning bash scripting so I may be wrong here since bash is bashed-together language ( thus the name - according to facts I made up ) --- I was reading the script to remove snap and I saw a few places where you used "while true". Since true is always true, that while loop will always run ( plus it's a loop, so it may run infinitely or cause some kind of unforeseen side-effect ) , you may be able to omit the while-do-done bit. If it's a matter of running it at a particular time, you may want to extract it into a function and then call that function. You can also convert it to a if-conditional which is guaranteed to only run once.

[TwoFistedJustice]

I followed through my own tutorial and had to suffer the consequences. Now I have a clean working dual boot system with fresh installs of Kubuntu and Kali.

I think the write up is finished or very close to finished.

Is it sticky-worthy?

https://github.com/TwoFistedJustice/...TRFS-and-Linux

[Schwarzer Kater]

"Kali's default desktop environment is Xfce." So I assume this is where the main focus of their bug fixing lies (it is based on Debian testing…).

Also on their website one can find a section in their docs about installing Kali on btrfs with snapper (you did't mention this so far in your posts about the btrfs journey, so in case you did not see it): https://www.kali.org/docs/installation/btrfs/

[TwoFistedJustice]

Now I've hit a snag.

I'm re-doing my test system to try out my own tutorial (which has resulted in a substantial rewrite of Phase 3).

The snag is that I chose the KDE desktop for Kali, which supposedly work just fine ( LIES!!!! )

This gives me the opportunity to remove a distro.


Booting back into Kubuntu I tried to delete the Kali installed subvolumes with


sudo btrfs subv delete @



and was harshly rebuked with

ERROR: Could not statfs: No such file or directory.


Google and various forums revealed nothing helpful.

1. Can I just rm -r these things from Live USB? (tried it: YES! sudo rm -rfv @xxx - then back into Kubuntu to wipe out the EFI/kali directory)
2. What is the correct way via btrfs?


I intend to add this to the write up since it seems important.

[Schwarzer Kater]

Feel free to do so (they are more meant for other people than for myself, but it is convenient to have them) - and removing snapd etc. is not irreversible (at least for the stuff that is installed by default), that's what the "reinstall Snap (for release-upgrade)" script is for.
Programming always has been more a hardship than a joy for me, and I would be glad if you told me something that can be improved (code- or language-wise).

PS: Oh, and the "Activities" comment above was only meant as a (bad) joke.

[TwoFistedJustice]

Cool idea! Sounds like a fun project.

I serious doubt snaps would work this way but maybe. depending on how they are stored. I don't use snapd but could be an interesting experiment.

Snaps are sort of like btrfs in that they mount snapshots (compressed ones). But they scatter files all over the system in order to operate. Frankly I don't understand why anyone would want to use them when Flatpaks have all the same functionality and are less resource intensive. The auto-update advantage that Snaps had, they no longer have because Flatpak does that too now. (or so I have read)

I was digging through flathub and just about every program I would want that is available in Snaps is also available in Flatpak. There are also a lot of other programs I like that are now available that way too like all the Jetbrains IDES and DIY Layout Creator. Also Firefox and Chromium.

I'm actually considering making use of Schwarzer Kater's Snap-terminator scripts. But one thing at a time.

[oshunluvr]

Cool idea! Sounds like a fun project.

I serious doubt snaps would work this way but maybe. depending on how they are stored. I don't use snapd but could be an interesting experiment.

[TwoFistedJustice]

*cough* syncthing *cough*cough*
*burp* Nextcloud* *burp* *belch* (though this probably works best on a separate computer/nas/VPS/etc)

Some people use github/gitlab to store and sync their 'dot' files between machines.
THIS project seems popular and active,. but there are tons of things out there for this specific purpose.
Sooooooo, not even the slightest bit crazy in any fashion.
But this topic will reveal many rabbit holes, many of them deep and long

I think they call it "Activities" in KDE Plasma…

Nextcloud and Activities aren't quite what I was thinking.

I was specifically thinking of Syncthing. But before I set that up I want to have my file systems set up in a helpful way. Which is where btrfs shared subolumes comes into play. I already have my dot files backed up to github.

Shared subvolumes make for some really cool possibilities.

For example:
I could have my dotfiles on a subolume called @dotfiles which is shared between various distros, which all reside on the same partition. I wouldn't need symlinks. Just a little modification to each distro's .bashrc.

Change

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi


to

if [ -f /dotfiles/.bash_aliases ]; then
. /dotfiles/.bash_aliases
fi

Now every distro on that machine can use the same aliases.

I have already tested it and it works just dandy.

You could also have a subvolume called @apps or @programs or @whatever and have your flatpaks all installed there and accessible from every distro. I have already tested this and confirmed that it is possible.

I can also have my Jetbrains IDEs all installed there and accessible the same way.

I'm less confident about Snaps.

[oshunluvr]

I've been messing around with sharing subvolumes between distros and have found that I can share not only my documents and pictures between distros, but also config files and even some programs, including flatpaks.

I think it's possible without too much trouble to set a system up such that a lot of stuff can be shared between distros. Maybe even going so far as syncing the shared files between machines so you can have two or more machines set up similarly such that a change on one is soon automagically replicated in the other. The benefit would be that you can have your at-home box, office-box, and to-go-box all share certain functionality that you can rely on while keeping them all up to date with each other in near real time. It may also simplify backups because you'd be able to back up the shared files at one go from one machine, instead of having a full back up of each machine.

Do I sound like a crazy Linux nutso yet? I'd love some help putting this together. Does anyone want to collaborate with me on creating this?

One obvious way to make this happen is to use BTRFS and subvolumes. By simply replacing any folder you want to share across distros with a subvolume, one could mount it on as many distros as one likes on a single machine. This is much different than "syncing." Syncing implies a duplicate copy is being made. Sharing subvolumes in this way would provide only a single copy so backups would still be required. Also, all kinds of measures would have to be taken to insure things like user IDs were the same across distros, etc.

If one was to attempt to implement something like this on separate machines (I assume via a network connection) anything needing to be present on the machine prior to network availability would have to obviously be on the machine. In this case the file system choice would be irrelevant because you'd be mounting network shares. I'm not familiar enough with Flatpaks to know how or if that would work.

I do this sort of sharing with Media (Documents, Music, Videos, etc.). I have a dedicated server that has a set of shared "folders" that mimic the same media folders Kubuntu installs by default. My concept was to allow any user on any system to add and access any file to the shared folders, but still retain "private" files. I mount these shared folders in the "Public" folder on every user account and every PC thus making it clear anything there is shared.

One could actually have a remote home folder so that whenever you logged into any system on your network, you'd have the same home. Again, some effort to keep things on par would probably be required.

Note that the term "server" has more than one meaning. In the physical sense, a dedicated machine. In the software sense, a service provided to one or many machines. My point here is the above could be undertaken by any system on the network without being a separately dedicated piece of hardware. But obviously it would have to be on-line to access it.

[Schwarzer Kater]

[…] The benefit would be that you can have your at-home box, office-box, and to-go-box all share certain functionality that you can rely on while keeping them all up to date with each other in near real time. […]

I think they call it "Activities" in KDE Plasma…

[claydoh]

*cough* syncthing *cough*cough*
*burp* Nextcloud* *burp* *belch* (though this probably works best on a separate computer/nas/VPS/etc)

Some people use github/gitlab to store and sync their 'dot' files between machines.
THIS project seems popular and active,. but there are tons of things out there for this specific purpose.
Sooooooo, not even the slightest bit crazy in any fashion.
But this topic will reveal many rabbit holes, many of them deep and long

[TwoFistedJustice]

I've been messing around with sharing subvolumes between distros and have found that I can share not only my documents and pictures between distros, but also config files and even some programs, including flatpaks.

I think it's possible without too much trouble to set a system up such that a lot of stuff can be shared between distros. Maybe even going so far as syncing the shared files between machines so you can have two or more machines set up similarly such that a change on one is soon automagically replicated in the other. The benefit would be that you can have your at-home box, office-box, and to-go-box all share certain functionality that you can rely on while keeping them all up to date with each other in near real time. It may also simplify backups because you'd be able to back up the shared files at one go from one machine, instead of having a full back up of each machine.

Do I sound like a crazy Linux nutso yet? I'd love some help putting this together. Does anyone want to collaborate with me on creating this?

[TwoFistedJustice]

I updated it the tutorial. https://github.com/TwoFistedJustice/...ure-primary-os


I added the parts about the symlinks, changed the other related parts about grub.cfg, and added some TOCs to help get around.

[TwoFistedJustice]

OK so I installed Kali in a VM and the file above is installed with two additional lines:

do_initrd = yes
do_link_in_boot = no

but not the deb package. However, it's not installed on my KDEneon install either.
I went ahead and edited the above file to

do_link_in_boot = yes

and updated the system, which installed new kernels - and viola!

I successfully tried this on my test system. But rather than pulling a system update, I made the symlinks manually.

I will update the write up to reflect this improved information -- but not tonight ＼（´Ｏ｀）／