I had the same problem (running Fedora 38), and this post really helped me - it goes through the whole MOK generation/enrollment and then provides a script to automatically sign the modules. I had to make a couple of adjustments to make it work on my system and to automatically load the modules with modprobe , but now I just run /sbin/vboxconfig; /root/bin/sign-vbox-modules each time my kernel gets updated and can use VBox fine again.
I'm very excited about how the Linux community generally seems to be moving towards various approaches to immutable systems - all of them having in common that system updates are going to be a lot less likely to break. The future is looking good!
is pretty vague. Do you mean locked down, with features like SafetyNet which locks people in to Google Services? Or do you mean locked down in the sense that installing packages doesn’t just directly change the files in / ?
Systems like rpm-ostree still allow modifications to the OS, it just requires other steps. OpenSUSE MicroOS even allows for arbitrary modifications to the root fs through transactional-update (it even allows for dropping in to a transactional-update shell, so it’s not necessary to prefix each command with transactional-update).
Especially OpenSUSE MicroOS feels more like OpenSUSE Tumbleweed, compared to Fedora rpm-ostree’s limitations compared to Fedora dnf.
Using Fedora Silverblue has gone a long way to dispel that concern for me. It goes out of its way to be much more user-centric than that. I can’t speak for the others yet.
I don’t think having a swap partition or file would be all that useful because I have plenty of memory. I’ve never had to reinstall Linux so I’m not sure why I would need a separate home. If I did bork my OS somehow I’m fairly confident I could repair it from a live distro. And even if I did end up having to save my home I could just copy the files I want to another drive if it really came to that.
In this case you could view a swap partition as a safety net. Put 20-30GB in a swap partition in case something goes wrong. You won’t miss the disk space.
I’ve never understood why people run without swap. There’s basically no downside to having it. If you’re running a high spec, high RAM machine you probably also have a big SSD/HDD and are very unlikely to be squeezing it to the last GB (and if you are you should probably look into upgrading that). And if you’re on a machine with very limited SSD/HDD capacity, you’re probably not in an “ample RAM” situation anyway.
Even on high RAM systems, a few GB of swap can enable better caching and more graceful memory management. But heck, even if the thing sits there like an 8GB lump of nothing, were you really going to miss that last 8GB?
Lots of great answers here already so I will only address a couple of things that haven’t been mentioned:
Regarding Fedora Silverblue:
Currently, Fedora Atomic Desktops are in a major shift to accept OCI container images for delivery of packages. This means that the built image becomes one compliant to OCI and that we boot into an OCI container as our system. As OCI images are relatively declarative (not to the extent that NixOS does (yet)), it becomes possible to have a set of config files (most importantly, the so-called Containerfile) in which your system is ‘declared’/‘configd’. In case you’re interested into how this looks/works, consider taking a look at uBlue’s startingpoint or if you’re more interested in the scope of configuration into Bazzite and/or Bluefin.
apx is available as a COPR on Fedora Atomic Desktops.
Nix can be installed on Fedora Atomic Desktops using Determinate Systems’ installer.
Regarding Vanilla OS:
They’re also moving to a model that’s very close to where Fedora Atomic Desktops is heading towards. So, expect a similar way to config/‘declare’ your system.
What are your thoughts on the three four distros mentioned above?
It’s a question of polish if you’d ask me. With Fedora Atomic Desktops and NixOS being advantageous due to being more established and better funded. I wouldn’t write off Vanilla OS yet as they seem to know what they’re doing. Though, I wouldn’t keep my hopes up for blendOS as its main developer was unaware of which MAC was configured by default on blendOS (spoiler alert: none, at least at the time).
Furthermore, NixOS is literally its own thing and unfortunately infamous for its steep learning curve. If you can afford to learn and conquer NixOS, then NixOS should be the recommendation; unless (like me) you seek SELinux on your systems.
Between Fedora Atomic Desktops and Vanilla OS; Vanilla OS is still in its major rewrite/revamp. The alpha builds are there, but I wouldn’t recommend using those on production machines. Fedora Atomic Desktops, on the other hand, has been going strong for a while now and the uBlue-team has even succeeded in making the OCI-stuff accessible for the general (Linux) public. So if you want to switch now and NixOS is/seems too hard; then Fedora Atomic Desktops it is. On that note, I recommend to check out the uBlue project.
Which ones are the most interesting, and for what reasons?
Honestly, all of them are really interesting, but NixOS does the most unique stuff; with only Guix doing something similar within the Linux landscape. To give you a taste of some of the wild stuff found on NixOS; there’s the so-called Impermanence module which -to my knowledge- happens to be the closest thing to a usable stateless system we’ve got; period. Consider reading this excellent blog post in case you’re interested to know what this entails.
I set it up this way so that if I need to reinstall Linux, I can just overwrite / while preserving /home and just keep working after a new install with very few hiccups.
Even with a single partition for / and /home you can keep the contents of /home during a reinstall by simple not formatting the partitions again. I know when I tried years ago with Ubuntu years ago the installed asked if I wanted to remove the system folders for you. But even if the installer does not you can delete them manually before hand. Installers wont touch /home contents if you don’t format the drive (or any files outside the system folders they care about).
Though I would still backup everything inside /home before any attempt at a reinstall as mistakes do happen no matter what process you decide to go with.
There was no option per say, at least on the ubuntu installed I tried many years ago. Just a popup that happened sometime before the install but after the manual partitioning if the root partition had folders like /etc /usr /var etc that were needed by the installer. Not sure if all installers do this - but I would suspect if they didnt you can just delete the folders manually before you enter the installer and pick manual partitioning option and opt to not format any partitions.
And that’s exactly what happened in your case David. Which is why I’m so happy (also because I fixed the tools from an author I like and already had the books at home :-P):
Really detailed and cool response from the kernel developer. I also found the use of the recent BPF feature to provide a workaround until a proper kernel fix lands really interesting.
First of all, check that hardware virtualization is enabled in your UEFI setup.
You need to have packages virtualbox-dkms and linux-headers installed (together with all their dependencies, but you don’t have to check them manually). linux-headers must be of the same version as linux-image. That’s all that you need to get driver properly built. Don’t listen those users who recommend you to remove and reinstall these packages or install additional packages manually, this kind of magic doesn’t work.
Also note that you cannot use kvm and virtualbox simultaneously. If you are using some kvm-based virtualization system, it causes a conflict.
I don't like wasting space or having to predict how much space I'll be using two years from now, so I prefer the minimum of partitions: efi, boot, and system(luks), with a btrfs subvol for /, home, and swapfile.
Except for EFI/swap, partitions nowadays only make sense if you want to force a hard cap on a directory, e.g. /tmp, /var/mail or /var/spool to make sure one function of a system doesn’t break the others when it goes out of hand, but there’s also quotas for that. It always sucks if you have to resize, so it’s probably best to have as few as possible.
I use btrfs subvols to keep my stuff separate without any sort of hard limit.
The reason? Makes managing system backups easier. The home and log directories are both on separate subvol; the tmp directories are on tmpfs. All I need to do is snapshpt the root subvol.
I disagree. Someone who isn’t willing to try Linux on their own, or otherwise investigate, just because they’re curious is not ready for the baggage that comes with a new OS. Agreeing with another comment: don’t make this change at the same time as other major changes to your career. That is a recipe for disaster.
I’m a Mac / Linux guy who dislikes Windows. I wouldn’t even suggest getting a Mac at the same time as making huge career changes. And Linux is harder. Not impossible, but no training-wheels. You want something new, but you aren’t really interested in Linux itself.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.