Re: [DNG] runit, ifupdown and simple-netaid (was: vdev in chimaera)

[aitor]

On 23/2/22 2:35, aitor wrote:

all the content in its config file to be piped to the sysctl command


*files*, better said, the ones found in /etc/sysctl.d/

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] runit, ifupdown and simple-netaid (was: vdev in chimaera)

[aitor]

Hi,

On 15/2/22 8:40, aitor wrote:

On 11/2/22 12:11, Didier Kryn wrote:

My normal interfaces file contains an "auto" stanza for wlan0,
which is superfluous, according to messages from ifplugd, and*only*  
"iface eth0 inet dhcp" for eth0 because it comes first in the file and

"auto" and/or "allow-hotplug" can just cause the abovementionned delay
when no Ethernet cable is connected.

Please, give a try to the following image:
https://www.gnuinos.org/mirror/chimaera/live/  

There are several services being handled by runit in these images, and 
ifupdown's networking is one of them.
Better said, it's not a service -as you pointed out- but a script that starts 
another service, that is dhcp.
You can test the image in live mode, and you'll find that the delay caused by 
the configuration in
/etc/network/interfaces disappears. Also, even if you boot without wired 
connection, the connection will be
stablished without the need of restarting the service when you plug/unplug the 
ethernet cable again and again.
Note, on the other hand, that the time interval in the periodic reminder of the 
automatically_connect option of
simple-netaid (setup in /etc/simple-netaid/snetaid.conf) is equal to zero so as 
not to interfere with the
stanzas defined in /etc/network/interfaces. Hence, the wired connection is 
stablished thanks to these definitions.
And yes..., *both* stanzas are required for that. With this in mind, I decided 
to leave the automatically connect
option of simple-netaid only for wired devices.


All those that tested the live images, just report to you that simple-netaid 
was not being responsive due to a missing
runit script in my packaging of procps (sysctl).

This script was missing as a result of a typo in the line:

dh $@ --with runit

in debian/rules. Concretely, there was a superfluous space in blank after the hyphens: 
that is, "-- with runit".

Before procceding further, I shall clarify that procps -someone may correct me 
at this point- isn't a service in the
broadest sense of the word. At least, it's not a service that requires 
supervision, not a long running daemon. Rather,
it's more like a script that causes all the content in its config file to be 
piped to the sysctl command. So, just like
the networking script provided by ifupdown, it must be run once because the act 
of starting the service is pretty much
the same as what you're manually doing when running such script.

With this in mind, I added the following lines to /etc/runit/1 in order to boot 
up the services and not supervise them:

touch /etc/sv/procps/down

touch /etc/sv/networking/down

All we need to do now is manually invoke each service via:


sv once 
 


from another runit script that may depend on it to work properly.

This said, it's easy to understand the way in which the missing runit script of 
procps was affecting to the networking
script, and therefore to the daemon of simple-netaid. Because a line that 
misbehave at the beginning of a runit script
blocks the whole service.

Someone else out there also has noticed this hung in simple-netaid, and today I 
fixed it and uploaded new iso images:

https://www.gnuinos.org/mirror/chimaera/  


Thanks for your help,

Aitor.

 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problems with amdgpu in the latest kernel upgrade? Ort just a glitch for me?

[Olaf Meeuwissen via Dng]

Hi,

Ludovic Bellière via Dng  writes:

> [[PGP Signed Part:Undecided]]
> Hello terryc,
>
> You seem to have a variety of kernel installed. Could you tell us which 
> version
> works for you, and which version showed the errors?
>
> In doubt, I would revert back to stable — not backport (bpo). So you want the
> latest of the 5.10 series, which should come from security.
>
> Care must be taken when dealing with backport kernels, as they don't usually 
> get
> shipped as a whole: the signing and verification process takes some time. Once
> you're on the kernel from the stable-security channel, you can then purge all
> the others you do not use. You could do that by marking all `linux-image` and
> `linux-headers` as automatically installed (1) followed by a call to `apt
> autoremove` (2). If your system is properly configured, it should remove all
> package that:
>
> a) are not required by another package and
> b) are automatically installed
>
> (1) sudo aptitude markauto ~nlinux-headers ~nlinux-image
> (2) sudo apt autoremove

In the default setup, that last command will leave configuration files.
That's what resulted in the

  rc  linux-image-5.10.0-6-amd64   5.10.28-1   amd64  Linux 5.10 for 64-bit PCs 
(signed)

entries in the original post.

  sudo apt purge --auto-remove

will get rid of the configuration files as well.

# There are some inconsistencies in what is parsed correctly and what
# not between apt and apt-get as well as the autoremove and auto-remove
# subcommands and options.  I normally use the above.

> Using the automated functions of apt is of great help when trying to keep a
> system somewhat clean of unwanted, or uneeded packages.

Indeed and tweaking a few configuration options goes a long way to
keeping your system lean and mean.  Just in case anyone is interested,
here's what I have in my /etc/apt.conf

  // Install packages based on their own merits, not because Debian
  // or Devuan maintainers think you might want them.

  APT::Install-Recommends "false";
  APT::Install-Suggests "false";

  // Remove installed packages as soon as they are no longer needed
  // by other packages.  This complements the above settings.  Note
  // that this only kicks in when installing or removing packages.
  // It does *not* apply when just upgrading installed packages.

  APT::AutoRemove::RecommendsImportant "false";
  APT::AutoRemove::SuggestsImportant "false";

  // Configuration files are tracked with `etckeeper` so there is a
  // whole history of any such file in its repository.  Whatever is
  // *not* in the repository was either not worth tracking or a bit
  // too sensitive (in which case some other backup mechanism would
  // normally have been available or configured).

  APT::Get::Purge "true";

Note, you'll need to install etckeeper to make that comment on purging
configuration true for your system.  I do and tend to muck around with
the apt and network configurations quite a bit but for most part there
is a lot of configuration that I use as is.

Hope this helps,
--
Olaf MeeuwissenFSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problems with amdgpu in the latest kernel upgrade? Ort just a glitch for me?

[Olaf Meeuwissen via Dng]

Hi,

terryc  writes:

> I've just performed to apt trio (update, upgrade and dist-upgrade) and
> following a reboot my system went very glitchy, especially o the screen.
>
> There was a warning in the stop start boot up, along with copious
> errors like this;
> [   21.260287] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your 
> previous command!
> [   25.797572] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your 
> previous command!
> [   30.325590] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your 
> previous command!
> [34.857594] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your previous 
> command!
> [   39.378689] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your 
> previous command!
> [   43.914156] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your 
> previous command!
> [48.439014] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your previous 
> command!
> [   54.227334] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your 
> previous command!
>
> I temporarily fixed the problem by rebooting to the previous kernel,but
> in investigating came across this oddity in the naming of my
> installed kernels

I'm not sure whether it makes a difference but do you have a *recent*
firmware-amd-graphics installed?  One that "matches" your kernel.  On
packages.debian.org (not on pkginfo.devuan.org, though), I see several
timestamp versioned packages.  Based on the kernel version you seem to
be using (from {bullseye,chimaera}-backports), I'd say you may need one
from 2021 and maybe even August (i.e. the one in {bookworm,daedalus}).

> user@system: dpkg --list | grep linux-image
> rc  linux-image-5.10.0-6-amd64 5.10.28-1   amd64Linux 
> 5.10 for 64-bit PCs (signed)
> rc  linux-image-5.10.0-7-amd64 5.10.40-1   amd64Linux 
> 5.10 for 64-bit PCs (signed)
> rc  linux-image-5.10.0-8-amd64 5.10.46-5   amd64Linux 
> 5.10 for 64-bit PCs (signed)
> rc  linux-image-5.10.0-9-amd64 5.10.70-1   amd64Linux 
> 5.10 for 64-bit PCs (signed)

You can safely remove the configuration files that are still lingering
from the above.  As root

  dpkg --list \
| grep -E '^rc *linux-image-' \
| awk '{ print $2 }' \
| xargs dpkg --purge

If you use sudo to get root, stick that between xargs and dpkg.

> ii  linux-image-5.14.0-0.bpo.2-amd64   5.14.9-2~bpo11+1amd64Linux 
> 5.14 for 64-bit PCs (signed)
> ii  linux-image-5.15.0-0.bpo.2-amd64   5.15.5-2~bpo11+1amd64Linux 
> 5.15 for 64-bit PCs (signed)
> ii  linux-image-5.15.0-0.bpo.3-amd64   5.15.15-2~bpo11+1   amd64Linux 
> 5.15 for 64-bit PCs (signed)
> ii   linux-image-amd64
>
> Looking for clubies on why the last image doesn't fit the pattern, and
> the best way to purge it.

As Antoine mentioned linux-image-amd64 is a meta package that depends on
the latest versioned linux-image-$version-amd64 package.  See

  
https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package=linux-image-amd64=5.15.15-2~bpo11+1

for what I think is what you have installed.  If your APT also pulls the
Translation file (contains translated, full package descriptions), you
can check with `apt show $pkgname` as well.

Hope this helps,
--
Olaf MeeuwissenFSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lvm2 depends on systemd

[aitor]

Hi Boian,

On 22/2/22 18:18, Boian Bonev wrote:


Maybe I have omitted to share more details - I am building the
plain upstream lvm and do not create a package (no patches involved).


I was supposing that this was the case. Both you and me are being able to build 
the sources,
but I cannot find the required files for building one of the packages defined 
in debian/control.


Also I may be missing what are you trying to do...


Just remove systemd from the build dependencies in debian/control. Packages of 
lvm2 can't be
built under devuan with the current configuration (pulled from debian).

But llvm2 is not solely the case. The same goes for czmq, to take another 
example:

https://zeromq.org/languages/cplusplus/  


a high level binding for ZeroMQ:https://zguide.zeromq.org  


The packaging of the above c++ wrapper -required by rsyslog- depends also on 
systemd.

Huh!


In case you share a repo, I may be able to help with that...


This is done:

http://packages.gnuinos.org/gnuinos/pool/main/l/lvm2/lvm2_2.03.02.orig.tar.gz  


http://packages.gnuinos.org/gnuinos/pool/main/l/lvm2/lvm2_2.03.11-2.1+gnuinos4.debian.tar.xz
  


http://packages.gnuinos.org/gnuinos/pool/main/l/lvm2/lvm2_2.03.11-2.1+gnuinos4.dsc  


It happens that disabling the dbus service, most of the files that belong to 
llvm2-dbusd are missing.
Therefore, this package must be removed from debian/control.

Thanks for your help,

Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problems with amdgpu in the latest kernel upgrade? Ort just a glitch for me?

[Ludovic Bellière via Dng]

Hello terryc,

You seem to have a variety of kernel installed. Could you tell us which version
works for you, and which version showed the errors?

In doubt, I would revert back to stable — not backport (bpo). So you want the
latest of the 5.10 series, which should come from security.

Care must be taken when dealing with backport kernels, as they don't usually get
shipped as a whole: the signing and verification process takes some time. Once
you're on the kernel from the stable-security channel, you can then purge all
the others you do not use. You could do that by marking all `linux-image` and
`linux-headers` as automatically installed (1) followed by a call to `apt
autoremove` (2). If your system is properly configured, it should remove all
package that:

a) are not required by another package and
b) are automatically installed

(1) sudo aptitude markauto ~nlinux-headers ~nlinux-image
(2) sudo apt autoremove

Using the automated functions of apt is of great help when trying to keep a
system somewhat clean of unwanted, or uneeded packages.


Cheers,
Ludovic


On Tue, 22 Feb 2022, terryc wrote:


I've just performed to apt trio (update, upgrade and dist-upgrade) and
following a reboot my system went very glitchy, especially o the screen.

[...]

I temporarily fixed the problem by rebooting to the previous kernel,but
in investigating came across this oddity in the naming of my
installed kernels


user@system: dpkg --list | grep linux-image
rc  linux-image-5.10.0-6-amd645.10.28-1
 amd64Linux 5.10 for 64-bit PCs (signed)
rc  linux-image-5.10.0-7-amd645.10.40-1
  amd64Linux 5.10 for 64-bit PCs (signed)
rc  linux-image-5.10.0-8-amd645.10.46-5
  amd64Linux 5.10 for 64-bit PCs (signed)
rc  inux-image-5.10.0-9-amd645.10.70-1
  amd64Linux 5.10 for 64-bit PCs (signed)
ii  linux-image-5.14.0-0.bpo.2-amd64  5.14.9-2~bpo11+1
  amd64Linux 5.14 for 64-bit PCs (signed)
ii  linux-image-5.15.0-0.bpo.2-amd64  5.15.5-2~bpo11+1
  amd64Linux 5.15 for 64-bit PCs (signed)
ii  linux-image-5.15.0-0.bpo.3-amd64  5.15.15-2~bpo11+1
  amd64Linux 5.15 for 64-bit PCs (signed)
ii   linux-image-amd64

Looking for clubies on why the last image doesn't fit the pattern, and
the best way to purge it.

T.I.A.
terryc


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another reason for why I use Devuan

[Antoine via Dng]

On Tuesday, 22 February at 08:56, Curtis Maurand wrote:

On 2/21/22 14:02, Dr. Nikolaus Klepp via Dng wrote:

Anno domini 2022 Mon, 21 Feb 18:08:20 +
 Arnt Karlsen scripsit:

On Fri, 18 Feb 2022 02:44:12 -0300, Gastón wrote in message
<20220218054412.ga5...@devuan.devuan.com.ar>:

On Thu, Feb 17, 2022 at 10:52:43PM -0500, Hendrik Boom wrote:

On Thu, Feb 17, 2022 at 05:41:59PM -0800, Syeed Ali wrote:

On Thu, 17 Feb 2022 15:25:05 -1000
Joel Roth via Dng  wrote:

On Thu, Feb 17, 2022 at 05:55:49PM -0700, Keith Christian via
Dng wrote:

This describes the machine ID:

https://www.freedesktop.org/software/systemd/man/machine-id.html

So a creation of the freedesktop folks.


I like this quote:

It should be considered "confidential", and must not be exposed
in untrusted environments,
...

Just checked.  On my pure devuan system,
there is no /etc/machine-id filre,
but there is a /var/lib/dbus/machine-id

Should I worry?

..dunno, chk
https://www.mail-archive.com/dng@lists.dyne.org/msg24726.html


I leave here the link to the thread with the discussion about
machine-id that occurred in this list in 2019

https://www.mail-archive.com/dng@lists.dyne.org/msg24687.html

In /etc/default/dbus you can set the IDTYPE to be a RANDOM value.

..thanks for the remainder, I had a feeling I had forgotten something
of importance updating a wee spare ascii disk install to chimaera.

IMO it's set to RANDOM by default, at leaset it is on my machines. But I run 
daedalus.

Nik


I'm running both Beowulf and Chimaera. it's set to "RANDOM" on 
everything.  I never changed it.  I never knew about it, so thank you 
all for the education.


--Curtis




One day when I was feeling feisty, I just manually softlinked both to 
/dev/null. No idea what the long-term consequences might be, but so far, so 
good.


- Antoine

--
It's still magic, even if you know how it's done.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Problems with amdgpu in the latest kernel upgrade? Ort just a glitch for me?

[Antoine via Dng]

On Tuesday, 22 February at 23:11, terryc wrote:

I've just performed to apt trio (update, upgrade and dist-upgrade) and
following a reboot my system went very glitchy, especially o the screen.

There was a warning in the stop start boot up, along with copious
errors like this;
[   21.260287] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command!
[   25.797572] amdgpu :09:00.0: amdgpu: SMU: I'm
not done with your previous command!
[   30.325590] amdgpu
:09:00.0: amdgpu: SMU: I'm not done with your previous command!
[34.857594] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command!
[   39.378689] amdgpu :09:00.0: amdgpu: SMU: I'm
not done with your previous command!
[   43.914156] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command!
[48.439014] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command!
[   54.227334] amdgpu :09:00.0: amdgpu: SMU: I'm
not done with your previous command!

I temporarily fixed the problem by rebooting to the previous kernel,but
in investigating came across this oddity in the naming of my
installed kernels


user@system: dpkg --list | grep linux-image
rc  linux-image-5.10.0-6-amd645.10.28-1
 amd64Linux 5.10 for 64-bit PCs (signed)
rc  linux-image-5.10.0-7-amd645.10.40-1
  amd64Linux 5.10 for 64-bit PCs (signed)
rc  linux-image-5.10.0-8-amd645.10.46-5
  amd64Linux 5.10 for 64-bit PCs (signed)
rc  inux-image-5.10.0-9-amd645.10.70-1
  amd64Linux 5.10 for 64-bit PCs (signed)
ii  linux-image-5.14.0-0.bpo.2-amd64  5.14.9-2~bpo11+1
  amd64Linux 5.14 for 64-bit PCs (signed)
ii  linux-image-5.15.0-0.bpo.2-amd64  5.15.5-2~bpo11+1
  amd64Linux 5.15 for 64-bit PCs (signed)
ii  linux-image-5.15.0-0.bpo.3-amd64  5.15.15-2~bpo11+1
  amd64Linux 5.15 for 64-bit PCs (signed)
ii   linux-image-amd64

Looking for clubies on why the last image doesn't fit the pattern, and
the best way to purge it.

T.I.A.
terryc



I wouldn't know about your graphics card not being done with previous 
commands (maybe a driver update?), but isn't linux-image-amd64 a 
meta-package? It doesn't contain anything but requires the most recent 
version of the kernel package (in your case 
linux-image-5.15.0-0.bpo.3-amd64), and when the kernel version is upgraded, 
the package itself doesn't change versions but the requirement does change.


- Antoine

--
Elegance is not a dispensable luxury but
a quality that decides between success and failure.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lvm2 depends on systemd

[Boian Bonev]

Hi,

Maybe I have omitted to share more details - I am building the plain upstream
lvm and do not create a package (no patches involved).
Also I may be missing what are you trying to do, in case you share a repo, I
may be able to help with that...

With best regards,
b.

On Tue, 2022-02-22 at 08:40 +0100, aitor wrote:
> 
> > It doesn't build successfully without disabling lvmlockd.
> I rectify: without modifying the quilt patch applied by debian.
> 
> llvm2-lockd is present in my packaging.
> 
> Aitor.
> 
> 
> Enviado con Aqua Mail para Android
> https://www.mobisystems.com/aqua-mail
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another reason for why I use Devuan

[Curtis Maurand]

On 2/21/22 14:02, Dr. Nikolaus Klepp via Dng wrote:

Anno domini 2022 Mon, 21 Feb 18:08:20 +
  Arnt Karlsen scripsit:

On Fri, 18 Feb 2022 02:44:12 -0300, Gastón wrote in message
<20220218054412.ga5...@devuan.devuan.com.ar>:


On Thu, Feb 17, 2022 at 10:52:43PM -0500, Hendrik Boom wrote:

On Thu, Feb 17, 2022 at 05:41:59PM -0800, Syeed Ali wrote:

On Thu, 17 Feb 2022 15:25:05 -1000
Joel Roth via Dng  wrote:
   

On Thu, Feb 17, 2022 at 05:55:49PM -0700, Keith Christian via
Dng wrote:

This describes the machine ID:

https://www.freedesktop.org/software/systemd/man/machine-id.html
  

So a creation of the freedesktop folks.


I like this quote:
   

It should be considered "confidential", and must not be exposed
in untrusted environments,
...

Just checked.  On my pure devuan system,
there is no /etc/machine-id filre,
but there is a /var/lib/dbus/machine-id

Should I worry?

..dunno, chk
https://www.mail-archive.com/dng@lists.dyne.org/msg24726.html


I leave here the link to the thread with the discussion about
machine-id that occurred in this list in 2019

https://www.mail-archive.com/dng@lists.dyne.org/msg24687.html

In /etc/default/dbus you can set the IDTYPE to be a RANDOM value.

..thanks for the remainder, I had a feeling I had forgotten something
of importance updating a wee spare ascii disk install to chimaera.

IMO it's set to RANDOM by default, at leaset it is on my machines. But I run 
daedalus.

Nik


I'm running both Beowulf and Chimaera. it's set to "RANDOM" on 
everything.  I never changed it.  I never knew about it, so thank you 
all for the education.


--Curtis



..lost a coupla days worth of emails and command line history in my 1GB
stopped dead disk, after getting distracted from backup-ing blue smoking
the red and blue wiring off my other Precision M4400, crisy clear green
monochrome at 1920x1200@60Hz didn't leave enough video memory for any X
on any plug-in screen, all the while while the consoles were annoyingly
consoling. ;oD






___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Problems with amdgpu in the latest kernel upgrade? Ort just a glitch for me?

[terryc]

I've just performed to apt trio (update, upgrade and dist-upgrade) and
following a reboot my system went very glitchy, especially o the screen.

There was a warning in the stop start boot up, along with copious
errors like this;
[   21.260287] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command!
[   25.797572] amdgpu :09:00.0: amdgpu: SMU: I'm
not done with your previous command!
[   30.325590] amdgpu
:09:00.0: amdgpu: SMU: I'm not done with your previous command! 
[34.857594] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command! 
[   39.378689] amdgpu :09:00.0: amdgpu: SMU: I'm
not done with your previous command! 
[   43.914156] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command! 
[48.439014] amdgpu :09:00.0: amdgpu: SMU: I'm not done with your
previous command! 
[   54.227334] amdgpu :09:00.0: amdgpu: SMU: I'm
not done with your previous command!

I temporarily fixed the problem by rebooting to the previous kernel,but
in investigating came across this oddity in the naming of my
installed kernels


user@system: dpkg --list | grep linux-image
rc  linux-image-5.10.0-6-amd645.10.28-1
  amd64Linux 5.10 for 64-bit PCs (signed) 
rc  linux-image-5.10.0-7-amd645.10.40-1
   amd64Linux 5.10 for 64-bit PCs (signed) 
rc  linux-image-5.10.0-8-amd645.10.46-5
   amd64Linux 5.10 for 64-bit PCs (signed) 
rc  inux-image-5.10.0-9-amd645.10.70-1
   amd64Linux 5.10 for 64-bit PCs (signed) 
ii  linux-image-5.14.0-0.bpo.2-amd64  5.14.9-2~bpo11+1
   amd64Linux 5.14 for 64-bit PCs (signed) 
ii  linux-image-5.15.0-0.bpo.2-amd64  5.15.5-2~bpo11+1
   amd64Linux 5.15 for 64-bit PCs (signed) 
ii  linux-image-5.15.0-0.bpo.3-amd64  5.15.15-2~bpo11+1
   amd64Linux 5.15 for 64-bit PCs (signed) 
ii   linux-image-amd64 

Looking for clubies on why the last image doesn't fit the pattern, and
the best way to purge it.

T.I.A.
terryc
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng