My new AMD video card


Will this default back to 5.10

1 Like

My alltime favourite is systemback.sh

It is just a script. Works well on local computer as well as on VPS or on a headless setup, like my Odroid.
It has some config options in the first couple lines of the script itself.
It uses rsync under the hood.
One thing to remember: when a system restore involves changing kernel, it is good run an update-grub before rebooting.

1 Like

No, it will stay to boot with kernel 6.0
You need to take actions to revert. When rebooting, change to the older kernel in GRUB menu. Then after remove the packages of kernel 6.0.
Installing/removing kernel packages automatically execute update-grub as well, so you don’t need to do it manually.
After you removed them via apt remove, it will boot the 5.10 again. Maybe do an apt autoremove just to cleanup unnecessary packages.

2 Likes

I learned something this morning, thanks!!

2 Likes

I think Ubuntu defaults to saving three kernel revisions. Other distros will surely vary. I’m not sure if it saves the same number in the grub menu or not.

1 Like

Gentoo will save as many kernels that it emerges, if one does not use the emerge --noreplace options for the kernel that is in use, the next time one boots, you will only have a blinking cursor. Such fun with Linux.

1 Like

Debian saves 3 kernels, like Ubuntu. Void saves every kernel… it has a special command vkpurge to delete them by hand.

@4dandl4 ,
Do you have any running problems with 6.0.0.0?

I am going to be a lot slower than you. My fiirst issue was getting Clonezilla to boot with the new graphics card present. It would seem I need a newer Clonezilla too, its kernel is too old… problems multiply.

I think I need to take a look at systemback
I have always used a mix of Clonezilla and manual rsync
I tried Borg, but it is too complicated for my ageing brain.

1 Like

My mobo does :

Machine:
  Type: Desktop System: Micro-Star product: MS-7C37 v: 3.0
    serial: <superuser required>
  Mobo: Micro-Star model: X570-A PRO (MS-7C37) v: 3.0
    serial: <superuser required> UEFI: American Megatrends LLC. v: H.H1
    date: 05/18/2022

But - ONLY if the CPU is an APU (i.e. GPU on the die) - my Ryzen 7 3700X does not have an APU/GPU. In some ways I kinda wish I’d gone for an APU - then I’d have even more display options - as well as a single HDMI, the mobo also has a USB C Thunderbolt / Lightning port if the board is rocking an APU. But at the time - best bang for buck was without APU, as there’s always a “cost” when you do stuff like that.

1 Like

It running well and am using it at this moment. When I first started 6.0, had to edit the advanced grub entry and find the 6.0 vmlinuz, did an F10 booted 6.0 from the menu. Are backports using Debian testing?

My understanding is that they are basically testing, but carefully screened to make sure they are compatable with stable

Sound like I can try 6.0.0.0. Thanks for trying it . Its fun learning new useful stuff. It is good of Laszlo to share his Debian expertise.

3 Likes

Here is what I did to Image Debian

  • mount the Debian root filesystem, and another empty partition
/dev/sda1       100597928  19493996  75967636  21% /run/media/nevj/LinuxRoot1
/dev/sdb1       191840572        24 182069440   1% /run/media/nevj/LinuxRH
  • run the following as root
rsync -aAXvH --exclude={'dev/*','proc/*','sys/*','tmp/*','run/*','mnt/*','media/*','lost+found','common/*'} /run/media/nevj/LinuxRoot1/  /run/media/nevj/LinuxRH
  • thats it , I end up with an image of Debian on the LinuxRH partition

Explanations:
Those excludes are to prevent it imaging the contents of directories like proc that are populated at boot time
or to not image the contents of any mounts
or to not image my /common data directory.

It must be run in bash shell … those {} are a bashism
You should not run it in the system that is being copied… ie I used Solus to copy Debian… dont use Debian to copy Debian

nevj@trinity ~ $ ls /run/media/nevj/LinuxRH
bin     dev   initrd.img      lib32   lost+found  opt   run   sys  var
boot    etc   initrd.img.old  lib64   media       proc  sbin  tmp  vmlinuz
common  home  lib             libx32  mnt         root  srv   usr  vmlinuz.old

Its all there!

I think , from what Laszlo says about his SystemBack, it does something similar. Will have a look.

1 Like

Systemback cares dfferently for /home folders, but basically yes, it does similar.

1 Like

@kovacslt , @4dandl4 and anyone interested
I did the backport, here is a script

root@trinity:/etc# apt search linux-image | grep backports

linux-headers-6.0.0-0.deb11.6-amd64/bullseye-backports 6.0.12-1~bpo11+1 amd64

linux-image-6.0.0-0.deb11.6-amd64/bullseye-backports 6.0.12-1~bpo11+1 amd64


root@trinity:/etc# apt install linux-image-6.0.0-0.deb11.6-amd64 linux-headers-6
.0.0-0.deb11.6-amd64

The following NEW packages will be installed:
  linux-compiler-gcc-10-x86 linux-headers-6.0.0-0.deb11.6-amd64
  linux-headers-6.0.0-0.deb11.6-common linux-image-6.0.0-0.deb11.6-amd64
  linux-kbuild-6.0


Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.0.0-0.deb11.6-amd64
Found initrd image: /boot/initrd.img-6.0.0-0.deb11.6-amd64
Found linux image: /boot/vmlinuz-5.10.0-20-amd64
Found initrd image: /boot/initrd.img-5.10.0-20-amd64
Found linux image: /boot/vmlinuz-5.10.0-19-amd64
Found initrd image: /boot/initrd.img-5.10.0-19-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot 
entries.
Found Debian GNU/Linux 11 (bullseye) on /dev/sda1
Found Void Linux on /dev/sda7
Found Void Linux on /dev/sdb12
Found Void Linux on /dev/sdb5
Found Solus (4.3) on /dev/sdb7
Found Devuan GNU/Linux 4 (chimaera) on /dev/sdb9
done

root@trinity:~# apt install firmware-amd-graphics -t bullseye-backports

The following additional packages will be installed:
  firmware-linux-nonfree firmware-misc-nonfree
The following packages will be upgraded:
  firmware-amd-graphics firmware-linux-nonfree firmware-misc-nonfree


root@trinity:~# apt search amdgpu | grep backports

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

firmware-amd-graphics/bullseye-backports,now 20210818-1~bpo11+1 all [installed,a
utomatic]
root@trinity:~# 
nevj@trinity:~$ 

It did an update-grub as part of the install, so I just rebooted

  • first reboot fails before gdm
  • second reboot fails after gdm
  • third reboot with acpi=off succeeds
    but
  • it is still running in vga mode
root@trinity:/home/nevj# lshw -c video
  *-display UNCLAIMED       
       description: VGA compatible controller
       product: Advanced Micro Devices, Inc. [AMD/ATI]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:03:00.0
       version: c7
       width: 64 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller cap_list
       configuration: latency=0
       resources: memory:c0000000-cfffffff memory:d0000000-d01fffff ioport:e000(size=256) memory:fb600000-fb6fffff memory:c0000-dffff

No driver there.

lspci
...
01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c7)
02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 743f (rev c7)
...

It should be Navi24.
It is not finding any driver for the card.
loading the driver with
modprobe -a amdgpu
does nothing.

So I have to conclude that the backport material was insufficient to drive the graphics card. Strange, Solus and Void using that kernel drive the card OK.
I dont think we have the required firmware, even though I installed the firmware backport.

The mystery of unreliable booting in vga mode remains.

Thanks to all for help.
Any further ideas welcome. The issue is not solved.

Just thinking… isn’t there some blacklist left from your previous nvidia attempts maybe?
Would you mind to try with a fresh installed Debian?
Or at least see how a Debian live USB (preferably unofficial with non-free blobs included) behaves with your card?

Nothing is blacklisted. Will doublecheck.
Good thinking… Both my Debian11 and Devuan4 are inline upgrades from Debian10 and Devuan3. There were some issues with printer drivers and scanner drivers after these upgrades, so it is entirely possible other things like graphics card detection were mangled.
Will do a fresh install with nonfree.
I have a few live DVD I might try too
I used an old gparted dvd (written in 2012) and it booted. With Clonezilla DVD I had to choose a failsafe option. So lots of things work with that RX6400 card present. They use VGA mode of course. I dont get Debian having such a problem in VGA mode.

I appreciate the thoughts.
Regards
Neville

1 Like

I think I found something:
https://forums.debian.net/viewtopic.php?p=752673&sid=1e54fa8ffe8e3546343c90f2e0a6a38e#p752673
That looks serious…

@nevj
I really cannot duplicate your graphics card issue, since I am not running your RX6400.


This is the latest lshw from a new (overnight) Gentoo install. Of course, it only proves that the 5.15.80 kernel supports the Radeon 5670 with the radeon driver, it may also support the new amdgpu AMD driver. Not saying Gentoo is right for you, or for anyone, but it just might help.

It says I need to download newer firmware.
I will still try the new fresh install… It might at least fix the unreliable vga booting. A failsafe system that fails is just a little inconvenient.

I can check on the firmware
If I use modinfo amdgpu it should tell me what is there.
Then compare it to what I get in Void or Solus.
If they differ, I have a firmware problem

Regards
Neville