Update issue (Amber); linux-image-librem5 kept back

I got an update of linux-image-librem5 today. But it “kept back” says apt. if i would install the updated kernel package directly apt would remove some gnome packages…

Any ideas?

Here is an earlier thread about the meaning of the “kept back” message:

Does that help?

Not really, because i don’t think it is a good idea to remove for example librem5-base… :confused:


(“linux-image-5.12.0-1-librem5” is the package linux-image-librem5 links to)

That looks unusual. Maybe @dcz can help.

1 Like

I have the same problem starting this morning:

uname -r
5.11.0-1-librem5

sudo apt-get update exits with success

sudo apt-get upgrade “The following packages have been kept back: linux-image-librem5”
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded

The PureOS Store software proposes the system to be updated and when you hit the button after a while it says “Unable to download updates: the following packages have unmet dependencies” and the list is empty.

Someone to help?

See https://source.puri.sm/Librem5/linux-next/-/issues/326

6 Likes

Came here to find out whether this was a known issue. Jolly good. :slight_smile:

Happened to me yesterday, too. Held back due to unmet dependencies: linux-image-librem5 5.11.15pureos1~amber1 to 5.12.1pureos1~amber1
In the store, the offered update won’t go away.

In the terminal, I see:

purism@pureos:~$ sudo apt update && apt list upgradable
Hit:1 https://repo.pureos.net/pureos amber InRelease
Hit:2 https://repo.pureos.net/pureos amber-updates InRelease
Get:3 https://repo.pureos.net/pureos amber-security InRelease [5,845 B]
Hit:4 https://repo.pureos.net/pureos amber-phone InRelease
Fetched 5,845 B in 13s (460 B/s)                                               
Reading package lists... Done
Building dependency tree       
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
Listing... Done
purism@pureos:~$ apt list --upgradable
Listing... Done
linux-image-librem5/amber-phone 5.12.1pureos1~amber1 arm64 [upgradable from: 5.11.15pureos1~amber1]
N: There is 1 additional version. Please use the '-a' switch to see it
purism@pureos:~$ apt list --upgradable -a
Listing... Done
linux-image-librem5/amber-phone 5.12.1pureos1~amber1 arm64 [upgradable from: 5.11.15pureos1~amber1]
linux-image-librem5/now 5.11.15pureos1~amber1 arm64 [installed,upgradable to: 5.12.1pureos1~amber1]

purism@pureos:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  linux-image-librem5
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
purism@pureos:~$ 

Whereupon, upgrade fails/package held back.

https://source.puri.sm/Librem5/linux-next/-/issues/326 is now closed… the bug still exists for me :frowning:

I think they closed it because they think it is done from the developers’ perspective, they have fixed it and now there is just some delay until some kind of automatic build/release system does its thing so that it reaches the users.

At least that’s my impression of how the issue tracking system is used, that an issue is closed when “there is nothing more for us to do here”. Maybe it would be better if they waited to verify that the fix really works for the users, and only closed the issue after that. Anyway, let’s hope the fix reaches users soon.

Maybe sudo apt install ... would be an alternative.

… please look at my first reply (3rd entry in this thread) or amaroks reply…

1 Like

I do software engineering (which, in my job, is sort of like a car mechanic for software). In my experience, your impression is generally pretty correct. You do have to understand, though, that the bug tracker is for developers, not users. Therefore it makes sense that a bug is closed once there is nothing more to be done with the code. The delay is indeed a product of testing and verification. For example, the process might go something like:

  1. Fix works in dev’s IDE (development environment)
  2. Image is built with fix, tested in VM, works in VM
  3. Two or three other devs test it in a VM. It works
  4. Image is tested on a few dev phones. It works. Ticket is closed
  5. Testers receive it in their queue to test. When it reaches the head of the queue, they test it. It works
  6. Fix pushed to repos, further tested and/or migrated
  7. Users receive fix via update

…or something similar. It makes sense that the ticket would be closed after everything is verified, but what it actually means is a fix has been accepted as “good.” That way devs can move on to other things while the bug fix moves down the pipeline on its way to users.

Hopefully that helps explain the understandably frustrating delay.

2 Likes

same thing.

After several tries always the same thing.
I switch to graphic mode there it offers me to restart the phone since the phone remains stuck on the Librem5 logo.

I am good for a reinstallation.

Anyone has had success with that update? I’m waiting for a solution, as in my understanding it could lead to a system failure (seems related to this L5 Evergreen update on May 24th leads to black screen) and I don’t have time and energy to reflash.

2 Likes

This issue with the linux-image-librem5 should now be solved in Amber.

9 Likes

Update done (refresh updates in PureOS Store or via apt needed); all went fine :slight_smile:
Thanks

1 Like

hi, glad to read that!

Same here (without doing anything on terminal)

Fixed for me, too.

1 Like