Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
amdgpu broken on bookworm?
666 views
Skip to first unread message
Jeffrey Chimene
Aug 27, 2021, 2:50:05 PM8/27/21
to
Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm. I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.
I've tried downgrading to stable from testing. No joy.
I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy.
I've checked
I just booted ubuntu live and graphics are high resolution.
It feels like there's some setting in /proc or /sys that got changed
accidentally.
Any debugging tips?
ago, this machine made an uneventful transition to bookworm. I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.
I've tried downgrading to stable from testing. No joy.
I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy.
I've checked
I just booted ubuntu live and graphics are high resolution.
It feels like there's some setting in /proc or /sys that got changed
accidentally.
Any debugging tips?
piorunz
Aug 28, 2021, 7:30:05 AM8/28/21
to
On 27/08/2021 19:20, Jeffrey Chimene wrote:
> Something happened to my amd firmware for a ryzen3 3200g. A few weeks
> ago, this machine made an uneventful transition to bookworm.
Great.
> Something happened to my amd firmware for a ryzen3 3200g. A few weeks
> ago, this machine made an uneventful transition to bookworm.
> I'd
> originally installed bullseye and the non-free firmware package to get
> the firmware for this setup. Everything was fine until yesterday
working fine.
> Everything was fine until yesterday, after
> some bookworm updates and a reboot. No more video driver for X.
problem. Please attach relevant logs from this "bookworm updates" event
so we can see what happened.
--
With kindest regards, piorunz.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀
songbird
Aug 28, 2021, 9:00:05 AM8/28/21
to
Jeffrey Chimene wrote:
just to note that using "bookworm" in your subject line can
give the implication that "bookworm" is actually released which
it hasn't. it is much better to use the keyword "testing" in
the subject line instead.
it does not take that much space to set up a separate
partition for stable on a system to keep a working version
available and for comparison. this is what i do.
songbird
just to note that using "bookworm" in your subject line can
give the implication that "bookworm" is actually released which
it hasn't. it is much better to use the keyword "testing" in
the subject line instead.
partition for stable on a system to keep a working version
available and for comparison. this is what i do.
songbird
Jeffrey Chimene
Aug 28, 2021, 9:00:05 AM8/28/21
to
On 8/28/21 04:28, piorunz wrote:
On 27/08/2021 19:20, Jeffrey Chimene wrote:
Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm.
Great.
I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday
Not bookworm upgrade fault then. You had upgraded the system and it was
working fine.
Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.
SOME bookworm updates? Please be more specific. That's the cause of your
problem. Please attach relevant logs from this "bookworm updates" event
so we can see what happened.
Hi,
Thanks for the advice. The problem I'm trying to solve is why the AMD firmware isn't getting incorporated in the kernel. I have to boot with NOMODESET. The bookworm updates, while coincidental, are probably not the cause. "Something else" happened, and I need help debugging. I can't see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.
I've run update-initramfs -c after replacing /var/lib/firmware. Still not getting positive results from lsmod | grep -i amdgpu
Booting with
ro loglevel=7 nomodeset
isn't giving any useable clues in boot.log
It feels like it's a kernel setting that got written and isn't reset after down/up grades. This is testing. It's supposed to be "broken". When bullseye was broken after the downgrade, I knew something broke in my local configuration. I'm trying to fix it. I'd like help debugging. It's probably only reproducible if one follows a set of steps that aren't easily retraced.
It's been too many years since I used Debian from the console. I do not remember enough X to debug building the init image towards that goal.
I'm also chuffed that Ubuntu manages to pull off video in the live CD.
At this point, I think I'll reinstall from bookworm netinst in a few weeks or after the transition to 12 finishes. Running the box headless will be good enough for now.
Thanks for the advice. The problem I'm trying to solve is why the AMD firmware isn't getting incorporated in the kernel. I have to boot with NOMODESET. The bookworm updates, while coincidental, are probably not the cause. "Something else" happened, and I need help debugging. I can't see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.
I've run update-initramfs -c after replacing /var/lib/firmware. Still not getting positive results from lsmod | grep -i amdgpu
Booting with
ro loglevel=7 nomodeset
isn't giving any useable clues in boot.log
It feels like it's a kernel setting that got written and isn't reset after down/up grades. This is testing. It's supposed to be "broken". When bullseye was broken after the downgrade, I knew something broke in my local configuration. I'm trying to fix it. I'd like help debugging. It's probably only reproducible if one follows a set of steps that aren't easily retraced.
It's been too many years since I used Debian from the console. I do not remember enough X to debug building the init image towards that goal.
I'm also chuffed that Ubuntu manages to pull off video in the live CD.
At this point, I think I'll reinstall from bookworm netinst in a few weeks or after the transition to 12 finishes. Running the box headless will be good enough for now.
Jeffrey Chimene
Aug 28, 2021, 9:10:05 AM8/28/21
to
On 8/28/21 05:36, songbird wrote:
> Jeffrey Chimene wrote:
>
>
> just to note that using "bookworm" in your subject line can
> give the implication that "bookworm" is actually released which
> it hasn't. it is much better to use the keyword "testing" in
> the subject line instead.
too old to be useful. My goal is to watch for bookworm topics via search
engine's "news alert" features.
>
>
>> Something happened to my amd firmware for a ryzen3 3200g. A few weeks
>> ago, this machine made an uneventful transition to bookworm. I'd
>> originally installed bullseye and the non-free firmware package to get
>> the firmware for this setup. Everything was fine until yesterday, after
>> some bookworm updates and a reboot. No more video driver for X.
>>
>> I've tried downgrading to stable from testing. No joy.
>>
>> I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy.
>> I've checked
>>
>> I just booted ubuntu live and graphics are high resolution.
>>
>> It feels like there's some setting in /proc or /sys that got changed
>> accidentally.
>>
>> Any debugging tips?
>
> it does not take that much space to set up a separate
> partition for stable on a system to keep a working version
> available and for comparison. this is what i do.
re-partitioning. Right now, to get this box on the air, I did the two
partition (/ and swap) setup and added lvm2 for backups and such. I
think the resolution to this issue is to reinstall. I'll wait a few
weeks for testing to ripen to 12, move /home to its own partition (and
probably /var), create a /stable partition and reinstall.
As I understand it, this /stable is not bootable?
piorunz
Aug 28, 2021, 9:10:05 AM8/28/21
to
On 28/08/2021 13:54, Jeffrey Chimene wrote:
Let me ask more questions, so we all can learn more about your situation
and start suggesting remedies.
> Hi,
>
> Thanks for the advice. The problem I'm trying to solve is why the AMD
> firmware isn't getting incorporated in the kernel.
How you assumed that firmware isn't getting to kernel? Do you have any
errors in the log stating that?
> I have to boot with
> NOMODESET.
What happens if you don't? Please show error logs when you don't have
nomodeset.
> The bookworm updates, while coincidental, are probably not
> the cause. "Something else" happened, and I need help debugging. I can't
> see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.
Try this:
inxi -G
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
Display: x11 server: X.Org 1.20.11 driver: loaded:
amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
1: 1920x1200~60Hz 2: 3840x2160
OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4
>
> I've run update-initramfs -c after replacing /var/lib/firmware. Still
> not getting positive results from lsmod | grep -i amdgpu
$ lsmod | grep -i amdgpu
amdgpu 6606848 90
gpu_sched 40960 1 amdgpu
i2c_algo_bit 16384 1 amdgpu
ttm 114688 1 amdgpu
drm_kms_helper 274432 1 amdgpu
drm 618496 39 gpu_sched,drm_kms_helper,amdgpu,ttm
For me it works.
>
> Booting with
>
> ro loglevel=7 nomodeset
>
> isn't giving any useable clues in boot.log
What is your GPU (integrated or not) model? Please say exact model from
inxi for example.
>
> It feels like it's a kernel setting that got written and isn't reset
> after down/up grades. This is testing. It's supposed to be "broken".
I don't know what you are trying to say here. What supposed to be broken
and why you think so?
Let me ask more questions, so we all can learn more about your situation
and start suggesting remedies.
> Hi,
>
> Thanks for the advice. The problem I'm trying to solve is why the AMD
> firmware isn't getting incorporated in the kernel.
errors in the log stating that?
> I have to boot with
> NOMODESET.
nomodeset.
> The bookworm updates, while coincidental, are probably not
> the cause. "Something else" happened, and I need help debugging. I can't
> see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.
inxi -G
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
Display: x11 server: X.Org 1.20.11 driver: loaded:
amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
1: 1920x1200~60Hz 2: 3840x2160
OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4
>
> I've run update-initramfs -c after replacing /var/lib/firmware. Still
> not getting positive results from lsmod | grep -i amdgpu
amdgpu 6606848 90
gpu_sched 40960 1 amdgpu
i2c_algo_bit 16384 1 amdgpu
ttm 114688 1 amdgpu
drm_kms_helper 274432 1 amdgpu
drm 618496 39 gpu_sched,drm_kms_helper,amdgpu,ttm
For me it works.
>
> Booting with
>
> ro loglevel=7 nomodeset
>
> isn't giving any useable clues in boot.log
inxi for example.
>
> It feels like it's a kernel setting that got written and isn't reset
> after down/up grades. This is testing. It's supposed to be "broken".
and why you think so?
Jeffrey Chimene
Aug 28, 2021, 9:30:04 AM8/28/21
to
On 8/28/21 05:36, songbird wrote:
Jeffrey Chimene wrote:
just to note that using "bookworm" in your subject line can
give the implication that "bookworm" is actually released which
it hasn't. it is much better to use the keyword "testing" in
the subject line instead.
Agreed. However, a net search on testing would yield results that
are too old to be useful. My goal is to watch for bookworm topics
via search engine's "news alert" features.
Something happened to my amd firmware for a ryzen3 3200g. A few weeks
ago, this machine made an uneventful transition to bookworm. I'd
originally installed bullseye and the non-free firmware package to get
the firmware for this setup. Everything was fine until yesterday, after
some bookworm updates and a reboot. No more video driver for X.
I've tried downgrading to stable from testing. No joy.
I've wiped /lib/firmware and reinstalled firmware-amd-graphics. No joy.
I've checked
I just booted ubuntu live and graphics are high resolution.
It feels like there's some setting in /proc or /sys that got changed
accidentally.
Any debugging tips?
it does not take that much space to set up a separate
partition for stable on a system to keep a working version
available and for comparison. this is what i do.
Jeffrey Chimene
Aug 28, 2021, 10:00:06 AM8/28/21
to
Hi piorunz,
Thanks for your interest! I really appreciate your time. Background:
I've been using Debian since Potato. This distro Just Works.
On 8/28/21 06:04, piorunz wrote:
> On 28/08/2021 13:54, Jeffrey Chimene wrote:
>
> Let me ask more questions, so we all can learn more about your situation
> and start suggesting remedies.
>
>> Hi,
>>
>> Thanks for the advice. The problem I'm trying to solve is why the AMD
>> firmware isn't getting incorporated in the kernel.
>
> How you assumed that firmware isn't getting to kernel? Do you have any
> errors in the log stating that?
There are no errors. Only warnings about an unsupported Wifi chip (r8169
missing RTL8125b-2).
As an aside: I have not mentioned this before, and I think it is a red
herring: The problems started when I connected the wifi antenna to the
board. The firmware for this chip isn't supported in this kernel, yet. I
think I can download the drivers from Intel. I'm not really interested
in wifi for this machine, as a wired connection works for now. This is
too coincidental and unrealistic, but I want to get past it so we can
move to other things. As soon as the antenna connections (dual coax) to
the board were made, the screen went black. I know. Bullshit. The board
doesn't really need an external antenna to detect wifi, so the antenna
connection only boosted the signal. If the OS wanted to load a
non-existent driver (which it's already trying to do as that failing
attempt appears in boot.log), it would've tried before then, external
antenna or no. Then somehow botch already loaded amdgpu firmeare? I
don't think so. It's as coincidental as the bookworm updates earlier
that day. When I rebooted to clear the issue (Linux isn't windows! One
doesn't reboot to fix issues), no display...
Anyway, on to your other questions...
>
>> I have to boot with
>> NOMODESET.
>
> What happens if you don't? Please show error logs when you don't have
> nomodeset.
There are no logs. nomodeset doesn't log anything. It enables display
twitching during boot. When XDM gains control, it will try to set the
display mode.
>
>> The bookworm updates, while coincidental, are probably not
>> the cause. "Something else" happened, and I need help debugging. I can't
>> see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.
>
> Try this:
>
> inxi -G
> Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
> 6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
> Display: x11 server: X.Org 1.20.11 driver: loaded:
> amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
> 1: 1920x1200~60Hz 2: 3840x2160
> OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
> 5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4
I don't have inxi installed. I will install it and post the results.
>
>>
>> I've run update-initramfs -c after replacing /var/lib/firmware. Still
>> not getting positive results from lsmod | grep -i amdgpu
>
> $ lsmod | grep -i amdgpu
> amdgpu 6606848 90
> gpu_sched 40960 1 amdgpu
> i2c_algo_bit 16384 1 amdgpu
> ttm 114688 1 amdgpu
> drm_kms_helper 274432 1 amdgpu
> drm 618496 39 gpu_sched,drm_kms_helper,amdgpu,ttm
>
> For me it works.
For me, nada. One of my earliest tests. I swear, I did see positive
results earlier!
>
>>
>> Booting with
>>
>> ro loglevel=7 nomodeset
>>
>> isn't giving any useable clues in boot.log
>
> What is your GPU (integrated or not) model? Please say exact model from
> inxi for example.
I'm sure it's integrated. It's a Asus board model B550M-A By now, it has
"reasonable" kernel support. About 18 months ago, it did not have such
support. As I said earlier, I think wifi isn't well supported, but I
don't care right now.
I would. I don't know where to start with such suppositions; which are
based on instructions like "cat BLAH > /FOO/BLECH" to change OS behavior.
Cheers,
jec
Thanks for your interest! I really appreciate your time. Background:
I've been using Debian since Potato. This distro Just Works.
On 8/28/21 06:04, piorunz wrote:
> On 28/08/2021 13:54, Jeffrey Chimene wrote:
>
> Let me ask more questions, so we all can learn more about your situation
> and start suggesting remedies.
>
>> Hi,
>>
>> Thanks for the advice. The problem I'm trying to solve is why the AMD
>> firmware isn't getting incorporated in the kernel.
>
> How you assumed that firmware isn't getting to kernel? Do you have any
> errors in the log stating that?
missing RTL8125b-2).
As an aside: I have not mentioned this before, and I think it is a red
herring: The problems started when I connected the wifi antenna to the
board. The firmware for this chip isn't supported in this kernel, yet. I
think I can download the drivers from Intel. I'm not really interested
in wifi for this machine, as a wired connection works for now. This is
too coincidental and unrealistic, but I want to get past it so we can
move to other things. As soon as the antenna connections (dual coax) to
the board were made, the screen went black. I know. Bullshit. The board
doesn't really need an external antenna to detect wifi, so the antenna
connection only boosted the signal. If the OS wanted to load a
non-existent driver (which it's already trying to do as that failing
attempt appears in boot.log), it would've tried before then, external
antenna or no. Then somehow botch already loaded amdgpu firmeare? I
don't think so. It's as coincidental as the bookworm updates earlier
that day. When I rebooted to clear the issue (Linux isn't windows! One
doesn't reboot to fix issues), no display...
Anyway, on to your other questions...
>
>> I have to boot with
>> NOMODESET.
>
> What happens if you don't? Please show error logs when you don't have
> nomodeset.
twitching during boot. When XDM gains control, it will try to set the
display mode.
>
>> The bookworm updates, while coincidental, are probably not
>> the cause. "Something else" happened, and I need help debugging. I can't
>> see amdgpu in lsmod. I can see the firmware in /var/lib/firmware.
>
> Try this:
>
> inxi -G
> Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
> 6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
> Display: x11 server: X.Org 1.20.11 driver: loaded:
> amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
> 1: 1920x1200~60Hz 2: 3840x2160
> OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
> 5.10.0-8-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.1.4
>
>>
>> I've run update-initramfs -c after replacing /var/lib/firmware. Still
>> not getting positive results from lsmod | grep -i amdgpu
>
> $ lsmod | grep -i amdgpu
> amdgpu 6606848 90
> gpu_sched 40960 1 amdgpu
> i2c_algo_bit 16384 1 amdgpu
> ttm 114688 1 amdgpu
> drm_kms_helper 274432 1 amdgpu
> drm 618496 39 gpu_sched,drm_kms_helper,amdgpu,ttm
>
> For me it works.
results earlier!
>
>>
>> Booting with
>>
>> ro loglevel=7 nomodeset
>>
>> isn't giving any useable clues in boot.log
>
> What is your GPU (integrated or not) model? Please say exact model from
> inxi for example.
"reasonable" kernel support. About 18 months ago, it did not have such
support. As I said earlier, I think wifi isn't well supported, but I
don't care right now.
>
>>
>> It feels like it's a kernel setting that got written and isn't reset
>> after down/up grades. This is testing. It's supposed to be "broken".
>
> I don't know what you are trying to say here. What supposed to be broken
> and why you think so?
It's based on intuition. If I had the resources to follow up that hunch,
>>
>> It feels like it's a kernel setting that got written and isn't reset
>> after down/up grades. This is testing. It's supposed to be "broken".
>
> I don't know what you are trying to say here. What supposed to be broken
> and why you think so?
I would. I don't know where to start with such suppositions; which are
based on instructions like "cat BLAH > /FOO/BLECH" to change OS behavior.
Cheers,
jec
Jeffrey Chimene
Aug 28, 2021, 10:20:04 AM8/28/21
to
On 8/28/21 06:04, piorunz wrote:
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
Display: server: X.Org 1.20.11 driver: loaded: ati,vesa
unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz
OpenGL: renderer: N/A v: N/A
$ aptitude search "~i firmware"
i firmware-amd-graphics - Binary firmware for AMD/ATI graphics chips
i firmware-iwlwifi - Binary firmware for Intel Wireless cards
i firmware-linux - Binary firmware for various drivers in the Linux
kernel (metapackage)
i A firmware-linux-free - Binary firmware for various drivers in the
Linux kernel
i firmware-linux-nonfree - Binary firmware for various drivers in the
Linux kernel (metapackage)
i A firmware-misc-nonfree - Binary firmware for various drivers in the
Linux kernel
$ ll /lib/firmware
total 40K
drwxr-xr-x 2 root root 20K Aug 27 05:50 amdgpu
drwxr-xr-x 2 root root 4.0K Aug 27 05:50 r128
drwxr-xr-x 2 root root 16K Aug 27 05:50 radeon
$ find /lib/firmware/ -iname \*pic\*
/lib/firmware/amdgpu/picasso_rlc_am4.bin
/lib/firmware/amdgpu/picasso_gpu_info.bin
/lib/firmware/amdgpu/picasso_ce.bin
/lib/firmware/amdgpu/picasso_ta.bin
/lib/firmware/amdgpu/picasso_me.bin
/lib/firmware/amdgpu/picasso_mec.bin
/lib/firmware/amdgpu/picasso_asd.bin
/lib/firmware/amdgpu/picasso_mec2.bin
/lib/firmware/amdgpu/picasso_sdma.bin
/lib/firmware/amdgpu/picasso_pfp.bin
/lib/firmware/amdgpu/picasso_vcn.bin
/lib/firmware/amdgpu/picasso_rlc.bin
Jeffrey Chimene
Aug 28, 2021, 10:30:04 AM8/28/21
to
No complaints about missing picasso firmware. I'll try removing the
/lib/firmware to see what happens.
$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for
module r8169
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/epiktistes--vg-swap_1)
I: Set the RESUME variable to override this.
/lib/firmware to see what happens.
$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for
module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for
module r8169
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/epiktistes--vg-swap_1)
I: Set the RESUME variable to override this.
Jeffrey Chimene
Aug 28, 2021, 10:30:04 AM8/28/21
to
On 8/28/21 07:04, Jeffrey Chimene wrote:
> No complaints about missing picasso firmware. I'll try removing the
> /lib/firmware to see what happens.
So this doesn't do what I thought it would. It's probably not even
> No complaints about missing picasso firmware. I'll try removing the
> /lib/firmware to see what happens.
looking for the picasso firmware.
ls: cannot access '/lib/firmware': No such file or directory
Jeffrey Chimene
Aug 28, 2021, 11:40:05 AM8/28/21
to
On 8/28/21 07:07, Jeffrey Chimene wrote:
> On 8/28/21 07:04, Jeffrey Chimene wrote:
>> No complaints about missing picasso firmware. I'll try removing the
>> /lib/firmware to see what happens.
>
> So this doesn't do what I thought it would. It's probably not even
> looking for the picasso firmware.
It's finding the firmware
> On 8/28/21 07:04, Jeffrey Chimene wrote:
>> No complaints about missing picasso firmware. I'll try removing the
>> /lib/firmware to see what happens.
>
> So this doesn't do what I thought it would. It's probably not even
> looking for the picasso firmware.
$# after removing /usr/lib/firmware
$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 > /tmp/before
$ grep -i pica /tmp/before
$ # revert /usr/lib/firmware
$ sudo update-initramfs -u
$ lsinitramfs /boot/initrd.img-5.10.0-8-amd64 > /tmp/after
$ grep -i pica /tmp/after
usr/lib/firmware/amdgpu/picasso_asd.bin
usr/lib/firmware/amdgpu/picasso_ce.bin
usr/lib/firmware/amdgpu/picasso_gpu_info.bin
usr/lib/firmware/amdgpu/picasso_me.bin
usr/lib/firmware/amdgpu/picasso_mec.bin
usr/lib/firmware/amdgpu/picasso_mec2.bin
usr/lib/firmware/amdgpu/picasso_pfp.bin
usr/lib/firmware/amdgpu/picasso_rlc.bin
usr/lib/firmware/amdgpu/picasso_rlc_am4.bin
usr/lib/firmware/amdgpu/picasso_sdma.bin
usr/lib/firmware/amdgpu/picasso_ta.bin
usr/lib/firmware/amdgpu/picasso_vcn.bin
piorunz
Aug 28, 2021, 12:00:04 PM8/28/21
to
picasso*.bin files are part of firmware-amd-graphics package.
$ apt-file search picasso_asd.bin
firmware-amd-graphics: /lib/firmware/amdgpu/picasso_asd.bin
These files are present in your system when you package installed.
Their presence doesn't mean that they will get loaded.
I can see in your inxi:
$ inxi -G
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
Display: server: X.Org 1.20.11 driver: loaded: ati,vesa
unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz
OpenGL: renderer: N/A v: N/A
You have no driver loaded, because you added nomodeset to boot
parameters. nomodeset instructs Linux kernel to not load video drivers.
You have installed non-free drivers (firmware-amd-graphics) and told
kernel not to load them.
Try without nomodeset and report back.
I may have missed your reply if you already did, please try to reply
with one post, not several consecutive posts, to keep discussion more
organized.
I can see that you said "It enables display twitching during boot. When
no driver and that's it.
$ apt-file search picasso_asd.bin
firmware-amd-graphics: /lib/firmware/amdgpu/picasso_asd.bin
These files are present in your system when you package installed.
Their presence doesn't mean that they will get loaded.
I can see in your inxi:
$ inxi -G
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
Display: server: X.Org 1.20.11 driver: loaded: ati,vesa
unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz
OpenGL: renderer: N/A v: N/A
parameters. nomodeset instructs Linux kernel to not load video drivers.
You have installed non-free drivers (firmware-amd-graphics) and told
kernel not to load them.
Try without nomodeset and report back.
I may have missed your reply if you already did, please try to reply
with one post, not several consecutive posts, to keep discussion more
organized.
I can see that you said "It enables display twitching during boot. When
XDM gains control, it will try to set the display mode."
You have to continue tests without nomodeset option, otherwise you have
no driver and that's it.
Jeffrey Chimene
Aug 28, 2021, 1:00:04 PM8/28/21
to
On 8/28/21 08:56, piorunz wrote:
> picasso*.bin files are part of firmware-amd-graphics package.
>
> $ apt-file search picasso_asd.bin
> firmware-amd-graphics: /lib/firmware/amdgpu/picasso_asd.bin
>
> These files are present in your system when you package installed.
> Their presence doesn't mean that they will get loaded.
>
> I can see in your inxi:
>
> $ inxi -G
> Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Picasso driver: N/A
> Display: server: X.Org 1.20.11 driver: loaded: ati,vesa
> unloaded: fbdev,modesetting,radeon resolution: 1440x876~1Hz
> OpenGL: renderer: N/A v: N/A
>
> You have no driver loaded, because you added nomodeset to boot
> parameters. nomodeset instructs Linux kernel to not load video drivers.
> You have installed non-free drivers (firmware-amd-graphics) and told
> kernel not to load them.
>
> Try without nomodeset and report back.
> I may have missed your reply if you already did, please try to reply
> with one post, not several consecutive posts, to keep discussion more
> organized.
>
forced me to add nomodeset.
David Wright
Aug 28, 2021, 3:20:05 PM8/28/21
to
On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
> Jeffrey Chimene wrote:
>
> just to note that using "bookworm" in your subject line can
> give the implication that "bookworm" is actually released which
> it hasn't. it is much better to use the keyword "testing" in
> the subject line instead.
I don't know where you got that from. A Release gets a *number*.
> Jeffrey Chimene wrote:
>
> just to note that using "bookworm" in your subject line can
> give the implication that "bookworm" is actually released which
> it hasn't. it is much better to use the keyword "testing" in
> the subject line instead.
(The number that might be given to trixie will depend on how
superstitious the Debian release team is.) It's legitimate to talk
about, say, features that might be retained in bookworm, but dropped
by trixie. That's what the codenames are for.
> > Any debugging tips?
>
> it does not take that much space to set up a separate
> partition for stable on a system to keep a working version
> available and for comparison. this is what i do.
Since a fortnight ago, they've become oldstable and oldoldstable.
See? Rather ambiguous. (They're buster and stretch.)
To interpret "testing" in an arbitrary post, I have to consult
my file listing the release dates of Debian suites.
0.01 1993-08
0.90 1993-12
0.91 1994-01
0.93R5 1995-03
0.93R6 1995-10-26
1.0 unreleased
buzz 1.1 1996-06-17
rex 1.2 1996-12-12
bo 1.3 1997-07-02/-06-05
hamm 2.0 1998-07-24
slink 2.1 1999-03-09
potato 2.2 2000-08-15
woody 3.0 2002-07-19
sarge 3.1 2005-06-06
etch 4.0 2007-04-08
lenny 5.0 2009-02-14
squeeze 6.0 2011-02-06
wheezy 7 2013-05-04
jessie 8 2015-04-25
stretch 9 2017-06-17
buster 10 2019-07-06
bullseye 11 2021-08-14
bookworm
trixie
sid (when woody started)
Cheers,
David.
piorunz
Aug 28, 2021, 4:50:05 PM8/28/21
to
On 28/08/2021 17:33, Jeffrey Chimene wrote:
>>
> Thanks! That was it. I don't know why it never loaded amdgpu; which
> forced me to add nomodeset.
Glad I could help! :) So everything is working now, removing this
>>
> Thanks! That was it. I don't know why it never loaded amdgpu; which
> forced me to add nomodeset.
nomodeset option solved it?
songbird
Aug 28, 2021, 10:30:05 PM8/28/21
to
David Wright wrote:
> On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
...
> On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
>> just to note that using "bookworm" in your subject line can
>> give the implication that "bookworm" is actually released which
>> it hasn't. it is much better to use the keyword "testing" in
>> the subject line instead.
>
> I don't know where you got that from.
because testing has always been just testing to me, when
>> give the implication that "bookworm" is actually released which
>> it hasn't. it is much better to use the keyword "testing" in
>> the subject line instead.
>
> I don't know where you got that from.
the images are made and sent out as official releases with
their signed packages and keys and all the rest that is when
i consider them by their code names. that is when the
release team actually releases it. just because i am following
along while they are putting it together in testing or sid
doesn't mean it is done.
> A Release gets a *number*.
> (The number that might be given to trixie will depend on how
> superstitious the Debian release team is.) It's legitimate to talk
> about, say, features that might be retained in bookworm, but dropped
> by trixie. That's what the codenames are for.
they're not done until they're released. of course this is
my opinion but i think the Release team also feels something
about the meaning of the word "Official" and the whole process
including the key signing and verification steps...
songbird
David Wright
Sep 1, 2021, 10:10:05 AM9/1/21
to
On Sat 28 Aug 2021 at 22:19:05 (-0400), songbird wrote:
> David Wright wrote:
> > On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
> ...
> >> just to note that using "bookworm" in your subject line can
> >> give the implication that "bookworm" is actually released which
> >> it hasn't. it is much better to use the keyword "testing" in
> >> the subject line instead.
> >
> > I don't know where you got that from.
>
> because testing has always been just testing to me, when
> the images are made and sent out as official releases with
> their signed packages and keys and all the rest that is when
> i consider them by their code names. that is when the
> release team actually releases it. just because i am following
> along while they are putting it together in testing or sid
> doesn't mean it is done.
That seems a reasonable viewpoint if you're a perpetual testing user,
> David Wright wrote:
> > On Sat 28 Aug 2021 at 08:36:32 (-0400), songbird wrote:
> ...
> >> just to note that using "bookworm" in your subject line can
> >> give the implication that "bookworm" is actually released which
> >> it hasn't. it is much better to use the keyword "testing" in
> >> the subject line instead.
> >
> > I don't know where you got that from.
>
> because testing has always been just testing to me, when
> the images are made and sent out as official releases with
> their signed packages and keys and all the rest that is when
> i consider them by their code names. that is when the
> release team actually releases it. just because i am following
> along while they are putting it together in testing or sid
> doesn't mean it is done.
living entirely in the present.
> > A Release gets a *number*.
> > (The number that might be given to trixie will depend on how
> > superstitious the Debian release team is.) It's legitimate to talk
> > about, say, features that might be retained in bookworm, but dropped
> > by trixie. That's what the codenames are for.
>
> sure, but those are all conversations about possibilities
> they're not done until they're released.
difficult to discuss future distributions without giving them
static codenames that don't shift under your feet. That's
standard practice in almost any project management.
> of course this is
> my opinion but i think the Release team also feels something
> about the meaning of the word "Official" and the whole process
> including the key signing and verification steps...
aren't "official" names?
Cheers,
David.
Andrew M.A. Cater
Sep 1, 2021, 10:40:04 AM9/1/21
to
switch to codenames at all (and a bunch of projects then followed our
example eg Ubuntu and Red Hat (though Red Hat's names are barely visible).
Someone at Infomagic wanted to steal a march on everyone else and publish
Debian 1.0 on their quarterly release. I can't remember quite what they
did package - but it wasn't release quality yet and didn't actually boot.
The end result was that Debian jumped straight to 1.1 and a new thing - a
codename (Buzz) because the then DPL (Bruce Perens) worked for Pixar.
bookworm is less than a month old but will follow the release until it's
oldoldstable - "testing" is a movable feast.
All the very best, as ever,
Andy Cater
> Cheers,
> David.
>
rhkr...@gmail.com
Sep 1, 2021, 11:40:05 AM9/1/21
to
On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater wrote:
> The end result was that Debian jumped straight to 1.1 and a new thing - a
> codename (Buzz) because the then DPL (Bruce Perens) worked for Pixar.
Just out of curiosity, I'm missing the significance of the then DPL (Bruce
> The end result was that Debian jumped straight to 1.1 and a new thing - a
> codename (Buzz) because the then DPL (Bruce Perens) worked for Pixar.
Perens) working for Pixar -- would something different have happened if he
worked somewhere else? Or ?
I tried googling (well DDGing) for a connection between Pixar and Infomagic,
but didn't turn up anything that looked relevant / useful.
The Wanderer
Sep 1, 2021, 11:50:04 AM9/1/21
to
On 2021-09-01 at 11:30, rhkr...@gmail.com wrote:
> On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater
> wrote:
>
>> The end result was that Debian jumped straight to 1.1 and a new
>> thing - a codename (Buzz) because the then DPL (Bruce Perens)
>> worked for Pixar.
>
> Just out of curiosity, I'm missing the significance of the then DPL
> (Bruce Perens) working for Pixar -- would something different have
> happened if he worked somewhere else? Or ?
Unless I'm greatly mistaken, the significance is that the Pixar
> On Wednesday, September 01, 2021 10:38:22 AM Andrew M.A. Cater
> wrote:
>
>> The end result was that Debian jumped straight to 1.1 and a new
>> thing - a codename (Buzz) because the then DPL (Bruce Perens)
>> worked for Pixar.
>
> Just out of curiosity, I'm missing the significance of the then DPL
> (Bruce Perens) working for Pixar -- would something different have
> happened if he worked somewhere else? Or ?
connection is why "buzz" was the codename that was chosen - and why
every single Debian release codename since then has also been the name
of a character from the Toy Story series.
I think this might have been slightly clearer if the grouping etc.
punctuation had been different. The best I've come up with on short
notice is something more like:
>>> The end result was that Debian jumped straight to 1.1 and a new
>>> worked for Pixar).
That's probably not enough of an improvement in clarity etc. to justify
the energy and attention *I*'ve spent on it, however, never mind the
same from Andrew.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Greg Wooledge
Sep 1, 2021, 11:50:05 AM9/1/21
to
he worked at Pixar.
The premature "Debian 1.0" had nothing to do with Pixar.
rhkr...@gmail.com
Sep 1, 2021, 12:20:05 PM9/1/21
to
0 new messages