Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[Charles Curley]

On Sun, 15 Sep 2024 21:04:18 +0200
Christian Britz  wrote:

> Am 09.09.24 um 10:27 schrieb David:
> 
> > `apt auto-remove'  
> 
> You generally might want apt --purge auto-remove
> This also cleans up configuration files.

Which is the same as "apt autopurge", which I suggested earlier in this
thread.

-- 
Does anybody read signatures any more?

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

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[Christian Britz]

Am 09.09.24 um 10:27 schrieb David:

> `apt auto-remove'

You generally might want apt --purge auto-remove
This also cleans up configuration files.

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[David]

On Mon, 2024-09-09 at 11:04 +0300, Anssi Saari wrote:
> Charles Curley  writes:
> 
> > apt purge linux-image-amd64 linux-headers-amd64
> > apt install linux-image-amd64 linux-headers-amd64
> > 
> > You may want an "apt autopurge" in between.
> 
> That should do it although it's apt autoremove 

`apt auto-remove'

Cheers!
> I believe but if not you
> can explicitly remove the backport kernel image and headers.
> 
> Running dpkg -l linux-headers-\* and dpkg -l linux-image-\* will list
> the relevant packages, rows that start with ii mean installed.
> 
> Backport kernels will have bpo in the version column and those are
> the
> ones that are from backports and can be removed.
> 

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[David]

On Mon, 2024-09-09 at 11:04 +0300, Anssi Saari wrote:
> Charles Curley  writes:
> 
> > apt purge linux-image-amd64 linux-headers-amd64
> > apt install linux-image-amd64 linux-headers-amd64
> > 
> > You may want an "apt autopurge" in between.
> 
> That should do it although it's apt autoremove 

`apt auto-remove'

Cheers!
> I believe but if not you
> can explicitly remove the backport kernel image and headers.
> 
> Running dpkg -l linux-headers-\* and dpkg -l linux-image-\* will list
> the relevant packages, rows that start with ii mean installed.
> 
> Backport kernels will have bpo in the version column and those are
> the
> ones that are from backports and can be removed.
> 

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[Anssi Saari]

Charles Curley  writes:

> apt purge linux-image-amd64 linux-headers-amd64
> apt install linux-image-amd64 linux-headers-amd64
>
> You may want an "apt autopurge" in between.

That should do it although it's apt autoremove I believe but if not you
can explicitly remove the backport kernel image and headers.

Running dpkg -l linux-headers-\* and dpkg -l linux-image-\* will list
the relevant packages, rows that start with ii mean installed.

Backport kernels will have bpo in the version column and those are the
ones that are from backports and can be removed.

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[Charles Curley]

On Fri, 6 Sep 2024 16:39:46 -0600
Rick Macdonald  wrote:

> Well, this is embarrassing. I found in the bash history that I ran
> this:
> 
> apt install -t bookworm-backports linux-image-amd64
> linux-headers-amd64

> 
> Sorry to sound so lame, but I do I remove the backport such that it
> goes back to the stock Bookworm kernel?

No worries; we've all done something similar. Well, except for the
wet-behind-the-ears know-it-alls. But that's why they're
wet-behind-the-ears know-it-alls.

Anyway, I seem to recall doing something like:

apt purge linux-image-amd64 linux-headers-amd64
apt install linux-image-amd64 linux-headers-amd64

You may want an "apt autopurge" in between.

You may also find yourself rebooting and manually purging surplus
kernels and headers packages.
-- 
Does anybody read signatures any more?

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

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[Rick Macdonald]

Well, this is embarrassing. I found in the bash history that I ran this:

apt install -t bookworm-backports linux-image-amd64 linux-headers-amd64

but I have no idea why. The timestamp of the deb file is July 18. I 
don't remember why I did this. Getting old sucks. Looking at the 
history, it looks like at the time I was having problems with 
pulseaudio, and it being replaced by pipewire.


Sorry to sound so lame, but I do I remove the backport such that it goes 
back to the stock Bookworm kernel?


Rick

On 2024-09-06 14:12, Anssi Saari wrote:

Rick Macdonald  writes:


I'm running an up-to-date Bookworm desktop. I have an NVIDIA GeForce
GTX 760 (192-bit) using the NVIDIA Driver Version 470.256.02, coming
from the nvidia-tesla-470 packages. I've searched this list and the
package pages and don't see any bugs reported.

The 6.10.6 image fails to build:

Errors were encountered while processing:
  linux-image-6.10.6+bpo-amd64
  linux-image-amd64
  linux-headers-6.10.6+bpo-amd64
  linux-headers-amd64

Is there some reason to run the backport kernel? Maybe just run with the
stock Bookworm kernel and consider upgrading hardware before Trixie?

Re: linux-image-6.10.6 fails to build in nvidia-tesla-470

[Anssi Saari]

Rick Macdonald  writes:

> I'm running an up-to-date Bookworm desktop. I have an NVIDIA GeForce
> GTX 760 (192-bit) using the NVIDIA Driver Version 470.256.02, coming
> from the nvidia-tesla-470 packages. I've searched this list and the
> package pages and don't see any bugs reported.
>
> The 6.10.6 image fails to build:
>
> Errors were encountered while processing:
>  linux-image-6.10.6+bpo-amd64
>  linux-image-amd64
>  linux-headers-6.10.6+bpo-amd64
>  linux-headers-amd64

Is there some reason to run the backport kernel? Maybe just run with the
stock Bookworm kernel and consider upgrading hardware before Trixie?

Re: linux-image 6.9.7+bpo-amd6 installed without problem from backports this morning

[Keith Bainbridge]

On 4/8/24 09:31, Keith Bainbridge wrote:
I've seen that some recent kernel has had trouble so I thought I'd 
report some good news





Error

Update

My vboxdrv module has disappeared.   I don't have time this side of a 4 
week trip to try to sort it.   I'll look for help when I got home.I 
leave the laptop at home

--
All the best

Keith Bainbridge

keithr...@gmail.com
keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00

Kali Linux is not Debian - no support here [WAS Re: LINUX-IMAGE-6.8.11 headers cannot be installed]

[Andrew M.A. Cater]

On Wed, Jul 24, 2024 at 12:33:51PM +0200, Aleix Piulachs wrote:
> How do you install them and tell me the characteristics of your computer
> 
> El El mié, 17 jul 2024 a las 2:38, Greg Wooledge 
> escribió:
> 
> > On Tue, Jul 16, 2024 at 19:30:20 -, Prajnanaswaroopa wrote:
> > > Hello,
> > > I am using a Kali Linux
> >
> > https://www.google.com/search?q=kali+linux+support
> >
> >

Aleix,

That's not a Debian kernel version, potentially.

Kali Linux? We've tried to tell you - most of us don't run / have
never run Kali for any length of time.

Kali is based on snapshots of Debian testing and is specialised for
penetration testing and secxurity tasks. It includes many packages
that aren't necessarily in mainstream Debian - ahat makes you think
that this is an appropriate forum to keep asking similar questions
in a similar way?

Accordingly, we _cannot_ help you with Kali. You have been directed
to Kali forums and other sources: please use these or an Internet 
search engine to answer your queries.

All the very best, as ever,

Andy
(amaca...@debian.org)

Re: LINUX-IMAGE-6.8.11 headers cannot be installed

[Aleix Piulachs]

How do you install them and tell me the characteristics of your computer

El El mié, 17 jul 2024 a las 2:38, Greg Wooledge 
escribió:

> On Tue, Jul 16, 2024 at 19:30:20 -, Prajnanaswaroopa wrote:
> > Hello,
> > I am using a Kali Linux
>
> https://www.google.com/search?q=kali+linux+support
>
>

Re: LINUX-IMAGE-6.8.11 headers cannot be installed

[George at Clug]

Prajnanaswaroopa,


What sources are you using to upgrade from?

e.g. what do you see for:
# cat /etc/apt/sources.list


I do not know what Kali Linux might use for non-free firmware.


Debian Bookworm can use something like:


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

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

# bookworm-updates, to get updates before a point release is made;
# see
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb https://deb.debian.org/debian/ bookworm-updates main contrib
non-free non-free-firmware
deb-src https://deb.debian.org/debian/ bookworm-updates main contrib
non-free non-free-firmware

# bookworm-backports, previously on backports.debian.org
deb https://deb.debian.org/debian/ bookworm-backports main contrib
non-free non-free-firmware
deb-src https://deb.debian.org/debian/ bookworm-backports main contrib
non-free non-free-firmware


George.





On Wednesday, 17-07-2024 at 05:30 Prajnanaswaroopa wrote:


Hello,
I am using a Kali Linux 6.6.9 version. When I tried to update and
upgrade, the terminal shows that the header linux-header-6.8.11-amd64
cannot be installed. I tried several commands, but all seen to return
the same comment. In addition, the error the terminal shows is as
follows:

    dpkg: error processing package linux-headers-6.8.11-amd64
(--configure):
    installed linux-headers-6.8.11-amd64 package post-installation
    script subprocess returned error exit status 11
    dpkg: dependency problems prevent configuration of
linux-headers-amd64:
    linux-headers-amd64 depends on linux-headers-6.8.11-amd64
    (=   6.8.11-1kali2); however:
    Package linux-headers-6.8.11-amd64 is not configured yet.

    dpkg: error processing package linux-headers-amd64
(--configure):
    dependency problems - leaving unconfigured
    Setting up linux-image-6.8.11-rt-amd64-dbg (6.8.11-1kali2) ...
    Setting up linux-image-6.8.11-rt-amd64 (6.8.11-1kali2) ...
    I: /initrd.img.old is now a symlink to
boot/initrd.img-6.8.11-rt-amd64
    /etc/kernel/postinst.d/dkms:
    dkms: running auto installation service for kernel
6.8.11-rt-amd64.
    Sign command:
/lib/modules/6.8.11-rt-amd64/build/scripts/sign-file
    Signing key: /var/lib/dkms/mok.key
    Public certificate (MOK): /var/lib/dkms/mok.pub

    Building module:
    Cleaning build area...
    Building module(s)(bad exit status: 2)
    Failed command:
    'make' all KVER=6.8.11-rt-amd64
    Error! Bad return status for module build on kernel:
    6.8.11-rt-amd64   (x86_64)
    Consult /var/lib/dkms/rtl8188fu/1.0/build/make.log for more
information.
    dkms autoinstall on 6.8.11-rt-amd64/x86_64 failed for
rtl8188fu(10)
    Error! One or more modules failed to install during
autoinstall.
    Refer to previous errors for more information.
    dkms: autoinstall for kernel: 6.8.11-rt-amd64 failed!

>From the errors, I feel the wifi driver `rtl8188fu` is the one that
creates trouble. But, it is the driver for the wifi adapter for my PC,
and deleting it would mean no internet for me. So, how should I
proceed. For information, I currently have linux-header `uname -a`
version as `6.6.9`. Rebooting will log me to the latest version `Kali
Linux 6.8.11`, but without wifi drivers in the `ifconfig`, and without
internet connection. For reference, here is first few lines of the
content of the /var/lib/dkms/rtl8188fu/1.0/build/make.log file:

    DKMS make.log for rtl8188fu-1.0 for kernel
    6.8.11-cloud-amd64 (x86_64)
    Friday 12 July 2024 04:51:10 PM IST
    make ARCH=x86_64 CROSS_COMPILE= -C
    /lib/modules/6.8.11- cloud-amd64/build
    M=/var/lib/dkms /rtl8188fu/1.0/build  modules
    make[1]: Entering directory
    '/usr/src/linux-headers-6.8.11-cloud-amd64'
    CC [M]  /var/lib/dkms/rtl8188fu/1.0/build/core/rtw_cmd.o
   
/var/lib/dkms/rtl8188fu/1.0/build/core/rtw_cmd.c:2225:4:
warning: no previous prototype for ‘_rtw_set_chplan_cmd’
[-Wmissing-prototypes]
 2225 | u8 _rtw_set_chplan_cmd(_adapter *adapter,  
    int  flags,   u8 chplan, const struct
    country_chplan  *country_ent, u8 swconfig)
  |    ^~~
    /var/lib/dkms/rtl8188fu/1.0/build/core/rtw_cmd.c:2769:6: 
warning: no previous prototype for ‘dynamic_chk_wk_hdl’
[-Wmissing-prototypes]
    2769 | void dynamic_chk_wk_hdl(_adapter *padapter)
  |  ^~
    /var/lib/dkms/rtl8188fu/1.0/build/core/rtw_cmd.c:2963:6:  
warning: no previous prototype for ‘rtw_dm_in_lps_hdl’
[-Wmissing-prototypes]
    2963 | void rtw_dm_in_lps_hdl(_adapter*padapter)
  |  ^
    /var/lib/dkms/rtl8188fu/1.0/build/core/rtw_cmd.c:3004:6:
warning: no previous prototype for ‘rtw_l

Re: LINUX-IMAGE-6.8.11 headers cannot be installed

[Greg Wooledge]

On Tue, Jul 16, 2024 at 19:30:20 -, Prajnanaswaroopa wrote:
> Hello,
> I am using a Kali Linux

https://www.google.com/search?q=kali+linux+support

Re: Linux supprt

[tomas]

On Thu, Nov 16, 2023 at 02:24:05PM -0500, Stefan Monnier wrote:

[...]

> > "You get what you settle for."
> >   -- Thelma and Louise
> 
> I settled for Debian.  Worked out OK 'til now.

This.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Linux supprt

[Stefan Monnier]

>> But mail as "they" know it has nothing to do with transport or
>> networking. They know it as a service not as anything else.
>> Like electricity. The "freedom" to exchange email is what
>> matters to them.
> Especially if they can control that freedom.

I think the "they" above referred to the users/victims.

>> Just about everyone in the developed countries permits and is ok
>> with their electric/telecom/heating service coming from a monopoly,
>> oligoploy, or government-owned entity. So the same situation for
>> email is ok with them as long as the cost is low.
> The difference with utilities like electricity is that they are
> _regulated_ monopolies.

Indeed.

> There is at least a bit of government oversight to make sure the
> electricity provider doesn't gouge its subscribers too badly.

And that they don't sell data about your electricity usage patterns to
the whoever offers the best price.

> In Canada they're threatening to cut off news feeds in retaliation for
> the government's attempts to make them pay news providers for the data
> they're redistributing.  Most people are too ignorant to realize that
> this is an idle threat

It's not an idle threat: (re)distributing news doesn't bring very much
benefits to those giants, so it's definitely in their best commercial
interest to cut it off rather than to pay what the government asks
for it.

> "You get what you settle for."
>   -- Thelma and Louise

I settled for Debian.  Worked out OK 'til now.


Stefan

Re: Linux supprt

[Charlie Gibbs]

On Tue Nov 14 13:25:36 2023 Nicholas Geovanis 
wrote:

> On Mon, Nov 13, 2023, 12:35 PM  wrote:
>
>> But yes, in a way convenience can drown out freedom. See that other
>> thread in this mailing list about mail providers. All people flocking
>> to gmail although it's clear that Google would like to kill mail
>> as we know it.
>
> But mail as "they" know it has nothing to do with transport or
> networking. They know it as a service not as anything else.
> Like electricity. The "freedom" to exchange email is what
> matters to them.

Especially if they can control that freedom.

> Just about everyone in the developed countries permits and is ok
> with their electric/telecom/heating service coming from a monopoly,
> oligoploy, or government-owned entity. So the same situation for
> email is ok with them as long as the cost is low.

The difference with utilities like electricity is that they are
_regulated_ monopolies.  There is at least a bit of government
oversight to make sure the electricity provider doesn't gouge
its subscribers too badly.  Tech giants like Google, etc. are
_unregulated_ monopolies, who can do whatever they want to us
without having the government come after them.  In Canada they're
threatening to cut off news feeds in retaliation for the government's
attempts to make them pay news providers for the data they're
redistributing.  Most people are too ignorant to realize that
this is an idle threat - there are plenty of other sources of
news - but they've already meekly accepted the tech corps. as
de facto monopolies.

"You get what you settle for."
  -- Thelma and Louise

--
/~\  Charlie Gibbs  |  Microsoft is a dictatorship.
\ /|  Apple is a cult.
 X   I'm really at ac.dekanfrus |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

Re: Linux supprt

[tomas]

On Tue, Nov 14, 2023 at 11:36:18AM -0600, Nicholas Geovanis wrote:
> On Mon, Nov 13, 2023, 12:35 PM  wrote:
> 
> >
> > But yes, in a way convenience can drown out freedom [...]

> But mail as "they" know it has nothing to do with transport or networking.
> They know it as a service not as anything else. Like electricity. The
> "freedom" to exchange email is what matters to them.
> 
> Just about everyone in the developed countries permits and is ok with their
> electric/telecom/heating service coming from a monopoly, oligoploy, or
> government-owned entity. So the same situation for email is ok with them as
> long as the cost is low.

These days, snuffing out freedom happens more subtly.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Linux supprt

[Nicholas Geovanis]

On Mon, Nov 13, 2023, 12:35 PM  wrote:

>
> But yes, in a way convenience can drown out freedom. See that other
> thread in this mailing list about mail providers. All people flocking
> to gmail although it's clear that Google would like to kill mail
> as we know it.
>

But mail as "they" know it has nothing to do with transport or networking.
They know it as a service not as anything else. Like electricity. The
"freedom" to exchange email is what matters to them.

Just about everyone in the developed countries permits and is ok with their
electric/telecom/heating service coming from a monopoly, oligoploy, or
government-owned entity. So the same situation for email is ok with them as
long as the cost is low.

Cheers
> --
> t
>

Re: Linux supprt

[Nicholas Geovanis]

On Mon, Nov 13, 2023, 2:56 PM Stefan Monnier 
wrote:

> > In my experience I get much better support from the user community of
> > an open source product then I get from paid support of a commercial
> > product. Frequently I know more about the product than the person I am
> > dealing with.
>
> Same for me.  But I suspect we're in the minority.
>

I'll echo that. And yet in those work situations where I have needed
support for licensed Linux products from Red Hat/IBM, Canonical and AWS,
the support has almost always been better than online community support.
Which of course I have also leaned on. And community support is  better
than 90% + of support for other software products, for example dealing with
BMC recently.

IOW supported Linux seems to be better supported than any other software
these days. Both by vendors and by the community.

Stefan
>
>

Re: Linux supprt

[tomas]

On Mon, Nov 13, 2023 at 08:17:20AM -0600, John Hasler wrote:
>  Stefan Monnier writes:
> > I think this still only covers a small fraction of the problem.  It
> > just lowers the bar of the "technically-inclined" limit.  I think many
> > more people just want to have someone they can call on the phone to
> > help them get through their yearly technical problem.

Very true. Still a long way to go ;-)

> I think that to most people their "devices" (cellphone, desktop,
> whatever) are appliances. They have no more interest in learning about
> the internals of those than in the internals of their washing machines.

In one of our local mailing list someone posted a request for help
to exchange his iPhone's and iPad's batteries. He has an appointment
in the local hacker space :-)

Little by little...

But yes, in a way convenience can drown out freedom. See that other
thread in this mailing list about mail providers. All people flocking
to gmail although it's clear that Google would like to kill mail
as we know it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Linux supprt

[John Hasler]

 Stefan Monnier writes:
> I think this still only covers a small fraction of the problem.  It
> just lowers the bar of the "technically-inclined" limit.  I think many
> more people just want to have someone they can call on the phone to
> help them get through their yearly technical problem.

I think that to most people their "devices" (cellphone, desktop,
whatever) are appliances. They have no more interest in learning about
the internals of those than in the internals of their washing machines.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Linux supprt

[Stefan Monnier]

> In my experience I get much better support from the user community of
> an open source product then I get from paid support of a commercial
> product. Frequently I know more about the product than the person I am
> dealing with.

Same for me.  But I suspect we're in the minority.


Stefan

Re: Linux supprt (was: Hardware for a back up server? [WAS Re: How to use dmsetuup?])

[Larry Martell]

On Mon, Nov 13, 2023 at 7:48 AM Stefan Monnier  wrote:
>
> >> Indeed, technically-inclined people are often better served with Free
> >> Software, and Free Software can also be a great choice for large
> >> corporations who can either have on-site techsupport people or can hire
> >> external support, but it is a lot more difficult to find commercial
> >> support for merely non-techie user.  This is mostly the domain of
> >> proprietary software :-(
> >
> > The way out of this is having strong local user groups, which is,
> > of course, easier in densely populated areas.
>
> I think this still only covers a small fraction of the problem.
> It just lowers the bar of the "technically-inclined" limit.
> I think many more people just want to have someone they can call on
> the phone to help them get through their yearly technical problem.

In my experience I get much better support from the user community of
an open source product then I get from paid support of a commercial
product. Frequently I know more about the product than the person I am
dealing with.

Re: linux-image-amd64: kernel fails to find all nvme SSDs

[Jeffrey Mark Siskind]

Supermicro provided a workaround: boot with the kernel command line
parameter pci=realloc=off.

As an side, Rocky 9.2 does not have this issue even though it boots
without that kernel command line parameter.

Jeff (http://engineering.purdue.edu/~qobi)

Re: linux-image-amd64: kernel fails to find all nvme SSDs

[Andy Smith]

Hi Jeff,

On Sat, Oct 14, 2023 at 05:18:52PM -0400, Jeffrey Mark Siskind wrote:
> I purchased a new server: Supermicro AS-8125GS-TNHR. It has 17 NVME
> drives installed:
> 
> 1x Micron 7450
>12x Micron 9300
> 4x Micron 9400
> 
> Upon boot, /dev/nvme* only shows 10 drives: the Micron 7450, 8 of the
> Micron 9300s, and 1 of the Micron 9400s.

It is strange that you get SOME of all of these drives. If it were
some sort of missing driver issue I'd expect an entire class of
drive to be missing.

I'm wondering if it is worth contacting Supermicro for hardware
support over this.

As there is apparently no version of a packaged Debian kernel that
works for you here, it may be even more worth using the latest
upstream kernel. If things do not work there then I'd pursue matters
with the upstream kernel community rather than Debian, as it seems
likely that the problem exists upstream and will need to be solved
upstream (assuming no actual hardware limitation).

Thanks,
Andy

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

Re: linux-image-amd64: failed to bring up processor 192

[Andy Smith]

Hi,

On Sat, Oct 14, 2023 at 05:15:04PM -0400, Jeffrey Mark Siskind wrote:
> When first installed, it ran kernel 6.1.0.12. That kernel found
> all 384 "CPUs". All were reported in /proc/cpuinfo. I subsequently
> did an apt upgrade which upgraded to 6.1.0.13. Upon boot, dmesg
> -lerr reports:
> 
>root@poto:~# dmesg -lerr
>[   11.080833] smpboot: do_boot_cpu failed(-1) to wakeup CPU#192
> 
> Further, /proc/cpuinfo is missing processor 192.
> 
> I subsequently installed 6.4.0-0-deb12.2-amd64 from bookwork
> backports. The issue still occurs. If I boot 6.1.0.12 I do not get the issue.

I think you should use "reportbug" to report the bug to the kernel
team.

You may like to try building a Debian kernel package from upstream
source:


https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-kernel-org-package

If that results in a package that works for you, that's something to
report in the bug.

If it doesn't, you can go back through the 6.1 kernel releases until
you find one that does work. Then you can report that.

Once you find an upstream source version that doesn't work, you can
use "git bisect" to go back and find the version that DOES work, and
then further bisect things until you find the exact commit that
causes the issue for you.

The Debian kernel team may then be able to backport a fix to the
bookworm stable kernel, and submit it upstream if necessary.

Alternatively, the kernel team may have a way for you to step
through individual changes in between Debian packages 6.1.0.12 and
6.1.0.13.

Good hunting!

Thanks,
Andy

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

Re: Linux source 6.1.38 with Debian patches

[Franco Martelli]

On 12/10/23 at 17:47, Michael Kjörling wrote:

On 12 Oct 2023 17:13 +0200, from martelli...@gmail.com (Franco Martelli):

The system seems rock solid with 6.1.38 so I'm looking for the Linux source
packages of the kernel 6.1.38 that is a previous kernel release of the
current stable distribution (maybe 12.1) does anybody know where can I find
it?


I think you want https://snapshot.debian.org/package/linux-signed-amd64/

More generally, start at https://tracker.debian.org/pkg/linux-signed-amd64
which is linked from https://packages.debian.org/bookworm/linux-image-amd64
as "developer information" in the right-hand side bar.



Thanks for your answer Michael,

No, I didn't find the whole kernel source code under 
"linux-signed-amd64". I don't know for what that files are useful for, 
however what I did was to search "linux-source-6.1" in the binary 
packages section of the [1] Debian snapshot homepage, the resulting page 
lists all 6.1 kernel sources packages.


[1] https://snapshot.debian.org/

--
Franco Martelli

Re: Linux source 6.1.38 with Debian patches

[Michael Kjörling]

On 12 Oct 2023 17:13 +0200, from martelli...@gmail.com (Franco Martelli):
> The system seems rock solid with 6.1.38 so I'm looking for the Linux source
> packages of the kernel 6.1.38 that is a previous kernel release of the
> current stable distribution (maybe 12.1) does anybody know where can I find
> it?

I think you want https://snapshot.debian.org/package/linux-signed-amd64/

More generally, start at https://tracker.debian.org/pkg/linux-signed-amd64
which is linked from https://packages.debian.org/bookworm/linux-image-amd64
as "developer information" in the right-hand side bar.

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

Re: linux kernel versions in stable

[Sven Joachim]

On 2023-04-22 12:13 -0700, Ross Boylan wrote:

> There are many signs of a new kernel version in the latest updates:
> linux-libc-dev, linux-source, linux-kbuild all show an upgrade
> available from 5.10.162-1 to 5.10.178-2.
>
> Conspicuously absent are any of the linux-image packages; the most
> recent ones are 5.10.162-1.  I figured they might just be delayed, but
> https://tracker.debian.org/pkg/linux-signed-amd64 doesn't mention the
> 178 version at all.
>
> What's up?

The problem seems to be that linux did FTBFS on mipsel*[1].

> First, is upgrading the apparently partial list of packages advisable
> without having the kernel against which, I presume, they were built,
> present?

The version of linux-libc-dev usually does not matter.  Upgrading the
other packages probably makes little sense.

> Second, is an upgraded linux-image coming, and where is it?

There has been an upload of linux 5.10.178-3 which seems to attempt to
fix the mipsel* problems[2].  Assuming this builds everywhere, I would
expect uploads of the linux-signed packages to follow shortly
thereafter.

Cheers,
   Sven


1. https://buildd.debian.org/status/package.php?p=linux&suite=bullseye
2. 
https://tracker.debian.org/news/1429652/accepted-linux-510178-3-source-into-proposed-updates/

Re: linux-image-4.19.0-22-amd64

[David]

On Sat, 1 Oct 2022 at 08:39, John Boxall  wrote:
> On 2022-09-30 13:31, Dan Ritter wrote:
> > Marc Auslander wrote:

> >> linux-image-amd64 wants linux-image-4.19.0-22-amd64 but only
> >> linux-image-4.19.0-22-amd64-unsigned show up in a search.

> > linux-image-amd64 is a virtual package that pulls in the
> > specific package that your machine architecture needs.

> I have a similar (same?) problem with my system.
>
> apt list -a --upgradable
> Listing... Done
> linux-image-amd64/oldstable 4.19+105+deb10u17 amd64 [upgradable from: 
> 4.19+105+deb10u16]
> linux-image-amd64/oldstable,now 4.19+105+deb10u16 amd64 [installed,upgradable 
> to: 4.19+105+deb10u17]

> When I try either an "apt upgrade" or "apt full-upgrade", the package is
> not upgraded to "4.19+105+deb10u17".

> Could this be a result of there being no more updates to buster?

Might be this bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021012

Re: linux-image-4.19.0-22-amd64

[John Boxall]

On 2022-09-30 13:31, Dan Ritter wrote:

Marc Auslander wrote:

linux-image-amd64 wants linux-image-4.19.0-22-amd64 but only
linux-image-4.19.0-22-amd64-unsigned show up in a search.



You are on an old version of Debian. Upgrade to the current
stable version or go digging through the archives to get what
you want.

linux-image-amd64 is a virtual package that pulls in the
specific package that your machine architecture needs. You can
apt install linux-image-4.19.0-22-amd64-unsigned  instead.

If you don't use UEFI Secure Boot -- and you probably don't --
the unsigned package does everything you need.

-dsr-




I have a similar (same?) problem with my system.

apt list -a --upgradable
Listing... Done
linux-image-amd64/oldstable 4.19+105+deb10u17 amd64 [upgradable from: 
4.19+105+deb10u16]
linux-image-amd64/oldstable,now 4.19+105+deb10u16 amd64 
[installed,upgradable to: 4.19+105+deb10u17]




dpkg -l | grep linux-image
rc  linux-image-4.19.0-13-amd64  4.19.160-2 
 amd64Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-14-amd64  4.19.171-2 
 amd64Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-16-amd64  4.19.181-1 
 amd64Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-17-amd64  4.19.194-3 
 amd64Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-18-amd64  4.19.208-1 
 amd64Linux 4.19 for 64-bit PCs (signed)
rc  linux-image-4.19.0-19-amd64  4.19.232-1 
 amd64Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-20-amd64  4.19.235-1 
 amd64Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-21-amd64  4.19.249-2 
 amd64Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-amd644.19+105+deb10u16 
 amd64Linux for 64-bit PCs (meta-package)


When I try either an "apt upgrade" or "apt full-upgrade", the package is 
not upgraded to "4.19+105+deb10u17".


Could this be a result of there being no more updates to buster?

--
Regards,

John Boxall

Re: linux-image-4.19.0-22-amd64

[Dan Ritter]

Marc Auslander wrote: 
> linux-image-amd64 wants linux-image-4.19.0-22-amd64 but only
> linux-image-4.19.0-22-amd64-unsigned show up in a search.


You are on an old version of Debian. Upgrade to the current
stable version or go digging through the archives to get what
you want.

linux-image-amd64 is a virtual package that pulls in the
specific package that your machine architecture needs. You can
apt install linux-image-4.19.0-22-amd64-unsigned  instead.

If you don't use UEFI Secure Boot -- and you probably don't --
the unsigned package does everything you need.

-dsr-

Re: linux headers and upgrading nvidia driver

[Andrew M.A. Cater]

On Thu, Sep 15, 2022 at 10:22:09PM +0800, Bret Busby wrote:
> On 15/9/22 21:01, Thomas Anderson wrote:
> > First off, I am running Debian 9, Stretch. I know it is old and I should
> > upgrade and that is something I want to do.
> > 
> > The primary problem is that I have a lot of important systems (email,
> > cloud), and other less important (web host). Simple dist-upgrades have
> > always broken my mail server, that I was not immediately able to recover
> > (fortunately, I had made a backup before). I have tried a couple of
> > times to upgrade, but all attempts have failed. Thus, why I am still
> > stick on 9. I don't like it, and still want to upgrade.
> > 
> > All that said, also I have been stuck on installing a simple nvidia
> > driver, also for months. I can install both the backports version and
> > the downloaded from nvidia version, but a driver can never be loaded
> > because of some linux headers error.  I know nvidia and linux have never
> > been nice to each other.
> > 

You may be able to do an upgrade from 9 to 10 and then reinstall the Nvidia
drivers - at this point, I wouldn't be running a 9 that's internet connected.

> > I think these problems are related.
> > 
> > How can i find the linux header, to point my driver to?
> > 
> > thanks in advance, sorry for the long sob story.
> > 
> 
> Hello.
> 
> Have you tried Ubuntu, with your nvidia stuff?
> 
> I note that you do not specify the nvidia hardware that you have.
> 
> I have two Acer laptops, unfortunately, one of which; my most powerful
> computer that I have, I can no longer boot, after an electricity grid supply
> failure here, in the last few days - the electricity grid supply here, is
> erratic, unstable, unsafe, and, harmful.
> 

Boo - that's a shame.

> The two Acer laptops both have nvidia graphics, and, nvidia Optimus.
> 
> When I got the more powerful one, in about 2013, I could not find a non-MS
> operating system to run the hardware, at first, and, the MS Windows version
> was too difficult to use. After about 18 months (it took me 18 months, to
> get the computer operating, so that I could start using it), I had found
> that only two non-MS operating systems had drivers for the CPU; an i7 of the
> Haskell (?) architecture - dragonflyBSD and Ubuntu Linux, and, of those,
> only Ubuntu Linux had drivers for the nvidia graphics, that ran with
> Optimus.
> 
> My understanding is that, to run Linux, or, any non-MS operating system,
> with nvidia graphics, especially, if you have nvidia Optimus, you need to
> run Ubuntu Linux.
> 
> I do not know whether Debian, as yet, has the drivers to run the nvidia
> graphics, and, in the absence of your nvidia hardware details, I think you
> might need to try running Ubuntu with your hardware.
> 

No, it should run fine - Debian has optimus packages and wiki pages
on how to run everything together. It is really helpful if you can do
a text mode install FIRST and then install the prerequisites for the
Nvidia drivers and at that point install the windowing system using tasksel.

If it fails horribly, that's usually because you've installed a desktop
environment that installs nouveau and fails with odd bugs including lock-ups.

> I am no expert, and, after about 20-25 years of using Linux, I still regard
> myself as a learner - this opinion is based solely on my personal
> experience.
> 
> ..
> Bret Busby
> Armadale
> West Australia
> (UTC+0800)
> ..
> 
All the very best, as ever,

Andy Cater

> 

Re: linux headers and upgrading nvidia driver

[Greg Wooledge]

On Thu, Sep 15, 2022 at 08:34:05PM +0200, Thomas Anderson wrote:
> I tried: sudo apt install linux-headers-$(uname -r)
> 
> says there is some c compiler requirement that is not fulfilled. And, there
> are broken packages that are being held back.

You probably need build-essential then.

> Where is the kernel located anyway?

/boot

Modules are in /lib/modules.

Re: linux headers and upgrading nvidia driver

[Thomas Anderson]

I tried the suggestions mentioned in this thread. I forgot to mention 
the hardware in question. It is a rather modern GTX 1030 low profile 
Nvidia card. it is nothing fancy at all, and would not expect to game 
from it, but that is not what I bought it for. Just wanted more than 
null graphics. Over the past half dozen years, have mostly done things 
over ssh anyway, just wanted something nicer to work on. Admittedly, 
it's not even that important, I have had this issue for maybe a year, 
but when I fired up a new installation this past weekend, in my bid to 
set everything up again, and saw that the card actually works (on a 
clean install), I thought I would give it another go.


I tried: sudo apt install linux-headers-$(uname -r)

says there is some c compiler requirement that is not fulfilled. And, 
there are broken packages that are being held back. I have gone deep 
into this rabbit hole, and still can't seem to find a solution to 
whatever shows up.


Where is the kernel located anyway? The nvidia software, to it's credit, 
has an option flag that will allow me to show the software where the 
kernel is located. I looked where nvidia suggests it should be, don't 
remember off the top of my head, and found an older kernel there, like 
4.9..whatever. But, not the 4.19...version.


I have been using Linux for 20 years, and usually can find a solution, 
but in this particular case, it's possible that my box is just beyond 
repair--at least by me =)


On 15/09/2022 18:37, Paul Johnson wrote:



On Thu, Sep 15, 2022, 09:46 Bret Busby  wrote:

My understanding is that, to run Linux, or, any non-MS operating
system,
with nvidia graphics, especially, if you have nvidia Optimus, you
need
to run Ubuntu Linux.


Have you looked at the Debian wiki?  Because the Nvidia pages do 
correctly show how to set up optimus five different ways.


https://wiki.debian.org/NVIDIA%20Optimus

The default render offload option works perfectly and I wished I 
bothered to try that first instead of fighting constantly with 
Bumblebee, which is both slow and brittle by comparison.

Re: linux headers and upgrading nvidia driver

[Paul Johnson]

On Thu, Sep 15, 2022, 09:46 Bret Busby  wrote:

> My understanding is that, to run Linux, or, any non-MS operating system,
> with nvidia graphics, especially, if you have nvidia Optimus, you need
> to run Ubuntu Linux.
>

Have you looked at the Debian wiki?  Because the Nvidia pages do correctly
show how to set up optimus five different ways.

https://wiki.debian.org/NVIDIA%20Optimus

The default render offload option works perfectly and I wished I bothered
to try that first instead of fighting constantly with Bumblebee, which is
both slow and brittle by comparison.

Re: linux headers and upgrading nvidia driver

[Anssi Saari]

Bret Busby  writes:

> My understanding is that, to run Linux, or, any non-MS operating
> system, with nvidia graphics, especially, if you have nvidia Optimus,
> you need to run Ubuntu Linux.

Maybe in 2012 that was the case? I have 2016 vintage HP zbook gen3 which
worked without issue when I put Debian 11 on it last fall. Nvidia M2000M
video and Optimus, although I'm not clear what this Optimus stuff
does. Video worked poorly with the Nouveau driver so I upgraded to
Nvidia's driver.

External displays work fine, I can connect one to HDMI and another to
Thunderbolt, with a TB to DP adapter cable.

Also, the OP said he has trouble with updating his video driver,
not that his video doesn't work.

Re: linux headers and upgrading nvidia driver

[Charles Curley]

On Thu, 15 Sep 2022 15:01:24 +0200
Thomas Anderson  wrote:

> I have tried a couple of 
> times to upgrade, but all attempts have failed. Thus, why I am still 
> stick on 9. I don't like it, and still want to upgrade.

The only way to upgrade is one major version at a time. In your case, 9
-> 10, then 10 -> 11. It may be less of a PITA to do a new install to
11.

-- 
Does anybody read signatures any more?

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

Re: linux headers and upgrading nvidia driver

[Bret Busby]

On 15/9/22 21:01, Thomas Anderson wrote:
First off, I am running Debian 9, Stretch. I know it is old and I should 
upgrade and that is something I want to do.


The primary problem is that I have a lot of important systems (email, 
cloud), and other less important (web host). Simple dist-upgrades have 
always broken my mail server, that I was not immediately able to recover 
(fortunately, I had made a backup before). I have tried a couple of 
times to upgrade, but all attempts have failed. Thus, why I am still 
stick on 9. I don't like it, and still want to upgrade.


All that said, also I have been stuck on installing a simple nvidia 
driver, also for months. I can install both the backports version and 
the downloaded from nvidia version, but a driver can never be loaded 
because of some linux headers error.  I know nvidia and linux have never 
been nice to each other.


I think these problems are related.

I currently have 4.19.0-0.bpo.amd64 headers. I try rebuilding them, also 
tried going back to 4.9.0-13--but the former still stays. the nvidia 
installer always says it can't find the kernel to build the driver. If 
my system keeps saying it's 4.19.0-0.bpo, why isn't it in the standard 
location? I have tried to locate it, but I cannot find it?


How can i find the linux header, to point my driver to?

thanks in advance, sorry for the long sob story.



Hello.

Have you tried Ubuntu, with your nvidia stuff?

I note that you do not specify the nvidia hardware that you have.

I have two Acer laptops, unfortunately, one of which; my most powerful 
computer that I have, I can no longer boot, after an electricity grid 
supply failure here, in the last few days - the electricity grid supply 
here, is erratic, unstable, unsafe, and, harmful.


The two Acer laptops both have nvidia graphics, and, nvidia Optimus.

When I got the more powerful one, in about 2013, I could not find a 
non-MS operating system to run the hardware, at first, and, the MS 
Windows version was too difficult to use. After about 18 months (it took 
me 18 months, to get the computer operating, so that I could start using 
it), I had found that only two non-MS operating systems had drivers for 
the CPU; an i7 of the Haskell (?) architecture - dragonflyBSD and Ubuntu 
Linux, and, of those, only Ubuntu Linux had drivers for the nvidia 
graphics, that ran with Optimus.


So, as it happened, the only way that I could get the i7 laptop (an Acer 
Aspire V3-772G) to run an external monitor, was to run Ubuntu Linux; at 
that time, v12.04. Prior to getting that computer operational, I had 
been running Debian, on most of my computers.


My understanding is that, to run Linux, or, any non-MS operating system, 
with nvidia graphics, especially, if you have nvidia Optimus, you need 
to run Ubuntu Linux.


I do not know whether Debian, as yet, has the drivers to run the nvidia 
graphics, and, in the absence of your nvidia hardware details, I think 
you might need to try running Ubuntu with your hardware.


I am no expert, and, after about 20-25 years of using Linux, I still 
regard myself as a learner - this opinion is based solely on my personal 
experience.


..
Bret Busby
Armadale
West Australia
(UTC+0800)
..

Re: linux headers and upgrading nvidia driver

[Dan Ritter]

Thomas Anderson wrote: 
> The primary problem is that I have a lot of important systems (email,
> cloud), and other less important (web host). Simple dist-upgrades have
> always broken my mail server, that I was not immediately able to recover
> (fortunately, I had made a backup before). I have tried a couple of times to
> upgrade, but all attempts have failed. Thus, why I am still stick on 9. I
> don't like it, and still want to upgrade.


All legitimate mail servers will retry delivery. If you're
concerned about timeliness, spend $10 and a day on setting up a
cloud VM as a secondary MX. That also gives you experience in 
setting up your mail server software.

-dsr-

Re: linux headers and upgrading nvidia driver

[Greg Wooledge]

On Thu, Sep 15, 2022 at 03:01:24PM +0200, Thomas Anderson wrote:
> How can i find the linux header, to point my driver to?

apt-get install linux-headers-$(uname -r)

Re: Linux problem

[Andrew M.A. Cater]

On Sun, Aug 28, 2022 at 10:59:14PM +0430, Parzival R wrote:
> Hi. Do i have to send my linux freezing problem to you?

Hi Parzival

This is the Debian channel for user support. It does depend whether you
are experiencing problems with Debian - we're quite happy to help with
a range of advice and help from volunteer users.

We would probably need more information to do anything useful, however.

All the very best, as ever,

Andy Cater

Re: Linux cannot find CD Rom

[David Christensen]

On 7/28/22 23:46, Schwibinger Michael wrote:


Hello
I try to open a CD.
But Linux cannot find it.
How can I repair it.
No light
no reaction during putting CD in.



On 7/29/22 08:03, Schwibinger Michael wrote:

> Its HP Deskjet
> Do You need more?
>
> Internal drive
>
> Debian 11
>
> USB Drive is running
> USB Stick is running.
>
>
> Some months ago it did work.


On 7/29/22 08:05, Schwibinger Michael wrote:

> First we did try
>
> commercial Video DVD
>
> Commercial CD
>
> Put DVD in another PC
> no problem.
>
> Put CD into the USB external drive.
>
> No problem.


HP Deskjet is an inkjet printer.  What is the make and model of your 
computer?



Reboot the computer and press the appropriate key to enter the computer 
motherboard firmware (BIOS/UEFI) CMOS Setup program.  Navigate the user 
interface to find a screen that lists installed drives.  Type the exact 
contents of that screen into a reply.



David

Re: Linux cannot find CD Rom

[rhkramer]

On Friday, July 29, 2022 07:51:59 AM Richard Owlett wrote:
> On 07/29/2022 01:46 AM, Schwibinger Michael wrote:
> > Hello
> > I try to open a CD.
> > But Linux cannot find it.

> What hardware are you using?
> Is the CD drive internal or external?
> What "Linux" are you using? This list is for Debian Linux.
> If you have Debian Linux:
>   a. what version do you have?
>   b. where did you obtain it?
>   c. have you had other problems?

I'll just add (or amplify?) one point -- have you tried a variety of CDs?  
Sometimes "burned" CDs, or rewritable CDs (in either case, from some media 
manufacturers will not work, yet a "printed" (that is a CD created in a 
"factory" by "industrial" methods (i.e., not with CD burning software) will 
work.

It would be helpful to know if some CD works va. no CD works -- if some CD 
works, then it is presumably not a software / configuration problem -- if no CD 
works, it could be the hardware (or hardware related -- e.g., is one of the 
cables loose?) to the CD drive.


-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma included at no 
charge.)  If you change topics, change the Subject: line. 

Writing is often meant for others to read (legal agreements excepted?) -- make 
it easier for your reader by various means, including liberal use of 
whitespace.

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: Linux cannot find CD Rom

[Richard Owlett]

On 07/29/2022 01:46 AM, Schwibinger Michael wrote:

Hello
I try to open a CD.
But Linux cannot find it.
How can I repair it.
No light
no reaction during putting CD in.
Thank You
Regards
Sophie



What hardware are you using?
Is the CD drive internal or external?
What "Linux" are you using? This list is for Debian Linux.
If you have Debian Linux:
 a. what version do you have?
 b. where did you obtain it?
 c. have you had other problems?

Re: Linux Kernel 5.16 from Backports Warnings

[piorunz]

On 19/03/2022 04:15, Kevin Exton wrote:

Hi All,

I just installed the latest kernel in the Debian Bullseye backports and
I'm getting these warnings:

W: Possible missing firmware /lib/firmware/i915/skl_guc_62.0.0.bin for
module i915

(...)


Normally the solution to these missing firmware warnings is to install
firmware-misc-nonfree but I guess that hasn't been backported yet?


Most likely that's correct.


Am I going to have to put up with these warnings for a while? Or have I
missed something?


Yep. You can check it yourself. Look where these files supposed to be -
first one off the list:
apt-file search skl_guc_62.0.0.bin

If they are not present in your distribution, then no wonder you don't
have them. They may arrive later at some point to backports to work
together with kernel you just downloaded.

Note: I do have that file (and most likely rest of them also) in Debian
Testing in firmware-misc-nonfree package, as expected.


--
With kindest regards, Piotr.

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

Re: linux kernel and nvidia - never ending story

[Vincent Lefevre]

On 2022-03-07 18:25:54 -0500, Stefan Monnier wrote:
> Obviously it depends who you ask.  The kernel side doesn't consider
> itself to blame because they do expose a "stable" API which Nvidia
> could use.

But note that the Xorg API is not stable. The 340 branch can no longer
be used at least because of that (it is no longer maintained by Nvidia
and does not support the latest Xorg API). Anyway, it is affected by
security issues, so that even if it still worked, this would not be
secure.

My machines are not concerned by the 340 branch, but by the 390 branch,
whose EOL is at the end of the year. So this will be an issue the next
time Xorg modifies its API.

> I encourage you to file bug reports for that and try to help fix the
> problem as best as you can.  It might be worth trying it with a "fresh"
> install since I've heard several reports that Nouveau installations can
> be impacted by the installation of the proprietary Nvidia driver.

It is useless to report bugs against Nouveau. See for instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/23
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/81
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/202
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/534

In particular, I reported Issue 23 in 2012 (almost 10 years ago)
and provided a script reproducing the bug, which was confirmed.
But there was no attempt to fix it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: linux kernel and nvidia - never ending story

[Eric S Fraga]

On Tuesday,  8 Mar 2022 at 22:47, Richmond wrote:
> Now that I have it working I fear to change it.

And this is exactly my modus operandum.  Once I get a system to a stable
productive working state, I leave it alone (except for security issues).

-- 
Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2

Re: linux kernel and nvidia - never ending story

[Richmond]

didier gaumet  writes:

> Le mardi 08 mars 2022 à 12:12 +, Richmond a écrit :
> [...]
>> I don't know if there are
>> any distributions other than debian which still support kernel 4.
>
> A RHEL 8 clone (Almalinux, Rocky Linux...) should do: kernel is blocked
> to 4.18 until EOL in 2029 (end of full support may 2024, other support
> unspecified right now)

Thanks. It looks like there are plenty of distros I have never heard of
to choose from:

https://distrowatch.com/search.php?pkg=linux&relation=similar&pkgver=4.18&distrorange=InLatest#pkgsearch
https://distrowatch.com/search.php?pkg=linux&relation=similar&pkgver=4.19&distrorange=InLatest#pkgsearch

But it will be difficult because not all the ones I have tried in the
past have managed to cope with the additional tv-out feature that I want
to use with nvidia-settings. Now that I have it working I fear to change
it.

Re: linux kernel and nvidia - never ending story

[duh]

On 3/8/22 5:05 AM, to...@tuxteam.de wrote:

On Tue, Mar 08, 2022 at 10:46:35AM +0100, Hans wrote:
No, of course not. It's you to blame, for upgrading your system.



Hilarious!!! (Please bear with me for a moment because it is actually
tragic, but ...)

Why might it be hilarious?. Well, speaking in generalities, typically
when someone has a problem, "popular" comments

in the first response(s) is(are) to provide more information, upgrade to
the latest version of the software -- duh, I am a

little (or should I say very) dense. What is a person to do? Guess write
this reply to the list. Unfortunately most people

will probably not think it is funny.


Actually in the opening post, the writer said he was debating posting.
My response: Thank you!!

The problem he describes is just a specific case within the bigger
problem or the more general case. Often times,

as a person starts making changes, new problems proliferate faster than
they can be solved.


I recently came across a list of 10 code words.

    A couple I remember are:

        id10t

        ip8

Don't think that is an accurate assessment of the situation.

FWIW, there is significant merit to:

    DO NOT UPGRADE!!


Just a thought. Am not intending to hijack the thread. Just pointing out
that the current problem is a subset of

a larger problem.

Once again, thank you for the first post that started this thread. Some
of the viewpoints expressed in reply have been

both interesting and informative -- perhaps not an area with a lot of
occupants on a VENN diagram

Have a good day. Looking forward to continue following (in silence) the
rest of this discussion

Re: linux kernel and nvidia - never ending story

[Alexander V. Makartsev]

On 08.03.2022 14:40, Hans wrote:

Am Dienstag, 8. März 2022, 00:07:05 CET schrieb Alexander V. Makartsev:
Yes, I am sure, no other version is working. It is GeForce G210 and GeForce
G86m, both NEED 340xx.
In that case, I've never actually tried to do it, but since Debian 
support for 340xx version is officially EoL, I think it's ok to install 
officially supported driver¹ from Nvidia.


Or, if you feel adventurous, you can build a backported packages of 
nvidia legacy 340xx driver from buster-backports.
I've always used parts of this guide² and had successfully build 
packages from source³ package and DKMS module was also build 
successfully during package installation.

You can get source package using "dget":
    $ dget 
http://deb.debian.org/debian/pool/non-free/n/nvidia-graphics-drivers-legacy-340xx/nvidia-graphics-drivers-legacy-340xx_340.108-10~bpo10+1.dsc


No code patches were made by me, except changing "changelog" file via 
'dch' and bumping up version numbers.


    $ uname -a
Linux hostname 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) 
x86_64 GNU/Linux


=8<=8<=8<=8<=
...
Setting up nvidia-legacy-340xx-kernel-dkms (340.108-10~bpo11+1) ...
Loading new nvidia-legacy-340xx-340.108 DKMS files...
Building for 5.10.0-11-amd64
Building initial module for 5.10.0-11-amd64
Done.

nvidia-legacy-340xx.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.0-11-amd64/updates/dkms/

nvidia-legacy-340xx-uvm.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.0-11-amd64/updates/dkms/

depmod

DKMS: install completed.
...
=8<=8<=8<=8<=

Here is listing of all build packages for amd64 arch:
=8<=8<=8<=8<=
$ ls -1
libegl1-nvidia-legacy-340xx_340.108-10~bpo11+1_amd64.deb
libgl1-nvidia-legacy-340xx-glx_340.108-10~bpo11+1_amd64.deb
libgles1-nvidia-legacy-340xx_340.108-10~bpo11+1_amd64.deb
libgles2-nvidia-legacy-340xx_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-cfg1_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-compiler_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-cuda1_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-eglcore_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-encode1_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-fbc1_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-glcore_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-ifr1_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-ml1_340.108-10~bpo11+1_amd64.deb
libnvidia-legacy-340xx-nvcuvid1_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-alternative_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-driver_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-driver-bin_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-driver-libs_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-kernel-dkms_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-kernel-source_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-kernel-support_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-opencl-icd_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-smi_340.108-10~bpo11+1_amd64.deb
nvidia-legacy-340xx-vdpau-driver_340.108-10~bpo11+1_amd64.deb
xserver-xorg-video-nvidia-legacy-340xx_340.108-10~bpo11+1_amd64.deb
=8<=8<=8<=8<=

Same listing is for i386 arch too.
To build 32-bit packages the process essentially the same, but you 
(AFAIK still) have to do it under 32-bit environment (chroot, lxc/lxd 
container, VM, etc).


I didn't tested this build on actual hardware yet, but it looks 
promising to me.

Good luck.


¹ https://www.nvidia.co.uk/Download/driverResults.aspx/156193/en-uk
² https://wiki.debian.org/SimpleBackportCreation
³ 
https://packages.debian.org/buster-backports/nvidia-legacy-340xx-kernel-dkms


--
With kindest regards, Alexander.

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

Re: linux kernel and nvidia - never ending story

[didier gaumet]

Le mardi 08 mars 2022 à 12:12 +, Richmond a écrit :
[...]
> I don't know if there are
> any distributions other than debian which still support kernel 4.

A RHEL 8 clone (Almalinux, Rocky Linux...) should do: kernel is blocked
to 4.18 until EOL in 2029 (end of full support may 2024, other support
unspecified right now)

Re: linux kernel and nvidia - never ending story

[Richmond]

Hans  writes:

> Dear list,
>
> how find the correct words, without being upset or stepping on
> someones feet.  But I believe, debian hates Nvidia, and debian does
> not want, to use Nvidia.
>
> I am now for a long time using debian and also using nvidia graphic
> cards for almost the same long time.
>
> But whenever debian ships a new kernel version, the proprietrary
> nvidia kernel modules can not be built. If lucky, there is a patch for
> it after months.
>
> Yes, modern Nvidia cards are supported, but using an older notebook
> you can not change the graphics card.
>
> But this is not a problem of Nvidia, not IMO it is a problem with the
> kernel developers. Suddenly, with a kernel the gcc was updated, oh,
> now the kernel module does not want it any more. Wtf? Or, with the new
> kernel, the kernel module crashes during building, but builds
> perfectly at the older kernel.
>
> And suddenly the kernel modul of nvidia disappears completely from the
> repo, problems solved? Get lost, you foolish users with old hardware,
> buy new hardware! What???
>
> Oh, and when someone says: Hey, use the nouveau driver, then tell him,
> nouveau is not working.
>
> I have several older notebooks, that my customers use. They worked
> perfectly with the proprietrary driver from Nvidia. But after update
> to bullseye, it was hardly get them running again. And why? They have
> an old graphics card in their notebooks, and they use Nvidia cards,
> specially the legacy 340xx.
>
> But:
>
> 1. no problem, Install nvidia kernel 340xx, oh no, it is no more in
> the repo, but
>
> 2. no problem, hey, use nouveau, oh no, nouveau crashes and freezes X,
> but
>
> 3. no problem, build just the downloaded 340xx from buster, oh no,
> does not build, wrong gcc installed, gcc to new, but
>
> 4. no problem, just downgrade gcc to the old one, oh no, many other
> packages need to be deinstalled, too, but
>
> 5. no problem, just do it, oh no, does not build with the latest
> kernel, but
>
> 6. no problem, just downgrade the kernel, too, oh no, no kernel from
> bullseye is working, but
>
> 7. no problem, just reactivate buster and install latest kernel from
> buster, and oh yes,
>
> 8. old kernel from buster let build 340xx, but oh no, kernel old...
>
> Well, I and these procedures are now accompanies me since years. New
> kernel, and building fails. Youu feel lost, you feel anger, can you
> believe me?
>
> In earlier times, debian potato and so, there were always prebuild
> kernel modules for graphic cards, Nvidia or AMD or whatever. Today
> these are gone, and people with older cards are lost. IMO here debian
> lost a lots of its quality.
>
> I thought a long time, if I should write this, and maybe I have not
> found the correct words. I do not want to harsh anyone or attack
> anyone, you know what I mean.
>
> But I felt in my heart, I had to say it.
>
> Please apologize, if someone is feeling agry about me now, this was
> not intended. And thanks for reading this.
>

I am in the same position as you. One of my laptops has an old Nvidia
card, so it is stuck on debian 10. But this isn't unique to debian, it
also applies to OpenSUSE which I also have on there dual booting, and
that cannot be upgraded either. It has to stay on the version 4 kernel,
and from what I read at the time this is because Nvidia will not support
later kernels 5+ . So it is ok until long term support ends, but then I
don't know what to do. Nouveau is unstable. I don't know if there are
any distributions other than debian which still support kernel 4.

Re: linux kernel and nvidia - never ending story

[tomas]

On Tue, Mar 08, 2022 at 06:25:54AM -0500, Dan Ritter wrote:
> to...@tuxteam.de wrote: 

[...]

> > (Sorry for the irony, but see, if NVIDIA's sources reference parts of
> > the kernel headers which aren't guaranteed to stay stable, well...)

> There is also the problem that NVidia has no incentive to keep purchasers
> of their hardware happy over the long term [...]

Exactly.

> Now, could NVidia have chosen another path? Certainly [...]

Once I understood that, I decided to not buy NVIDIA.

> I don't blame Hans for picking the wrong vendor. I did that too
> for a while. In that situation, talking to the Nouveau people is
> probably the best bet, other than buying a new graphics card
> from someone else -- and that's expensive this year.

No, nobody's to blame for that. Since a functional computer almost
always implies some "wrong vendor" at some place. I'm a bit miffed
by Hans throwing blame at those who deserve it the least (and he
even anticipates it: that makes it a bit stranger). Perhaps because
it's more difficult yelling at NVIDIA? I don't know.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: linux kernel and nvidia - never ending story

[Dan Ritter]

to...@tuxteam.de wrote: 
> On Tue, Mar 08, 2022 at 10:46:35AM +0100, Hans wrote:
> > Am Dienstag, 8. März 2022, 00:25:54 CET schrieb Stefan Monnier:
> > No, you are completzely wrong! It is not Nvidia to blam,e when COMPILING 
> > fails! [...]
> 
> No, of course not. It's you to blame, for upgrading your system.
> 
> Just stay with your old kernel, header files and toolchain and all will
> be well.
> 
> (Sorry for the irony, but see, if NVIDIA's sources reference parts of
> the kernel headers which aren't guaranteed to stay stable, well...)
>

There is also the problem that NVidia has no incentive to keep purchasers
of their hardware happy over the long term: the people who buy low-end
cards are not worth the profit margin dip caused by supporting them;
the people who buy high-end cards will continue to buy whatever the
magazines say are fastest this season, and businesses mostly run Windows.

Now, could NVidia have chosen another path? Certainly. There are
at least two more existence proofs: Intel decided that they
would open-source their drivers and not even pretend to be
competitive: for the last decade, nobody has purchased Intel
graphics cards. People buy Intel CPUs and get a just-good-enough
GPU embedded.

And over at AMD, they open-sourced their graphics drivers to
call functions in a big firmware blob, so the drivers need
minimal work each year.

I don't blame Hans for picking the wrong vendor. I did that too
for a while. In that situation, talking to the Nouveau people is
probably the best bet, other than buying a new graphics card
from someone else -- and that's expensive this year.

-dsr-

Re: linux kernel and nvidia - never ending story

[tomas]

On Tue, Mar 08, 2022 at 10:46:35AM +0100, Hans wrote:
> Am Dienstag, 8. März 2022, 00:25:54 CET schrieb Stefan Monnier:
> No, you are completzely wrong! It is not Nvidia to blam,e when COMPILING 
> fails! [...]

No, of course not. It's you to blame, for upgrading your system.

Just stay with your old kernel, header files and toolchain and all will
be well.

(Sorry for the irony, but see, if NVIDIA's sources reference parts of
the kernel headers which aren't guaranteed to stay stable, well...)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: linux kernel and nvidia - never ending story

[Hans]

Am Dienstag, 8. März 2022, 00:25:54 CET schrieb Stefan Monnier:
No, you are completzely wrong! It is not Nvidia to blam,e when COMPILING 
fails! It is NOT Nvidia to blame, when the packages are REMOVED from the repo, 
because your KERNEL breaks the compiling! And it is NOT Nvidia to blame, when 
the nouveau driver CRASHES! And it is NOT Nvidia to blame, when the new kernel 
BREAKS the compiler!

NO, it is not Nvidia to blame, that is just lame excuse. I know exactly,. whom 
to blame, but I do not tell it here.

Best

Hans 
> > Oh, no, this I see not this way. When there is a new kernel shipped,
> > I expect  that this does not break the system!
> 
> That's indeed what the kernel team aims for.
> 
> > I expect that at least the code, that is already existent, builds.
> 
> Problem is: even the "minor" changes of kernel bug fixes done within
> a stable release ... change the code.  By definition.
> 
> So they do incur the risk of breaking existing code.  To avoid this
> problem, bug fixes make as few changes as possible, but when the third
> party code relies on details considered internal to the kernel, this may
> sometimes break.
> 
> The kernel team would be much happier if they could work *with* Nvidia
> to avoid those problems.  But that would require Nvidia be more open
> about its code.
> 
> > This does NOT work., as I told.  The drivers from the nvidia site do
> > no more  build with a new kernel version.  Who is then to blame?
> 
> Obviously it depends who you ask.  The kernel side doesn't consider
> itself to blame because they do expose a "stable" API which Nvidia
> could use.
> 
> > It is the kernel that changed, who breaks the system, not the driver,
> > who has NOT chenged!
> 
> Not necessarily.  Maybe the part that did not change relied on a bug in
> the kernel, so there might have been no easy way to fix the bug without
> breaking the third party code.
> 
> >> 5. I only now realize that your card is actually too OLD, sorry. What
> >> should I say, the latest release of the 340 branch from nvidia is dating
> >> back to 2019.12.23. If they dont support their older products anymore
> >> themselves, do you expect Debian to hack their closed source driver?
> > 
> > And what? 3 years is too old???
> 
> Tell that to Nvidia.
> I have no such problems with my >10 year old AMD and Intel graphics cards.
> 
> > I do not expect the drivers to be improved,  but I expect, that the
> > drivers can be used further on!
> 
> The kernel changes.  If you want a driver to "survive" it will need to
> adapt.  Commercial interest will inevitably wane after a few years, so
> the only way it can last more than 3-5 years is if the code is Free
> Software so other people can pick up maintenance.
> 
> > This is not to few to be expected, isn't it?
> 
> Nowadays I consider a computer's expected lifetime to be at least 10 years.
> 
> >> 6. If nvidia would only be a little bit more cooperative, nouveau would
> >> be in a much better state. I found it usable for older cards, although
> >> the prorietary driver is of course much better in terms of performance
> >> and power saving.
> > 
> > As I wrote, please read it again: The nouveau driver does not work for
> > this
> > card, X is totally unstable and so often freezing, that it can not be
> > used.
> 
> I encourage you to file bug reports for that and try to help fix the
> problem as best as you can.  It might be worth trying it with a "fresh"
> install since I've heard several reports that Nouveau installations can
> be impacted by the installation of the proprietary Nvidia driver.
> 
> > Did I tell, it is debian/stable?
> 
> FWIW, the "stable" in the name doesn't refer to a claim that the
> resulting systems run reliably, but that they try to avoid behavioral
> changes within a given stable release.
> 
> Obviously, they're having trouble reaching this goal w.r.t compatibility
> with proprietary third party kernel modules.
> 
> >> 7. Intel (what I use these days) and AMD support Linux in a much cleaner
> >> way, avoiding many of the problems with the nvidia blob.
> > 
> > Yes, may be, but who cares.  As I wrote, it is not possible, to change the
> > graphics card in noterbooks.
> 
> No, but you can choose the card in the next laptop you buy (and in
> those you recommend others).
> 
> > Why shhould one? Shall I tell all customers, "Hey, throw away your
> > 5 or 8 year  old stuff!", which yesterday worked well and today, after
> > an upgrade does no  more, because a simple driver can not be compiled?
> > No, that is the wrong way!
> 
> Agreed.  Much better is to work with those who try to keep this hardware
> working with the rest of the software.  In the case of Nvidia cards,
> this is the Nouveau team.
> 
> Noone but Nvidia can do that for the proprietary driver.
> 
> 
> Stefan

Re: linux kernel and nvidia - never ending story

[Hans]

Am Dienstag, 8. März 2022, 00:07:05 CET schrieb Alexander V. Makartsev:
Yes, I am sure, no other version is working. It is GeForce G210 and GeForce 
G86m, both NEED 340xx.

Best 

Hans

> On 07.03.2022 23:49, Hans wrote:
> > Dear list,
> > 
> > how find the correct words, without being upset or stepping on someones
> > feet. But I believe, debian hates Nvidia, and debian does not want, to
> > use Nvidia.
> > 
> > I am now for a long time using debian and also using nvidia graphic cards
> > for almost the same long time.
> > 
> > But whenever debian ships a new kernel version, the proprietrary nvidia
> > kernel modules can not be built. If lucky, there is a patch for it after
> > months.
> > 
> > Yes, modern Nvidia cards are supported, but using an older notebook you
> > can
> > not change the graphics card.
> > ...
> > I have several older notebooks, that my customers use. They worked
> > perfectly with the proprietrary driver from Nvidia. But after update to
> > bullseye, it was hardly get them running again. And why? They have an old
> > graphics card in their notebooks, and they use Nvidia cards, specially
> > the legacy 340xx.
> Out of curiosity, can you name a model of nvidia GPU(-s) you have
> trouble with?
> Are you sure you need legacy 340xx driver specifically? That version is
> for hardware that was released in 2009-2010 and older.
> I think there is a chance you can install legacy 390xx version instead.
> You can use 'nvidia-detect' program to check your hardware and get a
> driver version recommendation.

Re: linux kernel and nvidia - never ending story

[Felix Miata]

Stefan Monnier composed on 2022-03-07 18:25 (UTC-0500):

> I've heard several reports that Nouveau installations can
> be impacted by the installation of the proprietary Nvidia driver.

I believe this happens due to incomplete purging of all effects of having
attempted to install, or succeeding to install, then "removing", NVidia's
proprietary drivers. I have a bunch of old NVidia cards, 8 years old and older.
All are running purely on FOSS:

1-the nouveau kernel device driver/module

2-the modesetting DIX display device driver (usually; optionally: nouveau DDX)

#2 is the upstream default for AMD, Intel and NVidia GPUs. Unlike the
reverse-engineered, old, "experimental" and optional nouveau DDX display driver
from package xserver-xorg-video-nouveau, the modesetting DIX is newer 
technology,
and less dependent on device specifications NVidia withholds from FOSS 
developers.

Other than for the issue reported at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006907
the FOSS drivers nouveau (module)/modesetting (DIX)/nouveau (DDX) provided by
Debian are fully suited to the needs of all my NVidia GPUs.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: linux kernel and nvidia - never ending story

[Alexander V. Makartsev]

On 07.03.2022 23:49, Hans wrote:

Dear list,

how find the correct words, without being upset or stepping on someones feet.
But I believe, debian hates Nvidia, and debian does not want, to use Nvidia.

I am now for a long time using debian and also using nvidia graphic cards for
almost the same long time.

But whenever debian ships a new kernel version, the proprietrary nvidia kernel
modules can not be built. If lucky, there is a patch for it after months.

Yes, modern Nvidia cards are supported, but using an older notebook you can
not change the graphics card.
...
I have several older notebooks, that my customers use. They worked perfectly
with the proprietrary driver from Nvidia. But after update to bullseye, it was
hardly get them running again. And why? They have an old graphics card in
their notebooks, and they use Nvidia cards, specially the legacy 340xx.
Out of curiosity, can you name a model of nvidia GPU(-s) you have 
trouble with?
Are you sure you need legacy 340xx driver specifically? That version is 
for hardware that was released in 2009-2010 and older.

I think there is a chance you can install legacy 390xx version instead.
You can use 'nvidia-detect' program to check your hardware and get a 
driver version recommendation.



--
With kindest regards, Alexander.

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

Re: linux kernel and nvidia - never ending story

[Hans]

Am Montag, 7. März 2022, 20:46:40 CET schrieb Christian Britz:
Hi Christian, 

I feel to answer your post and have to correct some of your essays.
> Hello Hans,
> 
> I understand your frustration, I was also frustrated sometimes back when
> I used nVidia, but IMO Debian is not to blame here, the situation is
> completely the responsibility of nVidia.
> 
> 0. After reading your post again, I realize that sections 1 to 4 of my
> reply do not really apply to your situation. I leave them in my text
> though, because in my opionion they describe the general problem with
> nvidia quite well.
> 

Yes, good idea.

> 1. You are probably not talking about Debian stable and the kernel that
> ships with it. I have not checked, but the binary nVidia packages almost
> certainly have not disappeared from Debian stable non-free within a
> release cycle. Nothing should have broken with the latest dot kernel
> update. If you have problems, please specify further. Testing/unstable
> may break at any time, you have to deal with that, especially when using
> non-free software, which can only be fixed to a certain amount by the
> maintainers.

No, I DO talk about debian/stable! And when I mean stable, I talk about 
bullseye. I expect bullseye to work.
> 
> 2. If you are talking about kernels newer than the one in Debian stable,
> the problem is a problem by design that can and will happen with every
> Linux distribution. The reason is simply that the kernel interfaces
> which nVidia uses are not stable and were never intended to be used by
> non-free software. Eventually, nVidia will adapt their interface module
> and release a new driver package. Eventually, this will be integrated in
> Debian non-free. It is a race between the kernel developers and the
> nvidia developers, which nvidia never can win. If at all, you can blame
> Linus and the developers for not providing a stable interface for
> proprietary non-free software. I fear they will laugh at you, at best.
> Some kernel developers even have the opinion that it is a GPL violation
> what nvidia does.

Oh, no, this I see not this way. When there is a new kernel shipped, I expect 
that this does not break the system! I expect that at least the code, that is 
already existent, builds. This is not too much expected! Why is it called 
stable???


> 
> 3. If you are not satisfied how fast updated nvidia drivers are
> integrated into testing/unstable, you could always install the drivers
> manually from the website of nvidia. It is not very hard to do if you
> are used to Linux.
> 

This does NOT work., as I told. The drivers from the nvidia site do no more 
build with a new kernel version. Who is then to blame? Those, who change the 
kernel or those who do not change the drivers?  It is the kernel that changed, 
who breaks the system, not the driver, who has NOT chenged!

> 4. Given the circumstances, I feel the nvidia integration in Debian
> quite smooth, on stable it works almost out of the box (if your card is
> not too new, but that is a general issue with the stable concept of Debian).
Agreed! If you get the driver compiled, then it is working very well, if you 
get it compiled. 

> 
> 5. I only now realize that your card is actually too OLD, sorry. What
> should I say, the latest release of the 340 branch from nvidia is dating
> back to 2019.12.23. If they dont support their older products anymore
> themselves, do you expect Debian to hack their closed source driver?
> 

And what? 3 years is too old??? I do not expect the drivers to be improved, 
but I expect, that the drivers can be used further on! This is not to few to 
be expected, isn't it?

> 6. If nvidia would only be a little bit more cooperative, nouveau would
> be in a much better state. I found it usable for older cards, although
> the prorietary driver is of course much better in terms of performance
> and power saving.
> 

As I wrote, please read it again: The nouveau driver does not work for this 
card, X is totally unstable and so often freezing, that it can not be used. 
Did I tell, it is debian/stable? 

> 7. Intel (what I use these days) and AMD support Linux in a much cleaner
> way, avoiding many of the problems with the nvidia blob.
> 
Yes, may be, but who cares. As I wrote, it is not possible, to change the 
graphics card in noterbooks.

> 8. If you buy a system with the goal to use it over many years, I can
> only reccomend to choose hardware components wich can be well supported
> by free drivers. Please support companies that support Linux well, like
> Intel and AMD.
> 

Why shhould one? Shall I tell all customers, "Hey, throw away your 5 or 8 year 
old stuff!", which yesterday worked well and today, after an upgrade does no 
more, because a simple driver can not be compiled? No, that is the wrong way!

The whole story with Nvidia-modules is shit, and even when I no come into the 
doghouse, IMO it is NOT the fault of Nvidia, how the developers always try to 
tell! Someone ist just closing the 

Re: linux kernel and nvidia - never ending story

[Christian Britz]

Hello Hans,

I understand your frustration, I was also frustrated sometimes back when
I used nVidia, but IMO Debian is not to blame here, the situation is
completely the responsibility of nVidia.

0. After reading your post again, I realize that sections 1 to 4 of my
reply do not really apply to your situation. I leave them in my text
though, because in my opionion they describe the general problem with
nvidia quite well.

1. You are probably not talking about Debian stable and the kernel that
ships with it. I have not checked, but the binary nVidia packages almost
certainly have not disappeared from Debian stable non-free within a
release cycle. Nothing should have broken with the latest dot kernel
update. If you have problems, please specify further. Testing/unstable
may break at any time, you have to deal with that, especially when using
non-free software, which can only be fixed to a certain amount by the
maintainers.

2. If you are talking about kernels newer than the one in Debian stable,
the problem is a problem by design that can and will happen with every
Linux distribution. The reason is simply that the kernel interfaces
which nVidia uses are not stable and were never intended to be used by
non-free software. Eventually, nVidia will adapt their interface module
and release a new driver package. Eventually, this will be integrated in
Debian non-free. It is a race between the kernel developers and the
nvidia developers, which nvidia never can win. If at all, you can blame
Linus and the developers for not providing a stable interface for
proprietary non-free software. I fear they will laugh at you, at best.
Some kernel developers even have the opinion that it is a GPL violation
what nvidia does.

3. If you are not satisfied how fast updated nvidia drivers are
integrated into testing/unstable, you could always install the drivers
manually from the website of nvidia. It is not very hard to do if you
are used to Linux.

4. Given the circumstances, I feel the nvidia integration in Debian
quite smooth, on stable it works almost out of the box (if your card is
not too new, but that is a general issue with the stable concept of Debian).

5. I only now realize that your card is actually too OLD, sorry. What
should I say, the latest release of the 340 branch from nvidia is dating
back to 2019.12.23. If they dont support their older products anymore
themselves, do you expect Debian to hack their closed source driver?

6. If nvidia would only be a little bit more cooperative, nouveau would
be in a much better state. I found it usable for older cards, although
the prorietary driver is of course much better in terms of performance
and power saving.

7. Intel (what I use these days) and AMD support Linux in a much cleaner
way, avoiding many of the problems with the nvidia blob.

8. If you buy a system with the goal to use it over many years, I can
only reccomend to choose hardware components wich can be well supported
by free drivers. Please support companies that support Linux well, like
Intel and AMD.

Best Regards,
Christian



On 2022-03-07 19:49 UTC+0100, Hans wrote:
> Dear list,
> 
> how find the correct words, without being upset or stepping on someones feet.
> But I believe, debian hates Nvidia, and debian does not want, to use Nvidia.
> 
> I am now for a long time using debian and also using nvidia graphic cards for 
> almost the same long time. 
> 
> But whenever debian ships a new kernel version, the proprietrary nvidia 
> kernel 
> modules can not be built. If lucky, there is a patch for it after months.
> 
> Yes, modern Nvidia cards are supported, but using an older notebook you can 
> not change the graphics card. 
> 
> But this is not a problem of Nvidia, not IMO it is a problem with the kernel 
> developers. Suddenly, with a  kernel the gcc was updated, oh, now the kernel 
> module does not want it any more. Wtf? Or, with the new kernel, the kernel 
> module crashes during building, but builds perfectly at the older kernel.
> 
> And suddenly the kernel modul of nvidia disappears completely from the repo, 
> problems solved? Get lost, you foolish users with old hardware, buy new 
> hardware! What???
> 
> Oh, and when someone says: Hey, use the nouveau driver, then tell him, 
> nouveau 
> is not working.
> 
> I have several older notebooks, that my customers use. They worked perfectly 
> with the proprietrary driver from Nvidia. But after update to bullseye, it 
> was 
> hardly get them running again. And why? They have an old graphics card in 
> their notebooks, and they use Nvidia cards, specially the legacy 340xx.
> 
> But: 
> 
> 1. no problem, Install nvidia kernel 340xx, oh no, it is no more in the repo, 
> but 
> 
> 2. no problem, hey, use nouveau, oh no, nouveau crashes and freezes X, but
> 
> 3. no problem, build just the downloaded 340xx from buster, oh no, does not 
> build, wrong gcc installed, gcc to new, but
> 
> 4. no problem, just downgrade gcc to the old one, oh no, many other packag

Re: linux-image-amd64 (5.10.84-1)

[Andrei POPESCU]

On Ma, 21 dec 21, 15:01:27, phil995511 - wrote:
> 
> I had to force the installation of the  5.10.84-1 kernel with this command :
> 
> apt update && apt install linux-image-amd64 -y && apt install
> linux-headers-amd64 -y && apt install firmware-linux firmware-linux-nonfree
> 
> I'm afraid I will have the same problem in the future...

Check the output of

apt list -a linux-image-amd64


You should have the version in stable(-security) installed, in which 
case the next upgrade should work automatically.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: linux-image-amd64 (5.10.84-1)

[Andrew M.A. Cater]

On Tue, Dec 21, 2021 at 03:01:27PM +0100, phil995511 - wrote:
> Hello Andy,
> 
> After tests on my Debian 11 virtual machine, the installation of the new
> upgraded kernel  is ok.
> 
> philippe@station:~$ uname -a
> Linux station 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64
> GNU/Linux
> 
> But on my workstation it's problematic !?
> 
> A few weeks ago I installed the 5.14 backports kernel on this PC, but since
> the Nvidia 460.91.03-1: amd64 arm64 driver does not work with this kernel,
> I have uninstalled this backports kernel manually.
> 
> However I did not modify the default installation of the kernel
> 5.10.70-1. After
> this, the upgrade to Debian 5.10.84-1 not work.
> 
> 
> I had to force the installation of the  5.10.84-1 kernel with this command :
> 
> apt update && apt install linux-image-amd64 -y && apt install
> linux-headers-amd64 -y && apt install firmware-linux firmware-linux-nonfree
> 
> I'm afraid I will have the same problem in the future...
> 
> My source list is ok :
> 
> philippe@station:~$ cat /etc/apt/sources.list
> # deb cdrom:[Debian GNU/Linux 11.0.0 _Bullseye_ - Unofficial amd64 DVD
> Binary-1 with firmware 20210814-10:10]/ bullseye contrib main non-free
> #
> # deb cdrom:[Debian GNU/Linux 11.0.0 _Bullseye_ - Unofficial amd64 DVD
> Binary-1 with firmware 20210814-10:10]/ bullseye contrib main non-free
> #
> #
> # Bullseye base repository
> deb https://deb.debian.org/debian/ bullseye main contrib non-free
> deb-src https://ftp.debian.org/debian/ bullseye main contrib non-free
> #
> # Bullseye-updates
> deb https://deb.debian.org/debian/ bullseye-updates main contrib non-free
> deb-src https://deb.debian.org/debian/ bullseye-updates main contrib
> non-free
> #
> # Security updates
> deb https://security.debian.org/debian-security bullseye-security main
> contrib non-free
> deb-src https://security.debian.org/debian-security bullseye-security main
> contrib non-free
> #
> # Backports
> deb https://deb.debian.org/debian bullseye-backports main contrib non-free
> deb-src https://deb.debian.org/debian bullseye-backports main contrib
> non-free
> #
> # Testing
> # deb https://deb.debian.org/debian/ testing main non-free contrib
> # deb-src https://deb.debian.org/debian/ testing main non-free contrib
> #
> # Testing security updates
> # deb https://deb.debian.org/debian/ testing-security main non-free contrib
> # deb-src https://deb.debian.org/debian/ testing-security main non-free
> contrib
> #
> # Sid (unstable)
> # deb https://deb.debian.org/debian/ sid main non-free contrib
> # deb-src https://deb.debian.org/debian/ sid main non-free contrib
> 
> Best regards.
> 
> Philippe
> 

Purge the 5.14 kernel - dpkg --purge [package name] - then comment out
the backports lines entirely.

Then apt-get update ; apt-get dist-upgrade to bring yourself definitely
up to 11.2 - that should sort it out, I think.

All the very best, as ever,

Andy Cater
> 
> 
> 
> Le mar. 21 déc. 2021 à 13:24, Andy Smith  a écrit :
> 
> > Hi Philippe,
> >
> > This is probably more of a debian-user question - let's continue
> > there.
> >
> > On Tue, Dec 21, 2021 at 11:43:28AM +0100, phil995511 - wrote:
> > > Hello,
> > >
> > > The linux-image-amd64 (5.10.84-1) are announced from something days on
> > this
> > > page :
> > >
> > > https://packages.debian.org/fr/linux-image-amd64
> > >
> > > https://packages.debian.org/fr/bullseye/linux-image-amd64
> > >
> > > But the deployment on our machines did not take place !? We are still in
> > > the old version :
> > >
> > > root@station:~# uname -a
> > > Linux station 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64
> > > GNU/Linux
> >
> > My bullseye machines have been offered the updated package so it
> > seems likely there is a problem with or misunderstanding about your
> > setup.
> >
> > Can you show us the output of:
> >
> > $ dpkg-query --show linux-image-amd64
> > $ dpkg-query --show linux-image-5.10.0-10-amd64
> > $ cat /etc/apt/sources.list
> >
> > please?
> >
> > On my bullseye systems, linux-image-amd64 is at version 5.10.84-1
> > and this depends upon linux-image-5.10.0-10-amd64 version 5.10.84-1.
> >
> > Thanks,
> > Andy
> >
> > > Has the person responsible for maintaining this repository not forgotten
> > to
> > > update the list of upgraded files available for our machines so that our
> > > PCs are up to date ? He should be provided with a procedure to follow if
> > > this is the case...
> > >
> > > You would be very kind to resolve this.
> > >
> > > Happy end of year celebrations to you.
> > >
> > > Philippe
> >

Re: linux-image-amd64 (5.10.84-1)

[phil995511 -]

Hello Andy,

After tests on my Debian 11 virtual machine, the installation of the new
upgraded kernel  is ok.

philippe@station:~$ uname -a
Linux station 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64
GNU/Linux

But on my workstation it's problematic !?

A few weeks ago I installed the 5.14 backports kernel on this PC, but since
the Nvidia 460.91.03-1: amd64 arm64 driver does not work with this kernel,
I have uninstalled this backports kernel manually.

However I did not modify the default installation of the kernel
5.10.70-1. After
this, the upgrade to Debian 5.10.84-1 not work.


I had to force the installation of the  5.10.84-1 kernel with this command :

apt update && apt install linux-image-amd64 -y && apt install
linux-headers-amd64 -y && apt install firmware-linux firmware-linux-nonfree

I'm afraid I will have the same problem in the future...

My source list is ok :

philippe@station:~$ cat /etc/apt/sources.list
# deb cdrom:[Debian GNU/Linux 11.0.0 _Bullseye_ - Unofficial amd64 DVD
Binary-1 with firmware 20210814-10:10]/ bullseye contrib main non-free
#
# deb cdrom:[Debian GNU/Linux 11.0.0 _Bullseye_ - Unofficial amd64 DVD
Binary-1 with firmware 20210814-10:10]/ bullseye contrib main non-free
#
#
# Bullseye base repository
deb https://deb.debian.org/debian/ bullseye main contrib non-free
deb-src https://ftp.debian.org/debian/ bullseye main contrib non-free
#
# Bullseye-updates
deb https://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb-src https://deb.debian.org/debian/ bullseye-updates main contrib
non-free
#
# Security updates
deb https://security.debian.org/debian-security bullseye-security main
contrib non-free
deb-src https://security.debian.org/debian-security bullseye-security main
contrib non-free
#
# Backports
deb https://deb.debian.org/debian bullseye-backports main contrib non-free
deb-src https://deb.debian.org/debian bullseye-backports main contrib
non-free
#
# Testing
# deb https://deb.debian.org/debian/ testing main non-free contrib
# deb-src https://deb.debian.org/debian/ testing main non-free contrib
#
# Testing security updates
# deb https://deb.debian.org/debian/ testing-security main non-free contrib
# deb-src https://deb.debian.org/debian/ testing-security main non-free
contrib
#
# Sid (unstable)
# deb https://deb.debian.org/debian/ sid main non-free contrib
# deb-src https://deb.debian.org/debian/ sid main non-free contrib

Best regards.

Philippe




Le mar. 21 déc. 2021 à 13:24, Andy Smith  a écrit :

> Hi Philippe,
>
> This is probably more of a debian-user question - let's continue
> there.
>
> On Tue, Dec 21, 2021 at 11:43:28AM +0100, phil995511 - wrote:
> > Hello,
> >
> > The linux-image-amd64 (5.10.84-1) are announced from something days on
> this
> > page :
> >
> > https://packages.debian.org/fr/linux-image-amd64
> >
> > https://packages.debian.org/fr/bullseye/linux-image-amd64
> >
> > But the deployment on our machines did not take place !? We are still in
> > the old version :
> >
> > root@station:~# uname -a
> > Linux station 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64
> > GNU/Linux
>
> My bullseye machines have been offered the updated package so it
> seems likely there is a problem with or misunderstanding about your
> setup.
>
> Can you show us the output of:
>
> $ dpkg-query --show linux-image-amd64
> $ dpkg-query --show linux-image-5.10.0-10-amd64
> $ cat /etc/apt/sources.list
>
> please?
>
> On my bullseye systems, linux-image-amd64 is at version 5.10.84-1
> and this depends upon linux-image-5.10.0-10-amd64 version 5.10.84-1.
>
> Thanks,
> Andy
>
> > Has the person responsible for maintaining this repository not forgotten
> to
> > update the list of upgraded files available for our machines so that our
> > PCs are up to date ? He should be provided with a procedure to follow if
> > this is the case...
> >
> > You would be very kind to resolve this.
> >
> > Happy end of year celebrations to you.
> >
> > Philippe
>

Re: linux-image-amd64 (5.10.84-1)

[Andy Smith]

Hi Philippe,

This is probably more of a debian-user question - let's continue
there.

On Tue, Dec 21, 2021 at 11:43:28AM +0100, phil995511 - wrote:
> Hello,
> 
> The linux-image-amd64 (5.10.84-1) are announced from something days on this
> page :
> 
> https://packages.debian.org/fr/linux-image-amd64
> 
> https://packages.debian.org/fr/bullseye/linux-image-amd64
> 
> But the deployment on our machines did not take place !? We are still in
> the old version :
> 
> root@station:~# uname -a
> Linux station 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64
> GNU/Linux

My bullseye machines have been offered the updated package so it
seems likely there is a problem with or misunderstanding about your
setup.

Can you show us the output of:

$ dpkg-query --show linux-image-amd64
$ dpkg-query --show linux-image-5.10.0-10-amd64
$ cat /etc/apt/sources.list

please?

On my bullseye systems, linux-image-amd64 is at version 5.10.84-1
and this depends upon linux-image-5.10.0-10-amd64 version 5.10.84-1.

Thanks,
Andy

> Has the person responsible for maintaining this repository not forgotten to
> update the list of upgraded files available for our machines so that our
> PCs are up to date ? He should be provided with a procedure to follow if
> this is the case...
> 
> You would be very kind to resolve this.
> 
> Happy end of year celebrations to you.
> 
> Philippe

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[Greg Wooledge]

On Tue, Jul 13, 2021 at 10:34:24AM -0500, David Wright wrote:
> Some Debian releases can run two completely different kernel versions,
> like buster with 4.19 and 5.10. IIRC jessie could run 4.9 kernels from
> backports.

The possible range of kernels is quite large.  You can actually run a
kernel *much* older or newer than the one which comes with your Debian
release.

Buster (Debian 10) ships with a 4.19 kernel, but you can run it with a
3.2 kernel.  Debian 9 can run with a kernel even older than that; my VPS
for example is on a 2.6 kernel, and I've got it up to Debian 9, which is
as far as I can go on that kernel.

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#glibc-and-linux

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[David Wright]

On Tue 13 Jul 2021 at 12:09:13 (+0200), Michael Lange wrote:
> On Tue, 13 Jul 2021 09:27:35 + mabi wrote:
> 
> (...)
> > So I can simply skip upgrading to 3.16.0-10 and upgrading directly to
> > 3.16.0-11 by downloading the .deb package as you suggest?

"Skipping" isn't a useful concept with respect to kernel versions.
Always run the newest you can. For example, there are 40 CVEs fixed
between versions 10(81) and 11(84), and it brings you up to June 2020,
buying you and extra six months of security.

Some Debian releases can run two completely different kernel versions,
like buster with 4.19 and 5.10. IIRC jessie could run 4.9 kernels from
backports.

> > Then is it simply a matter of running "dpkg -i
> > linux-image-3.16.0-11-amd64_3.16.84-1_amd64.deb" and that's it?

You might try:

apt-get install /path-to/linux-image-3.16.0-11-amd64_3.16.84-1_amd64.deb

so that APT remains aware of what's installed, and will inform you of
any dependencies. (You must include the path, not just a filename.)

On Tue 13 Jul 2021 at 04:29:59 (+), mabi wrote:
> On Tuesday, July 13th, 2021 at 3:29 AM, David Wright wrote:

> > BTW it might be worth posting why you're still running jessie.
> > People may be able to advise on how you might deal with what
> > you see as reasons not to change.
> 
> I think this is irrelevant to the fact that a package is missing from the 
> Debian security APT repository and I don't want to clutter this mailing list 
> with any discussions about why I can't upgrade yet.

I was unaware that the metadata is not up-to-date on the web, but no
package is "missing", it's just been upgraded.

As for "cluttering" this list, the question of upgrading your
distribution is likely of far more security value than upgrading
just the kernel.

But bear in mind that this is where "skipping" /is/ relevant. Whenever
you decide to upgrade, make sure to go one step at a time, through
stretch to buster, using the Release Notes as a guide.

Cheers,
David.

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[Michael Lange]

Hi,

On Tue, 13 Jul 2021 09:27:35 +
mabi  wrote:

(...)
> So I can simply skip upgrading to 3.16.0-10 and upgrading directly to
> 3.16.0-11 by downloading the .deb package as you suggest?
> 
> Then is it simply a matter of running "dpkg -i
> linux-image-3.16.0-11-amd64_3.16.84-1_amd64.deb" and that's it?
> 

yes, I think so.
Since it is a different package than 3.16.0-10 this should keep your
currently installed kernel intact, so if for some reason the new kernel
doesn't work the old one should still be there.

Best regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Madness has no purpose.  Or reason.  But it may have a goal.
-- Spock, "The Alternative Factor", stardate 3088.7

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[mabi]

‐‐‐ Original Message ‐‐‐

On Tuesday, July 13th, 2021 at 10:26 AM, Michael Lange  
wrote:

> I know this does not answer your question about the sources.list, but if
>
> it is only about the linux-image package and for some reason you cannot
>
> use a kernel newer than 3.16, maybe instead of struggling with
>
> sources.list to get the 3.16.81 kernel you may be better off just going to
>
> https://packages.debian.org/jessie/linux-image-3.16.0-11-amd64
>
> and manually download the debian package of the 3.16.84 kernel. This is
>
> the last from the 3.16 series, so if you are stuck with 3.16 there won't

Thank you for your answer.

So I can simply skip upgrading to 3.16.0-10 and upgrading directly to 3.16.0-11 
by downloading the .deb package as you suggest?

Then is it simply a matter of running "dpkg -i 
linux-image-3.16.0-11-amd64_3.16.84-1_amd64.deb" and that's it?

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[Michael Lange]

Hi,

On Tue, 13 Jul 2021 04:29:59 +
mabi  wrote:

> ‐‐‐ Original Message ‐‐‐
> 
> On Tuesday, July 13th, 2021 at 3:29 AM, David Wright
>  wrote:
> 
> > Your sources.list generated the URL:
> >
> > http://security.debian.org/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
> >
> > whereas this file is available through https://packages.debian.org/
> > links:
> >
> > http://security.debian.org/debian-security/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
> >
> > I think this change may have come with stretch, but seems to have been
> >
> > enacted retrospectively. (I haven't found a reference to the change.)
> 
> Thank you David for your answer, unfortunately even
> with /debian-security/ in the URL, the package is still missing. If you
> browse that directory you can see that the package is missing 3.16.0-10
> is missing but 3.16.0-11 is available.

I know this does not answer your question about the sources.list, but if
it is only about the linux-image package and for some reason you cannot
use a kernel newer than 3.16, maybe instead of struggling with
sources.list to get the 3.16.81 kernel you may be better off just going to

https://packages.debian.org/jessie/linux-image-3.16.0-11-amd64

and manually download the debian package of the 3.16.84 kernel. This is
the last from the 3.16 series, so if you are stuck with 3.16 there won't
be any future updates anyway.

Best regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

It is undignified for a woman to play servant to a man who is not hers.
-- Spock, "Amok Time", stardate 3372.7

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[mabi]

‐‐‐ Original Message ‐‐‐

On Tuesday, July 13th, 2021 at 3:29 AM, David Wright  
wrote:

> Your sources.list generated the URL:
>
> http://security.debian.org/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
>
> whereas this file is available through https://packages.debian.org/ links:
>
> http://security.debian.org/debian-security/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
>
> I think this change may have come with stretch, but seems to have been
>
> enacted retrospectively. (I haven't found a reference to the change.)

Thank you David for your answer, unfortunately even with /debian-security/ in 
the URL, the package is still missing. If you browse that directory you can see 
that the package is missing 3.16.0-10 is missing but 3.16.0-11 is available.

> BTW it might be worth posting why you're still running jessie.
>
> People may be able to advise on how you might deal with what
>
> you see as reasons not to change.

I think this is irrelevant to the fact that a package is missing from the 
Debian security APT repository and I don't want to clutter this mailing list 
with any discussions about why I can't upgrade yet.

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[David Wright]

On Mon 12 Jul 2021 at 19:47:37 (+), mabi wrote:
> Thank you Dan for your hint regarding the archive.debian.org APT repo. I have 
> now the following in my sources.list file:
> 
> deb http://archive.debian.org/debian/ jessie contrib main non-free
> deb http://security.debian.org/ jessie/updates main contrib non-free
> 
> Unfortunately it still does not work as you can see below:

Change   http://security.debian.org/
to   http://security.debian.org/debian-security

Your sources.list generated the URL:
http://security.debian.org/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
whereas this file is available through https://packages.debian.org/ links:
http://security.debian.org/debian-security/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb

I think this change may have come with stretch, but seems to have been
enacted retrospectively. (I haven't found a reference to the change.)

BTW it might be worth posting why you're still running jessie.
People may be able to advise on how you might deal with what
you see as reasons not to change.

Cheers,
David.

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[mabi]

Thank you Dan for your hint regarding the archive.debian.org APT repo. I have 
now the following in my sources.list file:

deb http://archive.debian.org/debian/ jessie contrib main non-free
deb http://security.debian.org/ jessie/updates main contrib non-free

Unfortunately it still does not work as you can see below:

$ sudo apt-get update
Hit http://security.debian.org jessie/updates InRelease
Ign http://archive.debian.org jessie InRelease
Get:1 http://archive.debian.org jessie Release.gpg [2,420 B]
Hit http://archive.debian.org jessie Release
Hit http://security.debian.org jessie/updates/main amd64 Packages
Ign http://archive.debian.org jessie Release
Hit http://security.debian.org jessie/updates/contrib amd64 Packages
Ign http://archive.debian.org jessie/contrib amd64 Packages/DiffIndex
Hit http://security.debian.org jessie/updates/non-free amd64 Packages
Hit http://security.debian.org jessie/updates/contrib Translation-en
Ign http://archive.debian.org jessie/main amd64 Packages/DiffIndex
Hit http://security.debian.org jessie/updates/main Translation-en
Hit http://security.debian.org jessie/updates/non-free Translation-en
Ign http://archive.debian.org jessie/non-free amd64 Packages/DiffIndex
Hit http://archive.debian.org jessie/contrib Translation-en
Hit http://archive.debian.org jessie/main Translation-en
Hit http://archive.debian.org jessie/non-free Translation-en
Hit http://archive.debian.org jessie/contrib amd64 Packages
Hit http://archive.debian.org jessie/main amd64 Packages
Hit http://archive.debian.org jessie/non-free amd64 Packages
Ign http://archive.debian.org jessie/contrib Translation-en_US
Ign http://archive.debian.org jessie/main Translation-en_US
Ign http://archive.debian.org jessie/non-free Translation-en_US
Fetched 2,420 B in 2s (841 B/s)
Reading package lists... Done
W: GPG error: http://archive.debian.org jessie Release: The following 
signatures were invalid: KEYEXPIRED 1587841717

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-image-3.16.0-10-amd64
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 34.6 MB of archives.
After this operation, 14.3 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Err http://security.debian.org/ jessie/updates/main linux-image-3.16.0-10-amd64 
amd64 3.16.81-1
  404  Not Found [IP: 151.101.2.132 80]
E: Failed to fetch 
http://security.debian.org/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
  404  Not Found [IP: 151.101.2.132 80]

E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?


‐‐‐ Original Message ‐‐‐

On Monday, July 12th, 2021 at 9:34 PM, Dan Ritter  wrote:

> mabi wrote:
>
> > Hello,
> >
> > I still have an older Debian 8.11 system running and would like to apply 
> > the latest security patches. Unfortunately it seems like some packages are 
> > missing from http://security.debian.org as you can see in the apt-get 
> > update/upgrade" below:
>
> There are no "latest security patches":
>
> In a few weeks Bullseye, Debian 11 will be stable.
>
> Debian 10 is currently stable.
>
> Debian 9 is currently oldstable, and has some security support,
>
> mostly from the donation-accepting Long-Term-Support team
>
> Debian 8 is before that.
>
> If you have any interest in system security at all, please upgrade. You
>
> should be able to upgrade in place without reinstalling from 8 to 9 to
>
> 10 and then to 11 in a few weeks.
>
> PS the packages you are looking for are archived:
>
> https://www.debian.org/distrib/archive
>
> -dsr-

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[Georgi Naplatanov]

On 7/12/21 10:07 PM, mabi wrote:
> Hello,
> 
> I still have an older Debian 8.11 system running and would like to apply the 
> latest security patches. Unfortunately it seems like some packages are 
> missing from http://security.debian.org as you can see in the apt-get 
> update/upgrade" below:
> 
> $ sudo apt-get update
> Ign http://ftp.ch.debian.org jessie InRelease
> Hit http://ftp.ch.debian.org jessie Release.gpg
> Hit http://ftp.ch.debian.org jessie Release
> Get:1 http://security.debian.org jessie/updates InRelease [44.9 kB]
> Hit http://ftp.ch.debian.org jessie/main amd64 Packages
> Hit http://ftp.ch.debian.org jessie/non-free amd64 Packages
> Hit http://ftp.ch.debian.org jessie/contrib amd64 Packages
> Get:2 http://security.debian.org jessie/updates/main amd64 Packages [781 kB]
> Hit http://ftp.ch.debian.org jessie/contrib Translation-en
> Hit http://ftp.ch.debian.org jessie/main Translation-en
> Hit http://ftp.ch.debian.org jessie/non-free Translation-en
> Get:3 http://security.debian.org jessie/updates/contrib amd64 Packages [2,506 
> B]
> Get:4 http://security.debian.org jessie/updates/non-free amd64 Packages 
> [4,702 B]
> Get:5 http://security.debian.org jessie/updates/contrib Translation-en [1,211 
> B]
> Get:6 http://security.debian.org jessie/updates/main Translation-en [401 kB]
> Get:7 http://security.debian.org jessie/updates/non-free Translation-en [11.8 
> kB]
> Fetched 1,247 kB in 2s (512 kB/s)
> Reading package lists... Done
> 
> $ sudo apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages have been kept back:
>   linux-image-amd64 xen-linux-system-amd64
> The following packages will be upgraded:
>   linux-image-3.16.0-10-amd64 xen-linux-system-3.16.0-10-amd64
> 2 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> Need to get 35.0 MB of archives.
> After this operation, 27.6 kB of additional disk space will be used.
> Do you want to continue? [Y/n] y
> Err http://security.debian.org/ jessie/updates/main 
> xen-linux-system-3.16.0-10-amd64 amd64 3.16.81-1
>   404  Not Found [IP: 151.101.2.132 80]
> Err http://security.debian.org/ jessie/updates/main 
> linux-image-3.16.0-10-amd64 amd64 3.16.81-1
>   404  Not Found [IP: 151.101.2.132 80]
> E: Failed to fetch 
> http://security.debian.org/pool/updates/main/l/linux/xen-linux-system-3.16.0-10-amd64_3.16.81-1_amd64.deb
>   404  Not Found [IP: 151.101.2.132 80]
> 
> E: Failed to fetch 
> http://security.debian.org/pool/updates/main/l/linux/linux-image-3.16.0-10-amd64_3.16.81-1_amd64.deb
>   404  Not Found [IP: 151.101.2.132 80]
> 
> E: Unable to fetch some archives, maybe run apt-get update or try with 
> --fix-missing?
> 
> I have the following entries in my /etc/apt/sources.list file:
> 
> deb http://ftp.ch.debian.org/debian jessie main non-free contrib
> deb http://security.debian.org/ jessie/updates main contrib non-free
> 
> Any idea how I can fix that?
> 
> Thank you very much in advance.
> 
> Best regards,
> Mabi
> 


Hi mabi,

Debian Jessie's support has ended even as LTS.

https://wiki.debian.org/LTS

Kind regards
Georgi

Re: linux-image-3.16.0-10-amd64 missing on security.debian.org

[Dan Ritter]

mabi wrote: 
> Hello,
> 
> I still have an older Debian 8.11 system running and would like to apply the 
> latest security patches. Unfortunately it seems like some packages are 
> missing from http://security.debian.org as you can see in the apt-get 
> update/upgrade" below:
> 

There are no "latest security patches":

In a few weeks Bullseye, Debian 11 will be stable.
Debian 10 is currently stable.
Debian  9 is currently oldstable, and has some security support,
mostly from the donation-accepting Long-Term-Support team

Debian 8 is before that.

If you have any interest in system security at all, please upgrade. You
should be able to upgrade in place without reinstalling from 8 to 9 to
10 and then to 11 in a few weeks.

PS the packages you are looking for are archived:
https://www.debian.org/distrib/archive

-dsr-

Re: Linux kernel 5.10 (or 5.4) with Debian Buster

[Andrei POPESCU]

On Mi, 19 mai 21, 10:25:36, Brendan Simon (eTRIX) wrote:
> I'm currently using Debian Buster on an embedded system (ARM) and am
> currently using an older 4.4 kernel.
> 
> I need to upgrade to later version to support a new Ethernet Phy device
> (KSZ9131).
> 
> Kernel 4.19 is the default for Buster, but it doesn't seem to have the
> KSZ9131 support.  I have cherry-picked some newer KSZ9131 commits and hope
> that it works.
> 
> Just wondering, is it safe to use kernel 5.4 or 5.10 with Debian Buster
> packages?
> 
> My preference would be 5.10 (over 5.4), mainly because that is what
> Unstable/Testing is currently using.

Not necessarily a guarantee, but having a version in backports is 
generally a good indicator that it should work with that particular 
release (backports is "tracking" the version in testing).

I can confirm that 5.10 from backports works fine with buster, at least 
on a PINE A64+ (5.10 has better support for the display adapter on the 
A64).

In general there is quite a lot of flexibility between kernel versions 
and userland, e.g. on another ARM64 machine buster is running on a 
(special) 3.18 kernel.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Linux kernel 5.10 (or 5.4) with Debian Buster

[IL Ka]

>
>
> Just wondering, is it safe to use kernel 5.4 or 5.10 with Debian Buster
> packages?
>
> Kernel has stable userland ABI. Any user program (like bash or nginx)
should be compatible with any future kernel release.
But kernel doesn't guarantee kernel modules ABI (even API is not stable).

So, regular apps should work. But packages that contain kernel modules or
kernel-specific tools will probably fail.
You may also face problems with settings in "apt.conf.d" that depend on
certain kernel.

Isn't it better to install debian bullseye?
It has 5.10 and will be released soon

Re: Linux kernel 5.10 (or 5.4) with Debian Buster

[Polyna-Maude Racicot-Summerside]

Hi

On 2021-05-18 8:25 p.m., Brendan Simon (eTRIX) wrote:
> I'm currently using Debian Buster on an embedded system (ARM) and am
> currently using an older 4.4 kernel.
> 
> I need to upgrade to later version to support a new Ethernet Phy device
> (KSZ9131).
> 
> Kernel 4.19 is the default for Buster, but it doesn't seem to have the
> KSZ9131 support.  I have cherry-picked some newer KSZ9131 commits and
> hope that it works.
> 
> Just wondering, is it safe to use kernel 5.4 or 5.10 with Debian Buster
> packages?
> 
You can build a debian package directly from the kernel source code.
Just clone the git repository.

This will give you a .deb package (and a .dsc too).

You don't risk much, but I'd still suggest you use the stable LTS tree
with 5.10.37

You can easily revert if needed and there ain't any risk that it does
break something. If you want to really play safe, boot into single user
mode with root read-only ( use init=/bin/bash in the kernel boot options).

I'm on a different architecture but still, I mostly use the kernel from
git.kernel.org so I don't have to wait for the package from Debian if a
vulnerability is found in the kernel.

> My preference would be 5.10 (over 5.4), mainly because that is what
> Unstable/Testing is currently using.
> 
> Thanks, Brendan.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

RE: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP withreserved IPs on wlan0?

[Michael Grant]

I have used openwrt, but not recent version of it.  I have been using Ubiquiti 
EdgeRouters running the stock EdgeOS.  Very solid routers.  I even have one 
sitting up in a tree in a Tupperware container in the snowy mountains!

I recently discovered that EdgeOS is based on Debian and you can install Debian 
packages on them.

Michael Grant

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Celejar]

On Mon, 8 Feb 2021 16:42:40 -0500
Dan Ritter  wrote:

> Celejar wrote: 
> > > If you are OK buying used equipment, Intel-based gigabit NICs, 4 ports
> > > to a PCIe slot, cost about $35 (or $70 new). If you've got a 5 year old
> > 
> > My understanding - please correct me if I'm wrong - is that with those
> > types of cards, the ports are distinct and aren't actually switched in
> > hardware, so switching occurrs at the OS / kernel level. I don't know
> > how much of a load this puts on the system in practice, but my
> > understanding is that it's certainly not an ideal way to design a
> > switch.
> 
> Modern processors -- even the ones 5 years old -- are really
> fast.
> 
> Linux bridging (switching) is very efficient.

Fair enough.

> Is it "ideal"? No. But given that you want one device which acts
> as a WAP, router, firewall and switch, it should perform quite 
> well. If you hate the idea of doing that, though, an 8-port
> gigabit switch is about the same price as a used 4-port gigabit
> NIC. Not as flexible, though.
> 
> > > desktop sitting around with 2GB or more RAM and 3 available PCIe slots,
> > > you can use it as a WAP and have nine switched/routed gigabit ports,
> > > counting one on the motherboard.  If you only need 5 ports, you only
> > > need 2 PCIe slots -- one for a WiFI NIC and one for the ethernet NIC.
> > 
> > My understanding, although I could not find solid documentation of this,
> > is that consumer wireless chipsets designed for client use don't make
> > particularly performant APs. They'll work, but purpose built APs will
> > perform much better, especially with their AP optimized antennas. I
> > don't really know if this is true, though, and to what extent it's an
> > issue, if it really is one.
> 
> Oh, no, this is a myth. The $20-150 consumer wifi routers use
> the same wifi interface chips as good PCIe cards, for the most
> part. OpenWRT is actually a great source of information on
> these.
> 
> Assuming you're comparing a 3 antenna MIMO on a PCIe card to a 3
> antenna MIMO on a consumer router, you should get equivalent
> range and performance.

Thanks. I'd love to see actual tests comparing performance of wireless
APs (consumer, enterprise, and DIY ones like we're discussing), but
they seem very hard to come by.

> > And the power usage on a five year old desktop (which I don't actually
> > have) will be much higher than a purpose-built AIO AP / switch / router.
> 
> That can be true. But then, the desktop can also be your server
> for a bunch of other things that, perhaps, you were going to
> run.

Fair enough. I'm currently using an old R210 ii as my server, so I'm
not one to talk ;) I suppose it might be fun to see if I can fit a
modern AX200 based PCIe (perhaps a low profile one) into it and see how
it performs as an AP / router ...

> > But again, I don't really disagree. If I had the hardware lying around,
> > and I determined that the power consumption wasn't a factor, it would
> > certainly be tempting to consider this route.
> 
> Everything is a tradeoff.

Yes.

Celejar

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Dan Ritter]

Celejar wrote: 
> > If you are OK buying used equipment, Intel-based gigabit NICs, 4 ports
> > to a PCIe slot, cost about $35 (or $70 new). If you've got a 5 year old
> 
> My understanding - please correct me if I'm wrong - is that with those
> types of cards, the ports are distinct and aren't actually switched in
> hardware, so switching occurrs at the OS / kernel level. I don't know
> how much of a load this puts on the system in practice, but my
> understanding is that it's certainly not an ideal way to design a
> switch.

Modern processors -- even the ones 5 years old -- are really
fast.

Linux bridging (switching) is very efficient.

Is it "ideal"? No. But given that you want one device which acts
as a WAP, router, firewall and switch, it should perform quite 
well. If you hate the idea of doing that, though, an 8-port
gigabit switch is about the same price as a used 4-port gigabit
NIC. Not as flexible, though.

> > desktop sitting around with 2GB or more RAM and 3 available PCIe slots,
> > you can use it as a WAP and have nine switched/routed gigabit ports,
> > counting one on the motherboard.  If you only need 5 ports, you only
> > need 2 PCIe slots -- one for a WiFI NIC and one for the ethernet NIC.
> 
> My understanding, although I could not find solid documentation of this,
> is that consumer wireless chipsets designed for client use don't make
> particularly performant APs. They'll work, but purpose built APs will
> perform much better, especially with their AP optimized antennas. I
> don't really know if this is true, though, and to what extent it's an
> issue, if it really is one.

Oh, no, this is a myth. The $20-150 consumer wifi routers use
the same wifi interface chips as good PCIe cards, for the most
part. OpenWRT is actually a great source of information on
these.

Assuming you're comparing a 3 antenna MIMO on a PCIe card to a 3
antenna MIMO on a consumer router, you should get equivalent
range and performance.

> And the power usage on a five year old desktop (which I don't actually
> have) will be much higher than a purpose-built AIO AP / switch / router.

That can be true. But then, the desktop can also be your server
for a bunch of other things that, perhaps, you were going to
run.

> But again, I don't really disagree. If I had the hardware lying around,
> and I determined that the power consumption wasn't a factor, it would
> certainly be tempting to consider this route.

Everything is a tradeoff.

-dsr-

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Celejar]

On Mon, 8 Feb 2021 11:03:35 -0500
Dan Ritter  wrote:

> Celejar wrote: 
> > > I can be glad that OpenWRT has improved their security practices
> > > and simultaneously not be interested in using it.
> > 
> > I think we are really in basic agreement. The reason I use OpenWRT is
> > that I use a residential all-in-one WAP / switch / router, which Debian
> > is unsuitable for. If I ever go the separate WAP / switch / router
> > route, I'll probably use Debian on the router for the reasons you
> > give: good support, a system I'm familiar with, etc.
> 
> Debian works well in this situation. You just need to arrange
> for enough NIC ports to meet your needs.
> 
> If you are OK buying used equipment, Intel-based gigabit NICs, 4 ports
> to a PCIe slot, cost about $35 (or $70 new). If you've got a 5 year old

My understanding - please correct me if I'm wrong - is that with those
types of cards, the ports are distinct and aren't actually switched in
hardware, so switching occurrs at the OS / kernel level. I don't know
how much of a load this puts on the system in practice, but my
understanding is that it's certainly not an ideal way to design a
switch.

> desktop sitting around with 2GB or more RAM and 3 available PCIe slots,
> you can use it as a WAP and have nine switched/routed gigabit ports,
> counting one on the motherboard.  If you only need 5 ports, you only
> need 2 PCIe slots -- one for a WiFI NIC and one for the ethernet NIC.

My understanding, although I could not find solid documentation of this,
is that consumer wireless chipsets designed for client use don't make
particularly performant APs. They'll work, but purpose built APs will
perform much better, especially with their AP optimized antennas. I
don't really know if this is true, though, and to what extent it's an
issue, if it really is one.

And the power usage on a five year old desktop (which I don't actually
have) will be much higher than a purpose-built AIO AP / switch / router.

> Debian has hostapd and dnsmasq packages.

But again, I don't really disagree. If I had the hardware lying around,
and I determined that the power consumption wasn't a factor, it would
certainly be tempting to consider this route.

Celejar

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Stefan Monnier]

> I think we are really in basic agreement. The reason I use OpenWRT is
> that I use a residential all-in-one WAP / switch / router, which Debian
> is unsuitable for. If I ever go the separate WAP / switch / router
> route, I'll probably use Debian on the router for the reasons you
> give: good support, a system I'm familiar with, etc.

Here's a related datapoint:

For a couple years, I have used a Pi box as router+WAP, running
Debian (after having used "home routers" running OpenWRT for many years
before that).

I was quite happy with it software side (a bit less convenient to
configure than OpenWRT for the WAP part, but largely makes up for it for
the ease with which I could add auxiliary services and the convenience
of using the same OS as I use on all my other machines), but I was
unable to make it provide a good enough wireless signal to cover
my apartment.

So I switched to a box dedicated to WAP+router (BT HomeHub, in my case
https://openwrt.org/toh/bt/homehub_v5a), whose hardware is too limited
to run Debian.  IOW the problem for me was to find hardware which is
low-power enough to have it "always on" yet whose wifi interface is good
enough to cover my apartment: these thingies seem to be much more often
able to run OpenWRT than to run Debian :-(

W.r.t security, an important advantage of Debian is that upgrades are
much easier and smoother (so much so that they can be fully automatic)
than in OpenWRT.  But I'm a very happy user of OpenWRT (and have been
for many many years).


Stefan


PS: Another reason I went with the BT HomeHub is that it includes the
modem (and that this modem is supported by OpenWRT, tho with
a proprietary firmware), so it saves me having to have yet another box
in that corner (I still have the Pi there since the HomeHub is not
well suited to provide some of those services, which require a largish
storage which I'd rather not connect via USB).

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Dan Ritter]

Celejar wrote: 
> > I can be glad that OpenWRT has improved their security practices
> > and simultaneously not be interested in using it.
> 
> I think we are really in basic agreement. The reason I use OpenWRT is
> that I use a residential all-in-one WAP / switch / router, which Debian
> is unsuitable for. If I ever go the separate WAP / switch / router
> route, I'll probably use Debian on the router for the reasons you
> give: good support, a system I'm familiar with, etc.

Debian works well in this situation. You just need to arrange
for enough NIC ports to meet your needs.

If you are OK buying used equipment, Intel-based gigabit NICs, 4 ports
to a PCIe slot, cost about $35 (or $70 new). If you've got a 5 year old
desktop sitting around with 2GB or more RAM and 3 available PCIe slots,
you can use it as a WAP and have nine switched/routed gigabit ports,
counting one on the motherboard.  If you only need 5 ports, you only
need 2 PCIe slots -- one for a WiFI NIC and one for the ethernet NIC.

Debian has hostapd and dnsmasq packages.

-dsr-

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Celejar]

On Mon, 8 Feb 2021 09:57:13 -0500
Dan Ritter  wrote:

> Celejar wrote: 
> > On Mon, 8 Feb 2021 08:36:34 -0500
> > Dan Ritter  wrote:
> > 
> > > OpenWRT's security process doesn't look as terrible as it used
> > > to be, but it doesn't really look good right now, just trying to
> > > be better.
> > 
> > Again, let's look at specific examples of vulnerabilities present in
> > both OpenWRT and Debian, and compare the projects' responses. I gave
> > you one timely example: OpenWRT's SA for the dnsmasq vulnerabilities
> > was issued about two weeks before Debian's.
> > 
> > You feel that OpenWRT's security process "doesn't look good." Based on
> > what? Can you provide a vulnerability that affects their software that
> > they dropped the ball on?
> 
> No, thanks. I don't need to poke at OpenWRT any further.
> 
> I already have a Debian firewall that has had good security
> support from Debian since 2014; I see no reason not to continue
> using it until the hardware fails. At that point, I will buy
> another relatively small fully supported Debian box, and carry
> on. Among other benefits, it means that all the machines at home
> have the same procedures and can be used as testbeds for each
> other. E.g. the music-playing machine in the living room is now
> testing out Bullseye.
> 
> I can be glad that OpenWRT has improved their security practices
> and simultaneously not be interested in using it.

I think we are really in basic agreement. The reason I use OpenWRT is
that I use a residential all-in-one WAP / switch / router, which Debian
is unsuitable for. If I ever go the separate WAP / switch / router
route, I'll probably use Debian on the router for the reasons you
give: good support, a system I'm familiar with, etc.

Celejar

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Dan Ritter]

Celejar wrote: 
> On Mon, 8 Feb 2021 08:36:34 -0500
> Dan Ritter  wrote:
> 
> > OpenWRT's security process doesn't look as terrible as it used
> > to be, but it doesn't really look good right now, just trying to
> > be better.
> 
> Again, let's look at specific examples of vulnerabilities present in
> both OpenWRT and Debian, and compare the projects' responses. I gave
> you one timely example: OpenWRT's SA for the dnsmasq vulnerabilities
> was issued about two weeks before Debian's.
> 
> You feel that OpenWRT's security process "doesn't look good." Based on
> what? Can you provide a vulnerability that affects their software that
> they dropped the ball on?

No, thanks. I don't need to poke at OpenWRT any further.

I already have a Debian firewall that has had good security
support from Debian since 2014; I see no reason not to continue
using it until the hardware fails. At that point, I will buy
another relatively small fully supported Debian box, and carry
on. Among other benefits, it means that all the machines at home
have the same procedures and can be used as testbeds for each
other. E.g. the music-playing machine in the living room is now
testing out Bullseye.

I can be glad that OpenWRT has improved their security practices
and simultaneously not be interested in using it.

-dsr-

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Celejar]

On Mon, 8 Feb 2021 08:36:34 -0500
Dan Ritter  wrote:

> Celejar wrote: 
> > On Mon, 8 Feb 2021 06:41:23 -0500
> > Dan Ritter  wrote:
> > 
> > > Gregory Seidman wrote: 
> > > > If you want a Linux router/AP, I recommend OpenWRT over Debian. It runs 
> > > > on
> > 
> > ...
> > 
> > > Debian gets security updates in a timely manner (for stable).
> > > 
> > > How's OpenWRT's security team?
> > 
> > I'm not sure if this is a genuine question or a rhetorical one (sorry -
> > tone doesn't always come across well in email), but OpenWRT does have a
> > security process, with advisories, bug fixes, etc.:
> 
> Semi-rhetorical: my experience with OpenWRT and ddWRT is that
> once a device is installed, it never gets an upgrade. I'd be
> happy to learn otherwise.

Rejoice, then! If you choose never to upgrade, that's your choice, but
the project releases point releases every couple of months or so, and
new major versions every year or two:

https://downloads.openwrt.org/releases/

> > https://openwrt.org/docs/guide-developer/security
> > 
> > I suspect the process may not be as good as Debian's, but they do fix
> > at least some serious bugs fairly quickly. E.g., if I'm reading the
> > following pages correctly, the Debian DSAs for the recent serious set of
> > dnsmasq vulnerabilities went out on Feb. 4, whereas OpenWRT issued its
> > Security Advisory on Jan. 19:
> 
> That page lists 15 advisories over the last 3 years -- let's say
> 2 years, since this year is just beginning. Four of those
> advisories are for OpenWRT-only problems.
> 
> In the 2 months of 2021, so far, Debian's security team has issued 28 notices.
> Let's discount the desktop software -- that's 8 of them, by my
> count -- because nobody runs desktop software on a router.

I think this is a misleading comparison. It's not just a question
of desktop software - Debian includes vastly more software in general,
for which the security team is responsible, than OpenWRT does. Debian
proudly announces that it comes with "more than 59000 packages":

https://www.debian.org/intro/about

OpenWRT includes merely "several thousand packages" (I can't find an
exact number):

https://openwrt.org/packages/start

So of course Debian is going to have more SAs.

> OpenWRT's security process doesn't look as terrible as it used
> to be, but it doesn't really look good right now, just trying to
> be better.

Again, let's look at specific examples of vulnerabilities present in
both OpenWRT and Debian, and compare the projects' responses. I gave
you one timely example: OpenWRT's SA for the dnsmasq vulnerabilities
was issued about two weeks before Debian's.

You feel that OpenWRT's security process "doesn't look good." Based on
what? Can you provide a vulnerability that affects their software that
they dropped the ball on?

> This probably doesn't matter much if you just want a WAP inside
> your house, but I feel confirmed that Debian is still a much
> better choice for an Internet-facing router/firewall.

Celejar

Re: Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Dan Ritter]

Celejar wrote: 
> On Mon, 8 Feb 2021 06:41:23 -0500
> Dan Ritter  wrote:
> 
> > Gregory Seidman wrote: 
> > > If you want a Linux router/AP, I recommend OpenWRT over Debian. It runs on
> 
> ...
> 
> > Debian gets security updates in a timely manner (for stable).
> > 
> > How's OpenWRT's security team?
> 
> I'm not sure if this is a genuine question or a rhetorical one (sorry -
> tone doesn't always come across well in email), but OpenWRT does have a
> security process, with advisories, bug fixes, etc.:

Semi-rhetorical: my experience with OpenWRT and ddWRT is that
once a device is installed, it never gets an upgrade. I'd be
happy to learn otherwise.

> https://openwrt.org/docs/guide-developer/security
> 
> I suspect the process may not be as good as Debian's, but they do fix
> at least some serious bugs fairly quickly. E.g., if I'm reading the
> following pages correctly, the Debian DSAs for the recent serious set of
> dnsmasq vulnerabilities went out on Feb. 4, whereas OpenWRT issued its
> Security Advisory on Jan. 19:

That page lists 15 advisories over the last 3 years -- let's say
2 years, since this year is just beginning. Four of those
advisories are for OpenWRT-only problems.

In the 2 months of 2021, so far, Debian's security team has issued 28 notices.
Let's discount the desktop software -- that's 8 of them, by my
count -- because nobody runs desktop software on a router.

OpenWRT's security process doesn't look as terrible as it used
to be, but it doesn't really look good right now, just trying to
be better.

This probably doesn't matter much if you just want a WAP inside
your house, but I feel confirmed that Debian is still a much
better choice for an Internet-facing router/firewall.

-dsr-

Security: OpenWRT vs. Debian [Was:] Re: Linux router AP with reserved IPs on wlan0?

[Celejar]

On Mon, 8 Feb 2021 06:41:23 -0500
Dan Ritter  wrote:

> Gregory Seidman wrote: 
> > If you want a Linux router/AP, I recommend OpenWRT over Debian. It runs on

...

> Debian gets security updates in a timely manner (for stable).
> 
> How's OpenWRT's security team?

I'm not sure if this is a genuine question or a rhetorical one (sorry -
tone doesn't always come across well in email), but OpenWRT does have a
security process, with advisories, bug fixes, etc.:

https://openwrt.org/docs/guide-developer/security

I suspect the process may not be as good as Debian's, but they do fix
at least some serious bugs fairly quickly. E.g., if I'm reading the
following pages correctly, the Debian DSAs for the recent serious set of
dnsmasq vulnerabilities went out on Feb. 4, whereas OpenWRT issued its
Security Advisory on Jan. 19:

https://www.debian.org/security/2021/dsa-4844
https://lists.debian.org/debian-security-announce/2021/msg00026.html

https://openwrt.org/advisory/2021-01-19-1

Celejar

Re: Linux router AP with reserved IPs on wlan0?

[Dan Ritter]

Gregory Seidman wrote: 
> If you want a Linux router/AP, I recommend OpenWRT over Debian. It runs on
> a variety of router hardware, but also PCs: 
> https://openwrt.org/docs/guide-user/installation/openwrt_x86
> 
> Importantly, it uses UCI
>  for configuration of
> switches, networks, 802.11 (wifi) radios, SSIDs, firewalls, etc. which
> substantially simplifies handling the issues you are encountering. Its web
> interface (luci) works directly with the UCI config files, so it's easy to
> switch between editing a file and working in the web UI.

Debian gets security updates in a timely manner (for stable).

How's OpenWRT's security team?

-dsr-

Re: Linux router AP with reserved IPs on wlan0?

[Gregory Seidman]

If you want a Linux router/AP, I recommend OpenWRT over Debian. It runs on
a variety of router hardware, but also PCs: 
https://openwrt.org/docs/guide-user/installation/openwrt_x86

Importantly, it uses UCI
 for configuration of
switches, networks, 802.11 (wifi) radios, SSIDs, firewalls, etc. which
substantially simplifies handling the issues you are encountering. Its web
interface (luci) works directly with the UCI config files, so it's easy to
switch between editing a file and working in the web UI.

--Gregory

On Sat, Feb 06, 2021 at 02:29:08AM -0800, John Conover wrote:
> 
> A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> works well with iptables, with one shortcoming.
> 
> After antagonizing the Google for hours, I can not find any way to add
> reserved IPs based on the the MAC address of devices connected on
> wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> for a wireless AP.
> 
> Am I correct in my assumption?
> 
> Thanks,
> 
> John
> 
> -- 
> 
> John Conover, cono...@rahul.net, http://www.johncon.com/
> 
> 

Re: Linux router AP with reserved IPs on wlan0?

[John Conover]

Tixy writes:
> On Sat, 2021-02-06 at 11:00 -0800, John Conover wrote:
> > Stefan Monnier writes:
> > > > A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> > > > works well with iptables, with one shortcoming.
> > > > 
> > > > After antagonizing the Google for hours, I can not find any way to add
> > > > reserved IPs based on the the MAC address of devices connected on
> > > > wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> > > > for a wireless AP.
> > > 
> > > I'm not familiar with dhcpd, but dnsmasq's built-in DHCP server has been
> > > perfectly sufficient so far and it lets you specify fixed IPs based on
> > > MACs by simply putting those in the `/etc/ethers` file.
> > > 
> > 
> > Thank you, Stefan.
> > 
> > Works like a charm. The syntax of /etc/ethers is ':' delimited MAC
> > address, followed by a space delimiter, followed by the IPv4 IP
> > address, per IP reservation. That IP address must also be in
> > /etc/hosts.
> 
> I didn't know about /etc/ethers, on my system I allocate fixed IP
> addresses and hostnames by adding a lines to dnsmasq.conf like
> 
> dhcp-host=MAC-Address,IP-Address,Hostname,Lease-Time
> 
> I guess there's more than one way to skin this cat.
>

Hi Tixy.

For the archives, the documentation to configuration of dnsmasq(1) is
in /etc/dnsmasq.conf, the dnsmasq configuration file. It is verbose,
and there are many options. Read thoroughly.

It is a very impressive accomplishment, and works well, and is fairly
easy to get working, (once familiar with the configuration file.)

As a closing note, the DHCP/DNS services, (for wlan0,) are configured
in the /etc/dnsmasq.conf file, *_NOT_* /etc/dhcpcd.conf, which is the
usual alternative.

(This is where I went astray-I mean the name is dnsmasq, probably
meaning it is something to do with dns, duh.)

Thanks to all,

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: Linux router AP with reserved IPs on wlan0?

[Tixy]

On Sat, 2021-02-06 at 11:00 -0800, John Conover wrote:
> Stefan Monnier writes:
> > > A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> > > works well with iptables, with one shortcoming.
> > > 
> > > After antagonizing the Google for hours, I can not find any way to add
> > > reserved IPs based on the the MAC address of devices connected on
> > > wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> > > for a wireless AP.
> > 
> > I'm not familiar with dhcpd, but dnsmasq's built-in DHCP server has been
> > perfectly sufficient so far and it lets you specify fixed IPs based on
> > MACs by simply putting those in the `/etc/ethers` file.
> > 
> 
> Thank you, Stefan.
> 
> Works like a charm. The syntax of /etc/ethers is ':' delimited MAC
> address, followed by a space delimiter, followed by the IPv4 IP
> address, per IP reservation. That IP address must also be in
> /etc/hosts.

I didn't know about /etc/ethers, on my system I allocate fixed IP
addresses and hostnames by adding a lines to dnsmasq.conf like

dhcp-host=MAC-Address,IP-Address,Hostname,Lease-Time

I guess there's more than one way to skin this cat.

-- 
Tixy

Re: Linux router AP with reserved IPs on wlan0?

[John Conover]

Stefan Monnier writes:
> > A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> > works well with iptables, with one shortcoming.
> >
> > After antagonizing the Google for hours, I can not find any way to add
> > reserved IPs based on the the MAC address of devices connected on
> > wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> > for a wireless AP.
> 
> I'm not familiar with dhcpd, but dnsmasq's built-in DHCP server has been
> perfectly sufficient so far and it lets you specify fixed IPs based on
> MACs by simply putting those in the `/etc/ethers` file.
>

Thank you, Stefan.

Works like a charm. The syntax of /etc/ethers is ':' delimited MAC
address, followed by a space delimiter, followed by the IPv4 IP
address, per IP reservation. That IP address must also be in
/etc/hosts.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: Linux router AP with reserved IPs on wlan0?

[Stefan Monnier]

> A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> works well with iptables, with one shortcoming.
>
> After antagonizing the Google for hours, I can not find any way to add
> reserved IPs based on the the MAC address of devices connected on
> wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> for a wireless AP.

I'm not familiar with dhcpd, but dnsmasq's built-in DHCP server has been
perfectly sufficient so far and it lets you specify fixed IPs based on
MACs by simply putting those in the `/etc/ethers` file.


Stefan

Re: Linux router AP with reserved IPs on wlan0?

[Dan Ritter]

John Conover wrote: 
> 
> A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> works well with iptables, with one shortcoming.
> 
> After antagonizing the Google for hours, I can not find any way to add
> reserved IPs based on the the MAC address of devices connected on
> wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> for a wireless AP.


host conoverlaptop {
 hardware ethernet 00:14:d3:11:22:32;
 fixed-address 192.168.0.20;
}

Re: Linux router AP with reserved IPs on wlan0?

[tomas]

On Sat, Feb 06, 2021 at 02:29:08AM -0800, John Conover wrote:
> 
> A wireless router made with hostapd/dnsmasq/dhcpcd is fairly easy, and
> works well with iptables, with one shortcoming.
> 
> After antagonizing the Google for hours, I can not find any way to add
> reserved IPs based on the the MAC address of devices connected on
> wlan0, (presumably in dhcpcd.conf.) Seems kind of a simple oversight
> for a wireless AP.
> 
> Am I correct in my assumption?

I think the jargon is "DHCP reservation" or thereabouts. Do these ([1],
[2]) fit your quest?

And oh, BTW. Don't antagonize Google. They don't love you (besides, they
don't make for good neighbours, but I disgress). My search provider just
gave me those results in exchange for a moderate amount of effort (~15
min).

Cheers :)

[1] 
https://servercomputing.blogspot.com/2012/02/reserve-ip-address-in-dhcp-server-linux.html
[2] 
https://askubuntu.com/questions/392599/how-to-reserve-ip-address-in-dhcp-server

 - t


signature.asc
Description: Digital signature

Re: Linux Installation - MacBook Air 2020

[himani agarwal]

I tried installing all those things and the b43-fwcutter

I tried to install the modules

modprobe wl
modprobe applespi
modprobe appletouch

None of them are working, some extra lines appear in the dmesg output after
modprobe

[9.515203] r8152 2-2.4:1.0 enx00e04c680b71: carrier on
[9.564672] rfkill: input handler disabled
[   58.249582] rfkill: input handler enabled
[   59.806574] rfkill: input handler disabled
[   62.072574] applesmc: probe of applesmc.768 failed with error -5
[   67.168685] show_signal_msg: 6 callbacks suppressed
[   67.168686] packagekitd[816]: segfault at 8 ip 556fe0c51631 sp
7ffed178ffa0 error 4 in packagekitd[556fe0c4f000+24000]
[   67.168717] Code: 00 eb 81 66 0f 1f 44 00 00 48 8b 44 24 10 4c 89 e1 48
8d 15 25 1d 02 00 be 10 00 00 00 48 8d 3d e6 1c 02 00 41 bc ff ff ff ff
<4c> 8b 40 08 31 c0 e8 d4 f0 ff ff e9 4a ff ff ff 0f 1f 80 00 00 00
[  118.428252] applesmc: driver init failed (ret=-5)!
[  123.864611] usbcore: registered new interface driver appletouch

On Sat, Dec 19, 2020 at 1:01 AM Karthik  wrote:

> first you're using a mac with t2chip(as i can see it in lspci).
> As far as I know if T2 is not doing something crazy in the background the
> following standard steps should work.
>
> for the wireless card(broadcom):
> install broadcom-sta-dkms , firmware-brcm80211 , linux-firmware ,
> linux-firmware-free,,non-free packages
> i don't if your card source is available yet in these packages but if
> available they should work
>
> for the builtin keyboard,touchpad
> As i can see these are not connected to system through usb or i2c and not
> reported in ACPI tables in standard way(Apple way of doing things
> nonstandard) as a result they are not detected(assuming i read those files
> correctly).
> So you have to load the " applespi " module manually if it works after
> loading, then add etc/modprobe/... files.
> for the audio
> The audio modules are loaded correctly and should work fine.
> if they are not then i don't know why.
>
> On Fri, Dec 18, 2020 at 10:36 PM himani agarwal 
> wrote:
>
>> Hi Karthik,
>>
>> Please find the attached files.
>>
>> On Fri, Dec 18, 2020 at 11:01 AM Karthik 
>> wrote:
>>
>>>
>>> Attach the output of lspci ,lsusb, dmesg
>>> So that we can help you further
>>>
>>> On Fri, Dec 18, 2020, 2:38 PM himani agarwal  wrote:
>>>
 I downloaded the bullseye alpha 3 installer,
 firmware-bullseye-DI-alpha3-amd64-DVD-1.iso
 MD5: a1e967406869b1b0b64a1b808d39dd1a

 My computer is a Macbook Air 2020

 I shrank the Apple partition, disabled secure boot and I was able to
 boot with the Debian installer.

 The keyboard, mouse, wifi and sound don't work in the installer or in
 the installed system.  I had to use a USB keyboard and mouse connected
 with a USB-C dock.

 During install, the grub install failed.  I booted with the
 altlinux.org
 resuce image, entered the Debian partition with chroot and used apt to
 install the Debian refind boot manager package.  refind is working but I
 have to press Option every time I turn on the machine, otherwise it
 always goes to Mac.

 Can anybody tell me how to make the builtin keyboard, trackpad, wifi and
 sound work again?

 --
 Regards
 Himani Agarwal[image:
 https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

>>>
>>
>> --
>> Regards
>> Himani Agarwal[image: https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>>
>

-- 
Regards
Himani Agarwal[image: https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Re: Linux not seeing all SATA drives

[Andrei POPESCU]

On Lu, 12 oct 20, 21:19:39, Dennis Wicks wrote:
> I have 3 SATA drives on my system. I replaced all my red cables with new
> black cables. The BIOS sees all of them but when linux finishes booting it
> only sees two of them. Do I have to do something to linux so it sees the
> third drive?
> 
> FYI, I have the system disk in sata-1, the drive on sata2 is not seen, but
> the drive on sata3 is seen and in use. The CD/DVD drive is on sata6 and is
> also seen.

Do you have a good enough power source? For testing purposes you could 
try removing any other component that is not strictly needed to start 
the system.

If you connect each drive individually, does Linux detect them?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature