Spoke too soon . . . not out of the woods on this one yet, but looks like previous thread was closed already. Seems like the edits made in the grub “EFI” menu are not maintained on reboot?? Doesn’t seem to be any hints on how to “save” the edits . . . just make them and then boot them??? But, then it appears that the edits are lost and it’s back to the previous version??
After I got 5.19 to boot I used the GUI mainline kernel app to remove the old 5.13 kernel, to try to get the system to default to 5.19, but on trying today it said, “5.13 not found, hit any key to continue” and back into Grub menu we went.
Arrowed down to Lubuntu, pressed “e” and changed the kernel data to 5.19 and it booted up.
Question is, why doesn’t it hold the data?? I’ve changed both line items, the “Lubuntu” and the “advanced options” data and I can boot it, one time . . . . I tried “ctrl o” but that didn’t do anything . . . . Do I need to take it to “command line” and then try to “ctrl o” it to save it??
I do not believe that editing GRUB options from within GRUB is designed to save those options. To change the options in a way that sticks, here’s a few ideas.
Edit /etc/default/grub. This is one of the files that GRUB looks at to find settings on how to generate the final configuration file. This is the recommended way to change GRUB’s settings, but it might not work here.
Edit /boot/grub/grub.cfg. This will let you edit GRUB’s settings in much the same way as editing them from within GRUB, but this time your settings will stick. The problem with this is that this file is designed to be automatically overwritten by GRUB when it generates its own config file (which happens when you get a kernel update), so your settings may get overwritten automatically.
Write your own grub.cfg file from scratch, plopping it in the appropriate location in your EFI system partition (I think it’s /boot/efi/EFI/ubuntu/grub.cfg with Ubuntu 22.04 and later, or /boot/efi/EFI/boot/grub/grub.cfg otherwise, I could be wrong here). Then maintain it yourself. I’ve done this a couple times when faced with seriously weird EFI messes like this, and it works. But keep in mind this throws ALL of the burden of getting this file right directly on you. If you set specific kernel versions in the file, it’s your job to update them yourself when the kernel is upgraded. If you want to be able to boot into older kernels, you have to code that yourself. Recovery mode? Write the configuration for that too. It’s quite powerful and works well, but it can also be a PAIN.
Of the three options, I personally would use option 3 in this instance. Make sure you have a live USB to boot from before trying this, since this is a great way to render your system mostly unbootable if you accidentally mess up the configuration file.
Hopefully someone else here will have a better or at least easier way to make this work, but if you have no other choice (or feel adventurous, or are comfortable with GRUB), then this may work for you. Should you choose to try writing the GRUB configuration file yourself (or possibly customizing the existing one), you’ll want to run info grub in a terminal so you can read through the documentation.
I would probably try grub-customizer (install from the default repos) and use it to point to the newer kernel by default. When the kernel upgrades, and as memory serves, it should continue pointing to the newer kernel.
Thanks for the thoughts . . . after I posted here I got the suggestion from the Lu list-serve to “update-grub” or “grub-update” . . . but in the controller system. I had run that a couple of times, but with the repeated returning to 5.13 I lost track of when I had done that . . . . The controller is TW and they run a different command, like “grub2-mkconfig xxxx” . . . so I both “reinstalled it” AND then I ran the grub2-mkconfig xxxxxx AFTER I had removed the old 5.13 kernel yesterday . . . .
And, that did find the new 5.19 kernel . . . fortunately I didn’t have to go into customizing grub . . . which, yes, would be a pain. It’s “painful” enough having a number of different types of linux systems installed and maintaining them . . . along with keeping grub up to speed . . . .
Somehow, Lubuntu got itself twisted up in the grub listing, showing itself as “1910” when it was “2210” . . . and hanging on to the 5.13 kernel . . . in spite of numerous updatings of grub . . . .
Just as a sidenote, if you were still on kernel 5.13, you may have been on that kernel for a while, which would have likely left you open to serious security bugs if that older kernel wasn’t being patched. Make sure to keep offsite (or at least usually-disconnected-from-your-computer) backups and be ready to respond in the event any malicious activity starts up on your systems or online accounts. You might even think about 2-Factor Authentication on your online accounts (though then you’ll also want recovery methods so that if you lose your phone or whatever, you can still get into your stuff). Backing up your system in a way that protects against ransomware would also be a good idea at this point (e.g., turn the system off, boot it from a recent and up-to-date live USB, and back up from there - it’s not 100% secure but it’s way better than nothing).
What does your /boot directory look like ? ls -l /boot
(it should not have anything that looks like …5.13…)
“had to do a fresh install of another OS, did that . . .”
That would point the 1st Stage loader to that OS’s /boot/grub/grub.cfg
and ought to have updated it using (it’s copy of) os-prober. So it
should have worked (it’s what you see for future boots).
If you want to grub-update the grub menu again, you have to do it using that OS.
Let’s have a look at (your booted copy) of; sudo os-prober
You have not said whether your Mac is booting in UEFI mode or
legacy (bios) mode. You can find that out in your bios settings.
(these two modes boot differently and might make a difference).
Also tell us what the other OSs are and if you have an EFI partition.
I’m pretty sure that I got it taken care of . . . as posted above. I just didn’t mark it as solved, because I had another thread on the issue, thought I had it fixed and marked it as “solved,” only to find out a day later . . . it wasn’t.
Started this new thread . . . Sunday PST is the next slated time to boot Lubuntu and that should be the final “proof of concept” . . . if it boots again to 5.19 . . . . Otherwise I’ll post back with yr requested data.
BTW, most Macs since at least OSX, so roughly '00 boot UEFI and they come with an EFI partition, for those that don’t know how to make one . . . .
What kind of threads is @ArrayBolt3 referring to? Usually Lubuntu desktop machines do not have any services published to the WAN side (like a webserver, mailserver, sshd).
I am using Lubuntu jammy for my desktop, but we are still using some virtual servers with a <5.13 kernel. These development VM’s are not connected to the internet, and not under control of a systems administration manager (the host is, ofcourse). So, these machines could be under threat from an inside job.
Indeed. With you on the “it’s not just the kernel that is the security leak,” across the 8 or so linux installs I have on my desktop . . . there is a range of kernels. Even Sid, which I assumed would be running a cutting edge kernel was running 5.10 earlier this week when I checked it . . . LM was running 5.13 as well until I manually changed it to 5.19 . . . .
Usually the threats are via unupdated browser or via self-sabotage when/if we respond to phishing emails and provide them with a credit card number . . . to "try to dig out of an over-charge from Norton . . . "
Is it better to have a newer kernel in terms of security? sure, but I don’t see that as “defcon red” . . . the linux kernel is still considered to be “the most secure” . . . esp in comparo to Windows, and now even OSX . . . .
There are many sneaky ways to get inside a vulnerable system that might be surprising. For instance, sure, maybe you don’t intentionally have any services listening to the outside world, but a vulnerability in the networking code of the kernel might allow a service you intentionally connect to, to be able to execute arbitrary code on your system at the kernel level. It’s not likely, but these kind of things can happen.
It’s not a kernel version that necessarily matters here, it’s whether the particular combination of distro and kernel version is still maintained. For instance, Ubuntu 20.04 can still use the 5.4 kernel, and it is still maintained for Ubuntu 20.04. The problem is that Ubuntu 21.10 is the version of Ubuntu that used and supported the 5.13 kernel, and Ubuntu 21.10 is EOL. That means that the 5.13 kernel is no longer being maintained for Ubuntu and will be potentially vulnerable as a result.
Definitely the Linux kernel is extraordinarily secure, but one of the reasons it is so secure is because tons and tons of security vulnerabilities are found and fixed in it quite easily due to its open-source nature. But regardless of how secure a system is in theory, if there are known vulnerabilities in it in practice, its security is bad. Any version of the Linux kernel actively maintained by a sufficiently proficient group (like Canonical) is going to be a force to be reckoned with, but an old, unmaintained kernel would probably be a pleasant snack to a skilled hacker.
TL;DR: It’s not that the kernel is old, it’s that the kernel is now unmaintained. Old or new maintained kernels are good. Unmaintained kernels of any age are bad. Stuff can go wrong in ways you wouldn’t imagine possible when using unmaintained stuff.
Thanks for your responses. Clear to me. Not so clear to others in my organisation what ‘‘likely’’ means exactly. But another reason for promoting and allowing only (e.g. Vagrant-)provisioned and managed boxes for development work too. Ansible (and/or friends) is the way to go, I guess, and a fresh rollout of a box at every start of the day, automatically without any human intervention should be the point at the horizon were we need to go. Some developers don’t like it when they do not have ‘‘su’’ / ‘‘sudo’’ access. Although likely necessary, this subject it is a bit out of scope of this thread.
Sounds like good ideas to me (locking an unsupported kernel behind a hypervisor with no Internet access should be more than sufficient protection AFAIK). I am a bit alarmed that you would still have to develop software for that particular kernel unless there’s other systems that still support that kernel, but that’s not really my business. Glad you’ve got a solution.
(Quick note on the Debian Sid kernel - you sure it’s supposed to be on 5.10? I also thought it should be on a cutting-edge kernel (5.19 is what I’m finding from a quick Internet search). Perhaps the same problem you were having with Lubuntu has also struck your Sid install.)
Hmm . . . replied several hours ago to the email as suggested could be done, as when I’m in Lubuntu Discourse “doesn’t work” . . . but seemingly the email wasn’t posted here in the thread??? I’m now in Pop! on a laptop and Discourse is available. I said:
Well, I’m booted in Lu today and that means that Discourse web forum doesn’t appear except in white. Same thing oddly with Debian Bookworm yesterday, but in SUSE & Manjaro it shows up?? So, I’m replying via email . . .
That is indeed the question, “what kernel am I supposed to be in?” . . . . On logging into Lu today there was a notification from GUI Mainline showing “5.19.11” as available for install . . . uname -r showed 5.19.5 as running . . . so not 5.13.
The question of the day is, does apt handle kernel upgrades in Lubuntu and/or Debian?? or, that is handled “manually”??? with some GUI app . . . or what was a console app like “mainline”??? LM seems to offer, or did offer a GUI app to select kernels . . . which had to be manually.
I’m going to run an apt update in a bit and I’ll check to see if there is a new kernel listed for install, or, if not check Mainline on it.
But, thanks for the “where Sid’s kernel should be” info . . . yes, I would have expected Sid to be running the bleeding edge of kernels . . . but, apparently not.
PS: After I sent that I ran an apt update/upgrade and there were 184 some packages available to upgrade, but an option for the kernel was not included??? Upgrading the kernel seems to be independent from apt??