Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264502 > unrolled thread

Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)

Back to article view | Back to linux.debian.user

Contents

  Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-10 13:50 +0100
    Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-12-10 14:40 +0100
      Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-11 04:40 +0100
        Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Greg Wooledge <greg@wooledge.org> - 2023-12-11 04:50 +0100
          Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-11 11:30 +0100
        Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-11 08:30 +0100
          Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-11 11:40 +0100
        Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-12-11 09:30 +0100
    Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-10 14:50 +0100
      Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Greg Wooledge <greg@wooledge.org> - 2023-12-10 16:10 +0100
        Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Greg Wooledge <greg@wooledge.org> - 2023-12-10 19:10 +0100
          Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-11 03:30 +0100
        Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-11 03:40 +0100
          Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Greg Wooledge <greg@wooledge.org> - 2023-12-11 04:30 +0100
            Re: Need clarifications about how to deal with the installed  problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1) Stella Ashburne <rewefie@gmx.com> - 2023-12-11 04:50 +0100
          Release process notes [WAS Re: Need clarifications about how to deal  with the installed problematic kernel, linux-image-6.1.0-14-amd64  (6.1.64-1)] "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-11 08:20 +0100
            Re: Release process notes [WAS  Need clarifications about how to  deal with the installed problematic kernel, linux-image-6.1.0-14-amd64  (6.1.64-1)] Stella Ashburne <rewefie@gmx.com> - 2023-12-11 14:40 +0100
              Re: Release process notes [WAS  Need clarifications about how to  deal with the installed problematic kernel, linux-image-6.1.0-14-amd64  (6.1.64-1)] Greg Wooledge <greg@wooledge.org> - 2023-12-11 15:20 +0100
                Re: Release process notes [WAS  Need clarifications about how to  deal with the installed problematic kernel, linux-image-6.1.0-14-amd64  (6.1.64-1)] Stella Ashburne <rewefie@gmx.com> - 2023-12-11 16:00 +0100

#264502 — Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)

Hi,

I am using Debian Bookworm, the current stable release with the whole SSD being encrypted with LUKS2. After decryption, the file system of the logical volume is ext4.

This is what happened to my computer many hours ago.

My device upgraded to the latest kernel, linux-image-6.1.0-14-amd64 and rebooted.

A few hours later, Debian put out an advisory warning its users against upgrading to linux-image-6.1.0-14-amd64, by which time it was too late for me.

According to some people on social media, I should boot using the previous kernel, linux-image-6.1.0-13-amd64, which is problem-free.

Question #1

I power up my device and upon seeing the GRUB menu, I highlight "Advance options for Debian GNU/Linux" and press Enter.

I highlight linux-image-6.1.0-13-amd64 and press Enter.

After supply the decryption password and entering my desktop environment, I did the following:

cat /etc/debian_user
*Result* is 12.3, even though I boot using the previous kernel, linux-image-6.1.0-13-amd64

uname -a
*Result* is linux-image-6.1.0-13-amd64

I remove the corrupt linux-image-6.1.0-14-amd64 by typing the following commands in a terminal. They are:

dpkg --search /boot/vmlinuz-*

sudo apt-get remove linux-image-6.1.0-14-amd64

sudo update-grub

sudo shutdown -r now

Is the above the correct way to remove the most recent/latest kernel?

Question #2a

Some users opine that after removing linux-image-6.1.0-14-amd64, I should re-install linux-image-6.1.0-13-amd64. Why should I re-install linux-image-6.1.0-1-amd64?

Am I right to state that Debian keeps the three recent kernels, including linux-image-6.1.0-14-amd64, for situations such as this one? (The situation in which a corrupt linux-image-6.1.0-14-amd64 was pushed to the repos for users to upgrade)

Question #2b

Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told me that it is no longer in the repos.

I can just download it manually by using the following link:

https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download

And then in a terminal, I type the commands:

sudo dpkg -i linux-image-6.1.0-13-amd64

sudo update-grub

sudo shutdown -r now

Is the above the correct way to install kernels that are not in the official repos?

Thanks for taking the time and effort to clarify my doubts.

Best regards.

Stella

[toc] | [next] | [standalone]

#264503

On 10 Dec 2023 13:48 +0100, from rewefie@gmx.com (Stella Ashburne):
> I highlight linux-image-6.1.0-13-amd64 and press Enter.
> 
> After supply the decryption password and entering my desktop
> environment, I did the following:
> 
> cat /etc/debian_user
> *Result* is 12.3, even though I boot using the previous kernel,
> linux-image-6.1.0-13-amd64
> 
> uname -a
> *Result* is linux-image-6.1.0-13-amd64

This combination is expected under the circumstances, assuming that
you mean /etc/debian_version. Booting into a different kernel does not
change the files installed by the base-files package, which is where
/etc/debian_version comes from; if you want to, you can verify this
with dpkg -S /etc/debian_version.


> I remove the corrupt linux-image-6.1.0-14-amd64 by typing the
> following commands in a terminal. They are:
> 
> dpkg --search /boot/vmlinuz-*
> 
> sudo apt-get remove linux-image-6.1.0-14-amd64
> 
> sudo update-grub
> 
> sudo shutdown -r now
> 
> Is the above the correct way to remove the most recent/latest kernel?

Seems reasonable, _because_ the problematic kernel is a new package.
If it had been an upgraded version of the same package, a similar fix
would have been somewhat more involved.


> Question #2a
> 
> Some users opine that after removing linux-image-6.1.0-14-amd64, I
> should re-install linux-image-6.1.0-13-amd64. Why should I
> re-install linux-image-6.1.0-1-amd64?

Probably because it's an easy way to ensure that your bootloader
configuration is accurate. If what you showed above completed without
any warnings or other troublesome output, I would expect everything to
be fine.


> Question #2b
> 
> Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told me that it is no longer in the repos.
> 
> I can just download it manually by using the following link:
> 
> https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download
> 
> And then in a terminal, I type the commands:
> 
> sudo dpkg -i linux-image-6.1.0-13-amd64
> 
> sudo update-grub
> 
> sudo shutdown -r now
> 
> Is the above the correct way to install kernels that are not in the official repos?

Not quite, because dpkg -i wants a file path, not a package name
(that's for apt/apt-get). Also dpkg won't automatically pull in any
dependencies that may have been uninstalled after the upgrade, or
necessarily handle any DKMS modules that would need to be recompiled
for the older kernel version, so you'd need to take care with those.

Someone on the Fediverse posted an apt preferences recipe to block the
broken kernel package from installation. I haven't tested it, but it
looks reasonable:

> create a file:
> 
> /etc/apt/preferences.d/buggy-kernel
> 
> with the contents:
> # avoid kernel with ext4 bug 
> # 1057843
> Package: linux-image-*
> Pin: version 6.1.64-1
> Pin-Priority: -1

Copied from https://octodon.social/@alienghic/111552556796482609

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#264583

Hi Michael

> Sent: Sunday, December 10, 2023 at 9:29 PM
> From: "Michael Kjörling" <2695bd53d63c@ewoof.net>
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
>
> 
> This combination is expected under the circumstances, assuming that
> you mean /etc/debian_version. Booting into a different kernel does not
> change the files installed by the base-files package, which is where
> /etc/debian_version comes from; if you want to, you can verify this
> with dpkg -S /etc/debian_version.
> 
Someone on a social media platform stated that there are only two "canonical" [sic] ways to verify the version of Debian installed on a system. They are:

uname -a

/proc/version

Do you agree with the above statement?

> 
> 
> > Question #2b
> > 
> > Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told me that it is no longer in the repos.
> > 
> > I can just download it manually by using the following link:
> > 
> > https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download
> > 
> > And then in a terminal, I type the commands:
> > 
> > sudo dpkg -i linux-image-6.1.0-13-amd64
> > 
> > sudo update-grub
> > 
> > sudo shutdown -r now
> > 
> > Is the above the correct way to install kernels that are not in the official repos?
> 
> Not quite, because dpkg -i wants a file path, not a package name
> (that's for apt/apt-get). Also dpkg won't automatically pull in any
> dependencies that may have been uninstalled after the upgrade, or
> necessarily handle any DKMS modules that would need to be recompiled
> for the older kernel version, so you'd need to take care with those.

Could you help me to understand what you meant when you wrote: "Not quite, because dpkg -i wants a file path, not a package name" please?

Please allow me to give you an example of how I use dpkg on a regular basis.

The version of OpenVPN software in the official Debian repos is lamentably outdated. It has version 2.6.3-1+deb12u2 whereas the official community version by OpenVPN Inc. has version 2.6.8 (By the way, Fedora users are lucky because David S., one of the developers of OpenVPN, is personally maintaining OpenVPN in Fedora's official repos; meaning, the version in Fedora's repos is in sync with the official OpenVPN's version.)

Whenever OpenVPN's developers release an update for OpenVPN, they will also publish the corresponding version for Debian users.

Below are the URLs for the latest version (2.6.8):

https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn_2.6.8-bookworm0_amd64.deb

https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn-dbgsym_2.6.8-bookworm0_amd64.deb

https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn-dco-dkms/openvpn-dco-dkms_0.2.20231117-bookworm0_all.deb

This is how I install the latest version of OpenVPN on my Debian Bookworm:

1. sudo apt remove openvpn

**Sometimes I sudo apt purge openvpn instead of sudo apt remove openvpn in order to remove the configuration files**

2. sudo dpkg -i openvpn_2.6.8-bookworm0_amd64.deb

3. sudo shutdown -r now

Based on your statement, what file path should I supply to dpkg?

> Someone on the Fediverse posted an apt preferences recipe to block the
> broken kernel package from installation. I haven't tested it, but it
> looks reasonable:
> 
> > create a file:
> > 
> > /etc/apt/preferences.d/buggy-kernel
> > 
> > with the contents:
> > # avoid kernel with ext4 bug 
> > # 1057843
> > Package: linux-image-*
> > Pin: version 6.1.64-1
> > Pin-Priority: -1
> 
> Copied from https://octodon.social/@alienghic/111552556796482609
> 
Thanks, Michael for your tip.

But I find the following command to be much simpler to use:

sudo apt-mark hold linux-image-amd64

Said command achieves the same goal, yes?

Best wishes.

Stella

[toc] | [prev] | [next] | [standalone]

#264586

On Mon, Dec 11, 2023 at 04:31:22AM +0100, Stella Ashburne wrote:
> Someone on a social media platform stated that there are only two "canonical" [sic] ways to verify the version of Debian installed on a system. They are:
> 
> uname -a
> 
> /proc/version
> 
> Do you agree with the above statement?

The second one isn't even a command.

Neither one of them tells you what version of Debian is installed, even
if you fix the second one.  All these tell you is which kernel is
running.

It's completely possible, and supported, to run a Debian system with a
custom kernel that you built yourself, in which case the kernel version
revealed by these commands tells you nothing about which OS is running
on top of that kernel.

To see the version of Debian, the correct command is:

    cat /etc/debian_version

This works for any *release* version of Debian.  It will not differentiate
among various pre-releases, including testing and unstable.  For those,
you'll need to go deeper.  "apt policy" and "cat /etc/apt/sources.list"
and "tail -n+1 /etc/apt/sources.list.d/*" would be good starts for that.

[toc] | [prev] | [next] | [standalone]

#264593

Hi Greg

> Sent: Monday, December 11, 2023 at 11:40 AM
> From: "Greg Wooledge" <greg@wooledge.org>
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
>
> On Mon, Dec 11, 2023 at 04:31:22AM +0100, Stella Ashburne wrote:
> > Someone on a social media platform stated that there are only two "canonical" [sic] ways to verify the version of Debian installed on a system. They are:
> >
> > uname -a
> >
> > /proc/version
> >
> > Do you agree with the above statement?
>
> The second one isn't even a command.

Sorry. The command should be:

cat /proc/version

> Neither one of them tells you what version of Debian is installed, even
> if you fix the second one.  All these tell you is which kernel is
> running.

You're right.

>
> To see the version of Debian, the correct command is:
>
>     cat /etc/debian_version
>
> This works for any *release* version of Debian.  It will not differentiate
> among various pre-releases, including testing and unstable.  For those,
> you'll need to go deeper.  "apt policy" and "cat /etc/apt/sources.list"
> and "tail -n+1 /etc/apt/sources.list.d/*" would be good starts for that.
>
Thanks.

Best wishes.

Stella

[toc] | [prev] | [next] | [standalone]

#264588

On Mon, Dec 11, 2023 at 04:31:22AM +0100, Stella Ashburne wrote:
> Hi Michael
> 
> > Sent: Sunday, December 10, 2023 at 9:29 PM
> > From: "Michael Kjörling" <2695bd53d63c@ewoof.net>
> > To: debian-user@lists.debian.org
> > Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
> >
> > 
> > This combination is expected under the circumstances, assuming that
> > you mean /etc/debian_version. Booting into a different kernel does not
> > change the files installed by the base-files package, which is where
> > /etc/debian_version comes from; if you want to, you can verify this
> > with dpkg -S /etc/debian_version.
> > 
> Someone on a social media platform stated that there are only two "canonical" [sic] ways to verify the version of Debian installed on a system. They are:
> 
> uname -a
> 

As you will have discovered this weekend - that one tells you which kernel
you're running, not which Debian version per se.

> /proc/version
> 

Likewise.

> Do you agree with the above statement?
> 
> > 
> > 
> > > Question #2b
> > > 
> > > Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told me that it is no longer in the repos.
> > > 
> > > I can just download it manually by using the following link:
> > > 
> > > https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download
> > > 
> > > And then in a terminal, I type the commands:
> > > 
> > > sudo dpkg -i linux-image-6.1.0-13-amd64
> > > 
> > > sudo update-grub
> > > 
> > > sudo shutdown -r now
> > > 
> > > Is the above the correct way to install kernels that are not in the official repos?
> > 
> > Not quite, because dpkg -i wants a file path, not a package name
> > (that's for apt/apt-get). Also dpkg won't automatically pull in any
> > dependencies that may have been uninstalled after the upgrade, or
> > necessarily handle any DKMS modules that would need to be recompiled
> > for the older kernel version, so you'd need to take care with those.
> 
> Could you help me to understand what you meant when you wrote: "Not quite, because dpkg -i wants a file path, not a package name" please?
> 
> Please allow me to give you an example of how I use dpkg on a regular basis.
> 

dpkg is low level: it will work to install one .deb, usually this has to be
one in the same directory. Apt will install more than one because it also
keeps tabs on dependencies.

> The version of OpenVPN software in the official Debian repos is lamentably outdated. It has version 2.6.3-1+deb12u2 whereas the official community version by OpenVPN Inc. has version 2.6.8 (By the way, Fedora users are lucky because David S., one of the developers of OpenVPN, is personally maintaining OpenVPN in Fedora's official repos; meaning, the version in Fedora's repos is in sync with the official OpenVPN's version.)
> 
> Whenever OpenVPN's developers release an update for OpenVPN, they will also publish the corresponding version for Debian users.
> 

Please ask OpenVPN to set up an apt repository :)

> Below are the URLs for the latest version (2.6.8):
> 
> https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn_2.6.8-bookworm0_amd64.deb
> 
> https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn/openvpn-dbgsym_2.6.8-bookworm0_amd64.deb
> 
> https://build.openvpn.net/debian/openvpn/release/2.6/pool/bookworm/main/o/openvpn-dco-dkms/openvpn-dco-dkms_0.2.20231117-bookworm0_all.deb
> 
> This is how I install the latest version of OpenVPN on my Debian Bookworm:
> 
> 1. sudo apt remove openvpn
> 
> **Sometimes I sudo apt purge openvpn instead of sudo apt remove openvpn in order to remove the configuration files**
> 
> 2. sudo dpkg -i openvpn_2.6.8-bookworm0_amd64.deb
> 
> 3. sudo shutdown -r now
> 
> Based on your statement, what file path should I supply to dpkg?
> 
> > Someone on the Fediverse posted an apt preferences recipe to block the
> > broken kernel package from installation. I haven't tested it, but it
> > looks reasonable:
> > 
> > > create a file:
> > > 
> > > /etc/apt/preferences.d/buggy-kernel
> > > 
> > > with the contents:
> > > # avoid kernel with ext4 bug 
> > > # 1057843
> > > Package: linux-image-*
> > > Pin: version 6.1.64-1
> > > Pin-Priority: -1
> > 
> > Copied from https://octodon.social/@alienghic/111552556796482609
> > 
> Thanks, Michael for your tip.
> 
> But I find the following command to be much simpler to use:
> 
> sudo apt-mark hold linux-image-amd64
> 
> Said command achieves the same goal, yes?
> 
> Best wishes.
> 
> Stella
> 

[toc] | [prev] | [next] | [standalone]

#264594

Hi Andy

> Sent: Monday, December 11, 2023 at 3:20 PM
> From: "Andrew M.A. Cater" <amacater@einval.com>
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)


> dpkg is low level: it will work to install one .deb, usually this has to be
> one in the same directory. Apt will install more than one because it also
> keeps tabs on dependencies.

Noted.

>
> Please ask OpenVPN to set up an apt repository :)
>
Many, many Debian users who also use OpenVPN have asked OpenVPN to do just that.

Based on my recollection, OpenVPN claimed that they were unable to accede to the request to set up an official repo for Debian. It appears that it's onerous on the part of OpenVPN's developers to conform to Debian's strict requirements and polices.

Best wishes.

Stella

P.S.: It doesn't matter to me the location of the official *deb files for OpenVPN as long as they are provided by OpenVPN.

[toc] | [prev] | [next] | [standalone]

#264590

On 11 Dec 2023 04:31 +0100, from rewefie@gmx.com (Stella Ashburne):
> Someone on a social media platform stated that there are only two
> "canonical" [sic] ways to verify the version of Debian installed on
> a system. They are:
> 
> uname -a
> 
> /proc/version
> 
> Do you agree with the above statement?

No.

Running `uname -a` or looking at the contents of `/proc/version` will
only tell you about the _currently running_ _kernel_. There is no
guarantee that a given kernel version maps exactly to any given Debian
release or point-in-time state.

If you want to specify the installation state of a Debian system, you
should specify the point release you're on (from /etc/debian_version
on any modern Debian) and the full _package_ version of any relevant
packages (as reported by e.g. dpkg -l). Note that the package version
may be different from the version reported by a program itself.

A lot of the time, something like "current up-to-date Bookworm" or
"Bookworm per <UTC timestamp>" is sufficiently precise, as long as you
have confirmed that this is actually the case.


>>> sudo dpkg -i linux-image-6.1.0-13-amd64
>>> [...]
>>> Is the above the correct way to install kernels that are not in the official repos?
>> 
>> Not quite, because dpkg -i wants a file path, not a package name
>> (that's for apt/apt-get).
> 
> 2. sudo dpkg -i openvpn_2.6.8-bookworm0_amd64.deb

linux-image-6.1.0-13-amd64 is a package name. (You can check this with
apt-cache show.)

openvpn_2.6.8-bookworm0_amd64.deb is presumably a file name.

"File path" does not necessarily require specifying a directory
component of the path; a bare file name is also a (relative) path.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#264505

On Sun, Dec 10, 2023 at 01:48:52PM +0100, Stella Ashburne wrote:
> Hi,
> 
> I am using Debian Bookworm, the current stable release with the whole SSD being encrypted with LUKS2. After decryption, the file system of the logical volume is ext4.
> 
> This is what happened to my computer many hours ago.
> 
> My device upgraded to the latest kernel, linux-image-6.1.0-14-amd64 and rebooted.
> 

Yes, this was a problem that surfaced properly half way through the release
process. The release team had already put out the main updates: I was involved
with testing the images with the images team.

The issue itself is only occasional and is hard to track down. It only
affects ext4 - but that's the default file system  used if you "just
install" Debian so the release team effectively stopped the release
process part way through.

We halted the release of installer images: so there are no installer images
out there for Debian 12.3 which would be problematic. The release team is
currently working on 12.4, images for which will probably be out within
the next couple of days.
(This will be the first time in a _long_ time that we've not put out a
release of images - breakage doesn't happen very often and the publicity
folks also got onto this to warn people.)

> A few hours later, Debian put out an advisory warning its users against upgrading to linux-image-6.1.0-14-amd64, by which time it was too late for me.
> 

Bad luck - but it looks as if you've done the right thing ...

> According to some people on social media, I should boot using the previous kernel, linux-image-6.1.0-13-amd64, which is problem-free.
> 
> Question #1
> 
> I power up my device and upon seeing the GRUB menu, I highlight "Advance options for Debian GNU/Linux" and press Enter.
> 
> I highlight linux-image-6.1.0-13-amd64 and press Enter.
> 
> After supply the decryption password and entering my desktop environment, I did the following:
> 
> cat /etc/debian_user
> *Result* is 12.3, even though I boot using the previous kernel, linux-image-6.1.0-13-amd64
> 

This is because base-files and everything else have been updated to reference
12.3 - so that probably comes from somewhere like /etc/debian_version

> uname -a
> *Result* is linux-image-6.1.0-13-amd64
> 

Correct: you've booted using 6.1.0-13

> I remove the corrupt linux-image-6.1.0-14-amd64 by typing the following commands in a terminal. They are:
> 
> dpkg --search /boot/vmlinuz-*
> 
> sudo apt-get remove linux-image-6.1.0-14-amd64
> 
> sudo update-grub
> 
> sudo shutdown -r now
> 
> Is the above the correct way to remove the most recent/latest kernel?
>

That will work: you might also want to apt-get purge linux-image-6.1.0-14-amd64
but you've done the main thing.
 
> Question #2a
> 
> Some users opine that after removing linux-image-6.1.0-14-amd64, I should re-install linux-image-6.1.0-13-amd64. Why should I re-install linux-image-6.1.0-1-amd64?
> 

If you'd removed 6.1.0-13 so that the later kernel was the only one - that 
would be right - Otherwise you're fine.

> Am I right to state that Debian keeps the three recent kernels, including linux-image-6.1.0-14-amd64, for situations such as this one? (The situation in which a corrupt linux-image-6.1.0-14-amd64 was pushed to the repos for users to upgrade)
> 

Routinely, I think it keeps only the latest and the previous - so in this case,
you would have had 6.1.0-14 and 6.1.0-13
 
> Question #2b
> 
> Suppose I need to re-install linux-image-6.1.0-13-amd64 but some users told me that it is no longer in the repos.
> 
> I can just download it manually by using the following link:
> 
> https://packages.debian.org/bookworm/amd64/linux-image-6.1.0-13-amd64/download
> 
> And then in a terminal, I type the commands:
> 
> sudo dpkg -i linux-image-6.1.0-13-amd64
> 
> sudo update-grub
> 
> sudo shutdown -r now
> 

That works: when the new kernel (presumably 6.1.0-15) comes out, that
will be installed appropriately.

> Is the above the correct way to install kernels that are not in the official repos?
> 

That will work while previous kernels still exist in the repositories yes.
When I installed, I still had 6.0.1.12 available too because I'd had that
previously.

> Thanks for taking the time and effort to clarify my doubts.
> 
> Best regards.
> 
> Stella
> 
>

No problem: debian-release team are working away quite hard at the moment
on sorting out the problems, providing a new kernel and, presumably,
removing the problematic kernel from the archive. It's been a long
weekend for them :(

All the very best, as ever,

Andy 

[toc] | [prev] | [next] | [standalone]

#264510

On Sun, Dec 10, 2023 at 01:41:14PM +0000, Andrew M.A. Cater wrote:
> That will work: you might also want to apt-get purge linux-image-6.1.0-14-amd64
> but you've done the main thing.

Note that purging 6.1.0-14 will also remove the linux-image-amd64
metapackage, which has a hard dependency on it (at the moment).

> That works: when the new kernel (presumably 6.1.0-15) comes out, that
> will be installed appropriately.

Only if you reinstall the kernel metapackage as soon as you notice that
there's been another point release.

This is not a criticism of Andrew's post.  I'm just reminding everyone,
including myself, that we're going to have to remember to do this extra
step.

[toc] | [prev] | [next] | [standalone]

#264542

On Sun, Dec 10, 2023 at 10:08:21AM -0500, Greg Wooledge wrote:
> On Sun, Dec 10, 2023 at 01:41:14PM +0000, Andrew M.A. Cater wrote:
> > That will work: you might also want to apt-get purge linux-image-6.1.0-14-amd64
> > but you've done the main thing.
> 
> Note that purging 6.1.0-14 will also remove the linux-image-amd64
> metapackage, which has a hard dependency on it (at the moment).
> 
> > That works: when the new kernel (presumably 6.1.0-15) comes out, that
> > will be installed appropriately.
> 
> Only if you reinstall the kernel metapackage as soon as you notice that
> there's been another point release.
> 
> This is not a criticism of Andrew's post.  I'm just reminding everyone,
> including myself, that we're going to have to remember to do this extra
> step.

In order to avoid having to remember to re-install the metapackage at a
future date, I've installed the prior version from snapshot:

http://snapshot.debian.org/archive/debian/20231002T025920Z/pool/main/l/linux-signed-amd64/linux-image-amd64_6.1.55-1_amd64.deb

[toc] | [prev] | [next] | [standalone]

#264576

Hi Greg

> Sent: Monday, December 11, 2023 at 2:06 AM
> From: "Greg Wooledge" <greg@wooledge.org>
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
>
>
> In order to avoid having to remember to re-install the metapackage at a
> future date, I've installed the prior version from snapshot:
>
> http://snapshot.debian.org/archive/debian/20231002T025920Z/pool/main/l/linux-signed-amd64/linux-image-amd64_6.1.55-1_amd64.deb
>
What command did you use? Was it

sudo dpkg -i linux-image-amd64_6.1.55-1_amd64.deb

[toc] | [prev] | [next] | [standalone]

#264577

Hi Greg

> Sent: Sunday, December 10, 2023 at 11:08 PM
> From: "Greg Wooledge" <greg@wooledge.org>
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
>
>
> Note that purging 6.1.0-14 will also remove the linux-image-amd64
> metapackage, which has a hard dependency on it (at the moment).

What is/was the hard dependency?

> Only if you reinstall the kernel metapackage as soon as you notice that
> there's been another point release.
>
> This is not a criticism of Andrew's post.  I'm just reminding everyone,
> including myself, that we're going to have to remember to do this extra
> step.


As of writing this reply, there's a new point release, 12.4.0

What if I don't reinstall the kernel's metapackage as soon as there's a new point release? Or if I forget to reinstall it?

Thanks for your clarification.

Best wishes.

Stella

[toc] | [prev] | [next] | [standalone]

#264580

On Mon, Dec 11, 2023 at 03:26:16AM +0100, Stella Ashburne wrote:
> What command did you use? Was it
> 
> sudo dpkg -i linux-image-amd64_6.1.55-1_amd64.deb

Yes.

On Mon, Dec 11, 2023 at 03:32:55AM +0100, Stella Ashburne wrote:
> As of writing this reply, there's a new point release, 12.4.0
> 
> What if I don't reinstall the kernel's metapackage as soon as there's a new point release? Or if I forget to reinstall it?

Well, the question is what you want.  If you want to use the new point
release, then you can simply do "apt update", "apt install linux-image-amd64"
and "apt upgrade" or whatever you would normally do.  That would get you
back to normal, on the new point release.

If you want to stick with the 6.1.0-13 kernel for a little while, but
use the point release for the other packages, then you can leave the
linux-image-amd64 package removed for now.  Whenever you're ready to try
the new kernel, install linux-image-amd64 at that time.

If you want to stick with 6.1.0-13, but use the point release for other
stuff, but you're afraid you'll forget to reinstall linux-image-amd64,
then you could install the old version of it (as I did), but DO NOT use
"apt upgrade", as that pulls in new packages.  Use "apt-get upgrade"
instead, and you won't get any new packages, including kernels with new
ABI version numbers.

Or use other solutions, for other desired outcomes.

[toc] | [prev] | [next] | [standalone]

#264585

Hi Greg

> Sent: Monday, December 11, 2023 at 11:27 AM
> From: "Greg Wooledge" <greg@wooledge.org>
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
>
>
> Well, the question is what you want.
*snip* *snip*
> Or use other solutions, for other desired outcomes.
>
Thanks for your detailed explanation. I learnt some new stuff today.

Best wishes.

Stella

[toc] | [prev] | [next] | [standalone]

#264587 — Release process notes [WAS Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

On Mon, Dec 11, 2023 at 03:32:55AM +0100, Stella Ashburne wrote:
> Hi Greg
> 
> > Sent: Sunday, December 10, 2023 at 11:08 PM
> > From: "Greg Wooledge" <greg@wooledge.org>
> > To: debian-user@lists.debian.org
> > Subject: Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
> >
> >
> > Note that purging 6.1.0-14 will also remove the linux-image-amd64
> > metapackage, which has a hard dependency on it (at the moment).
> 
> What is/was the hard dependency?
> 

linux-image-[foo]-amd64 always points to the latest available kernel image
for amd64 (and the same for other architectures). It's a metapackage
that pulls in other packages

When you first install, I suspect it's that package that makes sure your
kernel version is up to date. When you update between point releases
likewise. 

Hard removing the latest kernel _and_ the metapackage prevents you
from updating to the buggy kernel but you have to do some tidying up 
afterwards. :)

> > Only if you reinstall the kernel metapackage as soon as you notice that
> > there's been another point release.
> >
> > This is not a criticism of Andrew's post.  I'm just reminding everyone,
> > including myself, that we're going to have to remember to do this extra
> > step.
> 
> 
> As of writing this reply, there's a new point release, 12.4.0
> 
> What if I don't reinstall the kernel's metapackage as soon as there's a new point release? Or if I forget to reinstall it?
> 

If you don't reinstall it, then the metapackage won't be there. I installed
it as soon as the point release was being published before the install 
images were out. [Sequence: release team publish the packages - and they
can get put out to mirrors, daily updates etc. Images team build and test
media to check that there's no regressions. Images get published and pushed.
Formal release notification goes out. 12.3 was stopped as image releases
were being tested and the release team had to replace the buggy kernel,
make a decision as to where to put the fix, run through the whole process.
Images release team then had to build and test the media - which always
takes a few hours more. "Release" varies which way you look at it]

This time round the main release team had to effectively do two point
releases in very quick succession and the images team did two full sets
of testing

> Thanks for your clarification.
> 
> Best wishes.
> 
> Stella
> 

Andy
(amacater@debian.org)

[toc] | [prev] | [next] | [standalone]

#264615 — Re: Release process notes [WAS Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

Hi Andy

> Sent: Monday, December 11, 2023 at 3:13 PM
> From: "Andrew M.A. Cater" <amacater@einval.com>
> To: debian-user@lists.debian.org
> Subject: Release process notes [WAS Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]
>
>
> linux-image-[foo]-amd64 always points to the latest available kernel image
> for amd64 (and the same for other architectures). It's a metapackage
> that pulls in other packages
>
I thought the metapackage doesn't have the notation linux-image-[foo]-amd64. It is simply called linux-image-amd64 (as an example, please click the following link: https://packages.debian.org/bookworm/linux-image-amd64)

> When you first install, I suspect it's that package that makes sure your
> kernel version is up to date. When you update between point releases
> likewise.
>
> Hard removing the latest kernel _and_ the metapackage prevents you
> from updating to the buggy kernel but you have to do some tidying up
> afterwards. :)

I'm sorry but you lost me there.

Let's use linux-image-6.1.0-15-amd64 as an example for me to understand what you wrote above.

The metapackage of linux-image-6.1.0-15-amd64 is called linux-image-amd64 (cf. https://packages.debian.org/bookworm/linux-image-amd64)

I remember that when I upgrade packages, including kernels, in a terminal, the results of

sudo apt update

will always list

linux-image-amd64

Suppose linux-image-6.1.0-15-amd64 is installed successfully and I reboot my device.

A few days from now, I decide to remove linux-image-6.1.0-15-amd64 because it is buggy and so in a terminal, I type the commands:

sudo apt remove linux-image-6.1.0-15-amd64

or

sudo apt purge linux-image-6.1.0-15-amd64

sudo update-grub

sudo shutdown -r now

Based on the above commands, I have some questions for you. They are:

(1) Is it a "hard" or "soft" removal of linux-image-6.1.0-15-amd64?

(2) Is the metapackage linux-image-amd64 removed?

(3) What do you mean by your statement "prevents you from updating to the buggy kernel but you have to do some tidying up afterwards"?

Thanks, Andy for taking the time and effort to clarify my doubts.

Best regards.

Stella

[toc] | [prev] | [next] | [standalone]

#264620 — Re: Release process notes [WAS Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

On Mon, Dec 11, 2023 at 02:35:07PM +0100, Stella Ashburne wrote:
> Suppose linux-image-6.1.0-15-amd64 is installed successfully and I reboot my device.
> 
> A few days from now, I decide to remove linux-image-6.1.0-15-amd64 because it is buggy and so in a terminal, I type the commands:
> 
> sudo apt remove linux-image-6.1.0-15-amd64
> 
> or
> 
> sudo apt purge linux-image-6.1.0-15-amd64
> 
> sudo update-grub
> 
> sudo shutdown -r now
> 
> Based on the above commands, I have some questions for you. They are:
> 
> (1) Is it a "hard" or "soft" removal of linux-image-6.1.0-15-amd64?

I don't know what you mean by "hard removal" or "soft removal".

The other day, I used the phrase "hard dependency" to describe the
relationship between linux-image-amd64 and linux-image-SOME-VERSION-amd64.
The metapackage has a "Depends: ..." line which names the other kernel
package.  You *cannot* install linux-image-amd64 without also bringing
in the versioned kernel that it depends on.

This is different from "Suggests:" or "Recommends:" which are optional
dependencies.

> (2) Is the metapackage linux-image-amd64 removed?

Yes, because linux-image-amd64 *right now* depends on
linux-image-6.1.0-15-amd64.  Removing linux-image-6.1.0-15-amd64 will
therefore remove linux-image-amd64.

> (3) What do you mean by your statement "prevents you from updating to the buggy kernel but you have to do some tidying up afterwards"?

You have to go back in time, to when linux-image-amd64 depended on
the buggy linux-image-6.1.0-14-amd64 package.  At that time, removing
linux-image-6.1.0-14-amd64 would have removed linux-image-amd64 because
*back then* that's how the dependency was.

If you removed linux-image-6.1.0-14-amd64 and linux-image-amd64 as I'm
sure many people did, then in order to get back to normalcy, you would
have to reinstall the linux-image-amd64 metapackage.  But the question is
*when* to do this.  If you did it right away, it would just reinstall
the buggy kernel, so that's no good.  You had to wait.  But... how long?
It makes sense to wait until we have a confirmed good kernel version
available; otherwise, we just have to repeat this cycle all over again.

[toc] | [prev] | [next] | [standalone]

#264627 — Re: Release process notes [WAS Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

Hi Greg

Thank you for taking the time to explain in detail.

> Sent: Monday, December 11, 2023 at 10:16 PM
> From: "Greg Wooledge" <greg@wooledge.org>
> To: debian-user@lists.debian.org
> Subject: Re: Release process notes [WAS  Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]
>
*snip* *snip*
>
>
> If you removed linux-image-6.1.0-14-amd64 and linux-image-amd64 as I'm
> sure many people did, then in order to get back to normalcy, you would
> have to reinstall the linux-image-amd64 metapackage.  But the question is
> *when* to do this.  If you did it right away, it would just reinstall
> the buggy kernel, so that's no good.  You had to wait.  But... how long?
> It makes sense to wait until we have a confirmed good kernel version
> available; otherwise, we just have to repeat this cycle all over again.
>
May I refer you to my other post titled "From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?" (URL: https://lists.debian.org/debian-user/2023/12/msg00632.html).

Based on your above statements, I should boot my installed Debian using the kernel named linux-image-6.1.0-13-amd64 (the version prior to the buggy one).

Next in a terminal I should either

(1a) sudo apt remove linux-image-6.1.0-14-amd64

or

(1b) sudo apt purge linux-image-6.1.0-14-amd64

(1a) or (1b) will remove the metapackage linux-image-amd64, yes/no?

(2) sudo update-grub

(3) sudo shutdown -r now

Upon reboot, the GRUB menu will automatically boot using linux-image-6.1.0-13-amd64 as the buggy kernel named linux-image-6.1.0-14-amd64 has been removed in either (1a) or (1b), am I right?

Next in a terminal I typed the following commands:

sudo apt update && apt upgrade

(Note: The name of the metapackage, linux-image-amd64, will be listed in the terminal.)

After upgrading and rebooting my device, my installed Debian will have linux-image-6.1.0-15-amd64 as the latest kernel. Am I right?

Best wishes.

Stella

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web