Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #239365 > unrolled thread

amdgpu broken on bookworm?

Back to article view | Back to linux.debian.user

Contents

  amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-27 20:50 +0200
    Re: amdgpu broken on bookworm? piorunz <piorunz@gmx.com> - 2021-08-28 13:30 +0200
      Re: amdgpu broken on bookworm? Jeffrey Chimene <jchimene@gmail.com> - 2021-08-28 15:00 +0200
        Re: amdgpu broken on bookworm? piorunz <piorunz@gmx.com> - 2021-08-28 15:10 +0200
          Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 16:00 +0200
          Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 16:20 +0200
            Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 16:30 +0200
              Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 17:40 +0200
                Re: amdgpu broken on bookworm? piorunz <piorunz@gmx.com> - 2021-08-28 18:00 +0200
                  Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 19:00 +0200
                    Re: amdgpu broken on bookworm? piorunz <piorunz@gmx.com> - 2021-08-28 22:50 +0200
            Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 16:30 +0200
    Re: amdgpu broken on bookworm? songbird <songbird@anthive.com> - 2021-08-28 15:00 +0200
      Re: amdgpu broken on bookworm? Jeffrey Chimene <jchimene@gmail.com> - 2021-08-28 15:10 +0200
      Re: amdgpu broken on bookworm? Jeffrey Chimene <jeff@grandadventuresranch.com> - 2021-08-28 15:30 +0200
      Re: amdgpu broken on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2021-08-28 21:20 +0200
        Re: amdgpu broken on bookworm? songbird <songbird@anthive.com> - 2021-08-29 04:30 +0200
          Re: amdgpu broken on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2021-09-01 16:10 +0200
            Re: amdgpu broken on bookworm? "Andrew M.A. Cater" <amacater@einval.com> - 2021-09-01 16:40 +0200
              Re: amdgpu broken on bookworm? rhkramer@gmail.com - 2021-09-01 17:40 +0200
                Re: amdgpu broken on bookworm? The Wanderer <wanderer@fastmail.fm> - 2021-09-01 17:50 +0200
                Re: amdgpu broken on bookworm? Greg Wooledge <greg@wooledge.org> - 2021-09-01 17:50 +0200
                  Re: amdgpu broken on bookworm? rhkramer@gmail.com - 2021-09-01 18:20 +0200

Page 1 of 2  [1] 2  Next page →

#239365 — amdgpu broken on bookworm?

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?

[toc] | [next] | [standalone]

#239374

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.

--

With kindest regards, piorunz.

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

[toc] | [prev] | [next] | [standalone]

#239377

[Multipart message — attachments visible in raw view] — view raw

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.

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

[toc] | [prev] | [next] | [standalone]

#239379

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?

--

With kindest regards, piorunz.

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

[toc] | [prev] | [next] | [standalone]

#239382

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.
>
>>
>> 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, 
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

[toc] | [prev] | [next] | [standalone]

#239384

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?
>
>> 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
>
$ 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

$ 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

[toc] | [prev] | [next] | [standalone]

#239386

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.

$ 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.

$ ll /lib/firmware
ls: cannot access '/lib/firmware': No such file or directory

[toc] | [prev] | [next] | [standalone]

#239391

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

$# 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

[toc] | [prev] | [next] | [standalone]

#239393

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
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.

[toc] | [prev] | [next] | [standalone]

#239396

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.
>
Thanks! That was it. I don't know why it never loaded amdgpu; which 
forced me to add nomodeset.

[toc] | [prev] | [next] | [standalone]

#239404

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 
nomodeset option solved it?

-- 

With kindest regards, piorunz.

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

[toc] | [prev] | [next] | [standalone]

#239387

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.

[toc] | [prev] | [next] | [standalone]

#239376

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.


> 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.


  songbird

[toc] | [prev] | [next] | [standalone]

#239378

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.

Damn, that is such a good idea! I will add that to future 
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?

[toc] | [prev] | [next] | [standalone]

#239380

[Multipart message — attachments visible in raw view] — view raw

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.

Damn, that is such a good idea! I will add that to future 
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?

[toc] | [prev] | [next] | [standalone]

#239398

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*.
(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.

Ditto, except that typically mine are stable and oldstable.
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.

[toc] | [prev] | [next] | [standalone]

#239417

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.


> 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.  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

[toc] | [prev] | [next] | [standalone]

#239557

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,
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.

They have to be planned for in the years before release. It's
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...

I'm not sure what you're saying here; that bookworm and trixie
aren't "official" names?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239560

On Wed, Sep 01, 2021 at 09:06:47AM -0500, David Wright wrote:
> 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,
> 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.
> 
> They have to be planned for in the years before release. It's
> 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...
> 
> I'm not sure what you're saying here; that bookworm and trixie
> aren't "official" names?
> 

It's also worth reviewing ancient history which is what made Debian
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.
> 

[toc] | [prev] | [next] | [standalone]

#239562

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 ?

I tried googling (well DDGing) for a connection between Pixar and Infomagic, 
but didn't turn up anything that looked relevant / useful.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web