Re: Bookworm and its kernel: any updates coming?

[Timothy M Butterworth]

On Mon, Jun 3, 2024 at 8:52 PM  wrote:

> On 6/3/24 09:40, Tom Browder wrote:
> > I keep getting emails concerning the serious kernel vulnerability in
> > kernels 5.14 through 6.6.
> >
> > I have not seen any updates and uname -a shows: 6.1.0-13-amd64
> On 6/3/24 09:40, Tom Browder wrote:
> > I keep getting emails concerning the serious kernel vulnerability in
> > kernels 5.14 through 6.6.
> >
> > I have not seen any updates and uname -a shows: 6.1.0-13-amd64
> >
> > Anyone concerned?
>
> I have the same kernel, and no updates.
>
> eben@cerberus:~$ sudo apt-get update
> [sudo] password for eben:
> Hit:1 http://deb.debian.org/debian bookworm InRelease
> Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
> Hit:3 http://deb.debian.org/debian bookworm-proposed-updates InRelease
> Hit:4 http://deb.debian.org/debian bookworm-backports InRelease
> Hit:5 http://deb.debian.org/debian-security bookworm-security InRelease
> Hit:6 https://deb.torproject.org/torproject.org bookworm InRelease
> Hit:7 https://www.deb-multimedia.org bookworm InRelease
> Reading package lists... Done
>
> eben@cerberus:~$ apt list --upgradable
> Listing... Done
>
> eben@cerberus:~$ apt-cache policy linux-image-amd64
> linux-image-amd64:
>Installed: (none)
>Candidate: 6.1.90-1
>Version table:
>   6.7.12-1~bpo12+1 100
>  100 http://deb.debian.org/debian bookworm-backports/main amd64
> Packages
>

The above line shows that you have kernel 6.7.12 from Debian Backports
installed. You will not get any new 6.1.x kernel packages because 6.7.12 is
newer and has a priority of 100. To verify your kernel version try
running `uname
-a`. If it doesn't report 6.7.12 then try rebooting.


>   6.1.90-1 500
>  500 http://deb.debian.org/debian bookworm-proposed-updates/main
> amd64 Packages
>  500 http://deb.debian.org/debian-security bookworm-security/main
> amd64 Packages
>   6.1.76-1 500
>  500 http://deb.debian.org/debian bookworm/main amd64 Packages
>   6.1.67-1 500
>  500 http://deb.debian.org/debian bookworm-updates/main amd64
> Packages
>
> What am I doing wrong?  Also, I'm not sure how to interpret the apt-cache
> output.
>
>
> --
>
>This message was created using recycled electrons.
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Bookworm and its kernel: any updates coming?

[eben]

On 6/3/24 15:06, Greg Wooledge wrote:

On Mon, Jun 03, 2024 at 02:18:40PM -0400, e...@gmx.us wrote:

eben@cerberus:~$ apt-cache policy linux-image-amd64
linux-image-amd64:
   Installed: (none)
   Candidate: 6.1.90-1



What am I doing wrong?


You haven't installed the linux-image-amd64 metapackage, which means
you will not be offered new kernel versions automatically.  This isn't
technically "wrong", but it's not (or should not be) a common choice.


eben@cerberus:~$ apt-cache policy linux-image-amd64
linux-image-amd64:
  Installed: 6.1.90-1
  Candidate: 6.1.90-1

Excellent, thank you.

Also, if you happen to have a bit of a post selected in Tbird when you hit
"Reply List", it starts your reply with just that piece.  That's a
reasonable action, I guess, just not what I expected.

--
LEO:  Now is not a good time to photocopy your butt and staple it
to your boss' face, oh no.  Eat a bucket of tuna-flavored pudding
and wash it down with a gallon of strawberry Quik.  -- Weird Al

Re: Bookworm and its kernel: any updates coming?

[Greg Wooledge]

On Mon, Jun 03, 2024 at 02:18:40PM -0400, e...@gmx.us wrote:
> eben@cerberus:~$ apt-cache policy linux-image-amd64
> linux-image-amd64:
>   Installed: (none)
>   Candidate: 6.1.90-1

> What am I doing wrong?

You haven't installed the linux-image-amd64 metapackage, which means
you will not be offered new kernel versions automatically.  This isn't
technically "wrong", but it's not (or should not be) a common choice.

Re: Bookworm and its kernel: any updates coming?

[eben]

On 6/3/24 09:40, Tom Browder wrote:

I keep getting emails concerning the serious kernel vulnerability in
kernels 5.14 through 6.6.

I have not seen any updates and uname -a shows: 6.1.0-13-amd64

On 6/3/24 09:40, Tom Browder wrote:

I keep getting emails concerning the serious kernel vulnerability in
kernels 5.14 through 6.6.

I have not seen any updates and uname -a shows: 6.1.0-13-amd64

Anyone concerned?


I have the same kernel, and no updates.

eben@cerberus:~$ sudo apt-get update
[sudo] password for eben:
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://deb.debian.org/debian bookworm-proposed-updates InRelease
Hit:4 http://deb.debian.org/debian bookworm-backports InRelease
Hit:5 http://deb.debian.org/debian-security bookworm-security InRelease
Hit:6 https://deb.torproject.org/torproject.org bookworm InRelease
Hit:7 https://www.deb-multimedia.org bookworm InRelease
Reading package lists... Done

eben@cerberus:~$ apt list --upgradable
Listing... Done

eben@cerberus:~$ apt-cache policy linux-image-amd64
linux-image-amd64:
  Installed: (none)
  Candidate: 6.1.90-1
  Version table:
 6.7.12-1~bpo12+1 100
100 http://deb.debian.org/debian bookworm-backports/main amd64 Packages
 6.1.90-1 500
500 http://deb.debian.org/debian bookworm-proposed-updates/main
amd64 Packages
500 http://deb.debian.org/debian-security bookworm-security/main
amd64 Packages
 6.1.76-1 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
 6.1.67-1 500
500 http://deb.debian.org/debian bookworm-updates/main amd64 Packages

What am I doing wrong?  Also, I'm not sure how to interpret the apt-cache
output.


--

  This message was created using recycled electrons.

Re: Bookworm and its kernel: any updates coming?

[Michael Kjörling]

On 3 Jun 2024 11:29 -0500, from tom.brow...@gmail.com (Tom Browder):
> Thanks for your concern and help.

You're welcome. Glad you got it sorted.

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

Re: Bookworm and its kernel: any updates coming?

[Tom Browder]

On Mon, Jun 3, 2024 at 09:15 Michael Kjörling <2695bd53d...@ewoof.net>
wrote:

> On 3 Jun 2024 08:40 -0500, from tom.brow...@gmail.com (Tom Browder):
> > I keep getting emails concerning the serious kernel vulnerability in
> > kernels 5.14 through 6.6.
> >
> > I have not seen any updates and uname -a shows: 6.1.0-13-amd64
>
> Something's broken on your end.
>
> Bookworm is currently at ABI 6.1.0-21 / kernel 6.1.90-1 since May 6


Michael, on one my hosts I discovered both 13 and 21 pkgs are installed. I
did a reboot and I get uname -a = 6.1.0-21-amd4;

I must have missed a msg at some point.

Thanks for your concern and help.

-Tom

Re: Bookworm and its kernel: any updates coming?

[Michael Kjörling]

On 3 Jun 2024 09:51 -0500, from tom.brow...@gmail.com (Tom Browder):
> But another remote host seems to have the same problem. Each host comes
> from a different provider and had slightly different default pinnings in
> '/etc/apt/sources.list'.
> 
> I'll double-check my pinnings.

Try: apt-cache policy linux-image-amd64

Here's the output of that from my system, only slightly anonymized,
for comparison:

> linux-image-amd64:
>   Installed: 6.1.90-1
>   Candidate: 6.1.90-1
>   Version table:
>  *** 6.1.90-1 500
> 500 http://security.debian.org bookworm-security/main amd64 Packages
> 100 /var/lib/dpkg/status
>  6.1.76-1 500
> 500 https://mirror.debian.example/debian bookworm/main amd64 Packages
>  6.1.67-1 500
> 500 https://mirror.debian.example/debian bookworm-updates/main amd64 
> Packages

I also double-checked, and 6.1.0-13 is indeed the ABI version
immediately preceding the kernel bugs incident. The kernels affected
by that in mainline Debian were 6.1.0-14/6.1.64* and 6.1.0-15/6.1.66*;
the latter by unrelated bug #1057967 which may or may not affect you.
This further reinforces my belief that the problem is likely to be an
errant apt pin meant to exclude those kernels from being installed
accidentally, and which ended up matching too much. (The other obvious
possibility would be that the mirror you're using stopped updating
around that time, but frankly that seems less likely, especially if
you are seeing the same behavior across two different hosting
providers.)

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

Re: Bookworm and its kernel: any updates coming?

[Tom Browder]

On Mon, Jun 3, 2024 at 09:15 Michael Kjörling <2695bd53d...@ewoof.net>
wrote:
...

> > I have not seen any updates and uname -a shows: 6.1.0-13-amd64
>
...

> Something's broken on your end.

...

Check your apt pins to ensure that you're not
> blocking too much.


Thanks, Michael.

My system is a remote host, and I'm in the process of a reinstall on one.

If I correctly read the links you sent, the latest kernel has that CVE
covered.

But another remote host seems to have the same problem. Each host comes
from a different provider and had slightly different default pinnings in
'/etc/apt/sources.list'.

I'll double-check my pinnings.

-Tom

Re: Bookworm and its kernel: any updates coming?

[Michael Kjörling]

On 3 Jun 2024 08:40 -0500, from tom.brow...@gmail.com (Tom Browder):
> I keep getting emails concerning the serious kernel vulnerability in
> kernels 5.14 through 6.6.
> 
> I have not seen any updates and uname -a shows: 6.1.0-13-amd64

Something's broken on your end.

Bookworm is currently at ABI 6.1.0-21 / kernel 6.1.90-1 since May 6
[1]. Bookworm Backports seems to have a 6.7.12 kernel.

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

https://tracker.debian.org/news/1527641/accepted-linux-signed-amd64-61901-source-into-stable-security/

IIRC (but without having checked) 6.1.0-13 was around the kernel data
corruption bug incident. Check your apt pins to ensure that you're not
blocking too much.

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

Bookworm and its kernel: any updates coming?

[Tom Browder]

I keep getting emails concerning the serious kernel vulnerability in
kernels 5.14 through 6.6.

I have not seen any updates and uname -a shows: 6.1.0-13-amd64

Anyone concerned?

-Tom

apt-mirror can't read bookworm-updates

[fxkl47BF]

my config file has a single repo

deb-src https://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware

the following is what i get
it seems the bookworm-updates sources file has no line "Files:"



apt-mirror@odroid2:~$ apt-mirror /etc/apt/mirror.list
Downloading 23 index files using 20 threads...
Begin time: Sat May 11 16:54:06 2024
[20]... [19]... [18]... [17]... [16]... [15]... [14]... [13]... [12]... [11]... 
[10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]...
End time: Sat May 11 16:54:08 2024

Processing translation indexes: []

Downloading 0 translation files using 0 threads...
Begin time: Sat May 11 16:54:08 2024
[0]...
End time: Sat May 11 16:54:08 2024

Processing DEP-11 indexes: []

Downloading 0 dep11 files using 0 threads...
Begin time: Sat May 11 16:54:08 2024
[0]...
End time: Sat May 11 16:54:08 2024

Processing cnf indexes: []

Downloading 0 cnf files using 0 threads...
Begin time: Sat May 11 16:54:08 2024
[0]...
End time: Sat May 11 16:54:08 2024

Processing indexes: [SUse of uninitialized value $lines{"Files:"} in split at 
/usr/bin/apt-mirror line 929,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 2.A
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 3.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 4.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 5.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 6.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 7.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 8.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 9.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 10.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 11.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 12.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 13.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 929,  line 2.

0 bytes will be downloaded into archive.
Downloading 0 archive files using 0 threads...
Begin time: Sat May 11 16:54:08 2024
[0]...
End time: Sat May 11 16:54:08 2024

0 bytes in 0 files and 0 directories can be freed.
Run /data/backups/apt-mirror/var/clean.sh for this purpose.

Running the Post Mirror script ...
(/data/backups/apt-mirror/var/postmirror.sh)


Post Mirror script has completed. See above output for any possible errors.

Re: Could Gnome's "install pending software updates" cause installation scripts to misbehave?

[Lucas B. Cohen]

On Fri 29 Mar 2024 at 11:06:45 (-0400), Henning Follmann wrote:

On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote:

Hi,

I've had a bit of a headache understanding why my Debian bookworm system
suddenly panicked at boot with an 'unable to mount root fs' error. Turns out
the first of my two menuentries in grub.cfg were no longer specifying the
linux root by its device UUID (as I was expecting it to do, by honoring
GRUB_DISABLE_LINUX_UUID != true) ; instead these menuentries were using the
device node/file (/dev/md0 in this case, hence the kernel panic).



Was there any error message during the update?
I think what might have gone wrong, that you ran out of space on /boot.


Space on /boot couldn't have been the issue, I have 1GB allocated to 
that partition, and those 2 kernels only take up about a third of that 
space.


The was no visible error message at the time, as it's all hidden from 
the user's view by Gnome, right before power off. However I'm checking 
my /var/log/apt/term.log where it was handily stored, and here's what 
I'm seeing:


- seems that grub-mkconfig (the grub script called by Debian's 
update-grub wrapper) was in fact never called during that update 
sequence! (Therefore Gnome's handling of updates is off the hook.) 
Perhaps it was because of some bad dkms and linux-headers interaction. 
Some module failed to build, which cascaded into leaving the kernel and 
headers packages into the 'unconfigured' state:


Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j12 modules 
KERNEL_UNAME=6.1.0-18-amd64...(bad exit status: 2)

Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more 
information.

Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-18-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-6.1.0-18-amd64 (--configure):
 installed linux-image-6.1.0-18-amd64 package post-installation script 
subprocess returned error exit status 1


dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.1.0-18-amd64 (= 
6.1.76-1); however:

  Package linux-headers-6.1.0-18-amd64 is not configured yet.

- Consequence: my grub.cfg was only regenerated two days later, 
incidentally , during a scheduled unattended-upgrades run. Where


Log started: 2024-03-28  09:56:03
[...]
Removing linux-image-6.1.0-15-amd64 (6.1.66-1) ...
/etc/kernel/prerm.d/dkms:
[...]
depmod...
/etc/kernel/postrm.d/initramfs-tools:
[...]
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.1.0-18-amd64
Found linux image: /boot/vmlinuz-6.1.0-17-amd64
Found initrd image: /boot/initrd.img-6.1.0-17-amd64
Warning: Not executing os-prober.
done
[...]
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-18-amd64 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.1.0-18-amd64.postinst line 11.

dpkg: error processing package linux-headers-6.1.0-18-amd64 (--configure):
 installed linux-headers-6.1.0-18-amd64 package post-installation 
script subprocess returned error exit status 1

dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-18-amd64 (= 6.1.76-1); 
however:

  Package linux-image-6.1.0-18-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.1.0-18-amd64 (= 
6.1.76-1); however:

  Package linux-headers-6.1.0-18-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-18-amd64
 linux-headers-6.1.0-18-amd64
 linux-image-amd64
 linux-headers-amd64
Log ended: 2024-03-28  09:58:24

Something's now apparent: the initrd hadn't been created for this new 
-18 kernel until after grub-mkconfig's execution. My backed up erroneous 
grub.cfg confirms this. Maybe grub-mkconfig doesn't allow the use of 
UUID= absent an initrd? That would be enough to explain everything.


Anyway, this is not an easy thing to reproduce. I guess it just calls 
attention to the danger of unattended/automatic upgrades in odd cases 
like these.


Thanks Henning, and thank you David for your help. (Apologies for not 
replying to your messages; I'd forgotten

Re: Could Gnome's "install pending software updates" cause installation scripts to misbehave?

[David Wright]

On Fri 29 Mar 2024 at 11:06:45 (-0400), Henning Follmann wrote:
> On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote:
> > 
> > I've had a bit of a headache understanding why my Debian bookworm system
> > suddenly panicked at boot with an 'unable to mount root fs' error. Turns out
> > the first of my two menuentries in grub.cfg were no longer specifying the
> > linux root by its device UUID (as I was expecting it to do, by honoring
> > GRUB_DISABLE_LINUX_UUID != true) ; instead these menuentries were using the
> > device node/file (/dev/md0 in this case, hence the kernel panic).
> 
> Was there any error message during the update?
> I think what might have gone wrong, that you ran out of space on /boot.
> 
> > I've poured through the grub scripts a bit but they're quite complex. I've
> > noticed that :
> 
> Yeah, don't do that. These files are all automatically managed.
> All changes should be done in /etc/default/grub or in the config files in
> /etc/default/grub.d
> Then the grub config files are created by running
> update-grub
> 
> > - uninstalling the second of two kernels caused the remaining one to
> > correctly use the device UUID in grub.cfg ;
> 
> and that might have freed enough space on /boot.
> So now everything works again :)
> 
> > - reinstalling that second kernel caused grub.cfg to use UUIDs in all
> > menuentries, as expected.
> > 
> > (Kernel were the two most recent stable ones: 6.1.0-17 and -18.)
> > 
> > This leads me to suspect that my grub.cfg might have been damaged in the way
> > described above because update-grub might have been called in some unusual,
> > limited execution environment. I'd very recently powered off my system and
> > let the default "install pending software updates" option checked by
> > accident, which caused every updated package from the 12.5 release mark to
> > be pulled. I'm guessing that linux-image-6.1.0-18 was part of it.

I'd write "upgraded" rather than "pulled", if that's what you meant.

> > Has anyone witnessed something similar? Would anyone here care to check this
> > somehow? Or should I open a bug against gnome-desktop without waiting?
> >
> Usually it requires some trickery to install a new kernel on machines which
> might not have enough remaining space on the boot partition.
> 
> For simple housekeeping it often is sufficient to run 
> apt autoremove
> after recent updates (after you confirmed that the newly installed kernel
> boots fine).
> That usually frees enough space for a possible new update. 

You can also reduce the space taken up by initrd files, which are
getting rather large nowadays if they are built with MODULES=most
rather than MODULES=dep.

When you have at least two working kernels, remove any unnecessary
backups, copy the older kernel's initrd somewhere else, then rebuild
it with MODULES=dep. If that kernel still boots ok, then you probably
have a lot more room available now for the next kernel upgrade.
Finally, reboot the newer kernel.

Cheers,
David.

Re: Could Gnome's "install pending software updates" cause installation scripts to misbehave?

[Henning Follmann]

On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote:
> Hi,
> 
> I've had a bit of a headache understanding why my Debian bookworm system
> suddenly panicked at boot with an 'unable to mount root fs' error. Turns out
> the first of my two menuentries in grub.cfg were no longer specifying the
> linux root by its device UUID (as I was expecting it to do, by honoring
> GRUB_DISABLE_LINUX_UUID != true) ; instead these menuentries were using the
> device node/file (/dev/md0 in this case, hence the kernel panic).
> 

Was there any error message during the update?
I think what might have gone wrong, that you ran out of space on /boot.


> I've poured through the grub scripts a bit but they're quite complex. I've
> noticed that :

Yeah, don't do that. These files are all automatically managed.
All changes should be done in /etc/default/grub or in the config files in
/etc/default/grub.d
Then the grub config files are created by running
update-grub


> 
> - uninstalling the second of two kernels caused the remaining one to
> correctly use the device UUID in grub.cfg ;

and that might have freed enough space on /boot.
So now everything works again :)

> 
> - reinstalling that second kernel caused grub.cfg to use UUIDs in all
> menuentries, as expected.
> 
> (Kernel were the two most recent stable ones: 6.1.0-17 and -18.)
> 
> This leads me to suspect that my grub.cfg might have been damaged in the way
> described above because update-grub might have been called in some unusual,
> limited execution environment. I'd very recently powered off my system and
> let the default "install pending software updates" option checked by
> accident, which caused every updated package from the 12.5 release mark to
> be pulled. I'm guessing that linux-image-6.1.0-18 was part of it.
> 
> Has anyone witnessed something similar? Would anyone here care to check this
> somehow? Or should I open a bug against gnome-desktop without waiting?
>

Usually it requires some trickery to install a new kernel on machines which
might not have enough remaining space on the boot partition.

For simple housekeeping it often is sufficient to run 
apt autoremove
after recent updates (after you confirmed that the newly installed kernel
boots fine).
That usually frees enough space for a possible new update. 


-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com

Could Gnome's "install pending software updates" cause installation scripts to misbehave?

[Lucas B. Cohen]

Hi,

I've had a bit of a headache understanding why my Debian bookworm system 
suddenly panicked at boot with an 'unable to mount root fs' error. Turns 
out the first of my two menuentries in grub.cfg were no longer 
specifying the linux root by its device UUID (as I was expecting it to 
do, by honoring GRUB_DISABLE_LINUX_UUID != true) ; instead these 
menuentries were using the device node/file (/dev/md0 in this case, 
hence the kernel panic).


I've poured through the grub scripts a bit but they're quite complex. 
I've noticed that :


- uninstalling the second of two kernels caused the remaining one to 
correctly use the device UUID in grub.cfg ;


- reinstalling that second kernel caused grub.cfg to use UUIDs in all 
menuentries, as expected.


(Kernel were the two most recent stable ones: 6.1.0-17 and -18.)

This leads me to suspect that my grub.cfg might have been damaged in the 
way described above because update-grub might have been called in some 
unusual, limited execution environment. I'd very recently powered off my 
system and let the default "install pending software updates" option 
checked by accident, which caused every updated package from the 12.5 
release mark to be pulled. I'm guessing that linux-image-6.1.0-18 was 
part of it.


Has anyone witnessed something similar? Would anyone here care to check 
this somehow? Or should I open a bug against gnome-desktop without waiting?


Thank you for any insight.

Apologies for possible e-mail client misconfiguration.

Regards,

--
Lucas

Re: Stop packagekitd from downloading updates

[Michael Biebl]

In case of GNOME, you might try the following

gsettings set org.gnome.software download-updates false

(gnome-software used packagekitd internally)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Stop packagekitd from downloading updates

[Max Nikulin]

On 29/01/2024 04:24, Greg Wooledge wrote:

On Sun, Jan 28, 2024 at 03:57:30PM -0500, Stefan Monnier wrote:

 systemctl mask packagekit


I don't think you're looking at the right thing.  "packagekit" seems
to be an interface to dbus.  By itself, it doesn't do what you think
it does.


Perhaps there are other hacks like "equivs" to formally satisfy 
dependencies.


In my point of view, dbus-daemon has no flexible ways to override 
configuration like ones available in systemd (/lib, /etc, /run). Maybe I 
did something wrong, but an attempt to hide an installed service failed. 
I tried to put a /dev/null symlink in /usr/local/share/dbus-1/services. 
So "systemctl mask" may be the only way to prevent D-Bus activated 
service start. The disadvantage is noise in logs.

Re: Stop packagekitd from downloading updates

[Andy Smith]

Hello,

On Sun, Jan 28, 2024 at 04:42:18PM -0500, Greg Wooledge wrote:
> On Sun, Jan 28, 2024 at 04:31:02PM -0500, Stefan Monnier wrote:
> > I self-inflicted this by installing [unattended-upgrades] so many years ago?
> 
> It's a dependency of some/most(?) desktop environments, I think.  I
> doubt you installed it by name and forgot.

I do not have it installed on my recently-install Debian 12 / GNOME
desktop.

I do have packagekit though, which includes this config file:

$ cat /etc/apt/apt.conf.d/20packagekit 
// THIS FILE IS USED TO INFORM PACKAGEKIT THAT THE UPDATE-INFO MIGHT HAVE 
CHANGED

// Whenever dpkg is called we might have different updates
// i.e. if an user removes a package that had an update
DPkg::Post-Invoke {
"/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
};

// When APT's cache is updated (i.e. apt-cache update)
APT::Update::Post-Invoke-Success {
"/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
};

So I think probably that unattended-upgrades is downloading Stefan's packages
and then poking packagekit over DBUS to make the GNOME tell Stefan about it.
Which also explains the warning when packagekit is disabled.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Stop packagekitd from downloading updates

[Stephan Seitz]

Am So, Jan 28, 2024 at 16:31:02 -0500 schrieb Stefan Monnier:

the thing you don't want done.  Is "unattended-upgrades" installed by
any chance?

Hmm yep, it is!
So that's it?


Well, you can look in /var/log/unattended-upgrades/ for the log files.

„dpkg-reconfigure unattended-upgrades” will tell you if the package is 
configured to do its jobs.


Stephan

--
|If your life was a horse, you'd have to shoot it.|

Re: Stop packagekitd from downloading updates

[Greg Wooledge]

On Sun, Jan 28, 2024 at 04:31:02PM -0500, Stefan Monnier wrote:
> > There is probably some other package that's *using* packagekit to do
> > the thing you don't want done.  Is "unattended-upgrades" installed by
> > any chance?
> 
> Hmm yep, it is!
> So that's it?
> I self-inflicted this by installing this package so many years ago?

It's a dependency of some/most(?) desktop environments, I think.  I
doubt you installed it by name and forgot.

Re: Stop packagekitd from downloading updates

[Stefan Monnier]

> I don't think you're looking at the right thing.  "packagekit" seems
> to be an interface to dbus.  By itself, it doesn't do what you think
> it does.

Aha!

> There is probably some other package that's *using* packagekit to do
> the thing you don't want done.  Is "unattended-upgrades" installed by
> any chance?

Hmm yep, it is!
So that's it?
I self-inflicted this by installing this package so many years ago?
Thanks,


Stefan

Re: Stop packagekitd from downloading updates

[Greg Wooledge]

On Sun, Jan 28, 2024 at 03:57:30PM -0500, Stefan Monnier wrote:
> >> How can I stop those downloads?
> >> 
> >> Currently, I did
> >> 
> >> systemctl mask packagekit

I don't think you're looking at the right thing.  "packagekit" seems
to be an interface to dbus.  By itself, it doesn't do what you think
it does.

There is probably some other package that's *using* packagekit to do
the thing you don't want done.  Is "unattended-upgrades" installed by
any chance?

Re: Stop packagekitd from downloading updates

[Stefan Monnier]

>> How can I stop those downloads?
>> 
>> Currently, I did
>> 
>> systemctl mask packagekit
>
> Well, you might just get rid of the package.
>
> apt purge packagekit
>
> should do it.

Of course, but that also gets rid of packages I do want to keep (such as
the `gnome` metapackage).

> To prevent it from starting on the next boot:
>
> systemctl disable packagekit
>
> You may have to unmask it first.

This doesn't work:

# systemctl disable packagekit
The unit files have no installation config (WantedBy=, RequiredBy=, 
UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled 
using systemctl.
 
Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
# 

which is why I masked it instead.  In any case, I'd rather find a way to
say precisely what I mean (i.e. "don't download updates in the
background") than to have to chase down the daemon of the day used to
perform those automatic downloads (I remember going through the same
charade a few years back, before `packagekit` existed).
Especially since I don't know what else `packagekit` might be doing
(some of it might be things I do appreciate).  Also, maybe the downloads
are not initiated by `packagekit` but by some other system (which just
happens to delegate the task to `packagekit`), and that other system may
end up deciding to do the same downloads some other way if `packagekit`
isn't available.


Stefan

Re: Stop packagekitd from downloading updates

[Charles Curley]

On Sun, 28 Jan 2024 14:10:46 -0500
Stefan Monnier  wrote:

> How can I stop those downloads?
> 
> Currently, I did
> 
> systemctl mask packagekit

Well, you might just get rid of the package.

apt purge packagekit

should do it.

Less drastic, to simply shut down the current daemon,

systemctl stop packagekit

To prevent it from starting on the next boot:

systemctl disable packagekit

You may have to unmask it first.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Stop packagekitd from downloading updates

[Stefan Monnier]

Apparently, there's now a thing called `packagekit` whose daemon seems
to like to download updates "in the background" for me.

Thanks, but no, thanks.  This tends to occur at inopportune times for me
and it's not far enough "in the background", so it gets in the way
(furthermore, I like to download my packages with `debdelta` and
`packagekitd` doesn't know how to do that, AFAICT).

How can I stop those downloads?

Currently, I did

systemctl mask packagekit

which might get the job done, but I don't really know what other impact
it might have, and I see that APT complains about it (tho it still
works fine, as far as I can tell):

# LANG=C apt update
Hit:1 http://deb.debian.org/debian stable InRelease
Hit:2 http://security.debian.org stable-security InRelease
Hit:3 http://security.debian.org testing-security InRelease
Hit:4 http://deb.debian.org/debian testing InRelease
Hit:5 http://deb.debian.org/debian unstable InRelease
Error: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit 
packagekit.service is masked.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
#

Where can I say specifically that I don't want automatic background
download of updates?


Stefan

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

On 07.01.24 20:33, songbird wrote:

i see you've solved your issue, but i just wanted to
point out that it works and is ok for people who want to
try it out.

Says who?

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[songbird]

Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond repair, I 
> today tried to just replace it with rEFInd. Installation succeeded 
> without any trouble. But when I start my system, rEFInd just asks me if 
> I want to boot with fwupd or with the still very broken Grub. Am I 
> missing something? Is rEFInd really just something to select between 
> different OSs (and not just different distributions like Grub can very 
> well do) and then gives the rest over to their bootloaders or am I 
> missing something so rEFInd will take over all of Grubs jobs?

...

  i don't do encryption or raid so i keep things pretty
simple.

  i've been using refind for years without issues.  i also
have grub installed so if either of them breaks the other
is still likely going to work.

  i've also set it up so that each can be reached from the
other through their menus.

  i see you've solved your issue, but i just wanted to 
point out that it works and is ok for people who want to
try it out.


  songbird

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 04.01.24 19:49, Richard Rosner wrote:

On 04.01.24 19:02, David Wright wrote:

Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?

Cheers,
David.


Let's hope the mailing list let's this go through.

It did, but since it seems to have been malformed yet again, let's try 
again.


Keep in mind, this is based on the assumption that your whole / 
partition is LUKS encrypted (in my case now LUKS2). "root partition 
UUID1" is the UUID that's shown in Disks or on the Grub screen for the 
decryption password prompt. Now, I can't say for sure what 
"root-partition-UUID2" is, but that's what seems to be symlinked to 
/dev/dm-0 and with blkid, one of the entries will look like this:



/dev/mapper/luks-: UUID="" 
BLOCK_SIZE="4096" TYPE="ext4"



So maybe it's just some kind of virtual UUID for the decrypted root 
partition.


Adding to that, "root partition UUID1.1" is basically the same as  
UUID1.1, just without dashes. So it's the same format as Grub shows for 
the ususal bootup password prompt. Let's hope this time this is the 
right one.


#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u 
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'  

else
  search --no-floppy --fs-uuid --set=root 
fi
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
cryptomount -u 
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'  

else
  search --no-floppy --fs-uuid --set=root 
fi
insmod png
if background_image 
/usr/share/desktop-base/emerald-theme/grub/grub-4x3.png; then

  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
    set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 'gnulinux-simple-UUID2>' {

    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod cryptodisk
    insmod luks2
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod ext2
    cryptomount -u 
    set root='cryptouuid/'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint='cryptouuid/partition UUID1.1>'  

    else
      search --no-floppy --fs-uuid --set=root 
    fi
    echo    'Loading Linux 6.5.0-5-amd64 ...'
    linux    /boot/vmlinuz-6.5.0-5-amd64 root=UUID=UUID2> ro  quiet root=/dev/mapper/luks- splash 
resume=/dev/mapper/luks-

    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-' {
    menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class 

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 07.01.24 18:07, David Wright wrote:

I compared your new grub.cfg with mine (suitably decimated and edited)
and the significant differences are very few; extra modules are loaded:
cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256.
Myset root='hd0,gpt5' is replaced by
   set root='cryptouuid/'
and my
   --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5
is replaced by
   hint='cryptouuid/'

Unlike the first version of grub.cfg that you pasted earlier:

   cryptomount -u 
   set root='cryptouuid/

there's no cryptomount in your new one. I'm guessing that means that
the LUKS2 partition has been decrypted by Grub before grub.cfg is
commanded. Do you now get just the one prompt for the passphrase
when you boot? (I'm not very familiar with how far encrypted
/boot has progressed.)


There was always only one prompt for the passphrase when boot was 
working on its own. Only if you had to manually decrypt all partitions, 
you'd need to enter it for every encrypted partition there is — probably 
because you don't necessarily need to have the same password for 
everything. There might be an option to have it reuse the key, but I 
have yet to find that.


Also, that the cryptomount lines are missing must be why Grub was still 
a bit unreliable. I'll write my current grub.cfg in a separate message, 
as they are back now after some experiments with rEFInd, systemd-boot 
and trying to get resume from hibernation to work reliably.



The other difference in the earlier, pasted grub.cfg is that its
linux line was extremely long, and looked as though a large amount
of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or
GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub?
I commented previously on the multiple root= parameters, and have
also noticed that the recovery mode lines had "single" duplicated.
I presume all that configuration stuff has gone away now.


Well, that bunch of text is necessary, since grub has to communicate the 
location of the root and the swap partitions to the kernel, so of course 
they are automatically included in the default/grub. The last one there 
is just a little fix for better handling very old Synaptic touchpads in 
Wayland.


In my current grub.cfg the multiple root= entries in one line seem to be 
gone, but there are still multiple single in the recovery parts.



I somehow doubt whether all this will be any help, as you're working
well beyond my experience, and somewhere near the cutting edge of Grub.
Just shows how hopelessly outdated Grub is and that it sorely needs a 
replacement — and a better experience in replacing it. Grub 2.12 was 
just released in December. On the other hand, LUKS was originally 
released in 2004, LUKS2 followed in 2018 and became the default with 
cryptsetup 2.1.0 in early 2019 — though Debian seems to ignore that, 
since the installer still by default creates LUKS1 volumes. Also, by 
default, LUKS2 uses Argon2 key derivation function — unsupported even by 
Grub 2.12. All this in a time when smartphones have been encrypted for 
years by default, so have MacBooks and even Windows is slowing making it 
a default. Not to mention the fact that Linux distributions are offering 
encryption in their installers for many years now, with a few even 
making it a default, like Pop.

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Thu 04 Jan 2024 at 19:49:43 (+0100), Richard Rosner wrote:
> On 04.01.24 19:02, David Wright wrote:
> > Could you post the new grub.cfg file, so that people running testing,
> > and following along the thread later, can see how boot-repair fixed it?
> 
> Keep in mind, this is based on the assumption that your whole /
> partition is LUKS encrypted (in my case now LUKS2).
> "root-partition-UUID" is the UUID that's shown in Disks or on the Grub
> screen for the decryption password prompt. Now, I can't say for sure
> what "root-partition-UUID2" is, but that's what seems to be symlinked
> to /dev/dm-0 and with blkid, one of the entries will look like this:
> 
> /dev/mapper/luks-: UUID=""
> BLOCK_SIZE="4096" TYPE="ext4"
> 
> So maybe it's just some kind of virtual UUID for the decrypted root
> partition.

(I would have thought that you'd know encrypted filesystems have UUIDs.)

I compared your new grub.cfg with mine (suitably decimated and edited)
and the significant differences are very few; extra modules are loaded:
cryptodisk, luks2, gcry_rijndael, gcry_rijndael and gcry_sha256.
Myset root='hd0,gpt5' is replaced by
  set root='cryptouuid/'
and my
  --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-bar emetal=ahci0,gpt5
is replaced by
  hint='cryptouuid/'

Unlike the first version of grub.cfg that you pasted earlier:

  cryptomount -u 
  set root='cryptouuid/

there's no cryptomount in your new one. I'm guessing that means that
the LUKS2 partition has been decrypted by Grub before grub.cfg is
commanded. Do you now get just the one prompt for the passphrase
when you boot? (I'm not very familiar with how far encrypted
/boot has progressed.)

The other difference in the earlier, pasted grub.cfg is that its
linux line was extremely long, and looked as though a large amount
of text had been added from GRUB_CMDLINE_LINUX_DEFAULT and/or
GRUB_CMDLINE_LINUX, perhaps set in /etc/default/grub?
I commented previously on the multiple root= parameters, and have
also noticed that the recovery mode lines had "single" duplicated.
I presume all that configuration stuff has gone away now.

I passed over a couple of other, minor differences that probably don't
affect things, like the pasted grub.cfg allowing for decrypting / to
get at fonts in /usr/share/grub/, and the similar code (extra relative
to mine) in 05_debian_theme for prettyfying the main Grub screen.

I somehow doubt whether all this will be any help, as you're working
well beyond my experience, and somewhere near the cutting edge of Grub.

Cheers,
David.

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Jeffrey Walton]

On Thu, Jan 4, 2024 at 6:18 PM Joel Roth  wrote:
>
> On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote:
> > In theory, it should
> > be as simple as refind-install. So the only reason I could guess to be the
> > reason would be that rEFInd might not be capable of handling LUKS, which
> > would be quite disappointing.
>
> My experiences are with vanilla filesystems only. LUKS
> obviously has specific requirements. Perhaps you could try
> having a root partition that is unencrypted?

Be careful of that. Someone who is encrypting the filesystem likely
has password protected the firmware, disabled booting from USB sticks,
and disabled the root account so a rescue console cannot be used to
sidestep access restrictions. That is, you don't want to hand out a
passwordless root shell in rescue mode. Also see
.

Jeff

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 04.01.24 19:02, David Wright wrote:

Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?

Cheers,
David.


Let's hope the mailing list let's this go through.


Keep in mind, this is based on the assumption that your whole / 
partition is LUKS encrypted (in my case now LUKS2). 
"root-partition-UUID" is the UUID that's shown in Disks or on the Grub 
screen for the decryption password prompt. Now, I can't say for sure 
what "root-partition-UUID2" is, but that's what seems to be symlinked to 
/dev/dm-0 and with blkid, one of the entries will look like this:



/dev/mapper/luks-: UUID="" 
BLOCK_SIZE="4096" TYPE="ext4"



So maybe it's just some kind of virtual UUID for the decrypted root 
partition.



#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if loadfont unicode ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
set root='cryptouuid/'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/' 

else
  search --no-floppy --fs-uuid --set=root 
fi
insmod png
if background_image /boot/grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
    set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 
'gnulinux-simple-' {

    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod cryptodisk
    insmod luks2
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod ext2
    set root='cryptouuid/'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/' 

    else
      search --no-floppy --fs-uuid --set=root 
    fi
    echo    'Loading Linux 6.5.0-5-amd64 ...'
    linux    /boot/vmlinuz-6.5.0-5-amd64 
root=UUID= ro  quiet

    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-' {
    menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class 
debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.5.0-5-amd64-advanced-' {

    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod cryptodisk
    insmod luks2
    insmod gcry_rijndael
    insmod gcry_rijndael
    insmod gcry_sha256
    insmod ext2
    set root='cryptouuid/'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/' 

    else
      search --no-floppy --fs-uuid --set=root 
    fi
    echo    'Loading Linux 6.5.0-5-amd64 ...'
    linux    /boot/vmlinuz-6.5.0-5-amd64 
root=UUID= ro  quiet

    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-6.5.0-5-amd64
    }
    menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64 (recovery 
mode)' --class debian --class gnu-linux 

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Wed 03 Jan 2024 at 22:00:20 (+0100), Richard Rosner wrote:
> On 03.01.24 21:04, Eddie wrote:
> > On 1/3/24 14:23, Richard Rosner wrote:
> > > So, since for whatever reason Grub seems to be broken beyond
> > > repair, I today tried to just replace it with rEFInd.
> > > Installation succeeded without any trouble. But when I start
> > > my system, rEFInd just asks me if I want to boot with fwupd or
> > > with the still very broken Grub. Am I missing something? Is
> > > rEFInd really just something to select between different OSs
> > > (and not just different distributions like Grub can very well
> > > do) and then gives the rest over to their bootloaders or am I
> > > missing something so rEFInd will take over all of Grubs jobs?
> > 
> > I have had very good results using "Boot-Repair" software to
> > recover Grub difficulties.
> > 
> Thanks, this actually did the job. I don't know what it was, but my
> guess is it was the step "purge Grub before reinstalling it".
> 
> 
> PS: rewrote to the old subject, as this is clearly an answer to the
> original problem, as it doesn't have anything to do with replacing
> Grub all together.

Could you post the new grub.cfg file, so that people running testing,
and following along the thread later, can see how boot-repair fixed it?

Cheers,
David.

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Joel Roth]

On Thu, Jan 04, 2024 at 06:19:01PM +0100, Richard Rosner wrote:
> In theory, it should
> be as simple as refind-install. So the only reason I could guess to be the
> reason would be that rEFInd might not be capable of handling LUKS, which
> would be quite disappointing. 

My experiences are with vanilla filesystems only. LUKS
obviously has specific requirements. Perhaps you could try
having a root partition that is unencrypted?

-- 
Joel Roth

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

Well, that was a bust. I accidentally didn't just format the EFI 
partition, but deleted it. So I re-created it with the help of disks and 
gparted (to leave the first 3 MB empty, I remeber that being a fix added 
kinda recently to combat bad BIOS/EFI implementations, since Windows is 
doing the same and nobody could come up with anything better.


Anyways, after installing rEFInd with no grub present, it would boot 
into rEFInd, but that's it. No boot options, nothing under F2. Also, I 
couldn't find anything helpful on the Arch Wiki page for this. In 
theory, it should be as simple as refind-install. So the only reason I 
could guess to be the reason would be that rEFInd might not be capable 
of handling LUKS, which would be quite disappointing. Maybe I'll take a 
look at systemd-boot in the next days, as I don't need any customization 
anyways, and maybe it can handle encryption (or better decryption) 
better than Grub — especially with LUKS2 grub seems a bit unreasonably slow.


On 04.01.24 11:56, Richard Rosner wrote:
Good to know that it should be possible. But as mentioned, these 
symbols only offer me to boot from grub or fwupd. F2 also doesn't show 
that much more, it merely gives me the option to boot into the BIOS 
settings. Maybe I'll have to completely purge all Grub packages, wipe 
the existing EFI partition and then try to install rEFInd. I'll have 
to check.


On Thu, Jan 4, 2024, 09:29 Joel Roth  wrote:

On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond
repair, I today
> tried to just replace it with rEFInd. Installation succeeded
without any
> trouble. But when I start my system, rEFInd just asks me if I
want to boot
> with fwupd or with the still very broken Grub. Am I missing
something? Is
> rEFInd really just something to select between different OSs
(and not just
> different distributions like Grub can very well do) and then
gives the rest
> over to their bootloaders or am I missing something so rEFInd
will take over
> all of Grubs jobs?

I boot my debian-based system with rEFInd.  Grub is not
present. A couple big icons show on the boot screen. The
small print at the bottom mentions hit F2 for more options.
On my system, F2 offers a selection among all kernels
present.

rEFInd installs into  EFI/refind/ in the EFI partition.
I originally encountered it looking for something to
boot debian on a Intel Mac. It's been trouble-free.




> On 01.01.24 21:45, Richard Rosner wrote:
> >
> >
> > On 01.01.24 21:20, Richard Rosner wrote:
> > >
> > > On 01.01.24 20:30, David Wright wrote:
> > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > I can boot by hand, but since this is all archived
anyways and it's
> > > > > uneccessarily difficult to find some sort of guide how
to even do
> > > > > this, it might as well be a documentation for users
having such
> > > > > troubles in the future.
> > > > >
> > > > > Also, besides the way that I have no clue how it would
have to look
> > > > > like to set up a paragraph in the grub.cfg, I simply
don't see
> > > > > anything wrong with it anyways. So I can't even look at
the grub
> > > > > settings files grub.cfg is being generated from to check
where the
> > > > > error lies.
> > > > You append the commands that you used to boot manually
with into
> > > > /etc/grub.d/40_custom, observing the comments there, and
also into
> > > > grub.cfg itself at the appropriate place (near the
bottom). The
> > > > former is so that Grub includes it in any new grub.cfg
that you
> > > > create.
> > > Good to know.
> > Edit:, never mind. Tried that, it still booted straight to the
UEFI BIOS
> > menu after entering my password. At this point, I'm seriously
> > considering slapping rEFInd on it and pray that it picks up on
> > everything automatically and fix the situation. But so should
Grub have,
> > besides the fact that I can't even be entirely sure Grub is to
blame and
> > not something else.

-- 
Joel Roth

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

You should really re-read the FAQ that was sent in just two days ago...

On January 4, 2024 11:58:28 AM GMT+01:00, Jeffrey Walton  
wrote:
>On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner  wrote:
>>
>> Wow, what a bunch of unhelpful comments.
>>
>> First, if it wasn't for Eddie recommending boot-repair, "broken beyond 
>> repair" in fact was the very fitting term.
>
>Here was Eddie's comment" I have had very good results using
>"Boot-Repair" software to recover Grub difficulties."
>
>"Broken beyond repair" seems to be context dependent. And it seems to
>depend on the user.
>
>> Second, have you maybe considered that I've already read the home page of 
>> rEFInd and came to the same conclusion? Besides the fact that the page is 
>> virtually unreadable - both from a visual and a content point of view - I 
>> have yet to find anything indicating what it is actually capable of and what 
>> not. Because as far as I can tell, it should be able to do what I want it to 
>> do.
>
>No. You did not state it. And you did not cite something you did not
>understand. I think you are full of shit.
>
>> So please, if you don't have anything to add other than snarky remarks, just 
>> don't answer.
>
>You mean like: "So, since for whatever reason Grub seems to be broken
>beyond repair"?
>
>Jeff
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Jeffrey Walton]

On Thu, Jan 4, 2024 at 2:45 AM Richard Rosner  wrote:
>
> Wow, what a bunch of unhelpful comments.
>
> First, if it wasn't for Eddie recommending boot-repair, "broken beyond 
> repair" in fact was the very fitting term.

Here was Eddie's comment" I have had very good results using
"Boot-Repair" software to recover Grub difficulties."

"Broken beyond repair" seems to be context dependent. And it seems to
depend on the user.

> Second, have you maybe considered that I've already read the home page of 
> rEFInd and came to the same conclusion? Besides the fact that the page is 
> virtually unreadable - both from a visual and a content point of view - I 
> have yet to find anything indicating what it is actually capable of and what 
> not. Because as far as I can tell, it should be able to do what I want it to 
> do.

No. You did not state it. And you did not cite something you did not
understand. I think you are full of shit.

> So please, if you don't have anything to add other than snarky remarks, just 
> don't answer.

You mean like: "So, since for whatever reason Grub seems to be broken
beyond repair"?

Jeff

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

Good to know that it should be possible. But as mentioned, these symbols
only offer me to boot from grub or fwupd. F2 also doesn't show that much
more, it merely gives me the option to boot into the BIOS settings. Maybe
I'll have to completely purge all Grub packages, wipe the existing EFI
partition and then try to install rEFInd. I'll have to check.

On Thu, Jan 4, 2024, 09:29 Joel Roth  wrote:

> On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> > So, since for whatever reason Grub seems to be broken beyond repair, I
> today
> > tried to just replace it with rEFInd. Installation succeeded without any
> > trouble. But when I start my system, rEFInd just asks me if I want to
> boot
> > with fwupd or with the still very broken Grub. Am I missing something? Is
> > rEFInd really just something to select between different OSs (and not
> just
> > different distributions like Grub can very well do) and then gives the
> rest
> > over to their bootloaders or am I missing something so rEFInd will take
> over
> > all of Grubs jobs?
>
> I boot my debian-based system with rEFInd.  Grub is not
> present. A couple big icons show on the boot screen. The
> small print at the bottom mentions hit F2 for more options.
> On my system, F2 offers a selection among all kernels
> present.
>
> rEFInd installs into  EFI/refind/ in the EFI partition.
> I originally encountered it looking for something to
> boot debian on a Intel Mac. It's been trouble-free.
>
>
>
>
> > On 01.01.24 21:45, Richard Rosner wrote:
> > >
> > >
> > > On 01.01.24 21:20, Richard Rosner wrote:
> > > >
> > > > On 01.01.24 20:30, David Wright wrote:
> > > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > > I can boot by hand, but since this is all archived anyways and
> it's
> > > > > > uneccessarily difficult to find some sort of guide how to even do
> > > > > > this, it might as well be a documentation for users having such
> > > > > > troubles in the future.
> > > > > >
> > > > > > Also, besides the way that I have no clue how it would have to
> look
> > > > > > like to set up a paragraph in the grub.cfg, I simply don't see
> > > > > > anything wrong with it anyways. So I can't even look at the grub
> > > > > > settings files grub.cfg is being generated from to check where
> the
> > > > > > error lies.
> > > > > You append the commands that you used to boot manually with into
> > > > > /etc/grub.d/40_custom, observing the comments there, and also into
> > > > > grub.cfg itself at the appropriate place (near the bottom). The
> > > > > former is so that Grub includes it in any new grub.cfg that you
> > > > > create.
> > > > Good to know.
> > > Edit:, never mind. Tried that, it still booted straight to the UEFI
> BIOS
> > > menu after entering my password. At this point, I'm seriously
> > > considering slapping rEFInd on it and pray that it picks up on
> > > everything automatically and fix the situation. But so should Grub
> have,
> > > besides the fact that I can't even be entirely sure Grub is to blame
> and
> > > not something else.
>
> --
> Joel Roth
>
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Pocket]

On 1/4/24 02:45, Richard Rosner wrote:

Wow, what a bunch of unhelpful comments.

First, if it wasn't for Eddie recommending boot-repair, "broken beyond 
repair" in fact was the very fitting term.


Second, have you maybe considered that I've already read the home page 
of rEFInd and came to the same conclusion? Besides the fact that the 
page is virtually unreadable - both from a visual and a content point of 
view - I have yet to find anything indicating what it is actually 
capable of and what not. Because as far as I can tell, it should be able 
to do what I want it to do.





Have you looked at this?

https://wiki.archlinux.org/title/REFInd

I don't know if it will help as I do not use REFInd nor have I any 
experience with it.


--
Hindi madali ang maging ako

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Joel Roth]

On Wed, Jan 03, 2024 at 08:23:29PM +0100, Richard Rosner wrote:
> So, since for whatever reason Grub seems to be broken beyond repair, I today
> tried to just replace it with rEFInd. Installation succeeded without any
> trouble. But when I start my system, rEFInd just asks me if I want to boot
> with fwupd or with the still very broken Grub. Am I missing something? Is
> rEFInd really just something to select between different OSs (and not just
> different distributions like Grub can very well do) and then gives the rest
> over to their bootloaders or am I missing something so rEFInd will take over
> all of Grubs jobs?

I boot my debian-based system with rEFInd.  Grub is not
present. A couple big icons show on the boot screen. The
small print at the bottom mentions hit F2 for more options.
On my system, F2 offers a selection among all kernels
present. 

rEFInd installs into  EFI/refind/ in the EFI partition.
I originally encountered it looking for something to
boot debian on a Intel Mac. It's been trouble-free.




> On 01.01.24 21:45, Richard Rosner wrote:
> > 
> > 
> > On 01.01.24 21:20, Richard Rosner wrote:
> > > 
> > > On 01.01.24 20:30, David Wright wrote:
> > > > On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> > > > > On 01.01.24 18:13, David Wright wrote:
> > > > > I can boot by hand, but since this is all archived anyways and it's
> > > > > uneccessarily difficult to find some sort of guide how to even do
> > > > > this, it might as well be a documentation for users having such
> > > > > troubles in the future.
> > > > > 
> > > > > Also, besides the way that I have no clue how it would have to look
> > > > > like to set up a paragraph in the grub.cfg, I simply don't see
> > > > > anything wrong with it anyways. So I can't even look at the grub
> > > > > settings files grub.cfg is being generated from to check where the
> > > > > error lies.
> > > > You append the commands that you used to boot manually with into
> > > > /etc/grub.d/40_custom, observing the comments there, and also into
> > > > grub.cfg itself at the appropriate place (near the bottom). The
> > > > former is so that Grub includes it in any new grub.cfg that you
> > > > create.
> > > Good to know.
> > Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS
> > menu after entering my password. At this point, I'm seriously
> > considering slapping rEFInd on it and pray that it picks up on
> > everything automatically and fix the situation. But so should Grub have,
> > besides the fact that I can't even be entirely sure Grub is to blame and
> > not something else.

-- 
Joel Roth

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I have kept the referral to the old problem in the topic for a reason. Been
there, done that. I'm not entirely sure how, but boot-repair was the only
thing that was able to fix Grub. Before that I've reinstalled it countless
times, thanks.

But since this is very much not an answer to the question at hand, but to
the original question - and as such an entirely different topic - I'm
rewriting this to the old topic too.

On Thu, Jan 4, 2024, 02:12 Jeffrey Walton  wrote:

> On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner 
> wrote:
> >
> > So, since for whatever reason Grub seems to be broken beyond repair,
>
> I seriously doubt this is the case. I'm guessing the problem lies
> elsewhere.
>
> > I today tried to just replace it with rEFInd. Installation succeeded
> without any trouble. But when I start my system, rEFInd just asks me if I
> want to boot with fwupd or with the still very broken Grub. Am I missing
> something? Is rEFInd really just something to select between different OSs
> (and not just different distributions like Grub can very well do) and then
> gives the rest over to their bootloaders or am I missing something so
> rEFInd will take over all of Grubs jobs?
>
> The rEFInd website is at . I'm
> guessing you have not taken time to read about it based on your
> questions.
>
> Jeff
>
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

Wow, what a bunch of unhelpful comments.

First, if it wasn't for Eddie recommending boot-repair, "broken beyond
repair" in fact was the very fitting term.

Second, have you maybe considered that I've already read the home page of
rEFInd and came to the same conclusion? Besides the fact that the page is
virtually unreadable - both from a visual and a content point of view - I
have yet to find anything indicating what it is actually capable of and
what not. Because as far as I can tell, it should be able to do what I want
it to do.

So please, if you don't have anything to add other than snarky remarks,
just don't answer.

On Thu, Jan 4, 2024, 02:12 Jeffrey Walton  wrote:

> On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner 
> wrote:
> >
> > So, since for whatever reason Grub seems to be broken beyond repair,
>
> I seriously doubt this is the case. I'm guessing the problem lies
> elsewhere.
>
> > I today tried to just replace it with rEFInd. Installation succeeded
> without any trouble. But when I start my system, rEFInd just asks me if I
> want to boot with fwupd or with the still very broken Grub. Am I missing
> something? Is rEFInd really just something to select between different OSs
> (and not just different distributions like Grub can very well do) and then
> gives the rest over to their bootloaders or am I missing something so
> rEFInd will take over all of Grubs jobs?
>
> The rEFInd website is at . I'm
> guessing you have not taken time to read about it based on your
> questions.
>
> Jeff
>
>

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Timothy M Butterworth]

On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner 
wrote:

> So, since for whatever reason Grub seems to be broken beyond repair,
>

I am not sure what you mean by "broken beyond repair." I have no issues
with Grub on Debian 12 on AMD64. I had no issues with Grub on Debian 11 or
Debian 10 on AMD64 either. I also had no issues upgrading from Debian 11 to
Debian 12. Is it possible that you simply have a corrupted hard drive and
simply need to reinstall from scratch?

You can download a Debian LiveCD for AMD64 from here:
https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/ you can
then boot with it and mount your drive and copy your home directory to a
USB portable drive. When you reinstall I would create a separate partition
for /home. That way in the future you can always reinstall and just tell
the system to mount the existing /home partition.


> I today tried to just replace it with rEFInd. Installation succeeded
> without any trouble. But when I start my system, rEFInd just asks me if I
> want to boot with fwupd or with the still very broken Grub. Am I missing
> something? Is rEFInd really just something to select between different OSs
> (and not just different distributions like Grub can very well do) and then
> gives the rest over to their bootloaders or am I missing something so
> rEFInd will take over all of Grubs jobs?
> On 01.01.24 21:45, Richard Rosner wrote:
>
>
> On 01.01.24 21:20, Richard Rosner wrote:
>
>
> On 01.01.24 20:30, David Wright wrote:
>
> On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
>
> On 01.01.24 18:13, David Wright wrote:
> I can boot by hand, but since this is all archived anyways and it's
> uneccessarily difficult to find some sort of guide how to even do
> this, it might as well be a documentation for users having such
> troubles in the future.
>
> Also, besides the way that I have no clue how it would have to look
> like to set up a paragraph in the grub.cfg, I simply don't see
> anything wrong with it anyways. So I can't even look at the grub
> settings files grub.cfg is being generated from to check where the
> error lies.
>
> You append the commands that you used to boot manually with into
> /etc/grub.d/40_custom, observing the comments there, and also into
> grub.cfg itself at the appropriate place (near the bottom). The
> former is so that Grub includes it in any new grub.cfg that you
> create.
>
> Good to know.
>
> Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS
> menu after entering my password. At this point, I'm seriously considering
> slapping rEFInd on it and pray that it picks up on everything automatically
> and fix the situation. But so should Grub have, besides the fact that I
> can't even be entirely sure Grub is to blame and not something else.
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Jeffrey Walton]

On Wed, Jan 3, 2024 at 2:24 PM Richard Rosner  wrote:
>
> So, since for whatever reason Grub seems to be broken beyond repair,

I seriously doubt this is the case. I'm guessing the problem lies elsewhere.

> I today tried to just replace it with rEFInd. Installation succeeded without 
> any trouble. But when I start my system, rEFInd just asks me if I want to 
> boot with fwupd or with the still very broken Grub. Am I missing something? 
> Is rEFInd really just something to select between different OSs (and not just 
> different distributions like Grub can very well do) and then gives the rest 
> over to their bootloaders or am I missing something so rEFInd will take over 
> all of Grubs jobs?

The rEFInd website is at . I'm
guessing you have not taken time to read about it based on your
questions.

Jeff

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

Thanks, this actually did the job. I don't know what it was, but my 
guess is it was the step "purge Grub before reinstalling it".



PS: rewrote to the old subject, as this is clearly an answer to the 
original problem, as it doesn't have anything to do with replacing Grub 
all together.


On 03.01.24 21:04, Eddie wrote:
I have had very good results using "Boot-Repair" software to recover 
Grub difficulties.


Eddie

On 1/3/24 14:23, Richard Rosner wrote:
So, since for whatever reason Grub seems to be broken beyond repair, 
I today tried to just replace it with rEFInd. Installation succeeded 
without any trouble. But when I start my system, rEFInd just asks me 
if I want to boot with fwupd or with the still very broken Grub. Am I 
missing something? Is rEFInd really just something to select between 
different OSs (and not just different distributions like Grub can 
very well do) and then gives the rest over to their bootloaders or am 
I missing something so rEFInd will take over all of Grubs jobs?

Re: Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Eddie]

I have had very good results using "Boot-Repair" software to recover 
Grub difficulties.


Eddie

On 1/3/24 14:23, Richard Rosner wrote:
So, since for whatever reason Grub seems to be broken beyond repair, I 
today tried to just replace it with rEFInd. Installation succeeded 
without any trouble. But when I start my system, rEFInd just asks me if 
I want to boot with fwupd or with the still very broken Grub. Am I 
missing something? Is rEFInd really just something to select between 
different OSs (and not just different distributions like Grub can very 
well do) and then gives the rest over to their bootloaders or am I 
missing something so rEFInd will take over all of Grubs jobs?

Replace Grub with rEFInd [WAS Possibly broken Grub or initrd after updates on Testing]

[Richard Rosner]

So, since for whatever reason Grub seems to be broken beyond repair, I 
today tried to just replace it with rEFInd. Installation succeeded 
without any trouble. But when I start my system, rEFInd just asks me if 
I want to boot with fwupd or with the still very broken Grub. Am I 
missing something? Is rEFInd really just something to select between 
different OSs (and not just different distributions like Grub can very 
well do) and then gives the rest over to their bootloaders or am I 
missing something so rEFInd will take over all of Grubs jobs?


On 01.01.24 21:45, Richard Rosner wrote:



On 01.01.24 21:20, Richard Rosner wrote:


On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.
Edit:, never mind. Tried that, it still booted straight to the UEFI 
BIOS menu after entering my password. At this point, I'm seriously 
considering slapping rEFInd on it and pray that it picks up on 
everything automatically and fix the situation. But so should Grub 
have, besides the fact that I can't even be entirely sure Grub is to 
blame and not something else.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 01.01.24 21:20, Richard Rosner wrote:


On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.
Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS 
menu after entering my password. At this point, I'm seriously 
considering slapping rEFInd on it and pray that it picks up on 
everything automatically and fix the situation. But so should Grub have, 
besides the fact that I can't even be entirely sure Grub is to blame and 
not something else.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.



This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4

The UUID of the first partition containing the EFI stuff is 3647-0C47,
the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1
with ext4 as it seems - why does Debian still not default to creating
LUKS2 by default anyways after 5 years?) and the swap partition has
b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1).

Because it could lock people out of their preexisting LUKS partitions.
I meant when you use the automated installer and wipe the whole disk 
anyways. There wouldn't be any preexisting LUKS partitions left that 
could be broken. Or can there not be LUKS1 and LUKS2 at the same time in 
the event that e.g. the device with the system on is LUKS2 and another 
device just containing data was LUKS1?



For me it looks like the grub.cfg has everything it needs to work.

Why do your linux lines have two root= strings?

No idea. I never really touched anything related to grub, besides the 
earlier mentioned tries to get some logs. Also, since it looks like 
there is no grub rescue mode installed (at least it's not being entered 
when it should) I did remove the comment in front of 
GRUB_DISABLE_RECOVER and set it to "false", just in case that for some 
reason it would default to true, thus not installing grub rescue. 
There's only one root in the /etc/default/grub.

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> On 01.01.24 18:13, David Wright wrote:
> > On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote:
> > > On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote:
> > > 
> > > > Like this?
> > > > 
> > > >   └─sda6  8:60 406.2G  0 
> > > > part
> > > > └─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 
> > > > crypt /home
> > > > 
> > > > That's groups of 8 4 4 4 12.
> > > Yes, exactly. Is there a way to show that from inside Grub? Lsblk and 
> > > blkid aren't available there?
> > I thought you could boot by hand. Then all the UUIDs are available
> > to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe
> > them into a 40_custom paragraph in grub.cfg so you can boot easily.
> > Then I would work on getting Grub to write its grub.cfg correctly.
> > In the meantime, 40_custom would stay put.
> > 
> I can boot by hand, but since this is all archived anyways and it's
> uneccessarily difficult to find some sort of guide how to even do
> this, it might as well be a documentation for users having such
> troubles in the future.
> 
> Also, besides the way that I have no clue how it would have to look
> like to set up a paragraph in the grub.cfg, I simply don't see
> anything wrong with it anyways. So I can't even look at the grub
> settings files grub.cfg is being generated from to check where the
> error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

> This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4
> 
> The UUID of the first partition containing the EFI stuff is 3647-0C47,
> the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1
> with ext4 as it seems - why does Debian still not default to creating
> LUKS2 by default anyways after 5 years?) and the swap partition has
> b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1).

Because it could lock people out of their preexisting LUKS partitions.

> For me it looks like the grub.cfg has everything it needs to work.

Why do your linux lines have two root= strings?

Cheers,
David.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I can boot by hand, but since this is all archived anyways and it's 
uneccessarily difficult to find some sort of guide how to even do this, 
it might as well be a documentation for users having such troubles in 
the future.


Also, besides the way that I have no clue how it would have to look like 
to set up a paragraph in the grub.cfg, I simply don't see anything wrong 
with it anyways. So I can't even look at the grub settings files 
grub.cfg is being generated from to check where the error lies.


This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4

The UUID of the first partition containing the EFI stuff is 3647-0C47, 
the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1 with 
ext4 as it seems - why does Debian still not default to creating LUKS2 
by default anyways after 5 years?) and the swap partition has 
b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1).


For me it looks like the grub.cfg has everything it needs to work.

On 01.01.24 18:13, David Wright wrote:

On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote:

On January 1, 2024 5:43:12 PM GMT+01:00, David Wright 
 wrote:


Like this?

  └─sda6  8:60 406.2G  0 part
└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt /home

That's groups of 8 4 4 4 12.

Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid 
aren't available there?

I thought you could boot by hand. Then all the UUIDs are available
to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe
them into a 40_custom paragraph in grub.cfg so you can boot easily.
Then I would work on getting Grub to write its grub.cfg correctly.
In the meantime, 40_custom would stay put.

Cheers,
David.

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote:
> On January 1, 2024 5:43:12 PM GMT+01:00, David Wright 
>  wrote:
> 
> >Like this?
> >
> >  └─sda6  8:60 406.2G  0 part  
> >└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt 
> > /home
> >
> >That's groups of 8 4 4 4 12.
> 
> Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid 
> aren't available there?

I thought you could boot by hand. Then all the UUIDs are available
to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe
them into a 40_custom paragraph in grub.cfg so you can boot easily.
Then I would work on getting Grub to write its grub.cfg correctly.
In the meantime, 40_custom would stay put.

Cheers,
David.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid 
aren't available there?

On January 1, 2024 5:43:12 PM GMT+01:00, David Wright 
 wrote:

>Like this?
>
>  └─sda6  8:60 406.2G  0 part  
>└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt 
> /home
>
>That's groups of 8 4 4 4 12.
>
>Cheers,
>David.
>

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Mon 01 Jan 2024 at 17:37:44 (+0100), Richard Rosner wrote:
> So, I found a way to manually mount luks partition in Grub and boot from it.
> 
> What I did to get there:
> set root=(hd0,gpt2)
> cryptomount -a
> 
> This gave me the unencrypted version of the root partition as (crypto1)
> 
> set root=(crypto1)
> linux /vmlinuz root=/dev/mapper/luks-UUID
> initrd /initrd.img
> boot
> 
> The problem only is to get the UUID format right. When you're asked to enter 
> the decryption key in a normal boot, it's shown, but without any dashes. But 
> the format must be the same eg Disks shows it. But sure if a Grub tool can 
> show that, but worst case you'll be booted into a initrd BusyBox terminal 
> where you can just look inside /dev/mapper and see the true path that needs 
> to be entered.
> 
> Question is, how do I repair the boot process so I don't have to boot by hand 
> every time?

Like this?

  └─sda6  8:60 406.2G  0 part  
└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt /home

That's groups of 8 4 4 4 12.

Cheers,
David.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

So, I found a way to manually mount luks partition in Grub and boot from it.

What I did to get there:
set root=(hd0,gpt2)
cryptomount -a

This gave me the unencrypted version of the root partition as (crypto1)

set root=(crypto1)
linux /vmlinuz root=/dev/mapper/luks-UUID
initrd /initrd.img
boot

The problem only is to get the UUID format right. When you're asked to enter 
the decryption key in a normal boot, it's shown, but without any dashes. But 
the format must be the same eg Disks shows it. But sure if a Grub tool can show 
that, but worst case you'll be booted into a initrd BusyBox terminal where you 
can just look inside /dev/mapper and see the true path that needs to be entered.

Question is, how do I repair the boot process so I don't have to boot by hand 
every time?


On January 1, 2024 12:52:40 PM GMT+01:00, Richard Rosner 
 wrote:
>I do not see an answer to my questions.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I do not see an answer to my questions.

> On Jan 1, 2024, at 11:52, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> 
> On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner):
>> I'm not sure what you meant with "rescue mode", but I've reinstalled
>> grub anyways. The log of it doesn't look good though. Quite a bunch
>> of errors. The result also is the same.
> 
> Please review the posts in the thread starting on Dec 21 2023 14:25:26
> UTC, 
> https://lists.debian.org/msgid-search/254ebb90-9a49-4b5a-b1d6-e41b51d8a...@columbus.rr.com
> 
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
> 

Re: Possibly broken Grub or initrd after updates on Testing

[Michael Kjörling]

On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner):
> I'm not sure what you meant with "rescue mode", but I've reinstalled
> grub anyways. The log of it doesn't look good though. Quite a bunch
> of errors. The result also is the same.

Please review the posts in the thread starting on Dec 21 2023 14:25:26
UTC, 
https://lists.debian.org/msgid-search/254ebb90-9a49-4b5a-b1d6-e41b51d8a...@columbus.rr.com

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

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I'm not sure what you meant with "rescue mode", but I've reinstalled grub 
anyways. The log of it doesn't look good though. Quite a bunch of errors. The 
result also is the same.

https://pastes.io/nvmlsxghlm


> On Jan 1, 2024, at 11:03, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> 
> On 1 Jan 2024 09:16 +0100, from rich...@rosner-online.de (Richard Rosner):
>> could you please check if you received either of my two tries to get
>> this answer through the mailing list?
> 
> I did not. Maybe they are held for moderation due to size?
> 
> Next time, you can check for yourself at either
> https://lists.debian.org/debian-user/recent or at
> https://lists.debian.org/debian-user/ under the "archives" heading.
> There's also a search there. If a message is not in the archive after
> one or two archive refreshes, it probably didn't make it through the
> list for whatever reason there may be.
> 
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
> 

Re: Possibly broken Grub or initrd after updates on Testing

[Michael Kjörling]

On 29 Dec 2023 23:29 +0100, from rich...@rosner-online.de (Richard Rosner):
> For a fraction of a second it shows something about slot 0 open, that's it.

Well, that means that GRUB at least succeeds in opening the LUKS
container. That's good; it means that we can rule out that part of the
chain as the cause of your problems, as well as everything before it.

I still don't have any good idea what might cause GRUB to simply
reboot, though. Normally, if there is a critical problem, GRUB will
drop you to a built-in Unix-esque command-line interface with a
"grub>" prompt.

You do mention that you regenerated the initrd, but the initrd doesn't
really figure into GRUB; it comes into play after the kernel is loaded
into memory, which itself happens past the boot menu which you don't
get to. I know it likely won't point you toward what the actual
problem is, but I would suggest booting off live media (a Debian
installer written to a USB stick and running in rescue mode should
do), unlock/mount/chroot/shell into your root file system, and run
`grub-install -v --no-nvram --recheck` (possibly with additional
parameters; see grub-install(8) for details) from there to reinstall
the boot loader itself.

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

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

As far as I can tell, /boot and /boot/grub are the same filesystem. After all, 
I didn't really do anything custom. Just your default LUKS installation with 
the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted swap on 
3.

I did make a video. Nothing that's not showing up always. For a fraction of a 
second it shows something about slot 0 open, that's it.

> On Dec 29, 2023, at 20:37, Richard Rosner  wrote:
> 
> As far as I can tell, /boot and /boot/grub are the same filesystem. After 
> all, I didn't really do anything custom. Just your default LUKS installation 
> with the boot efi stuff on sda1/sdb1/whatever, LUKS on 2 and LUKS encrypted 
> swap on 3.
> 
> I did make a video. Nothing that's not showing up always. For a fraction of a 
> second it shows something about slot 0 open, that's it.
> 
>> On Dec 29, 2023, at 20:13, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
>> 
>> On 29 Dec 2023 18:56 +0100, from rich...@rosner-online.de (Richard Rosner):
>>> Hey, I have quite the strange issue. After updating a bunch of
>>> packages today [1], mostly related to systemd, gstreamer and udev,
>>> and restarting my device, it no longer boots. I have an encrypted
>>> system. So I do get asked for my decryption password as usual, but a
>>> few seconds later, instead of continuing to the Grub boot menu, my
>>> device simply reboots to the BIOS menu.
>> 
>> Sounds to me very much like GRUB is having trouble finding or reading
>> critical files under /boot/grub, and gives up for that reason. But it
>> _should_ stop, not reboot, if that's the case.
>> 
>>> From what you describe, it sounds like you use a LUKS-encrypted /boot.
>> Is that correct? Also, please confirm that the contents of /boot/grub
>> are located on the same file system as the contents of /boot (that is,
>> that /boot/grub is not on its own file system).
>> 
>> You probably already know this, but the GRUB LUKS passphrase prompt is
>> very early stage.
>> 
>> Have you tried making a video recording of the screen from when you
>> press Enter at the passphrase prompt, to when it reboots, and then go
>> through that carefully (frame by frame)? Maybe GRUB _does_ print
>> something indicating what the actual problem is, but it reboots so
>> quickly after that that you don't have time to see it. A video might
>> capture that fraction-of-a-second display (even if only partially) and
>> help point you in the right direction.
>> 
>> --
>> Michael Kjörling  https://michael.kjorling.se
>> “Remember when, on the Internet, nobody cared that you were a dog?”
>> 

Re: Possibly broken Grub or initrd after updates on Testing

[Michael Kjörling]

On 29 Dec 2023 18:56 +0100, from rich...@rosner-online.de (Richard Rosner):
> Hey, I have quite the strange issue. After updating a bunch of
> packages today [1], mostly related to systemd, gstreamer and udev,
> and restarting my device, it no longer boots. I have an encrypted
> system. So I do get asked for my decryption password as usual, but a
> few seconds later, instead of continuing to the Grub boot menu, my
> device simply reboots to the BIOS menu.

Sounds to me very much like GRUB is having trouble finding or reading
critical files under /boot/grub, and gives up for that reason. But it
_should_ stop, not reboot, if that's the case.

>From what you describe, it sounds like you use a LUKS-encrypted /boot.
Is that correct? Also, please confirm that the contents of /boot/grub
are located on the same file system as the contents of /boot (that is,
that /boot/grub is not on its own file system).

You probably already know this, but the GRUB LUKS passphrase prompt is
very early stage.

Have you tried making a video recording of the screen from when you
press Enter at the passphrase prompt, to when it reboots, and then go
through that carefully (frame by frame)? Maybe GRUB _does_ print
something indicating what the actual problem is, but it reboots so
quickly after that that you don't have time to see it. A video might
capture that fraction-of-a-second display (even if only partially) and
help point you in the right direction.

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

Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

Hey, I have quite the strange issue. After updating a bunch of packages today 
[1], mostly related to systemd, gstreamer and udev, and restarting my device, 
it no longer boots. I have an encrypted system. So I do get asked for my 
decryption password as usual, but a few seconds later, instead of continuing to 
the Grub boot menu, my device simply reboots to the BIOS menu.

It's not the first time I ran into such an issue. I did once after manually 
updating initrd because Grub wouldn't offer to boot the 6.5.0-4 kernel because 
of malformed grub.cfg. The solution was kinda simple. Boot into a life system, 
mount the encrypted system according to [2], find out the guide was either 
outdated or not suitable for updating initrd, find a fix, recreate initrd again 
and done.

Sadly, this time that solution won't help. Also I can't find any way to get a 
log of which troubles Grub runs into that it can't continue the boot process. I 
tried getting Grub to write logs to the system by modifying 
GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub by removing quite and splash 
and adding loglevel=7 (and update-grub), but nothing is written, probably 
because for some reason Grub can't really decrypt the system.

So, how do I even find out what's wrong? I'm not familiar with the Grub cmd, I 
have no idea how to get it to tell me what's wrong to even start finding a 
solution. Anybody knows more?

[1]:
Start-Date: 2023-12-28 19:40:04

Upgrade: udev:amd64 (254.5-1, 255.2-2), acl:amd64 (2.3.1-3+b1, 2.3.1-4), 
wpasupplicant:amd64 (2:2.10-20, 2:2.10-21), libacl1:amd64 (2.1.1-3-61, 
2.3.1-4), libarmadillo12:amd64 (1:12.6.4+dfsg-1, 1:12.6.7±dfsg-1), 
libpam-systemd:amd64 (254.5-1, 255.2-2), libp11-kit0:amd64 (0.25.3-2, 
0.25.3-4), libp11-kit0:i386 (0.25.3-2.6.25.3-4), libsonic0:amd64 (0.2.0-12, 
0.2.0-13), libinput10:amd64 (1.23.0-2, 1.23.0-2.1), libsystemd0:amd64 (254.5-1, 
255.2-2), libsystend0:i386 (254.5-1. 255.2-2), pandoc-data:amd64 (3.0.1-3, 
3.0.1-4), libudev-dev:amd64 (254.5-1, 255.2-2), systemd:amd64 (254.5-1, 
255.2-2), libudev1:amd64 (254.5-1, 255.2-2), libudev1:i386 (254.5-1, 255-2-2), 
p11-kit-modules:amd64 (0.25.3-2, 0.25.3-4), python3-wxgtk4.0:amd64 
(4.2.1+dfsg-2, 4.2.1-dfsg-3), gstreamer1.0-gtk3:amd64 (1.22.7-1, 1.22.8-3), 
gstreamer1.0-plugins-good:amd64 (1.22,7-1, 1-22-83-3),  
gstreamer1.0-plugins-good:i386 (1.22.7-1, 1.22.8-3), libcap-ng0:amd64 (0.8.3-3, 
0.8.4-1), mdamd:amd64 (4.2+20231026-1, 4.2+20231121-1), libinput-tools:amd64 
(1.23.0-2, 1.23.0-2.1), libsystemd-shared:amd64 (254.5-1, 255.2-2), 
libattr1:amd64 (1:2.5.1-4+b1, 1:2.5.1-5), cpio:amd64 (2.13+dfsg-7.1, 
2.14+dfsg-1), gstreamer1.0-pulseaudio:amd64 (1:22.7-1, 1.22.8-3), 
libsystemd-dev:amd64 (254.5-1, 255.2-2), p11-kit:amd64 (0.25.3-2, 0.25.3-4), 
libinput-bin:amd64 (1.23.0-2, 1.23.0-2.1)

End-Date: 2023-12-28 19:45:40



[2]: https://wiki.debian.org/GrubEFIReinstall 

Debian 12 Gnome - No notification for available updates

[Yvan Masson]

Hi Debian users,

I have a computer running Gnome 43.6 that does not show notification 
when updates are available. It was working a few months ago, but can not 
tell when it stops working.


Questions:
- How can I bring back available update notifications?
- Do you think it deserves a bug report on Debian bugtracker or upstream?

Some details:

- The computer was installed with Debian 11 and manually upgraded to 
Debian 12, and currently runs Gnome Software 43.5-1~deb12u1.
- I confirm that /usr/bin/gnome-software --gapplication-service is 
started automatically when I open a session, which in turn runs 
PacakeKit to get update information (as seen with pkmon).

- apt list --upgradable lists many available updates.
- I do not use a metered connection.
- I do not have any fancy settings in dconf (I only disable automatic 
download):


$ dconf dump /org/gnome/software/
[/]
check-timestamp=int64 1691236134 => Sat Aug  5 13:48:54 CEST 2023
download-updates=false
first-run=false
install-timestamp=int64 1661718901 => Sun Aug 28 22:35:01 CEST 2022
online-updates-timestamp=int64 1675285379 => Wed Feb  1 22:02:59 CET 2023
update-notification-timestamp=int64 1698304770 => Thu Oct 26 09:19:30 
CEST 2023


- When I start Gnome Software, it displays the number of updates on the top.
- Notifications are enabled:

$ dconf dump 
/org/gnome/desktop/notifications/application/org-gnome-software/

[/]
application-id='org.gnome.Software.desktop'
enable=true

- I have just created a new user on the machine, member of the sudo 
group, but it does not get any notification either (but updates are 
automatically downloaded)


Regards,
Yvan


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: proposed updates

[Paul van der Vlis]

Hoi Gijs,

Op 04-08-2023 om 16:44 schreef Gijs Hillenius:

On  4 August 2023 15:03 Paul van der Vlis, wrote:


Hoi Gijs,

Op 04-08-2023 om 10:34 schreef Gijs Hillenius:

De handleiding:
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#proposed-updates
4.2.9. The proposed-updates section
If you have listed the proposed-updates section in your APT
source-list
files, you should remove it before attempting to upgrade your system.
This is a precaution to reduce the likelihood of conflicts.


Nu heb je het over proposed-updates, en niet over release-updates.
"Proposed" betekent "voorgesteld", proposed-updates is bedoeld om de
updates te testen voordat ze gereleased worden.


Right. Dank.

hier

https://wiki.debian.org/StableUpdates

staat:

"All packages from stable-updates will be included in point releases."

en

"This path will be used for updates which many users may wish to install
on their systems before the next point release is made, such as updates
to virus scanners and timezone data."


Ik vind dit wat onduidelijk moet ik zeggen.

Ik heb zelf nooit proposed-updates gebruikt om die reden, ik vind 
stable-updates genoeg, en proposed-updates meer een testplatform 
daarvoor. Maar misschien denken anderen daar anders over.


Bedenk dat het ook om updates van de virusscanner zelf gaat, niet om de 
virusdefinities, die gaan apart.



Dat klinkt niet alsof dit gaat om "cyrus-imap met een majeure update".


Ik weet niet zo goed wat je bedoeld met "majeure update".

Dit was duidelijk geen security update maar een "andere belangrijke 
kleine update". Ik zie bij Debian langzaam een tendens dat er meer 
kleine wijzigingen komen via stable-updates, dit is daar een voorbeeld van.


Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: proposed updates

[Gijs Hillenius]

On  4 August 2023 15:03 Paul van der Vlis, wrote:

> Hoi Gijs,
>
> Op 04-08-2023 om 10:34 schreef Gijs Hillenius:
>> De handleiding:
>> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#proposed-updates
>> 4.2.9. The proposed-updates section
>> If you have listed the proposed-updates section in your APT
>> source-list
>> files, you should remove it before attempting to upgrade your system.
>> This is a precaution to reduce the likelihood of conflicts.
>
> Nu heb je het over proposed-updates, en niet over release-updates.
> "Proposed" betekent "voorgesteld", proposed-updates is bedoeld om de
> updates te testen voordat ze gereleased worden.

Right. Dank.

hier

https://wiki.debian.org/StableUpdates 

staat:

"All packages from stable-updates will be included in point releases."

en

"This path will be used for updates which many users may wish to install
on their systems before the next point release is made, such as updates
to virus scanners and timezone data."

Dat klinkt niet alsof dit gaat om "cyrus-imap met een majeure update".



-- 
He who loses, wins the race,
And parallel lines meet in space.
-- John Boyd, "Last Starship from Earth"

Re: proposed updates (was: Debian Bookworm en Cyrus? Stap nog ff niet over)

[Paul van der Vlis]

Hoi Gijs,

Op 04-08-2023 om 10:34 schreef Gijs Hillenius:


De handleiding:

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#proposed-updates

4.2.9. The proposed-updates section

If you have listed the proposed-updates section in your APT source-list
files, you should remove it before attempting to upgrade your system.
This is a precaution to reduce the likelihood of conflicts.


Nu heb je het over proposed-updates, en niet over release-updates. 
"Proposed" betekent "voorgesteld", proposed-updates is bedoeld om de 
updates te testen voordat ze gereleased worden.


Groet,
Paul



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

proposed updates (was: Debian Bookworm en Cyrus? Stap nog ff niet over)

[Gijs Hillenius]

De handleiding:

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#proposed-updates

4.2.9. The proposed-updates section

If you have listed the proposed-updates section in your APT source-list
files, you should remove it before attempting to upgrade your system.
This is a precaution to reduce the likelihood of conflicts.


-- 
In the stairway of life, you'd best take the elevator.

Re: laptop stopped getting to desktop after latest updates [RESOLVED]

[Gary Dale]

On 2023-05-19 23:32, Gary Dale wrote:
I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD 
Ryzen processor but an NVidia graphics card that provides me with 
great evidence for why I had previously avoided NVidia cards. I'm 
running Bookworm because I couldn't get it work on Bullseye.


It'd been running OK with the proprietary drivers (but not the 
Nouveau) until earlier today. I don't use it very often so it was 
probably a few weeks since I last updated it. I had trouble the 
previous time I'd updated it too, but that was the move to the 
non-free-firmware section that messed it up. Once I added the new 
section to the sources, things worked again.


The symptoms I'm getting are the same as what it used to display when 
I tried to use sddm to start the desktop. Gdm3 and lightdm both worked 
in the past but now I'm getting the same symptom with all of them - a 
blank screen with a cursor flashing in the top-left corner. At that 
point I can't even bring up a text console, but I can reboot 
(ctrl-alt-del still works).


I can boot to a recovery mode and start the network, but not sure how 
to track this down. Removing and reinstalling the NVidia driver didn't 
help. Trying to start the desktop without the NVidia driver (and 
firmware) installed also didn't work. I still get the system booting 
to a blank screen with a flashing cursor in the top let corner.


Any ideas?

Thanks.

I got some time this afternoon to play around with the system. My first 
effort was to go back to Debian/Bullseye (11.7) and do a fresh install. 
Surprisingly, it worked this time. I could boot into Gnome without 
problems. However I had no wifi. Changing to sddm however led to failure 
to reach a login screen. Installing lightdm let me select Plasma 5 
however. This is all with the Nouveau drivers.


However the wifi issue needed to be resolved. It turns out there are 
working (non-free) drivers available but they require a more recent 
kernel. I added bullseye-backports and installed the newer kernel and 
firmware-misc-non-free. This led to a failure to reach a login screen 
(in fact, the boot appears to hang after producing about 4 lines of 
output but booting to recovery mode let me see that it failed loading 
the Nouveau drivers).


Installing the nvidia-driver allowed the system to reach a graphical 
login but the system was not very stable. The difference in kernel 
versions was giving me a lot of errors so I tried to upgrade completely 
to Bookworm. That got me back to the point I was at when I first posted 
my original problem. I couldn't get to a working graphical login.


This led me back to the Debian site to download the latest Bookworm 
installer. The RC3 netinst is problematic - it didn't recognize my /home 
partition as formatted and ended up wiping it out. And when I rebooted 
into the installed system, it left me at a grub prompt. But when I 
rebooted and selected the boot partition manually through the BIOS, I 
was able to boot into the system. I ran update-grub and it's now booting 
properly.


Surprisingly, I was even able to switch to sddm and get into Plasma 5 
(Wayland!), all while using the Nouveau drivers. And wifi just worked!

Re: laptop stopped getting to desktop after latest updates

[Gary Dale]

Share with the Debian community
the X server logs  of "Debian" and "systemrescuecd".


Groeten
Geert Stappers


First is the log from a session that failed. Below is a log from a 
previous session that worked. Sorry, didn't get one from a 
systemrescuecd session - I thought I'd copied it to a network share but 
now I can't find it...



[    15.585]
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[    15.585] Current Operating System: Linux Aspect23 6.1.0-9-amd64 #1 
SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64
[    15.585] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=9562e6ee-0942-46a6-abdd-2e3a1a3a80bb ro quiet

[    15.585] xorg-server 2:21.1.7-3 (https://www.debian.org/support)
[    15.585] Current version of pixman: 0.42.2
[    15.585]     Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[    15.585] Markers: (--) probed, (**) from config file, (==) default 
setting,

    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    15.585] (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 22 
12:43:47 2023

[    15.585] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    15.585] (==) No Layout section.  Using the first Screen section.
[    15.585] (==) No screen section available. Using defaults.
[    15.585] (**) |-->Screen "Default Screen Section" (0)
[    15.585] (**) |   |-->Monitor ""
[    15.585] (==) No monitor specified for screen "Default Screen Section".
    Using a default monitor configuration.
[    15.585] (==) Automatically adding devices
[    15.585] (==) Automatically enabling devices
[    15.585] (==) Automatically adding GPU devices
[    15.585] (==) Automatically binding GPU devices
[    15.585] (==) Max clients allowed: 256, resource mask: 0x1f
[    15.585] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[    15.585]     Entry deleted from font path.
[    15.585] (==) FontPath set to:
    /usr/share/fonts/X11/misc,
    /usr/share/fonts/X11/100dpi/:unscaled,
    /usr/share/fonts/X11/75dpi/:unscaled,
    /usr/share/fonts/X11/Type1,
    /usr/share/fonts/X11/100dpi,
    /usr/share/fonts/X11/75dpi,
    built-ins
[    15.585] (==) ModulePath set to "/usr/lib/xorg/modules"
[    15.585] (II) The server relies on udev to provide the list of input 
devices.
    If no devices become available, reconfigure udev or disable 
AutoAddDevices.

[    15.585] (II) Loader magic: 0x55b923332f00
[    15.585] (II) Module ABI versions:
[    15.585]     X.Org ANSI C Emulation: 0.4
[    15.585]     X.Org Video Driver: 25.2
[    15.585]     X.Org XInput driver : 24.4
[    15.585]     X.Org Server Extension : 10.0
[    15.586] (++) using VT number 7

[    15.586] (II) systemd-logind: logind integration requires -keeptty 
and -keeptty was not provided, disabling logind integration

[    15.586] (II) xfree86: Adding drm device (/dev/dri/card0)
[    15.586] (II) Platform probe for 
/sys/devices/pci:00/:00:01.1/:01:00.0/drm/card0
[    15.589] (--) PCI: (1@0:0:0) 10de:25a2:1043:16ad rev 161, Mem @ 
0xfb00/16777216, 0xfe/4294967296, 0xff/33554432, I/O 
@ 0xf000/128, BIOS @ 0x/524288
[    15.589] (--) PCI:*(6@0:0:0) 1002:1636:1043:16ad rev 198, Mem @ 
0xff1000/268435456, 0xff2000/2097152, 0xfc50/524288, I/O @ 
0xd000/256

[    15.589] (II) LoadModule: "glx"
[    15.589] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    15.590] (II) Module glx: vendor="X.Org Foundation"
[    15.590]     compiled for 1.21.1.7, module version = 1.0.0
[    15.590]     ABI class: X.Org Server Extension, version 10.0
[    15.590] (II) Applying OutputClass "nvidia" to /dev/dri/card0
[    15.590]     loading driver: nvidia
[    15.712] (==) Matched nvidia as autoconfigured driver 0
[    15.712] (==) Matched nouveau as autoconfigured driver 1
[    15.712] (==) Matched nv as autoconfigured driver 2
[    15.712] (==) Matched ati as autoconfigured driver 3
[    15.712] (==) Matched modesetting as autoconfigured driver 4
[    15.712] (==) Matched fbdev as autoconfigured driver 5
[    15.712] (==) Matched vesa as autoconfigured driver 6
[    15.712] (==) Assigned the driver to the xf86ConfigLayout
[    15.712] (II) LoadModule: "nvidia"
[    15.712] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[    15.713] (II) Module nvidia: vendor="NVIDIA Corporation"
[    15.713]     compiled for 1.6.99.901, module version = 1.0.0
[    15.713]     Module class: X.Org Video Driver
[    15.713] (II) LoadModule: "nouveau"
[    15.713] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[    15.713] (II) Module nouveau: vendor="X.Org Foundation"
[    15.713]     compiled for 1.21.1.3, module version = 1.0.17
[    15.713]     Module class: X.Org Video Driver
[    15.713]     ABI class: X.Org Video Driver, version 25.2
[    15.713] (II) LoadModule: "nv"
[    15.713] 

Re: laptop stopped getting to desktop after latest updates

[Timothy M Butterworth]

On Mon, May 22, 2023 at 12:36 AM  wrote:

> On Sun, May 21, 2023 at 03:16:56PM -0400, Gary Dale wrote:
>
> [...]
>
> > I purged lightdm, rebooted and re-installed it but got the same errors.
> >
> > I don't believe this is a problem with lightdm because it is also
> happening
> > with gdm3 and sddm [...]
>
> Right: most probably it is the X server failing. The display manager
> (whichever one) will try to talk to X and fail consequently.
>
> Cheers
> --
> t
>

Try switching to terminal 2 `Ctrl, Alt amd F2` login as root and run startx
and see what messages you receive.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: laptop stopped getting to desktop after latest updates

[tomas]

On Sun, May 21, 2023 at 03:16:56PM -0400, Gary Dale wrote:

[...]

> I purged lightdm, rebooted and re-installed it but got the same errors.
> 
> I don't believe this is a problem with lightdm because it is also happening
> with gdm3 and sddm [...]

Right: most probably it is the X server failing. The display manager
(whichever one) will try to talk to X and fail consequently.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: laptop stopped getting to desktop after latest updates

[Geert Stappers]

On Sun, May 21, 2023 at 03:16:56PM -0400, Gary Dale wrote:
> On 2023-05-19 23:32, Gary Dale wrote:
> > I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD
> > Ryzen processor but an NVidia graphics card that provides me with great
> > evidence for why I had previously avoided NVidia cards. I'm running
> > Bookworm because I couldn't get it work on Bullseye.
> > 
> > It'd been running OK with the proprietary drivers (but not the Nouveau)
> > until earlier today. I don't use it very often so it was probably a few
> > weeks since I last updated it. I had trouble the previous time I'd
> > updated it too, but that was the move to the non-free-firmware section
> > that messed it up. Once I added the new section to the sources, things
> > worked again.
> > 
> > The symptoms I'm getting are the same as what it used to display when I
> > tried to use sddm to start the desktop. Gdm3 and lightdm both worked in
> > the past but now I'm getting the same symptom with all of them - a blank
> > screen with a cursor flashing in the top-left corner. At that point I
> > can't even bring up a text console, but I can reboot (ctrl-alt-del still
> > works).
> > 
> > I can boot to a recovery mode and start the network, but not sure how to
> > track this down. Removing and reinstalling the NVidia driver didn't
> > help. Trying to start the desktop without the NVidia driver (and
> > firmware) installed also didn't work. I still get the system booting to
> > a blank screen with a flashing cursor in the top let corner.
> > 
> > Any ideas?

Yes,


> Further to above, I purged the nVidia drivers then noticed that there was
> still some nVidia stuff left (e.g. nvidia-persistence) so I did a further
> purge. When I rebooted, the system stalled initially after a couple of ACPI
> errors (there were only those lines on the screen - it was barely starting)
> but a ctrl-alt-del later and it got all the way to starting the nouveau
> drivers before stalling.
> 
> I reinstalled the nVidia drivers and was back to the same problem. Rebooting
> to recovery mode and checking the journal for the previous boot, there were
> a string of errors relating to lightdm failing to start, followed by retry
> and the same error.
> 
> I purged lightdm, rebooted and re-installed it but got the same errors.
> 
> I don't believe this is a problem with lightdm because it is also happening
> with gdm3 and sddm. The only difference is that its been happening with sddm
> since I got the laptop last November whereas the problem with lightdm and
> gdm3 is much more recent.
> 
> I can run the system with the Nouveau drivers when booting from
> systemrescuecd (a couple of recent versions, including 10.0), so this is a
> Debian issue.

Share with the Debian community
the X server logs  of "Debian" and "systemrescuecd".


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: laptop stopped getting to desktop after latest updates

[Gary Dale]

On 2023-05-19 23:32, Gary Dale wrote:
I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD 
Ryzen processor but an NVidia graphics card that provides me with 
great evidence for why I had previously avoided NVidia cards. I'm 
running Bookworm because I couldn't get it work on Bullseye.


It'd been running OK with the proprietary drivers (but not the 
Nouveau) until earlier today. I don't use it very often so it was 
probably a few weeks since I last updated it. I had trouble the 
previous time I'd updated it too, but that was the move to the 
non-free-firmware section that messed it up. Once I added the new 
section to the sources, things worked again.


The symptoms I'm getting are the same as what it used to display when 
I tried to use sddm to start the desktop. Gdm3 and lightdm both worked 
in the past but now I'm getting the same symptom with all of them - a 
blank screen with a cursor flashing in the top-left corner. At that 
point I can't even bring up a text console, but I can reboot 
(ctrl-alt-del still works).


I can boot to a recovery mode and start the network, but not sure how 
to track this down. Removing and reinstalling the NVidia driver didn't 
help. Trying to start the desktop without the NVidia driver (and 
firmware) installed also didn't work. I still get the system booting 
to a blank screen with a flashing cursor in the top let corner.


Any ideas?

Thanks.

Further to above, I purged the nVidia drivers then noticed that there 
was still some nVidia stuff left (e.g. nvidia-persistence) so I did a 
further purge. When I rebooted, the system stalled initially after a 
couple of ACPI errors (there were only those lines on the screen - it 
was barely starting) but a ctrl-alt-del later and it got all the way to 
starting the nouveau drivers before stalling.


I reinstalled the nVidia drivers and was back to the same problem. 
Rebooting to recovery mode and checking the journal for the previous 
boot, there were a string of errors relating to lightdm failing to 
start, followed by retry and the same error.


I purged lightdm, rebooted and re-installed it but got the same errors.

I don't believe this is a problem with lightdm because it is also 
happening with gdm3 and sddm. The only difference is that its been 
happening with sddm since I got the laptop last November whereas the 
problem with lightdm and gdm3 is much more recent.


I can run the system with the Nouveau drivers when booting from 
systemrescuecd (a couple of recent versions, including 10.0), so this is 
a Debian issue.

laptop stopped getting to desktop after latest updates

[Gary Dale]

I'm running Debian/Bookworm on an ASUS FA506IC laptop. It's got an AMD 
Ryzen processor but an NVidia graphics card that provides me with great 
evidence for why I had previously avoided NVidia cards. I'm running 
Bookworm because I couldn't get it work on Bullseye.


It'd been running OK with the proprietary drivers (but not the Nouveau) 
until earlier today. I don't use it very often so it was probably a few 
weeks since I last updated it. I had trouble the previous time I'd 
updated it too, but that was the move to the non-free-firmware section 
that messed it up. Once I added the new section to the sources, things 
worked again.


The symptoms I'm getting are the same as what it used to display when I 
tried to use sddm to start the desktop. Gdm3 and lightdm both worked in 
the past but now I'm getting the same symptom with all of them - a blank 
screen with a cursor flashing in the top-left corner. At that point I 
can't even bring up a text console, but I can reboot (ctrl-alt-del still 
works).


I can boot to a recovery mode and start the network, but not sure how to 
track this down. Removing and reinstalling the NVidia driver didn't 
help. Trying to start the desktop without the NVidia driver (and 
firmware) installed also didn't work. I still get the system booting to 
a blank screen with a flashing cursor in the top let corner.


Any ideas?

Thanks.

Re: XFCE updates

[tomas]

On Wed, Feb 22, 2023 at 10:20:39PM +, ghe2001 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I use XFCE4 for my GUI desktop, and I subscribe to XFCE's discussion list.  I 
> see lots of posts on the list about XFCE things being updated, but I run 
> stable, and I've been told to stick to only Debian updates.  What, if 
> anything, happens to the updates advertised by XFCE?  Do they go into Sid?  
> Testing?

I'd recommend [1] or, for the more technical description,
[2].

In a nutshell, software (major) versions don't change in
the stable distribution unless something very bad happens.
Maintainers prefer to backport security and other fixes
to the versions already there. This is what "stable" means.

As a corollary, interfaces between the different parts
stay more or less stable. One package update doesn't carry
a flurry of dependency updates after it.

The nice part of that is that you can, most of the time,
just "apt update && apt upgrade" without much risk.

You pay for that with somewhat older versions.

When some "upstream" (as Debian calls that: in your case
it would be XFCE) publishes a new version, that goes first
into sid. There it breaks other things (that's why it is
called sid). When it stops breaking things it goes into
testing.

At some point in time (called "freeze"), the stream of
packages from sid to testing is stopped: that's when the
new stable version is about to hatch from testing.

Once that is done, the stream from sid to the new testing
starts again.

That was a very rough map, possibly with some corners
cut.

Cheers
[1] https://www.debian.org/doc/manuals/debian-faq/choosing.en.html
[2] https://www.debian.org/releases/

-- 
t


signature.asc
Description: PGP signature

Re: XFCE updates

[Charles Curley]

On Wed, 22 Feb 2023 22:20:39 +
ghe2001  wrote:

> What, if anything, happens to the updates advertised by XFCE?  Do
> they go into Sid?  Testing?

Eventually. Debian seems to do things by the upstream release. Right
now, XFCE for Bookworm/testing is 4.18, Bullseye/stable 4.16.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

XFCE updates

[ghe2001]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I use XFCE4 for my GUI desktop, and I subscribe to XFCE's discussion list.  I 
see lots of posts on the list about XFCE things being updated, but I run 
stable, and I've been told to stick to only Debian updates.  What, if anything, 
happens to the updates advertised by XFCE?  Do they go into Sid?  Testing?

--
Glenn English
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAnBQJj9pUWCRDmyitW0WqrdxYhBMRG7aHlwXhPX67r9+bKK1bR
aqt3AACzFAf/eyO7uieWNeVxMV6A95Y0WHk+39UkMvDE9erx+LDHsQytZc8b
teCjLPijy2VcmJuXshJbsCVy13j6Z4yGM5abyPRy04WSfIIk58D+/2BZL39+
u4oKjBFidteK3uzR3yXtFNZSMtqtP/SF8Vc0fg5m/8QBo3l3KPRA0eBYUDp5
w3tAQNsqRaTIYG30t/XyyKy/j8e/ZfVh5MsyHjmS+sbpme1LzPlEYZvZmvqw
tGz3E+L7bYfuUt5mAxeieg4gCf/jGiB24M2G/dWDaPhrSSkxqobMumnDvXp6
TrowXVT7GBP+gePMU3PfN0T0CJOWnynrjRfQ71Z7ZzEdxRvmqymGJQ==
=Iu73
-END PGP SIGNATURE-

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Mon, Jan 30, 2023 at 12:59 PM Georgi Naplatanov  wrote:

> On 1/28/23 12:04, Timothy M Butterworth wrote:
> > All,
> >
> > I just upgraded to the 1/28/23 updates to KF5 102 and now I have no
> > audio devices found. My USB headset is plugged in but KDE does not see
> it.
> >
> > lsusb lists my USB headphones:
> > Bus 001 Device 009: ID 046d:0a37 Logitech, Inc. USB Headset H540
> >
> > lspci lists my audio devices
> > 04:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD]
> > ACP/ACP3X/ACP6x Audio Coprocessor (rev 01)
> > 04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h
> > HD Audio Controller
> >
> > This appears to be a KDE issue. Is anyone else having this problem?
> > Please note the problem started after installing KF5-102 and a reboot.
> >
>
> Hi Timothy!
>
> These are a few things to check
>
> - run alsamixer in console as your user and check that needed channels
> are not muted and volume levels are high enough
> - be sure that you use one of these - PulseAudio or PipeWire (not both)
>

I had PulseAudio and Pipewire installed. I uninstalled PipeWire and now my
sound cards show up again.

Thanks


> - chances for missing firmware are small for this device but Debian has
> a new section "non-free-firmware" so check output of dmesg command and
> in case of missing firmware you can add "non-free-firmware" to
> /etc/apt/sources.list (something like this)
>
> deb http://deb.debian.org/debian/ bookworm main non-free
> non-free-firmware contrib
>
> Files containing firmware files, you can find with "apt-file"
> package/command. Example:
>
> # apt-file search firware101.bin
>
> Kind regards
> Georgi
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Georgi Naplatanov]

On 1/28/23 12:04, Timothy M Butterworth wrote:

All,

I just upgraded to the 1/28/23 updates to KF5 102 and now I have no 
audio devices found. My USB headset is plugged in but KDE does not see it.


lsusb lists my USB headphones:
Bus 001 Device 009: ID 046d:0a37 Logitech, Inc. USB Headset H540

lspci lists my audio devices
04:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] 
ACP/ACP3X/ACP6x Audio Coprocessor (rev 01)
04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h 
HD Audio Controller


This appears to be a KDE issue. Is anyone else having this problem? 
Please note the problem started after installing KF5-102 and a reboot.




Hi Timothy!

These are a few things to check

- run alsamixer in console as your user and check that needed channels 
are not muted and volume levels are high enough

- be sure that you use one of these - PulseAudio or PipeWire (not both)
- chances for missing firmware are small for this device but Debian has 
a new section "non-free-firmware" so check output of dmesg command and 
in case of missing firmware you can add "non-free-firmware" to 
/etc/apt/sources.list (something like this)


deb http://deb.debian.org/debian/ bookworm main non-free 
non-free-firmware contrib


Files containing firmware files, you can find with "apt-file" 
package/command. Example:


# apt-file search firware101.bin

Kind regards
Georgi

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Sun, Jan 29, 2023 at 12:59 PM Brad Rogers  wrote:

> On Sun, 29 Jan 2023 12:11:33 -0500
> Timothy M Butterworth  wrote:
>
> Hello Timothy,
>
> >I did not try a new user. I did try deleting "~/.config/pulseaudio"
>
> Sorry to say, I've reached the limit of my knowledge on the subject.
> :-(
>
> --
>  Regards  _   "Valid sig separator is {dash}{dash}{space}"
>  / )  "The blindingly obvious is never immediately apparent"
> / _)rad   "Is it only me that has a working delete key?"
> All these things are mine!
> Money is Not Our God -  Killing Joke
>

sudo alsactl init
Found hardware: "HDA-Intel" "ATI R6xx HDMI"
"HDA:1002aa01,00aa0100,00100700" "0x103c" "0x87c5"
Hardware is initialized using a generic method
Found hardware: "USB-Audio" "USB Mixer" "USB046d:0a37" "" ""
Hardware is initialized using a generic method
Found hardware: "acp" "" "" "" ""
Hardware is initialized using a generic method

I also fixed alsa-state daemon.

sudo vim /lib/systemd/system/alsa-state.service, I know I should have put
this in /etc but I am not concerned at the moment.
added ! to ConditionPathExists
systemctl daemon-reload
systemctl restart alsa-state

sudo systemctl status  alsa-state
● alsa-state.service - Manage Sound Card State (restore and store)
Loaded: loaded (/lib/systemd/system/alsa-state.service; static)
Active: active (running) since Mon 2023-01-30 10:59:40 EST; 11min ago

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Brad Rogers]

On Sun, 29 Jan 2023 12:11:33 -0500
Timothy M Butterworth  wrote:

Hello Timothy,

>I did not try a new user. I did try deleting "~/.config/pulseaudio"

Sorry to say, I've reached the limit of my knowledge on the subject.
:-(

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
All these things are mine!
Money is Not Our God -  Killing Joke


pgpcVPMwvALzC.pgp
Description: OpenPGP digital signature

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Sun, Jan 29, 2023 at 12:11 PM Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> wrote:

>
>
> On Sun, Jan 29, 2023 at 7:55 AM Brad Rogers  wrote:
>
>> On Sun, 29 Jan 2023 07:22:02 -0500
>> Timothy M Butterworth  wrote:
>>
>> Hello Timothy,
>>
>> >I upgraded to 5.27beta so far no new issues. I just installed Wayland
>>
>> Good to know.  Thanks for the info.
>>
>> >so I can try it out. My sound cards are still not working though.
>>
>> Have you tried;
>>
>> (a) checking volume levels
>> because sometimes things get 'fiddled with' on update.
>>
>
> It is not a volume or a mute problem. KDE does not register any sound
> cards being installed. The hardware has drivers and it is installed. I can
> see the hardware with aplay.
>
> aplay -l
>  List of PLAYBACK Hardware Devices 
> card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [SAMSUNG]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> card 1: Generic_1 [HD-Audio Generic], device 0: ALC287 Analog [ALC287
> Analog]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> card 2: H540 [Logitech USB Headset H540], device 0: USB Audio [USB Audio]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
>
> (b) with a new user
>> to try and ascertain whether it's unique to your usual
>> user or an across the board problem.
>>
>
> I did not try a new user. I did try deleting "~/.config/pulseaudio"
>

I tried creating a new user, it still has the same problem.


> --
>>  Regards  _   "Valid sig separator is {dash}{dash}{space}"
>>  / )  "The blindingly obvious is never immediately apparent"
>> / _)rad   "Is it only me that has a working delete key?"
>> Success defined by acquisition stinks
>> Money is Not Our God -  Killing Joke
>>
>
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Sun, Jan 29, 2023 at 7:55 AM Brad Rogers  wrote:

> On Sun, 29 Jan 2023 07:22:02 -0500
> Timothy M Butterworth  wrote:
>
> Hello Timothy,
>
> >I upgraded to 5.27beta so far no new issues. I just installed Wayland
>
> Good to know.  Thanks for the info.
>
> >so I can try it out. My sound cards are still not working though.
>
> Have you tried;
>
> (a) checking volume levels
> because sometimes things get 'fiddled with' on update.
>

It is not a volume or a mute problem. KDE does not register any sound cards
being installed. The hardware has drivers and it is installed. I can see
the hardware with aplay.

aplay -l
 List of PLAYBACK Hardware Devices 
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [SAMSUNG]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
card 1: Generic_1 [HD-Audio Generic], device 0: ALC287 Analog [ALC287
Analog]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
card 2: H540 [Logitech USB Headset H540], device 0: USB Audio [USB Audio]
 Subdevices: 1/1
 Subdevice #0: subdevice #0

(b) with a new user
> to try and ascertain whether it's unique to your usual
> user or an across the board problem.
>

I did not try a new user. I did try deleting "~/.config/pulseaudio"


> --
>  Regards  _   "Valid sig separator is {dash}{dash}{space}"
>  / )  "The blindingly obvious is never immediately apparent"
> / _)rad   "Is it only me that has a working delete key?"
> Success defined by acquisition stinks
> Money is Not Our God -  Killing Joke
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Brad Rogers]

On Sun, 29 Jan 2023 07:22:02 -0500
Timothy M Butterworth  wrote:

Hello Timothy,

>I upgraded to 5.27beta so far no new issues. I just installed Wayland

Good to know.  Thanks for the info.

>so I can try it out. My sound cards are still not working though.

Have you tried;

(a) checking volume levels
because sometimes things get 'fiddled with' on update.

(b) with a new user
to try and ascertain whether it's unique to your usual
user or an across the board problem.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Success defined by acquisition stinks
Money is Not Our God -  Killing Joke


pgpdNPZcrEvD0.pgp
Description: OpenPGP digital signature

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Sun, Jan 29, 2023 at 5:19 AM Brad Rogers  wrote:

> On Sat, 28 Jan 2023 10:41:38 -0500
> Timothy M Butterworth  wrote:
>
> Hello Timothy,
>
> >I am looking forward to 5.27beta! It has a lot of good improvements.
>
> As I suggested, the migration to testing has started today.  I'm holding
> off for a few days to be sure (well, as sure as I can be) that
> everything necessary for a smooth upgrade has migrated.
>

I upgraded to 5.27beta so far no new issues. I just installed Wayland so I
can try it out. My sound cards are still not working though.


> --
>  Regards  _   "Valid sig separator is {dash}{dash}{space}"
>  / )  "The blindingly obvious is never immediately apparent"
> / _)rad   "Is it only me that has a working delete key?"
> I ain't got no time for intellectual music, e.g. Hergest Ridge
> Heads Down No Nonsense Mindless Boogie - Alberto y Lost Trios Paranoias
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Brad Rogers]

On Sat, 28 Jan 2023 10:41:38 -0500
Timothy M Butterworth  wrote:

Hello Timothy,

>I am looking forward to 5.27beta! It has a lot of good improvements.

As I suggested, the migration to testing has started today.  I'm holding
off for a few days to be sure (well, as sure as I can be) that
everything necessary for a smooth upgrade has migrated.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
I ain't got no time for intellectual music, e.g. Hergest Ridge
Heads Down No Nonsense Mindless Boogie - Alberto y Lost Trios Paranoias


pgpXNRkgfbFlP.pgp
Description: OpenPGP digital signature

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Sat, Jan 28, 2023 at 7:50 AM Brad Rogers  wrote:

> On Sat, 28 Jan 2023 05:04:59 -0500
> Timothy M Butterworth  wrote:
>
> Hello Timothy,
>
> >This appears to be a KDE issue. Is anyone else having this problem?
> >Please note the problem started after installing KF5-102 and a reboot.
>
> KDE Plasma is undergoing big changes ATM.  Soon(1) Plasma 5.27beta
> (2) will start transitioning to testing.


I am looking forward to 5.27beta! It has a lot of good improvements.


> Things are going
> to be sticky until everything is in sync.  That said you could, of
> course, still have run into some bug or other, I couldn't say.
>
> When large numbers of suite(3) packages start arriving in testing(4), I
> usually hold off a day or two before I update in an attempt to be sure
> everything upgrades in sync.  Because, as you've found out, although
> things can upgrade without any apparent issue, they may leave your
> desktop in an undesirable state.
>
> That's all part of running testing, of course.  In fact, it's the reason
> testing exists.
>
> (1)  Probably tomorrow
> (2)  Versioned as 4:5.26.90-1
> (3)  By which I mean things like Plasma, Gnome, etc.
> (4)  In this particular case KDE packages from 5.101.* to 5.102.*
>
> --
>  Regards  _   "Valid sig separator is {dash}{dash}{space}"
>  / )  "The blindingly obvious is never immediately apparent"
> / _)rad   "Is it only me that has a working delete key?"
> There's no point in asking you'll get no reply
> Pretty Vacant - Sex Pistols
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

debian testing updates - python3.11 landed today

[songbird]

  for those running the testing distribution:

  just thought i would put this out there for those here
who are heavy python users who might not be aware of how
this transition is going (seems to be mostly ok for now
but i'm sure some people who are doing strange things 
might find it needs some work to get things running again).

  if you are a heavy processing user i'll be interested
to hear how your system changes because there are supposed
to be some performance improvements.


  songbird

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Brad Rogers]

On Sat, 28 Jan 2023 05:04:59 -0500
Timothy M Butterworth  wrote:

Hello Timothy,

>This appears to be a KDE issue. Is anyone else having this problem?
>Please note the problem started after installing KF5-102 and a reboot.

KDE Plasma is undergoing big changes ATM.  Soon(1) Plasma 5.27beta
(2) will start transitioning to testing.  Things are going
to be sticky until everything is in sync.  That said you could, of
course, still have run into some bug or other, I couldn't say.

When large numbers of suite(3) packages start arriving in testing(4), I
usually hold off a day or two before I update in an attempt to be sure
everything upgrades in sync.  Because, as you've found out, although
things can upgrade without any apparent issue, they may leave your
desktop in an undesirable state.

That's all part of running testing, of course.  In fact, it's the reason
testing exists.

(1)  Probably tomorrow
(2)  Versioned as 4:5.26.90-1
(3)  By which I mean things like Plasma, Gnome, etc.
(4)  In this particular case KDE packages from 5.101.* to 5.102.*

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
There's no point in asking you'll get no reply
Pretty Vacant - Sex Pistols


pgpkO9o3RTu6V.pgp
Description: OpenPGP digital signature

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Brad Rogers]

On Sat, 28 Jan 2023 07:37:01 -0500
Timothy M Butterworth  wrote:

Hello Timothy,

>I forgot to mention that I am using Bookworm.

It *was* in the subject header.   :-)

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
I can't do a thing 'cause I can't relax
Independence Day - Comsat Angels


pgpI2I3pOiayf.pgp
Description: OpenPGP digital signature

Re: Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

On Sat, Jan 28, 2023 at 5:04 AM Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> wrote:

> All,
>
> I just upgraded to the 1/28/23 updates to KF5 102 and now I have no audio
> devices found. My USB headset is plugged in but KDE does not see it.
>

I forgot to mention that I am using Bookworm.


> lsusb lists my USB headphones:
> Bus 001 Device 009: ID 046d:0a37 Logitech, Inc. USB Headset H540
>
> lspci lists my audio devices
> 04:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD]
> ACP/ACP3X/ACP6x Audio Coprocessor (rev 01)
> 04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD
> Audio Controller
>
> This appears to be a KDE issue. Is anyone else having this problem? Please
> note the problem started after installing KF5-102 and a reboot.
>
> Thanks
>
> Tim
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Bookworm 1/28/23 updates - No Audio Devices Found

[Timothy M Butterworth]

All,

I just upgraded to the 1/28/23 updates to KF5 102 and now I have no audio
devices found. My USB headset is plugged in but KDE does not see it.

lsusb lists my USB headphones:
Bus 001 Device 009: ID 046d:0a37 Logitech, Inc. USB Headset H540

lspci lists my audio devices
04:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD]
ACP/ACP3X/ACP6x Audio Coprocessor (rev 01)
04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD
Audio Controller

This appears to be a KDE issue. Is anyone else having this problem? Please
note the problem started after installing KF5-102 and a reboot.

Thanks

Tim
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Monthly FAQ for Debian-user mailing lists [No updates Dec 2022]

[Andrew M.A. Cater]

Debian-user is a mailing list provided for support for Debian users,
and to facilitate discussion on relevant topics. 

Some guidelines which may help explain how the list works:

* The language on this mailing list is English. There may be other mailing 
  lists that are language-specific, for example, debian-user-french 

* It is common for users to be redirected here from other lists, for example,
  from debian-project. It is also common for people to be posting here when 
  English is not their primary language. Please be considerate.

* The list is a Debian communication forum. As such, it is subject to both 
  the Debian mailing list Code of Conduct and the main Debian Code of Conduct
  https://www.debian.org/MailingLists/#codeofconduct
  https://www.debian.org/code_of_conduct

* This is a fairly busy mailing list and you may have to wait for an
  answer - please be patient. Please post answers back to the list so
  others can benefit; private conversations don't benefit people who
  may be following along on the list or reading the archives later.

* Help and advice on this list is provided by volunteers in their own time.
  It is common for there to be different opinions or answers provided.

 * Please try to stay on topic. Arguments for the sake of it are not
   welcome here. Partisan political / religious / cultural arguments
   do not belong here either. Debian's community is world wide; do not
   assume others will agree with your views or need to read them on a
   Debian list.

* There is an FAQ on the Debian wiki derived from some questions asked on this
  list at https://wiki.debian.org/FAQsFromDebianUser

* One question that comes up on almost all Debian lists from time to time is of
  the form: 

  "I have done something wrong / included personal details in an email.
   Could you please delete my name / details / remove the mail"

Practically, this is impossible: the mailing lists are archived, potentially
cached by Google and so on.

Unfortunately, there is nothing much we can do to ensure that all copies
anywhere on the Internet are deleted. Asking to do this may only serve to
draw further attention - the so-called "Streisand effect"
See:  https://en.wikipedia.org/wiki/Streisand_effect

Problems?
=

Complaints about inappropriate behaviour should be referred to the
Debian Community Team .

Inappropriate behaviour on the list may lead to warnings; repeated bad
behaviour may lead to temporary or permanent bans for offenders.

Re: Maximum time for offline updates?

[Yvan Masson]

For those interested, I reported this upstream: 
https://github.com/PackageKit/PackageKit/issues/590


Yvan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Maximum time for offline updates?

[debian-user]

Yvan Masson wrote:

[snip]
> 
> Indeed, in a perfect setup, system should make a snapshot before
> updates are applied (see 6. in systemd.offline-updates manpage, note
> that I have not heard it is done yet by any distribution by default),
> and revert the changes if the update fails. Anyway, being able to fix
> a system that has been broken by *online* updates is only relevant if
> the user has technical skills to do so.
> 
openSUSE does that by default, assuming you use their recommended
filesystem of btrfs. The snapper program takes a snapshot before any
update and again afterwards.

[snip]

Re: Maximum time for offline updates?

[Yvan Masson]

Le 23/12/2022 à 16:03, Stefan Monnier a écrit :

I find the idea of offline update rather odd: not only it's inconvenient
since the machine is unusable during this time, but on top of it, in
case of trouble, it can make it harder to fix the problem because you
may not be able to boot into a conveniently-usable system.

That was my feeling, too. Only very involved scenarios came to mind,
like "you have connectivity now, but are running on battery, and later
you'll have AC power but no connectivity" or something.


That scenario is already (arguably better) served by the distinction
between downloading the update(s) and installing them, which APT
supports already.  No need to reboot into a special mode to perform
the install.

Yes APT can do that. Offline update also ensures that :
- the computer is not used while applying updates
- the computer is rebooted just after applying updates



Offline update has disadvantages, but it makes sure that every programs are
restarted, thus avoiding strange issues or crashes due to conflicts in
libraries versions ([1] is a KDE article that very briefly explaining
this).  In an another article I could not find anymore, someone from KDE
explains that they receive many bug reports where issues comes from system
update without reboot (I would also be interested to know what is "many"
here).


Rebooting after the updates is different from the offline update you describe.

Yes.>

Indeed, in a perfect setup, system should make a snapshot before updates are
applied (see 6. in systemd.offline-updates manpage, note that I have not
heard it is done yet by any distribution by default), and revert the changes
if the update fails.


[ Agreed.  Ideally the updates should be performed in a "clone" of the current
   system, and only after it's done and sanity-checked should we switch to
   the new system.  We've known how to do that for many years (thanks to
   IBM's main frames, for example).  ]


Anyway, being able to fix a system that has been broken by *online*
updates is only relevant if the user has technical skills to do so.


But that is no different than for offline updates, is it?

I agree.



Windows, targeting both technical and non technical users, does exactly
this. I did not use an Apple system for years, but I think it was quite
similar for system updates. Please don't byte me ;-)


Indeed.  But they have different trade-offs.  They want to have as much
control as possible over the process so as to get as close as possible
to the "just works!" black box.  Basically they want their system
partition to be a binary blob that the end users can't even look at, so
updates merely require replacing one known binary blob with another, and
to minimize external factors they kick the users out before performing
the updates since for them users are fundamentally an annoyance (a
source of unpredictability).
And if something goes wrong along the way, their answer is "reinstall".

Debian's updates are hence quite different due to the basic
philosophical premise that user are here to help and that there isn't
just one "Debian version 10.1" but instead every Debian system is
different from the others.
So the upgrade scripts have to be a lot more careful to handle a much
wilder variety of situations, and they go through extra efforts to
interact correctly with a fully running system.

Indeed, for major upgrades, rebooting *some time* after the upgrade is
often a good idea, but that's different from the offline update
you describe.
I am not an expert, but I have seen many times that just after some 
"minor" *online* update, let's say LibreOffice and a few libraries, that 
a very strange bug appears (some application refuses to start, clicking 
on a button does nothing, and so on). And rebooting or re-opening the 
session fixed that.


Anyway, I am sorry but I have probably not the skills to discuss if 
offline updates are a good thing or not (I just think "it depends", I 
personally also prefer to update via command line and then reboot if 
necessary). But I really want to find why it did stop after ten minutes, 
because other non technical people might encounter this issue and won't 
be able to fix their system.



 Stefan "sorry for having hijacked your thread"

No worries, it is always interesting to know how other think :-)




OpenPGP_signature
Description: OpenPGP digital signature

Re: Maximum time for offline updates?

[Stefan Monnier]

>>> I find the idea of offline update rather odd: not only it's inconvenient
>>> since the machine is unusable during this time, but on top of it, in
>>> case of trouble, it can make it harder to fix the problem because you
>>> may not be able to boot into a conveniently-usable system.
>> That was my feeling, too. Only very involved scenarios came to mind,
>> like "you have connectivity now, but are running on battery, and later
>> you'll have AC power but no connectivity" or something.

That scenario is already (arguably better) served by the distinction
between downloading the update(s) and installing them, which APT
supports already.  No need to reboot into a special mode to perform
the install.

> Offline update has disadvantages, but it makes sure that every programs are
> restarted, thus avoiding strange issues or crashes due to conflicts in
> libraries versions ([1] is a KDE article that very briefly explaining
> this).  In an another article I could not find anymore, someone from KDE
> explains that they receive many bug reports where issues comes from system
> update without reboot (I would also be interested to know what is "many"
> here).

Rebooting after the updates is different from the offline update you describe.

> Indeed, in a perfect setup, system should make a snapshot before updates are
> applied (see 6. in systemd.offline-updates manpage, note that I have not
> heard it is done yet by any distribution by default), and revert the changes
> if the update fails.

[ Agreed.  Ideally the updates should be performed in a "clone" of the current
  system, and only after it's done and sanity-checked should we switch to
  the new system.  We've known how to do that for many years (thanks to
  IBM's main frames, for example).  ]

> Anyway, being able to fix a system that has been broken by *online*
> updates is only relevant if the user has technical skills to do so.

But that is no different than for offline updates, is it?

> Windows, targeting both technical and non technical users, does exactly
> this. I did not use an Apple system for years, but I think it was quite
> similar for system updates. Please don't byte me ;-)

Indeed.  But they have different trade-offs.  They want to have as much
control as possible over the process so as to get as close as possible
to the "just works!" black box.  Basically they want their system
partition to be a binary blob that the end users can't even look at, so
updates merely require replacing one known binary blob with another, and
to minimize external factors they kick the users out before performing
the updates since for them users are fundamentally an annoyance (a
source of unpredictability).
And if something goes wrong along the way, their answer is "reinstall".

Debian's updates are hence quite different due to the basic
philosophical premise that user are here to help and that there isn't
just one "Debian version 10.1" but instead every Debian system is
different from the others.
So the upgrade scripts have to be a lot more careful to handle a much
wilder variety of situations, and they go through extra efforts to
interact correctly with a fully running system.

Indeed, for major upgrades, rebooting *some time* after the upgrade is
often a good idea, but that's different from the offline update
you describe.


Stefan "sorry for having hijacked your thread"

Re: Maximum time for offline updates?

[Yvan Masson]

Le 23/12/2022 à 07:50, to...@tuxteam.de a écrit :

On Thu, Dec 22, 2022 at 04:57:54PM -0500, Stefan Monnier wrote:

[...]


I find the idea of offline update rather odd: not only it's inconvenient
since the machine is unusable during this time, but on top of it, in
case of trouble, it can make it harder to fix the problem because you
may not be able to boot into a conveniently-usable system.


That was my feeling, too. Only very involved scenarios came to mind,
like "you have connectivity now, but are running on battery, and later
you'll have AC power but no connectivity" or something.

Cheers


Offline update has disadvantages, but it makes sure that every programs 
are restarted, thus avoiding strange issues or crashes due to conflicts 
in libraries versions ([1] is a KDE article that very briefly explaining 
this). In an another article I could not find anymore, someone from KDE 
explains that they receive many bug reports where issues comes from 
system update without reboot (I would also be interested to know what is 
"many" here).


Indeed, in a perfect setup, system should make a snapshot before updates 
are applied (see 6. in systemd.offline-updates manpage, note that I have 
not heard it is done yet by any distribution by default), and revert the 
changes if the update fails. Anyway, being able to fix a system that has 
been broken by *online* updates is only relevant if the user has 
technical skills to do so.


Windows, targeting both technical and non technical users, does exactly 
this. I did not use an Apple system for years, but I think it was quite 
similar for system updates. Please don't byte me ;-)


I definitely won't use those OS either unless I have to, but I admit 
they do many things very well and have competent UI designers. But our 
favorite OS is still the best because at least we have the choice 
between online and offline.


1. https://blog.neon.kde.org/2021/03/01/offline-updates-are-coming/

Regards,
Yvan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Maximum time for offline updates?

[tomas]

On Thu, Dec 22, 2022 at 04:57:54PM -0500, Stefan Monnier wrote:

[...]

> I find the idea of offline update rather odd: not only it's inconvenient
> since the machine is unusable during this time, but on top of it, in
> case of trouble, it can make it harder to fix the problem because you
> may not be able to boot into a conveniently-usable system.

That was my feeling, too. Only very involved scenarios came to mind,
like "you have connectivity now, but are running on battery, and later
you'll have AC power but no connectivity" or something.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Maximum time for offline updates?

[Stefan Monnier]

> I am using testing with KDE (but I suppose the desktop environnent does not
> matter).  I had a LOT of updates to apply today, so I used KDE Discover
> (Gnome Software equivalent for KDE) to apply those in offline mode, ie
> updates are dowloaded and then computer reboots in a special mode just to
> update packages, and reboot normally when finished.

Why?

> Also, do you think I should report this issue?

Yes.

> Against which package?

The package you used to do this "offline update" (hadn't heard of such
a thing until now for Debian).

I find the idea of offline update rather odd: not only it's inconvenient
since the machine is unusable during this time, but on top of it, in
case of trouble, it can make it harder to fix the problem because you
may not be able to boot into a conveniently-usable system.


Stefan