My college-bound child has a frame.work laptop DIY edition coming soon. We're preparing now by installing Fedora Silverblue on the SSD we already have. I put the SSD into a USB NVMe housing, attached it to their existing Fedora system, then guided them through setting up a virtual machine and installing Silverblue inside the virtual machine.
Sadly, libvirt-manager doesn't support directly attaching a device to a VM. So we added a dummy qcow file in VM setup, chose to configure before booting, deleted the dummy device and its associated qcow file, and then booted. Waited at the boot prompt, ran virsh attach-disk silverblue38 /dev/sdb vda in a root terminal, and then let it boot into the installer.
In the installer, it was just like installing on bare metal, except that we didn't have to set up WiFi, since it was using the host system's networking.
When the new laptop arrives, we'll stop the VM, mount /var/home (because Silverblue) on the host system, copy the /home content from the host system to the new drive, and when we drop the SSD into the frame.work laptop, it should just boot up into a working system.
Oops. Installed in a BIOS VM doesn't work so good for working on an EFI system. Will have to reinstall tomorrow from a USB stick on the actual hardware, but can leave /var/home alone without formatting it, so it should be a quick last step to a working laptop. 🤞
The installer did an even better job than I expected at preserving the installed content. We've now used rpm-ostree (to install restic) and installed libreoffice from flathub.
I'll not be surprised if toolbox comes in handy later, but it's unlikely to be critical in the first semester.
The expansion cards are really tight. It's hard to pull them out with one hand while pressing the release button with the other. This will get in the way of, say, easily swapping in a wired Ethernet port when necessary. ☹️
One #silverBlue annoyance is that if you are doing manual partitioning (in this case, reserving disk space in case the school unexpectedly creates a need to run Windows at some point), there's insufficient guidance on partitioning. The documentation points out that the installer doesn't know about Silverblue limitations, and so describes what partitions/file systems you can and can't create, but has nothing on expected sizes. Hopefully we guessed right. 🤞
@clolsonus The entire OS is read-only. You can have "overlays" on top of the base OS. It allows rollback even of an update to the next version!
It updates kind of like an android phone — downloading a kind of pre-installed next version in the background, and then just booting into it. The security update of the day and the update to the next major version are similar in that regard.
Unlike android, it doesn't silently upgrade you to a new version; for that, you have to explicitly change the base version (with a single command). But the rest of the process is just like applying the security update of the day: Download in the background, reboot. No waiting while RPM changes lots of little files and then spends a minute running post scripts.
Also unlike android, rollbacks are designed in, and you don't have to wipe your system to return to an older software state if something goes wrong in the new version.
You could reasonably switch back and forth between the current stable version and rawhide rolling beta with just a reboot each time.
In this model, many additional apps you run are also more like an Android app: you run a flatpak or an Appimage, and that isn't touched by the update. You can still install third-party RPMs (say, Chrome) as a "layer" though you have to do it a bit different (using rpm-ostree) and I don't have experience with it.
I haven't set this up yet on my own laptop but am seriously considering buying a larger SSD for my laptop and moving over. Finding an hour I don't care about for a system update is sometimes a pain. And if I did this for my home server, home internet outages for security updates would be shorter and less disruptive to my family.
@mcdanlj Interesting ... I definitely need to find an hour to play with this too. Your explanation just leads to 100 more questions, but maybe those are better answered by trying it out and playing with it. I know that I typically end up installing a myriad of packages on any system I run for all the stuff that isn't in the stock image, and I've gotten in the [dumb] habit of running dnf update before my first coffee each day, so I'd be curious to see how all that gets handled in layers on top of an immutable base system.
@clolsonus That's exactly the problem I see for myself. I've installed a lot of extra packages on top of the base. However, many of the packages that I use the most I'm using appimages and for others could use flatpaks, so it isn't crazy to think that I could move.
@mcdanlj One of these days I need to figure out how dnf and flatpack play together. F38 made a big deal about flatpack, but I think everything on my system is still rpm/dnf? If flatpack on fedora is anything like snap on ubuntu, then I definitely won't be able to understand it. 🙂
And @cassidy has an image that's a modified version of stock GNOME with some tweaks — it's a good example of how to have something similar to Silverblue but with adjustments "baked in".
For mounting the drive on the host system directly for copying the files, I did have to look up how to use cryptsetup because it's been a few years since the last time I did something crazy that caused me to need to do it manually. I'm so used to filesystem encryption on Linux being It Just Works. In fact, I had forgotten the name cryptsetup because I hadn't had to use it for so long. 😀
Add comment