Trisquel 8 does not boot after updating and upgrading
- Inicie sesión ou rexístrese para enviar comentarios
Hi, please look at the screenshot of the screen of my laptop that appears after boot. I saw the same letters/screen after I tried to shut down the laptop last time. It was several hours ago. After that it happens every time. Can I do something to fix this? Thanks.
I forgot to attach the screenshot.
If GRUB menu is displayed before boot then select an entry for an older Linux kernel and try to boot. After that uninstall your 5.4.0-gnu kernel image (it does not seem to be available from Trisquel repositories, report the bug about your laptop not booting to https://bugzilla.kernel.org) and update the GRUB configuration.
This does not appear to be a kernel bug. If you'll notice, the problem seems to be with the init system. When the init system is killed, the kernel does indeed panic. This is expected behavior. It might be useful to see if there's anything earlier that wasn't photographed that might explain why.
> It might be useful to see if there's anything earlier that wasn't photographed that might explain why.
Do you mean that what I had done with the laptop before the trouble happened?
If so, I think I did not do unusual something. Just browsing, checking emails, writing something to post here on Plama, and updating and upgrading.
What would be the cause of the trouble?
jxself:
> It might be useful to see if there's anything earlier that wasn't photographed that might explain why.
How can I find something to share here that might tell you why the kernel is panicking with 5.4.0 but not with 5.3.12? Is there a command I can run to spit out some useful output or a log file I can share the contents of?
> How can I find something to share here that might tell you why the
> kernel is panicking with 5.4.0 but not with 5.3.12?
I don't know the answer to this, but my general suggestion is that any
upgrade comes with a risk of regression, so when you upgrade it should
be for a reason. In general the reason to upgrade your kernel is for
newer hardware support. Since the hardware you run is rather old, I
don't think you have much to gain from running a bleeding-edge kernel.
I would just pick the most recent LTS kernel that works with your
hardware, and stick with that for as long as it receives security
updates.
Chaosmonk:
> I would just pick the most recent LTS kernel that works with your hardware, and stick with that for as long as it receives security updates.
I thought I did that, but I guess not. 5.4 is an LTS version. The last version before that was 4.19, which is projected to EOL in a year's time. Before that 4.14, which is projected to EOL in 2024, which is three years after 5.4 stops being supported. Unless there is an error in the table here?
https://www.kernel.org/category/releases.html
So if that table is correct, how to I downgrade to 4.14, and how do I make sure I only get updates to that version, rather than newer kernel versions?
> So if that table is correct, how to I downgrade to 4.14, and how do I
> make sure I only get updates to that version, rather than newer kernel
> versions?
If you are using jxself's repo, run
$ sudo apt install linux-libre-4.14
which is a metapackage that always depends on the latest 4.14 kernel, so
you'll get security updates to 4.14 but won't get upgraded to a newer
kernel for as long as 4.14 is supported.
When booting, select "Advanced Options for Trisquel" in the grub menu
(if the grub menu is hidden, you might have to hold Shift) and select
the 4.14 kernel. Once you've booted into 4.14, remove all kernels newer
than 4.14, so that next time you boot 4.14 is the default.
"which is a metapackage that always depends on the latest 4.14 kernel, so you'll get security updates to 4.14 but won't get upgraded to a newer kernel for as long as 4.14 is supported."
More like "won't get upgraded to a newer kernel ever, even when 4.14 is no longer supported." Once 4.14 is no longer supported the updates to the linux-libre-4.14 metapackage just stop; i.e., it doesn't get updated to pull in a newer one. Then, I will usually wait a week or two to give people time to update to that final 4.14 version before removing 4.14 from the repository entirely. Thus, the onus is on the people using it to decide when/if to move off of 4.14.
There are a few questions in this. It will take some effort to unpack them all, so here goes:
There was an announcement back in (I think) April 2018 that LTS kernels would be supported for 6 years. Well, it turns out that's not entirely true. Well, maybe it is. What seems to happen is that LTS kernels start off with 2 years of support only, and then later get updated to add 4 more years later on for a total of 6 years.
That (going from 2 years to 6 years) happened with 4.14 back in July:
https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=a294222b772df262eb284c0503f6a6070f5bb22a
Since that April 2018 announcement, every LTS kernel since has been given the 6 year treatment (4.4, 4.9, 4.14) but 4.19 and 5.4 have not, or at least have not *yet*. Will they in the future? I do not know; all I can say is that they're not listed that way right now but that doesn't mean the extra 4 years won't be added later like it was for 4.14.
Anyway, I was able to duplicate this problem and believe it has been fixed in version 5.4.0-gnu-2.0. It would be helpful to test that, as it seems to be fixed for me now.
To answer the other question involves consulting the table at https://jxself.org/linux-libre/
As you can see, the package called linux-libre-lts always gets you the "current" LTS. This would be why you were upgraded to 5.4, since that is an LTS version. If you want to stick with an a specific LTS version, the way to do that would be to uninstall linux-libre-lts: sudo apt purge linux-libre-lts (otherwise you'll be getting prompted soon to upgrade to 5.4.1 soon, as I am currently compiling that version as I write this message) and install one of:
linux-libre-5.4
linux-libre-4.19
linux-libre-4.14
linux-libre-4.9
linux-libre-4.4
The package names that contain a specific version number like those will cause you to stick with that kernel series only. If you should decide that you want to move to another LTS in the future it will be on you to decide both when and which one, since you won't be automatically moved anymore. BUT: I encourage you to re-try 5.4 since I believe the problem has been fixed with 5.4.0-gnu-2.0.
Also, I think this was a learning experience for me. I think that what I will do going forward is that, when new LTS versions some out (like 5.4 did) I think I will wait for a while before upgrading the linux-libre-lts package to use it until it's been out for a while and any problems are found and fixed. This should result in greater stability for LTS kernel users, who have probably picked LTS kernels for that very reason. I'm sorry for any problems people have experienced with the new 5.4 kernel version, although though I believe they are fixed now.
Thanks for your reply. GRUB menu displays before boot by pressing c key and I did "grub> boot"
and I got "error: you need to load the kernel first.". It reminded me what I had have had to boot from GRUB and I got the same error message then, too. I don't remember well why I was trying to boot from GRUB but I think I gave up to boot from GRUB then and reinstalled Trisquel 8. I had read the manual of GRUB then and I read it again yesterday but I did not understand how to load the kernel first.
And I did autoremove right before the trouble happened so older kernels might not remain in the laptop. When autoremove, I see old kernels are maybe deleted in the terminal.
And in bugzilla.kernel.org, it is written that "This is the Kernel.org Bugzilla for posting bugs against the upstream Linux kernels (not distribution kernels)." I am not sure if Linux libre kernels belong to the upstream Linux kernels or distribution kernels. However, should I update the GRUB configuration first?
Or rather, what the cause of the trouble do you think?
PS: sometimes a post is placed in an unintended place.
I'm getting pretty much the same issue as Masaru. I've been installing kernels from the jxself linux-libre repo for months now, on both my laptops, with no issues. But I did an upgrade last night before I shut my 32-bit laptop down, and when I tried to boot it today using the latest kernel (5.4.0), I got pretty much the same kernel panic screen as Masaru. Same thing when I tried using the advanced option (upstart and recovery) with that kernel version. But if I boot using the previous version (5.3.12), it boots up as normal.
I'm typing this using my 64-bit laptop which is working fine, but it's using the low latency kernels (I was thinking about trying to do some audio editing on it), and uname -r spits out 4.19.92 as the kernel version.
FYI I ran ...
sudo apt purge linux-image-5.4.0-gnu
... on my 32-bit laptop and rebooted it and now its booting fine.
Quick questions, since I ran ...
sudo apt purge linux-image-5.4.0-gnu
... on my 32-bit laptop, it seems unable to connect to the linux-libre repo when I apt update. Is that expected behaviour after running that command? Would I have been better to just use 'remove' instead of 'purge'?
> Quick questions, since I ran ...
>
> sudo apt purge linux-image-5.4.0-gnu
>
> ... on my 32-bit laptop, it seems unable to connect to the linux-libre
> repo when I apt update. Is that expected behaviour after running that
> command? Would I have been better to just use 'remove' instead of
> 'purge'?
The difference between "purge" and "remove" is that purge removes
system-wide configuration files for the package. It would not prevent
you from connecting to the repo. Can you still not connect? Maybe your
mirror was down.
What happens when you try?
jxself:
> What happens when you try?
Either the apt update hangs, or I get the following error message:
Err:5 mirror://linux-libre.fsfla.org/pub/linux-libre/freesh/mirrors.txt freesh InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9D0DB31B545A3198
Sounds like the keyring package was also removed when the kernel package was uninstalled. Do:
wget -O - https://jxself.org/gpg.asc | sudo apt-key add -
OK, apt update appears to be working now, but apt upgrade is not offering any upgrades. uname -r still outputs:
5.3.12-gnu
I tried entering:
sudo apt install linux-image-5.
... and then double-tabbing to see what kernel versions are available to install. The only 5.4 options were:
5.4.2-gnu
5.4.2-gnue.nonpae
Shall I apt install one of these? Or is there another step I need to take to put the repo back in charge of pushing me the latest LTS kernel?
I appreciate your help with this. Just FYI though, this:
wget -O - https://jxself.org/gpg.asc | sudo apt-key add -
Produced some odd display in my terminal. It did some business then seemed to have hung. It turned out it was waiting for my password, but the order the output came in made that unclear, I only realized because I happened to hit the space bar and that produced another password prompt. It might have been better to give this suggestion as two separate commands:
wget -O - https://jxself.org/gpg.asc
sudo apt-key add -
... or put a sudo at the start so the password prompt came up before any further output :)
If you install linux-image-5.4.2-gnu for example you will forever be stuck on 5.4.2 so that's not what you want to do.
The idea is you don't install the linux-image packages directly but one of the metapackages, which then pull in the linux-image packages as a dependency. Those metapackages are the ones that enable you to get updates to newer versions according to whatever sort of upgrade rules you want. They are described in detail in the table on https://jxself.org/linux-libre/ along with the upgrade rules that go along with them. Find a rule (aka "use case") you like, and install the package shown.
Ah, I think I see what my error was. By using "purge" instead of "remove", I not only removed the Linux kernel version that was causing me problems, but I undid almost everything I did when I added your linux-libre repo in the first place. A better approach would have been to use "remove", and then use "apt-get upgrade" (*not* "apt-get dist-upgrade"), instead of "apt upgrade" to avoid updating the kernel again until you told me the bug was fixed. Does this sound correct?
I'm fortunate that my error left me with a bootable system and that you and Chaosmonk have been available to patiently help me get things back in order :) It's late here so I will follow your instructions tomorrow and report back on the results.
I do not think that is the error you committed. Maybe you ran 'sudo apt autoremove' after removing all jxself's kernels.
> Maybe you ran 'sudo apt autoremove' after removing all jxself's kernels.
AFAIK I didn't remove them all, I removed only the one that was causing the problem, using the purge command mentioned further up in the thread:
sudo apt purge linux-image-5.4.0-gnu
I may have run automremove after this, I can't remember now.
If I had removed all jxself's kernels, my system would now be using the latest kernel currently being offered from the standard Trisquel repos, yes? Is that 5.3.12-gnu? Because that is what my system is currently using.
Because, as Chaosmonk points out, getting the latest and greatest kernel versions isn't that useful for an old 32-bit laptop, I decided to go with:
"I want the latest version of Linux-libre, but when 5.5 comes out as the next major new release I want to wait a bit before upgrading so that any problems can get sorted out. I'll decide when I'm ready to upgrade to 5.5, but I still want to get updates for 5.4 while I'm waiting."
So I ran the accompanying command:
sudo apt install linux-libre-5.4
As you said, the bug in 5.4 causing the kernel panic has been fixed and my laptop is now booting fine with it. Thanks to you and everyone for your help.
5.4 will get security updates for at least 2 years. Hopefully support will be extended to 6 years, by which time I'll be very impressed if this 10 year old laptop is still working and useful ;)
One question, will I get any kind of indication from the update system when the 5.4 kernel version reaches EoL, or will I just have to remember to check back in a couple of years?
No, you will not get any notification when the support of version 5.4 ends.
Yes, I have not had prompts thinking that if people are following some specific version then they have a reason they want to and should also keep track of such things themselves.
Would it be a good idea to have an interactive prompt in the package manager?
If yes, I'm thinking perhaps a few different types:
* One might start appearing, say, 30 days before it becomes end-of-life. With each new version during that time there would be a message with an "OK" button. Is that a good amount of time?
* The very last kernel version would say it has reached end-of-life and is no longer supported also with an "OK" button to acknowledge.
But: This depends on people applying updates timely; I've heard of some that don't. If they don't apply updates within that 30 day window they'd miss it. And, once an version has reached end-of-life I usually remove it after a week or 2 to keep the APT repository small, so people could miss the last version entirely if they don't update before I remove it. Also, you can tell the package manager to now show interactive prompts.
Thoughts? Ideas?
*EDIT*: And: Should such a prompt be done for all kernels or just LTS ones?
Also, there is the linux-libre-announce mailing list mentioned on my site that people could get notifications from.
> Would it be a good idea to have an interactive prompt from the package
> manager?
Perhaps when an LTS kernel reaches EOL, you could bump the version
number and replace it with a transitional package to the next LTS
kernel. For example, when 4.4 reaches EOL, turn linux-libre-4.4 into a
dummy package which depends on linux-libre-4.9. Maybe you could also
implement an interactive prompt warning the user when this happens, or
you could update the webpage to state that this is the default behavior.
"Because, as Chaosmonk points out, getting the latest and greatest kernel versions isn't that useful for an old 32-bit laptop"
There can still be other benefits, like new (non-hardware) features in the kernel. An example is how 5.4 has various filesystem improvements.
Everything seems to be working OK, but when I ran apt update and apt upgrade today, I noticed the output included the following error message:
> * dkms: running auto installation service for kernel 5.4.5-gnu Error! echo
Your kernel headers for kernel 5.4.5-gnu cannot be found at
/lib/modules/5.4.5-gnu/build or /lib/modules/5.4.5-gnu/source.
Is this something I need to be concerned about? What, if anything, do I need to do about it?
If you have something that needs the kernel headers that can be done by installing the appropriate -headers package.
I think earlier you installed linux-libre-5.4, so that it would be linux-libre-5.4-headers. Maybe I should mention this on the website just in case.
The kernel headers are (currently) not installed by default. It's not clear to me if they should be or not. I've done it both ways over the years where they are and aren't. I usually get feedback from people both ways saying both yes and no.
I would argue that headers should not be installed by default. Headers are useful to some developers (but they should know how to install an additional package) and to those who want additional drivers, which are almost always proprietary. So, for the vast majority of the users who value their freedoms, the headers are useless.
I believe that the bug you reported is now fixed in kernel version 5.4.0-gnu-2.0. This has been uploaded to the master server: http://linux-libre.fsfla.org/pub/linux-libre/freesh/pool/main/l/linux-5.4.0-gnu/ and the mirrors should sync over the next 24 hours.
Thank you. It booted with 5.3.12 and I learned some things what I should do after the trouble solved. I was trying to copy the data to the USB disk.
- Inicie sesión ou rexístrese para enviar comentarios