Trisquel 8 does not boot after updating and upgrading

24 replies [Last post]
Masaru Suzuqi
Offline
Joined: 06/06/2018

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.

Masaru Suzuqi
Offline
Joined: 06/06/2018

I forgot to attach the screenshot.

125F231E-B8AE-4873-A959-57DD98A34C0A.jpeg
marit
Offline
Joined: 08/31/2019

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.

jxself
Offline
Joined: 09/13/2010

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.

Masaru Suzuqi
Offline
Joined: 06/06/2018

> 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?

strypey
Offline
Joined: 05/14/2015

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?

chaosmonk

I am a member!

I am a translator!

Offline
Joined: 07/07/2017

> 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.

strypey
Offline
Joined: 05/14/2015

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?

chaosmonk

I am a member!

I am a translator!

Offline
Joined: 07/07/2017

> 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.

jxself
Offline
Joined: 09/13/2010

"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.

jxself
Offline
Joined: 09/13/2010

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.

Masaru Suzuqi
Offline
Joined: 06/06/2018

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.

strypey
Offline
Joined: 05/14/2015

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.

strypey
Offline
Joined: 05/14/2015

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.

strypey
Offline
Joined: 05/14/2015

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'?

chaosmonk

I am a member!

I am a translator!

Offline
Joined: 07/07/2017

> 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.

jxself
Offline
Joined: 09/13/2010

What happens when you try?

strypey
Offline
Joined: 05/14/2015

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

jxself
Offline
Joined: 09/13/2010

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 -

strypey
Offline
Joined: 05/14/2015

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 :)

jxself
Offline
Joined: 09/13/2010

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.

strypey
Offline
Joined: 05/14/2015

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.

Magic Banana

I am a member!

Offline
Joined: 07/24/2010

I do not think that is the error you committed. Maybe you ran 'sudo apt autoremove' after removing all jxself's kernels.

jxself
Offline
Joined: 09/13/2010

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.

Masaru Suzuqi
Offline
Joined: 06/06/2018

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.