Hot do I not use backports kernel?

[emilianomacht]

Hello! I just installed gnome spiral linux yesterday and I'm loving it so far! Thank you so much for putting this together

I would prefer to use the regular stable debian kernel, not the backports one. So, I ran this:

sudo apt-get --purge remove linux-image-5.18.0-0.bpo.1-amd64

The option for 5.18 disappeared in the grub menu (advanced option), and the only one left was 5.10, which is expected! Everything's good so far.

$ uname -r 
5.10.0-15-amd64

However, I have a couple of questions:

1. Just to confirm, running the following command to see what's still installed:

$ apt list --installed | grep linux
[...]
linux-headers-5.10.0-15-amd64/stable-security,now 5.10.120-1 amd64 [installed,automatic]
linux-headers-5.10.0-15-common/stable-security,stable-security,now 5.10.120-1 all [installed,automatic]
linux-headers-5.18.0-0.bpo.1-amd64/bullseye-backports,now 5.18.2-1~bpo11+1 amd64 [installed,automatic]
linux-headers-5.18.0-0.bpo.1-common/bullseye-backports,bullseye-backports,now 5.18.2-1~bpo11+1 all [installed,automatic]
linux-headers-amd64/bullseye-backports,now 5.18.2-1~bpo11+1 amd64 [installed]
linux-image-5.10.0-15-amd64/stable-security,now 5.10.120-1 amd64 [installed,automatic]
linux-kbuild-5.10/stable-security,now 5.10.127-2 amd64 [installed,automatic]
linux-kbuild-5.18/bullseye-backports,now 5.18.14-1~bpo11+1 amd64 [installed,automatic]
[...]

I should also remove the rest of the *bpo packages, right? I would run this:

sudo apt-get --purge remove linux-headers-5.18.0-0.bpo.1-amd64 
sudo apt-get --purge remove linux-headers-5.18.0-0.bpo.1-common 
sudo apt-get --purge remove linux-headers-amd64 
sudo apt-get --purge remove linux-kbuild-5.18

The thing I'm worried about is the linux-headers-amd64, which brings me to the next question:

2. How do I keep the 5.10 updated? As I've said before, I have 5.10.0-15 installed, but that's confusing because if I look at https://packages.debian.org/source/stable/linux , there is no 5.10.0-15, only 5.10.0-13 and 5.10.0-16. Where did the -16 come from?

But more to the point, I suppose the solution is to really install linux-headers-amd64, which is a metapackage, from the regular repo, right? And not from backports. But how do I do that? Apparently that package is only in backports, if I run this:

$ apt search ^linux-headers-amd64$
Sorting... Done
Full Text Search... Done
linux-headers-amd64/bullseye-backports,now 5.18.2-1~bpo11+1 amd64 [installed]
  Header files for Linux amd64 configuration (meta-package)

[geckolinux]

Hi there, really glad to hear that you like it and it's working well for you.

Regarding the kernel version, to make it automatically install the latest Stable kernel version you can remove the /etc/apt/preferences.d/99backports file that makes it prefer the Backports kernel version. Then reinstall the linux-image-amd64 package, which is a metapackage that always depends on the latest kernel version, and if necessary force its version to the stable-security branch:

Regarding the linux-headers* , they're only required if you need to compile the broadcom-sta-dkms WiFI driver. If needed, they can be switched to the Stable version with the linux-headers-amd64 metapackage similar to the above mentioned process.

[emilianomacht]

That worked perfectly, thank you so much for your time!

If anyone finds this post in the future, here are the commands:

# Remove the file that prioritizes backports
sudo rm /etc/apt/preferences.d/99backports

# Remove backports metapackages
sudo apt remove linux-image-amd64
sudo apt remove linux-headers-amd64

# Install regular stable versions metapackages
sudo apt install linux-image-amd64
sudo apt install linux-headers-amd64

# Clean the leftover backports packages
sudo apt autoremove

sudo reboot

[geckolinux]

Excellent, thanks for reporting back!

[Xispra]

Perhaps the maintainer might consider making the installer set up the standard stable kernel by default, along with other standard non-backports packages and have a post-install script to upgrade things like xorg & the kernel to the backports version.

Normally I routinely upgrade my firmware & kernel to the backports version, but the latest iteration of the backports kernel seems to be causing me problems, system freezes & even crashes on multiple systems, A8-7600 onboard graphics & a six-year old Nvidia GeForce GTX 750 Ti 2GB card. After several freezes and a lock-up on the later I decided to give the proprietary Nvidia driver a throw. But because several packages were the backports versions I ran into dependency issues that I couldn't easily sort out.

I tried the standard Debian stable kernel with a "apt-get install linux-image-amd64/stable" but the regular kernel still didn't play nice with nouveau and this card and I still couldn't install the proprietary driver for some reason (I'm guessing the different versions of xorg packages).

I ended up just upgrading that system to Debian Testing. I'm pleased to report that the upgrade went smoothly, I was a little concerned when on my system I got a message:

Configuration file '/etc/cryptsetup-initramfs/conf-hook'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.

I know the encryption options are different for standard Debian and the version that comes with the Calamares installer, especially as augmented by grub-customier, which I advise my friend in Mexico not to use; it does a bunch of stuff in /etc/grub.d that isn't clearly documented & is hard to trouble-shoot. For instance the /etc/grub.d on this Spiral installation is 9.8 MB, on my friend's Ubuntu is was close to 40 MB, on my straight Debian system which has been progressively updated from 2015 it is only 84k. And most things you want to do with grub can be done by editing /etc/default/grub and maybe adding a file for a background.

Anyway, I chose Debian's version of the cryptsetup hook going forward and was pleased that my system was still bootable after the upgrade, though it did hang for a minute or two at network detection, hopefully that is just a one-time thing that will sort itself out.

I used to go to distrowatch and download and install various derivatives of Debian & *buntu, but got out of the habit. First of all, I realized that they all made distribution upgrades from LTS to LTS much harder. Plus, these little derivatives had a habit of disappearing on a regular basis or re-basing themselves on Debian or Ubuntu, sometimes multiple times. Luckily I'm pretty hard-headed and was able to make the upgrades work generally, but eventually I started removing the non-standard repositories & PPAs during major upgrades and just turning these installations into straight Debian or *Buntu.

FWIW, the upgrade of this Spiral to testing/bookworm seems to have sorted out the instability I was having with this video card. I normally just use onboard graphics since I don't use 3D or game (and if I did game I'd prefer to use AMD since Nvidia doesn't go out of its way to be open source friendly). But a (Linux using) gamer friend gave me his old video card and it seems like the CPU makers have been charging a bit more for processors with onboard graphics options, particularly AMD, which doesn't want to cannibalize its profitable GPU business.

On the issue of using full-disk encryption, I really like the fact that Calamares sets up even the /boot in a big encrypted partition, that helps me keep from having to tinker to keep my systems up to date when the /boot partition fills up, as I've mentioned in another post. But I've found there are significant trade-offs. Instead of getting to the prompt to enter my decryption password in just a few seconds I have to wait 15-25 seconds, and even after I enter my encryption password it takes another maybe 5-10 seconds before the system starts really booting up the system in earnest. And if I fat-finger my decryption key instead of promptly giving me two more chances to enter the correct password before the system locks me out for a spell, with the Calamares encryption scheme it just hangs for 20-40 seconds and dumps me in an efi shell, forcing me to reboot. Have others had that experience? If anyone has a work-around to either of these issues I'd be interested in hearing about it.

And while I'm annoying the maintainer if geckolinux is still reading I noticed on my system that the bluetooth packages were not installed by default in the KDE version. I've only installed Spiral once and cloned it to 2 other systems, maybe that wasn't everyone's experience, but I had to install the bluedevil package on my KDE Plasma Spirallinux systems.

[geckolinux]

Hi there @Xispra , thanks for the great observations.

Perhaps the maintainer might consider making the installer set up the standard stable kernel by default, along with other standard non-backports packages
...
I tried the standard Debian stable kernel with a "apt-get install linux-image-amd64/stable"

The Stable kernel (5.10) is also installed by default in SpiralLinux, both in the live system and in the installed system. So you can follow these instructions if you don't want the Backports kernel on the installed system, or you can use GRUB Customizer to make it boot the Stable kernel by default. I prefer the current approach of including both kernels and booting the Backports kernel by default, because it significantly increases the chances of it booting and supporting newer hardware, although the Stable kernel is still there by default for those cases where it works better. Currently SpiralLinux includes the following rule in /etc/apt/preferences.d/99backports :

##### Kernel / firmware

Package: linux-image-*
Pin: release a=bullseye-backports
Pin-Priority: 600

Package: linux-headers-*
Pin: release a=bullseye-backports
Pin-Priority: 600

Package: firmware-*
Pin: release a=bullseye-backports
Pin-Priority: 600

##### NVIDIA proprietary drivers

Package: nvidia-driver
Pin: release a=bullseye-backports
Pin-Priority: 600

I noticed on my system that the bluetooth packages were not installed by default in the KDE version. I've only installed Spiral once and cloned it to 2 other systems, maybe that wasn't everyone's experience, but I had to install the bluedevil package on my KDE Plasma Spirallinux systems.

It sounds like you installed from one of the earlier releases of SpiralLinux, correct? Those were indeed missing the bluedevil package, and it was added to the 11.220628 release.

[Xispra]

Yes, geckolinux, I installed from SpiralLinux_Plasma_11.220606_x86-64.iso.

To clarify my post above about encrypted booting with Calamares, I get my decryption prompt reasonably quickly, about 7 seconds, but that may be a BIOS/motherboard limitation. But it takes 15-25 seconds after entering my decryption key to get the green grub screen, then maybe 5 seconds on this recently built machine to see the motherboard flash screen. From there the boot process is quite quick, maybe 7 seconds to full desktop once I got rid of the 3 minute wait for the network to be configured with:
systemctl mask systemd-networkd-wait-online.service

Incidentally, I don't like seeing a splash screen when booting my system, I prefer to see the dmesg stuff scrolling by, it is more entertaining and informational. I know I can see that stuff by hitting Esc, but without grub-customizer it was a simple matter to make text scrolling the default by taking the word 'splash' out of /etc/default/grub & running 'update-grub'. There doesn't seem to be a way to do that with grub-customizer, hold on, in the General Settings tab there is a kernel parameters line, I removed 'splash' from the end, I hope my system still boots. Back in a minute. Also, grub-customizer would not accept either my root or regular-user-with-sudo-privileges passwords when I started it from the menu, I had to start it with 'sudo' from the command line.
BRB.

Well, that worked, my system is now showing the dmesg stuff. But it is sub-optimal that there wasn't a check box in the grub-customer GUI to allow me to disable the BIOS splash screen & I had to figure out how to do it on my own. That kind of defeats the point of the whole GUI.

Also, I'd earlier tried to make grub-customizer display an image of my recently deceased old hound that I used in other computers, but I got the default green screen. So I tried another image that I use, no joy. It did finally work when I put the image of my choice in /boot/grub (which is how I do it on regular machines), and then ran grub-customizer. But grub-customizer should have warned me that it couldn't use my image where it was located or automagically put the image in /boot/grub, it did neither. I was afraid I was going to have to rename my image 'splash.png', which is also in /boot/grub, but that wasn't necessary. grub-customizer just seems buggy to me. If removing the 'splash' word had caused my system not to boot I'm not sure how I could have fixed it. Normally I'd just chroot and fix a text file entry and do a 'update-grub' command.

I guess I should have started a new post with all this verbiage, but I originally just intended to comment on emilianomacht's kernel question & my natural prolixity ran away with me. Apologies.

[geckolinux]

Hi again @Xispra , thanks for the details.

But it takes 15-25 seconds after entering my decryption key to get the green grub screen

Yep, that's what I've seen too. I assumed that it was just a function of the initial decryption taking a bit of time.

From there the boot process is quite quick, maybe 7 seconds to full desktop once I got rid of the 3 minute wait for the network to be configured with:
systemctl mask systemd-networkd-wait-online.service

Hmm, interesting. Thanks for mentioning this. Had you previously manually enabled that service? I haven't seen any other reports of this happening, but I wonder if it would be best to ship SpiralLinux with systemd-networkd-wait-online.service disabled.

Regarding GRUB Customizer, yeah, it's not perfect. I think for most users it could be helpful on certain occasions though.

[Xispra]

I guess it is the initial decryption, but it just takes a couple of seconds after entering my key to start the boot process on my other LUKS-encrypted Debian & Ubuntu builds, but of course, they each have separate ext2 /boot partitions. Also, a few years ago I had a opensuse 15 install, it decrypted quickly and I don't remember if it had a /boot partition or used Calamares. It didn't survive a distribution upgrade & I couldn't rescue it with my inadequate zypper skills, so I abandoned opensuse for the moment, maybe I should give it a try again.

The weird systemd-networkd-wait-online.service that was causing my system to choke must have been something I picked up upgrading from Debian stable to testing, trying to get around the driver issue. I didn't have it when my Spirallinux was based on stable.