> > > ff fc 00 00 02 00
> > > [ 9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer
> > >
> > > I am starting to consider re-installing, although everything is
> > > working,
> > > I don't like the look of it. Perhaps I should
Hi,
piorunz wrote:
> read attempts continue,
Obviously your drive groper is different from Richmond's. Both get lured
into their activities by the kernel bugs.
> Inserting blank disc on every reboot is not a solution in my opinion. And I
> didn't verified it myself,
It woul
On 25/01/2023 15:26, Thomas Schmitt wrote:
it might be that there are no further (periodic) read attempts.
If the messages only appear once during the boot procedure, then i think
the issue is explored as far as possible without starting kernel
programming.
Just to briefly comment on this
> > I see errors when booting, which also appear in /var/log/messages:
it might be that there are no further (periodic) read attempts.
If the messages only appear once during the boot procedure, then i think
the issue is explored as far as possible without starting kernel
programming.
The Linux
I put in a blank DVD+RW.
>
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048
>
> It has stayed like this after I removed it.
I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting
the blank disk in did not change the values, it still showed 512.
"Thomas Schmitt" writes:
> Hi,
>
> i wrote:
>> > If you have some blank optical medium, then try whether the emitter of
>> > the read attempt can be discouraged if the drive is perceived as offering
>> > just one block of 2048 bytes.
>
> Richmond wrote:
>> I don't know how to do that. Do you mean
Hi,
i wrote:
> > If you have some blank optical medium, then try whether the emitter of
> > the read attempt can be discouraged if the drive is perceived as offering
> > just one block of 2048 bytes.
Richmond wrote:
> I don't know how to do that. Do you mean make a DVD with 1 block of data?
Just
"Thomas Schmitt" writes:
> I assume that you will see the same result there.
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODEL SIZE PHY-SEC LOG-SEC
HL-DT-ST HL-DT-ST_DVDRAM_GH15F 1073741312 512 512
5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-
On 25/01/2023 10:38, Thomas Schmitt wrote:
Are users of Debian 10 (actually of kernel 4.19) here who are willing to
run
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
directly after booting with empty drive tray ?
$ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR
ou will see the same result there.
It would explain the block address of the first read attempt and the
log messages about unaligned access.
kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff
fc 00 00 02 00
kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned
"Thomas Schmitt" writes:
>
> Are users of Debian 10 (actually of kernel 4.19) here who are willing to
> run
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> directly after booting with empty drive tray ?
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SE
0
> VENDOR MODELSIZE PHY-SEC LOG-SEC
> hp hp_DVDRW_GUE1N 335334604820482048
So we know that the kernel-perceived block size is correctly 2048 when
a medium is inserted. Do the complaints continue to appear in the logs
while the medium is loaded ?
The remaining que
On 24/01/2023 18:58, Thomas Schmitt wrote:
Hi,
the log messages about "unaligned transfer" would be explained if indeed
the block size of the drive would be mistaken as 512 bytes rather than
2048 bytes.
So it might be interesting to let lsblk report "sector" sizes as per
Hi,
the log messages about "unaligned transfer" would be explained if indeed
the block size of the drive would be mistaken as 512 bytes rather than
2048 bytes.
So it might be interesting to let lsblk report "sector" sizes as perceived
by the kernel:
lsblk -b -o VENDOR,MO
Hi,
piorunz wrote:
> Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D
>
> $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0
> VENDOR MODELSIZE
> hp hp_DVDRW_GUE1N 1073741312
Now that's a strange size: 1 GiB - 512 bytes.
The readable data ca
ago, on kernel 4.19. Today, kernel
5.10, Debian 11 Bullseye, and problem still exists :D
However, error message has since changed, word udev is not present in
the message.
Old format:
udev: Buffer I/O error on dev sr0, logical block 0, async page read
New format:
Buffer I/O error on dev sr0
David Wright writes:
> On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote:
>> It may be a coincidence but yesterday I installed some
>> libguestfs-tools. Now I see errors when booting, which also appear in
>> /var/log/messages:
>>
>> kernel: [ 9.506798
On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote:
> It may be a coincidence but yesterday I installed some
> libguestfs-tools. Now I see errors when booting, which also appear in
> /var/log/messages:
>
> kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result:
&g
;> tray closed
>> [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00
>> 00 02 00
>> [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer
>>
>> I am starting to consider re-installing, although everything is working,
>> I don
: pktcdvd0: writer mapped to sr0
Looks normal.
> Then removed the DVD and rebooted, back to these:
I wonder what happens if you simply put in and out the medium, without
rebooting.
It looks somewhat as if the kernel perceives a wrong medium status and size
and so lures some software like
c 00 00
> 02 00
> [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer
>
> I am starting to consider re-installing, although everything is working,
> I don't like the look of it. Perhaps I should just re-install the
> kernel?
This would most likely not help. Instead y
"Thomas Schmitt" writes:
> Hi,
>
> Richmond wrote:
>> kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result:
>> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
>> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready
>> [cu
Hi,
Richmond wrote:
> kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result:
> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready
> [current]
> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Se
It may be a coincidence but yesterday I installed some
libguestfs-tools. Now I see errors when booting, which also appear in
/var/log/messages:
kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE cmd_age=2s
kernel: [9.507009] sr 3:0:0:0
Windows-10-Jorge.xml
Description: XML document
Hi! After I upgraded to bookworm, my QEMU-KVM VM fails to boot the
guest OS; instead it drops to the EFI shell. If I boot the physical
host into bullseye's kernel (Linux 5.10) then the VM boots normally.
This VM has two virtual disks, each b
> I used the MODULES=dep setting and got a reduction from 70mb to 20mb
> for each initramfs.
Wow, that's still about twice as large as what I get on my
amd64/armhf/686 systems (I typically get about 40MB for MODULES=most and
10-12MB for MODULES=dep).
The compression algorithm in use makes some di
> On 13 Nov 2022, at 23:06, Mike Kupfer wrote:
>
> Hi Stefan!
>
> Stefan Monnier wrote:
>
>> I use `MODULES=dep` and my kernel+initrd uses less than 20MB still so my
>> 250MB /boot partition is currently 21% full with 2 kernels installed.
>
> Ah, thank
Hi Stefan!
Stefan Monnier wrote:
> I use `MODULES=dep` and my kernel+initrd uses less than 20MB still so my
> 250MB /boot partition is currently 21% full with 2 kernels installed.
Ah, thanks for the tip. I'll give that a try, as well as trying more
aggressive compression (th
it at least 1 GB. I
> tried adjusting the sizes with the installer's partition manager, but I
> got stuck. Unfortunately, I don't have adequate notes about how I got
> stuck. I'm suspecting it had something to do with the fact that I had
> asked for a LUKS-encrypted dis
does not get size of /boot right
>> - even with only one new kernel update wanting to install itself it often
>> fails with lack of space. One solution I found is to change the initramfs
>> compression algorithm, which gives me space for two full kernels and
>> initramfses.
On Sun, 13 Nov 2022 14:45:15 +
"Andrew M.A. Cater" wrote:
> Ideally, you shouldn't need more than the current kernel and,
> perhaps, the previous version.
One nitpick: I believe that installing a new kernel means installing
the new kernel, and only if that is successfu
with only one new kernel update wanting to install itself it often fails
with lack of space. One solution I found is to change the initramfs compression
algorithm, which gives me space for two full kernels and initramfses. But this
is still problematic. Are there other solutions other than
Peter von Kaehne wrote:
> It now appears that the automatic installer does not get size of /boot
> right - even with only one new kernel update wanting to install itself
> it often fails with lack of space.
I have had this problem, too, so thank you for bringing it up on the
lis
Andrew M.A. Cater wrote:
> Ideally, you shouldn't need more than the current kernel and, perhaps, the
> previous version. If the current kernel works on the reboot, then you should
> be able to remove all previous variants with the same major version number.
It used to be that I c
taller does not get size of /boot right
> - even with only one new kernel update wanting to install itself it often
> fails with lack of space. One solution I found is to change the initramfs
> compression algorithm, which gives me space for two full kernels and
> initramfses. Bu
I mostly let the installer do what it likes to do when installing Debian and
this has worked out fine until the last couple installs on UEFI rather than
legacy boot.
It now appears that the automatic installer does not get size of /boot right -
even with only one new kernel update wanting to
Hi all,
thanks for pointing me to the wiki and the hint with the script. Yes, in the
meantime things have changed, I was not aware of the bindep-pkg command.
I looked into the manual, but this specific command I did not find, but lots
of very usefull other descriptions.
So, this little questio
Hans wrote:
I want to create a kernel package, which I can install with dpkg. There was a
command doing it instead of "make && make install", and I could not find it
any more. Last time I did it is a long time ago. Does someone know?
I also don't remember the old com
On 10/7/22 11:00, Hans wrote:
Hi folks,
some easy questions.
I want to create a kernel package, which I can install with dpkg. There was a
command doing it instead of "make && make install", and I could not find it
any more. Last time I did it is a long time ago. Does some
Hi folks,
some easy questions.
I want to create a kernel package, which I can install with dpkg. There was a
command doing it instead of "make && make install", and I could not find it
any more. Last time I did it is a long time ago. Does someone know?
Second question: My
On Sat, Oct 01, 2022 at 12:43:37AM +0200, Dmitry Katsubo wrote:
> I have disabled and stopped this service:
>
> # systemctl status getty@tty1.service
> ● getty@tty1.service - Getty on tty1
> Loaded: loaded (/lib/systemd/system/getty@.service; disabled; vendor
> preset: enabled)
> Drop-In
On 2022-09-25 17:52, basti wrote:
> Am 25.09.22 um 17:25 schrieb David Wright:
>> On Sun 25 Sep 2022 at 17:01:23 (+0200), Dmitry Katsubo wrote:
>>> I am trying to make a following setup on Debian bullseye:
>>>
>>> * tty1 is used to display kernel messages o
Am 25.09.22 um 17:25 schrieb David Wright:
On Sun 25 Sep 2022 at 17:01:23 (+0200), Dmitry Katsubo wrote:
I am trying to make a following setup on Debian bullseye:
* tty1 is used to display kernel messages only
* tty[2-5] are allocated for login
I have modified /etc/default/console-setup so
On Sun 25 Sep 2022 at 17:01:23 (+0200), Dmitry Katsubo wrote:
> I am trying to make a following setup on Debian bullseye:
>
> * tty1 is used to display kernel messages only
> * tty[2-5] are allocated for login
>
> I have modified /etc/default/console-setup so that it reads:
&g
Dear Debian users,
I am trying to make a following setup on Debian bullseye:
* tty1 is used to display kernel messages only
* tty[2-5] are allocated for login
I have modified /etc/default/console-setup so that it reads:
ACTIVE_CONSOLES="/dev/tty[2-5]"
and rebooted. What I observe is
Hi all.
Problem solved. Kernel misconfiguration.
It's simple and clear. At least for anyone who knows details regarding
different security options in ChromeOS and Debian.
SystemTap for the win! Probing parameters for call_modprobe(), argv[0]
for call_usermodehelper_setup() and the r
hi all.
Am 19.09.2022 16:27, schrieb hede:
I need help getting module on-demand-loading working with a custom
kernel.
Additional information:
My problem seems less related to udev but more probably related the
kernel kmod subsystems!?
The kernel usually calls /sbin/modprobe if
Hi all.
I need help getting module on-demand-loading working with a custom
kernel.
Currently I'm running Debian 11 for x86_64 on a Chromebook in developer
mode directly via Coreboot/Depthcharge. Not having UEFI or classical
BIOS boot code means that the default Debian kernel doesn&#
On Mon, 5 Sep 2022, Andy Smith wrote:
Hello,
On Sun, Sep 04, 2022 at 01:54:16PM +0100, Tim Woodall wrote:
and remove pvshim=1
I think this was your issue. pvshim is PV-inside-PVH. So the
hypervisor that starts your guest kernel is in PV mode, which as
mentioned is not supported for 32-bit
Hello,
On Sun, Sep 04, 2022 at 01:54:16PM +0100, Tim Woodall wrote:
> and remove pvshim=1
I think this was your issue. pvshim is PV-inside-PVH. So the
hypervisor that starts your guest kernel is in PV mode, which as
mentioned is not supported for 32-bit in newer Linux kernels.
Modern Li
On Sun, 4 Sep 2022, Andy Smith wrote:
Hello,
On Sun, Sep 04, 2022 at 11:07:35AM +0100, Tim Woodall wrote:
Should I be able to boot a 686-pae i686 kernel on a xen domU (bullseye -
but bookworm fails too)
The Linux kernel removed PV mode 32-bit Xen domU support at version
5.9. What type of
Hello,
On Sun, Sep 04, 2022 at 11:07:35AM +0100, Tim Woodall wrote:
> Should I be able to boot a 686-pae i686 kernel on a xen domU (bullseye -
> but bookworm fails too)
The Linux kernel removed PV mode 32-bit Xen domU support at version
5.9. What type of virtualisation are you using? (s
Hi,
Should I be able to boot a 686-pae i686 kernel on a xen domU (bullseye -
but bookworm fails too)
(XEN) d46v0 Unhandled page fault fault/trap [#14, ec=0010]
(XEN) Pagetable walk from 0100:
(XEN) L4[0x000] = 09790027 1f90
(XEN) L3[0x000] = 097a4027
On Sat, Aug 20, 2022 at 06:21:21PM -0700, Wylie wrote:
>
> i am getting this error ... on a fresh install of nfs-kernel-server
>
> mount.nfs: access denied by server while mounting
> 192.168.42.194:/ShareName
>
> i'm not having this issue on other machines installed
i am getting this error ... on a fresh install of nfs-kernel-server
mount.nfs: access denied by server while mounting
192.168.42.194:/ShareName
i'm not having this issue on other machines installed previously
i've tried re-installing Debian and nfs several times
Wylie!
"blacklist intel_ips" >> /etc/modprobe.d/blacklist.conf
2. add i915 and intel_ips to /etc/modules
echo -e "i915\nintel_ips" >> /etc/modules
I only made the first point and the log flood was over.
Two questions:
1. Could disabling the intel_ips kerne
On Sat, 16 Jul 2022 at 23:41, Brian wrote:
> But you did not download and try the one I suggested? Therefore, you
> are working blindfolded. It is dated 2022-0 7-05. The archive modules
> may match the d-i kernel.
I successfully installed Sid using the Bullseye mini.iso that I
downlo
gested? Therefore, you
are working blindfolded. It is dated 2022-0 7-05. The archive modules
may match the d-i kernel.
> which is supposed to be the one to install Sid. The one you ask about
> seems to be not for Sid. There is another method of installation which
You are misunderstanding; all
/dev, and so on).
On BusyBox I ran 'uname -a' and it told me I am running the debian-sid
kernel 5.10.0-8, built on 2021-07-28. This might be the reason for the
error message I got, "No kernel modules found". It is a very old
kernel. So perhaps the mini.iso was not built in a long whi
On Sat, 16 Jul 2022 at 19:26, Charles Curley
wrote:
> Look in the installation logs for suspicious messages. During
> installation, they are at /target/var/log/installer/. After you reboot
> into the newly installed system, they are at /var/log/installer/.
I chose "Execute Shell", got a window w
On Sat, 16 Jul 2022 at 19:49, Brian wrote:
>
> On Sat 16 Jul 2022 at 18:27:29 +0100, Piscium wrote:
> > [1] https://wiki.debian.org/DebianUnstable
> > [2] deb.debian.org
>
> Is the mini.iso at
>
>
> http://ftp.nl.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/
>
>
h all the various
> options without any error, network configuration also succeeded, then
> at the step "Download installer components" I got the error "No kernel
> modules found". The mirror is the default and recommended [2].
>
> Any ideas? Could it be that the
On Sat, 16 Jul 2022 18:27:29 +0100
Piscium wrote:
> … network configuration also succeeded, then
> at the step "Download installer components" I got the error "No kernel
> modules found". The mirror is the default and recommended [2].
>
> Any ideas? Cou
ed, then
at the step "Download installer components" I got the error "No kernel
modules found". The mirror is the default and recommended [2].
Any ideas? Could it be that the specified ISO got somehow out of sync
with what is available in the default mirror?
[1] h
leared out the offending
> directory and moved on.
Not necessarily a bug. There are packages whose goal is to build
modules. While the source is tracked by the packaging system,
what is built isn't.
It could still be a bug in some /etc/kernel/prerm.d script.
Or you could write a script there t
DdB wrote on 6/20/22 10:07:
Since i am running dozens of VM's, i can say:
Me2 am running into this regularly, when i am trying to purge old
kernels. I am seeing this so frequently, that i even wrote a script
(meant to be run inside the VM's) to clean up the mess, some apt-scripts
happen to leave
Since i am running dozens of VM's, i can say:
Me2 am running into this regularly, when i am trying to purge old
kernels. I am seeing this so frequently, that i even wrote a script
(meant to be run inside the VM's) to clean up the mess, some apt-scripts
happen to leave behind.
But in this special ca
On Mon, 20 Jun 2022 08:58:55 -0600
"D. R. Evans" wrote:
Hello D.,
>But it failed, with the error message:
Actually; .exited, with the warning.
That is to say, it's doing what it's supposed to do.
--
Regards _
/ ) "The blindingly obvious is never immediately apparent"
d
> have arisen. Has anyone else seen this happen, and does anyone have a
> reasonable suggestion as to how it could have occurred?
I've seen similar before. The only two reasons for this I can think of
are:
1) Something other than the kernel package put something into that
dire
Normally to remove an old kernel from my debian stable systems, I issue the
following command:
apt purge linux-headers--amd64
linux-headers--common linux-image--amd64
Following this recipe, which has always worked in the past, I issued:
apt purge linux-headers-5.10.0-11
On Fri, Jun 17, 2022 at 12:45 AM Keith Bainbridge wrote:
>
>
> On 17/6/22 00:08, Boyan Penkov wrote:
> > On Thu, Jun 16, 2022 at 12:09 AM Keith Bainbridge
> > wrote:
> >>> Cheers!
> >>
> >> Good afternoon Boyan
> >>
> >> What happened when you installed to 2 suggested items?
> > Hey Keith -- yes
On 17/6/22 00:08, Boyan Penkov wrote:
On Thu, Jun 16, 2022 at 12:09 AM Keith Bainbridge wrote:
Cheers!
Good afternoon Boyan
What happened when you installed to 2 suggested items?
Hey Keith -- yes, thanks for the pointer; you're absolutely correct...
Somehow linux-image-headers was not ins
On 16/6/22 06:11, Boyan Penkov wrote:
Hello folks,
Installing virtualbox and virtualbox-qt from sid, and running
`virtualbox --version` returns the below:
```
WARNING: The character device /dev/vboxdrv does not exist.
Please install the virtualbox-dkms package and the appropriate
h
Hello folks,
Installing virtualbox and virtualbox-qt from sid, and running
`virtualbox --version` returns the below:
```
WARNING: The character device /dev/vboxdrv does not exist.
Please install the virtualbox-dkms package and the appropriate
headers, most likely linux-headers-amd64.
Muhammad Akbar Yanuar Mantari wrote:
> Dear Debian Developer,
>
> Please patch broadcom-sta for kernel 5.18 from arch linux
>
> https://github.com/archlinux/svntogit-community/commits/packages/broadcom-wl-dkms/trunk
This is the Debian Users' list, not developers.
In a
On 4/05/22 18:57, Tixy wrote:
On Wed, 2022-05-04 at 00:44 +0300, IL Ka wrote:
Linux kernel is backward compatible. Linus calls it "we do not break
userspace".
That means _old_ applications should work on new kernel
There's also the issue of what config options the kernel is
On Wed, 2022-05-04 at 00:44 +0300, IL Ka wrote:
> Linux kernel is backward compatible. Linus calls it "we do not break
> userspace".
> That means _old_ applications should work on new kernel
There's also the issue of what config options the kernel is built with.
I'
Linux kernel is backward compatible. Linus calls it "we do not break
userspace".
That means _old_ applications should work on new kernel
On Wed, May 4, 2022 at 12:40 AM Richard Hector
wrote:
> Hi all,
>
> For various reasons, I have some stretch LXC containers, on a buste
Hi all,
For various reasons, I have some stretch LXC containers, on a buster
host that I now need to upgrade. That will mean they end up running on
buster's 5.10 kernel.
Is that likely to be a problem?
If so, I guess I can leave the host on buster's kernel for the time
being,
On Thu, 2022-04-14 at 11:18 -0400, Stefan Monnier wrote:
> > I think it would be great to provide such a (semi-)official support
> > for
> > backported kernels in the installer again. There is probably a
> > significant number of users which use testing, just because they
> > can't
> > install sta
Thank you for your good hints, Andrew. My approach is different.
I am in the lucky position that the question is of theoretical interest
to me this time only, in the past I had cases where I had to use
testing, because the kernel of the installer was too old to support
basic functions of my
On Thu, Apr 14, 2022 at 11:16:00AM +0200, Christian Britz wrote:
> Hello dear Debianists,
>
> if a new system has at least basic hardware support by the kernel
> provided by the Debian installer, you can solve many hardware problems
> by installing a newer kernel from backports a
Hello dear Debianists,
if a new system has at least basic hardware support by the kernel
provided by the Debian installer, you can solve many hardware problems
by installing a newer kernel from backports after the system setup.
Is there a solution for the case where the installer kernel is too
; > system fails with kernel panics
> >
> > By adding init=/bin/bash from within grub works and we can then do
> things
> > like
> >
> > mount - o remount /
> > cd /etc/init.d
> > ./networking start
> > ./ssh start
> > apt install stress
> Our servers were running Debian 10 without any issues
> We have been trying to do a fresh install of debian 11.3 on exactly the
> same hardware. The install works without any errors but on rebooting the
> system fails with kernel panics
>
> By adding init=/bin/bash from wit
Hi
Our servers were running Debian 10 without any issues
We have been trying to do a fresh install of debian 11.3 on exactly the
same hardware. The install works without any errors but on rebooting the
system fails with kernel panics
By adding init=/bin/bash from within grub works and we can
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 fir
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
W: Possible missing firmware /lib/firmware/i915/bxt_guc_62.0.0.bin for
module i915
W: Possible mi
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
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
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
>
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, spea
======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.
- O
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
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 ch
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
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 stab
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
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
ithout 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.
> >
301 - 400 of 24405 matches
Mail list logo
