Hi, I have done a radical (= complete) upgrade of my 15 old
Packard Bell, consisting in motherboard, CPU, GPU, RAM ...
basically everything apart from 4 HDDs), which was likely to
have some broken ram or worse (not even ram-check program at
boot was able to complete the test !, but since it was an
aged machine I did not do extensive inquiry and I decided
for upgrade).

In origin (I mean when it work, roughly 2 years ago) the
machine was a DUAL BOOT.
In one SDD there was Debian BUSTER (or maybe BULLSEYE, but I
am not sure I upgraded it or not), and SWAP partition.
In another SDD there was Linux MX 21 WildFlower.

Once purchased, I connected the 4 HDDs to the e-sata
channels (consuming them all :\ :\), had some problems with
the new bios, completely windows-preconfigured, and had to
disable secure boot, fast boot, enable uefi/legacy features
and some other hidden options not immediately exposed, and
finally it "saw" the OSes installed.

Since Buster/Bullseye was by far the most used distro (still
is, on the main machine), I tried to boot it.

The system fails to boot entirely (and reasonably complaints
about missing firmwares), I mean, the boot does not complete
the GUI, but hitting ALT+F3 the commandline at full screen
shows up.

Linux MX (which had hated the older Packard Bell and had
never been stable on it), managed to boot smoothly and fast.
So first of all I made some two-days long update, upgrade.

I also shrinked the Buster/Bullseye ROOT partition (which
was 917 GiB wide, leaving room for just 16 GiB of Swap) in
order to enlarge SWAP to 64 GiB (the current amount of
physical RAM) since I want to re-enable HIBERNATION feature
(which at worst require the same amount of RAM ... even if I
don't plan to hibernate with so much RAM usage !). And the
thing went all right (for MX at least).

So in this machine now I have a "fully functional" MX
updated to Kernel 6.2

A Buster/Bullseye able to load the console interface.

A completely different hardware with respect with the one
where Debian had been installed.

Could you give me some "generic" advice in order to recover
the Debian install ?

I am not sure how many things need taking care of.
Maybe firmware, maybe some reconfigurations (preventing X
.... or Wayland, cannot remember which was the active graphic
server last run, from executing).

Since Debian was really heavily installed and configured,
I'd be eager to recover it without reinstalling.

A sub question ....
I was silly not to take note of the UUID of swap
before and after RESIZING (this is not a real problem : in
the new MX FSTAB file the new is consistent, and I could
check FSTAB from "offline" Debian and compare the old
value), but a simple RESIZE should not alter UUID of the
partition, am I right ? So FSTAB of Debian should not need
editing ... just for confirmation, I likely check anyway.

Tnx for any advice, for which tests to do to diagnose what
actually prevents X to execute in Debian.

I can easily act with its partition "offline" from MX, which
I by far find it easier to do, than working from inside in
cmdline ...

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

Am 30.03.2023 schrieb MarioCPPP <NoliMihiFrangereMentulam@libero.it>:

> Since Buster/Bullseye was by far the most used distro (still
> is, on the main machine), I tried to boot it.
>
> The system fails to boot entirely (and reasonably complaints
> about missing firmwares), I mean, the boot does not complete
> the GUI, but hitting ALT+F3 the commandline at full screen
> shows up.

Please check the logs - which firmware is missing?

Which GPU do you have and which driver?
nvidia/amd proprietary driver installed?
If so, uninstall it.

New hardware likes a new kernel - buster and bullseye are some years
old and maybe the kernel lacks drivers for your new hardware.

On Thu, 30 Mar 2023 14:13:50 +0200
MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:

> Hi, I have done a radical (= complete) upgrade of my 15 old
> Packard Bell, consisting in motherboard, CPU, GPU, RAM ...
> basically everything apart from 4 HDDs), which was likely to
> have some broken ram or worse (not even ram-check program at
> boot was able to complete the test !, but since it was an
> aged machine I did not do extensive inquiry and I decided
> for upgrade).
>
>
>
> In origin (I mean when it work, roughly 2 years ago) the
> machine was a DUAL BOOT.
> In one SDD there was Debian BUSTER (or maybe BULLSEYE, but I
> am not sure I upgraded it or not), and SWAP partition.
> In another SDD there was Linux MX 21 WildFlower.
>
> Once purchased, I connected the 4 HDDs to the e-sata
> channels (consuming them all :\ :\), had some problems with
> the new bios, completely windows-preconfigured, and had to
> disable secure boot, fast boot, enable uefi/legacy features
> and some other hidden options not immediately exposed, and
> finally it "saw" the OSes installed.
>
>
> Since Buster/Bullseye was by far the most used distro (still
> is, on the main machine), I tried to boot it.
>
> The system fails to boot entirely (and reasonably complaints
> about missing firmwares), I mean, the boot does not complete
> the GUI, but hitting ALT+F3 the commandline at full screen
> shows up.
>
>
>
>
> Linux MX (which had hated the older Packard Bell and had
> never been stable on it), managed to boot smoothly and fast.
> So first of all I made some two-days long update, upgrade.
>
> I also shrinked the Buster/Bullseye ROOT partition (which
> was 917 GiB wide, leaving room for just 16 GiB of Swap) in
> order to enlarge SWAP to 64 GiB (the current amount of
> physical RAM) since I want to re-enable HIBERNATION feature
> (which at worst require the same amount of RAM ... even if I
> don't plan to hibernate with so much RAM usage !). And the
> thing went all right (for MX at least).
>
>
> So in this machine now I have a "fully functional" MX
> updated to Kernel 6.2
>
> A Buster/Bullseye able to load the console interface.
>
> A completely different hardware with respect with the one
> where Debian had been installed.
>
> Could you give me some "generic" advice in order to recover
> the Debian install ?
>
> I am not sure how many things need taking care of.
> Maybe firmware, maybe some reconfigurations (preventing X
> ... or Wayland, cannot remember which was the active graphic
> server last run, from executing).
>
> Since Debian was really heavily installed and configured,
> I'd be eager to recover it without reinstalling.
>
> A sub question ....
> I was silly not to take note of the UUID of swap
> before and after RESIZING (this is not a real problem : in
> the new MX FSTAB file the new is consistent, and I could
> check FSTAB from "offline" Debian and compare the old
> value), but a simple RESIZE should not alter UUID of the
> partition, am I right ? So FSTAB of Debian should not need
> editing ... just for confirmation, I likely check anyway.
>
> Tnx for any advice, for which tests to do to diagnose what
> actually prevents X to execute in Debian.
>
> I can easily act with its partition "offline" from MX, which
> I by far find it easier to do, than working from inside in
> cmdline ...
>
>
>
>

I had the same problem with MX Linux. The screen was black until I hit
alt f1. The problem was the Intel graphics driver wasn't being used.
I solved the problem using the MX Tweak tool to change from the default
display driver to the Intel driver.

On 30/03/23 14:31, Johnny wrote:
> On Thu, 30 Mar 2023 14:13:50 +0200
> MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:
>
>> Hi, I have done a radical (= complete) upgrade of my 15 old
>> Packard Bell, consisting in motherboard, CPU, GPU, RAM ...
>> basically everything apart from 4 HDDs), which was likely to
>> have some broken ram or worse (not even ram-check program at
>> boot was able to complete the test !, but since it was an
>> aged machine I did not do extensive inquiry and I decided
>> for upgrade).
>>
>>
>>
>> In origin (I mean when it work, roughly 2 years ago) the
>> machine was a DUAL BOOT.
>> In one SDD there was Debian BUSTER (or maybe BULLSEYE, but I
>> am not sure I upgraded it or not), and SWAP partition.
>> In another SDD there was Linux MX 21 WildFlower.
>>
>> Once purchased, I connected the 4 HDDs to the e-sata
>> channels (consuming them all :\ :\), had some problems with
>> the new bios, completely windows-preconfigured, and had to
>> disable secure boot, fast boot, enable uefi/legacy features
>> and some other hidden options not immediately exposed, and
>> finally it "saw" the OSes installed.
>>
>>
>> Since Buster/Bullseye was by far the most used distro (still
>> is, on the main machine), I tried to boot it.
>>
>> The system fails to boot entirely (and reasonably complaints
>> about missing firmwares), I mean, the boot does not complete
>> the GUI, but hitting ALT+F3 the commandline at full screen
>> shows up.
>>
>>
>>
>>
>> Linux MX (which had hated the older Packard Bell and had
>> never been stable on it), managed to boot smoothly and fast.
>> So first of all I made some two-days long update, upgrade.
>>
>> I also shrinked the Buster/Bullseye ROOT partition (which
>> was 917 GiB wide, leaving room for just 16 GiB of Swap) in
>> order to enlarge SWAP to 64 GiB (the current amount of
>> physical RAM) since I want to re-enable HIBERNATION feature
>> (which at worst require the same amount of RAM ... even if I
>> don't plan to hibernate with so much RAM usage !). And the
>> thing went all right (for MX at least).
>>
>>
>> So in this machine now I have a "fully functional" MX
>> updated to Kernel 6.2
>>
>> A Buster/Bullseye able to load the console interface.
>>
>> A completely different hardware with respect with the one
>> where Debian had been installed.
>>
>> Could you give me some "generic" advice in order to recover
>> the Debian install ?
>>
>> I am not sure how many things need taking care of.
>> Maybe firmware, maybe some reconfigurations (preventing X
>> ... or Wayland, cannot remember which was the active graphic
>> server last run, from executing).
>>
>> Since Debian was really heavily installed and configured,
>> I'd be eager to recover it without reinstalling.
>>
>> A sub question ....
>> I was silly not to take note of the UUID of swap
>> before and after RESIZING (this is not a real problem : in
>> the new MX FSTAB file the new is consistent, and I could
>> check FSTAB from "offline" Debian and compare the old
>> value), but a simple RESIZE should not alter UUID of the
>> partition, am I right ? So FSTAB of Debian should not need
>> editing ... just for confirmation, I likely check anyway.
>>
>> Tnx for any advice, for which tests to do to diagnose what
>> actually prevents X to execute in Debian.
>>
>> I can easily act with its partition "offline" from MX, which
>> I by far find it easier to do, than working from inside in
>> cmdline ...
>>
>>
>>
>>
>
> I had the same problem with MX Linux. The screen was black until I hit
> alt f1. The problem was the Intel graphics driver wasn't being used.
> I solved the problem using the MX Tweak tool to change from the default
> display driver to the Intel driver.
>

but I have the problem with Debian (MX, which was more
recent, did not have problems).

I am going to add some HW info in another subthread ...

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 30/03/23 14:13, MarioCPPP wrote:

Some more details on the NEW hardware :

RAM 1 : CMW32GX4M2D3600 VENGEANCE RGB 32GB DDR4 3600 2X 1 12
RAM 2 : CMW32GX4M2D3600 VENGEANCE RGB 32GB DDR4 3600 2X 1 12
Cpu :100000644BOX AMD Ryzen5 4500 1 1
Power : FAL506FS12B TECNOWARE - PC ATX 500W fan 12 CM 2 X
SATA 1 X 24 POLI
Motherboard : PRIME-B550M-A PRIME B550M-A 1 17
Case : VCO-A2699 Case Atx Vultech VCO-A2699 con 1x USB 3.0 +
2x USB 2.0

The old graphic had both an Intel on board and a nVidia
external (one of the two had been disabled).

I cannot recall which driver was used by Debian (from the
commandline I am not able to get anything done).

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 30/03/23 14:29, Marco Moock wrote:
> Am 30.03.2023 schrieb MarioCPPP <NoliMihiFrangereMentulam@libero.it>:
>
>> Since Buster/Bullseye was by far the most used distro (still
>> is, on the main machine), I tried to boot it.
>>
>> The system fails to boot entirely (and reasonably complaints
>> about missing firmwares), I mean, the boot does not complete
>> the GUI, but hitting ALT+F3 the commandline at full screen
>> shows up.
>
> Please check the logs - which firmware is missing?

I'll try to search for them (even if I don't know where they
are located and the filenames) ...

>
> Which GPU do you have and which driver?

the NEW GPU is integrated into Ryzen 5 processor (not in the
mainboard). Later I'll see if INXI says more details.

As for the Drivers, MX has the old ones (I guess nouveau)
who still worked on new HW. Debian dunno, since it does not
load the GUI, I dunno how to know which driver it tries to load.

> nvidia/amd proprietary driver installed?

I seem to remember it had been unistalled, but unsure. I
worked on Synpaptic (in the GUI), I dunno how to do the same
things from cmdline

> If so, uninstall it.

is it possible to do this from the extern ? I mean, running
MX and working on Debian partition ?

>
> New hardware likes a new kernel - buster and bullseye are some years
> old and maybe the kernel lacks drivers for your new hardware.

on MX, who was able to run an old 5.10 kernel, the first
thing I did (after the proposed updates) was to use the
latest kernel available in the repo TESTING (the 6.2), which
went smooth. But from the GUI is easy to me ... Debian is
locked with the terminal :(

>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

Am 30.03.2023 schrieb MarioCPPP <NoliMihiFrangereMentulam@libero.it>:

> On 30/03/23 14:29, Marco Moock wrote:
> > Am 30.03.2023 schrieb MarioCPPP
> > <NoliMihiFrangereMentulam@libero.it>:
> >> Since Buster/Bullseye was by far the most used distro (still
> >> is, on the main machine), I tried to boot it.
> >>
> >> The system fails to boot entirely (and reasonably complaints
> >> about missing firmwares), I mean, the boot does not complete
> >> the GUI, but hitting ALT+F3 the commandline at full screen
> >> shows up.
> >
> > Please check the logs - which firmware is missing?
>
> I'll try to search for them (even if I don't know where they
> are located and the filenames) ...

sudo dmesg |grep -i firmware should be relevant.

> > Which GPU do you have and which driver?
>
> the NEW GPU is integrated into Ryzen 5 processor (not in the
> mainboard). Later I'll see if INXI says more details.

Then amdgpu should be fine with a new kernel.

> I seem to remember it had been unistalled, but unsure. I
> worked on Synpaptic (in the GUI), I dunno how to do the same
> things from cmdline

dpkg -l |grep -i nvidia

> > If so, uninstall it.
>
> is it possible to do this from the extern ? I mean, running
> MX and working on Debian partition ?

I don't recommend that. You can use the virtual console (ctrl+Alt+F1,
F2 etc.).

> > New hardware likes a new kernel - buster and bullseye are some years
> > old and maybe the kernel lacks drivers for your new hardware.
>
> on MX, who was able to run an old 5.10 kernel, the first
> thing I did (after the proposed updates) was to use the
> latest kernel available in the repo TESTING (the 6.2), which
> went smooth. But from the GUI is easy to me ... Debian is
> locked with the terminal :(

Try to boot the current Debian Bookworm Live image to see if he GPU
works there.

On Thu, 30 Mar 2023 15:42:34 +0200
MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:

> On 30/03/23 14:13, MarioCPPP wrote:
>
> Some more details on the NEW hardware :
>
>
> RAM 1 : CMW32GX4M2D3600 VENGEANCE RGB 32GB DDR4 3600 2X 1 12
> RAM 2 : CMW32GX4M2D3600 VENGEANCE RGB 32GB DDR4 3600 2X 1 12
> Cpu :100000644BOX AMD Ryzen5 4500 1 1
> Power : FAL506FS12B TECNOWARE - PC ATX 500W fan 12 CM 2 X
> SATA 1 X 24 POLI
> Motherboard : PRIME-B550M-A PRIME B550M-A 1 17
> Case : VCO-A2699 Case Atx Vultech VCO-A2699 con 1x USB 3.0 +
> 2x USB 2.0
>
> The old graphic had both an Intel on board and a nVidia
> external (one of the two had been disabled).
>
> I cannot recall which driver was used by Debian (from the
> commandline I am not able to get anything done).
>
>
>

Using MX Linux, click on Quick System Info. That may give you
some information on Debian.

On 30/03/23 15:54, Marco Moock wrote:
> Am 30.03.2023 schrieb MarioCPPP <NoliMihiFrangereMentulam@libero.it>:
>
>> On 30/03/23 14:29, Marco Moock wrote:
>>> Am 30.03.2023 schrieb MarioCPPP
>>> <NoliMihiFrangereMentulam@libero.it>:
>>>> Since Buster/Bullseye was by far the most used distro (still
>>>> is, on the main machine), I tried to boot it.
>>>>
>>>> The system fails to boot entirely (and reasonably complaints
>>>> about missing firmwares), I mean, the boot does not complete
>>>> the GUI, but hitting ALT+F3 the commandline at full screen
>>>> shows up.
>>>
>>> Please check the logs - which firmware is missing?
>>
>> I'll try to search for them (even if I don't know where they
>> are located and the filenames) ...
>
> sudo dmesg |grep -i firmware should be relevant.

tnx a lot. I'll try this cmq later.

Meanwhile, I have been making attempts with SystemCtl, who
in RED color evidenced some criticities, which I copy beneath :

status unit Load Active Sub info

* lightdm.service loaded failed failed light display manager

* nvidia-persistent.service loaded failed failed NVIDIA
PERSISTENCE DAEMON

* system-modules-load.service loaded failed failed Load
Kernel Modules

(this latter also showed up on boot, in red)

>
>>> Which GPU do you have and which driver?
>>
>> the NEW GPU is integrated into Ryzen 5 processor (not in the
>> mainboard). Later I'll see if INXI says more details.

now some results from INXI :

graphics section : AMD/ATI, drivers loaded : amdgpu v.
kernel, ati
drivers unloaded : fbdev, vesa, modsetting

Debian had been upgraded to v. 11 (Bullseye) and kernel was
5.10.0-16 (the very same kernel which I had on MX before
yesterday upgrades, and that there worked fine)

CPU 6-core AMD Ryzen 5 - 4600 G with Radeon Graphics (-MT MGP-)

These acronyms do not tell anything to me.

But I'll try to scan better as you advised.

>
> Then amdgpu should be fine with a new kernel.
>
>> I seem to remember it had been unistalled, but unsure. I
>> worked on Synpaptic (in the GUI), I dunno how to do the same
>> things from cmdline
>
> dpkg -l |grep -i nvidia

nice. If I find it, I'll try to use man to remember how to
uninstall

>
>>> If so, uninstall it.
>>
>> is it possible to do this from the extern ? I mean, running
>> MX and working on Debian partition ?
>
> I don't recommend that. You can use the virtual console (ctrl+Alt+F1,
> F2 etc.).

The console are powerful to those who know the commands ...
I'm handycapped working in CLI mode :(

>
>>> New hardware likes a new kernel - buster and bullseye are some years
>>> old and maybe the kernel lacks drivers for your new hardware.
>>
>> on MX, who was able to run an old 5.10 kernel, the first
>> thing I did (after the proposed updates) was to use the
>> latest kernel available in the repo TESTING (the 6.2), which
>> went smooth. But from the GUI is easy to me ... Debian is
>> locked with the terminal :(
>
> Try to boot the current Debian Bookworm Live image to see if he GPU
> works there.

I don't have bookworm, I never found an .iso prebuilt, just
hints to upgrade the repos from the latest stable.

>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 30/03/23 16:16, Johnny wrote:
> On Thu, 30 Mar 2023 15:42:34 +0200
> MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:
>
>> On 30/03/23 14:13, MarioCPPP wrote:
>>
>> Some more details on the NEW hardware :
>>
>>
>> RAM 1 : CMW32GX4M2D3600 VENGEANCE RGB 32GB DDR4 3600 2X 1 12
>> RAM 2 : CMW32GX4M2D3600 VENGEANCE RGB 32GB DDR4 3600 2X 1 12
>> Cpu :100000644BOX AMD Ryzen5 4500 1 1
>> Power : FAL506FS12B TECNOWARE - PC ATX 500W fan 12 CM 2 X
>> SATA 1 X 24 POLI
>> Motherboard : PRIME-B550M-A PRIME B550M-A 1 17
>> Case : VCO-A2699 Case Atx Vultech VCO-A2699 con 1x USB 3.0 +
>> 2x USB 2.0
>>
>> The old graphic had both an Intel on board and a nVidia
>> external (one of the two had been disabled).
>>
>> I cannot recall which driver was used by Debian (from the
>> commandline I am not able to get anything done).
>>
>>
>>
>
> Using MX Linux, click on Quick System Info. That may give you
> some information on Debian.
>

I got some info from SystemCtl (about the problems, surely
NOT all of them) and some HW / SW info from INXI.
I reported them in my reply to to MarcoMoock of 19:48. Are
they useful ?

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

MarioCPPP <NoliMihiFrangereMentulam@libero.it> writes:

> The old graphic had both an Intel on board and a nVidia external (one
> of the two had been disabled).

Then I might guess you're missing package firmware-amd-graphics.

> I cannot recall which driver was used by Debian (from the commandline
> I am not able to get anything done).

apt install firmware-amd-graphics

On Thu, 30 Mar 2023 14:13:50 +0200, MarioCPPP wrote:
>
> Hi, I have done a radical (= complete) upgrade of my 15 old
> Packard Bell, consisting in motherboard, CPU, GPU, RAM ...
> basically everything apart from 4 HDDs), which was likely to
> have some broken ram or worse (not even ram-check program at
> boot was able to complete the test !, but since it was an
> aged machine I did not do extensive inquiry and I decided
> for upgrade).

> A sub question ....
> I was silly not to take note of the UUID of swap
> before and after RESIZING (this is not a real problem :

You should be able to get the old UUID from /etc/fstab of an old
install.

I got rid of the UUID problem by using partition Name and Partition Labels.

$ head -8 /etc/fstab
# Created by /local/bin/fstab_changes Mon 02 Jan 12:36 2023
LABEL=mga9 / ext4 relatime,acl 1 1
LABEL=accounts /accounts ext4 relatime,acl 1 2
LABEL=BOOT_EFI /boot/EFI vfat users,noauto,relatime,acl,umask=000 1 2
LABEL=local /local ext4 relatime,acl 1 2
none /proc proc defaults 0 0
LABEL=spare /spare ext4 relatime,acl 1 2
PARTLABEL=swap swap swap defaults,nofail 0 0

On 3/30/23 14:13, MarioCPPP wrote:

> A sub question ....
> I was silly not to take note of the UUID of swap
> before and after RESIZING (this is not a real problem : in the new MX
> FSTAB file the new is consistent, and I could check FSTAB from "offline"
> Debian and compare the old value), but a simple RESIZE should not alter
> UUID of the partition, am I right ? So FSTAB of Debian should not need
> editing ... just for confirmation, I likely check anyway.

mkswap will change the UUID each time you run it.

--
//Aho

First of all, I am glad to thank all who gave their advices
: my old Debian Bullseye was revived successfully ! Geeee
I try to resume the path in case sb else might need my
incomplete notes.

the output of the suggested command (sudo dmesg | grep -i
firmware) contained roughly
amdgpu firmware :
direct-loading firmware amdgpu/renoir_sdma.bin
direct-loading firmware amdgpu/renoir_asd.bin
direct-loading firmware amdgpu/renoir_ta.bin
direct-loading firmware amdgpu/renoir_fpf.bin
direct-loading firmware amdgpu/renoir_me.bin
direct-loading firmware amdgpu/renoir_ce.bin
direct-loading firmware amdgpu/renoir_rcl.bin
direct-loading firmware amdgpu/renoir_mec.bin
direct-loading firmware amdgpu/renoir_mec2.bin
direct-loading firmware amdgpu/renoir_dmcub.bin
direct-loading firmware amdgpu/renoir_vcm.bin
amdgpu : will use PSP to load VCN firmware

then some further errors related to "r8169" (which, If I got
it right, is some network card)
r8169 : FAILED TO LOAD rtl_nic/rtl8168h-2.fw (-2)
r8169 unable to load firmware rtl_nic/rtl8168h-2.fw returned
error code 2

--------------------------------------------------------------------------------

the output of the other suggested command (sudo dpkg -l |
grep -i nvidia) contained roughly
possible missing firmware rtl_nic/rtl8168h-2.fw for module r8169
and a lot of very similar entries like
/lib/firmware/amdgpu/arcturus_ta.bin
/lib/firmware/amdgpu/arcturus_asd.bin
/lib/firmware/amdgpu/arcturus_sos.bin
/lib/firmware/amdgpu/arcturus_rcl.bin
/lib/firmware/amdgpu/arcturus_mec2.bin
/lib/firmware/amdgpu/arcturus_mec.bin
/lib/firmware/amdgpu/arcturus_sdma.bin
/lib/firmware/amdgpu/arcturus_smc.bin
/lib/firmware/amdgpu/navy_flounder_rcl.bin
/lib/firmware/amdgpu/navy_flounder_mec2.bin
/lib/firmware/amdgpu/navy_flounder_mec.bin
/lib/firmware/amdgpu/navy_flounder_me.bin
/lib/firmware/amdgpu/navy_flounder_fpf.bin
/lib/firmware/amdgpu/navy_flounder_ce.bin
/lib/firmware/amdgpu/navy_flounder_sdma.bin
/lib/firmware/amdgpu/navy_flounder_smc.bin
/lib/firmware/amdgpu/navy_flounder_dmcub.bin

------------------------------------------------------------------------

now, what I am able to recall I tried to solve

I failed to run dpkg. Then I tried apt list *nvidia* and, later
APT REMOVE (or UNINSTALL ? dunno :\) *nvidia*
APT listed some not installed packages (not removed) and
removed all nvidia-related packages. It automatically
installed OTHER packages.
Apparently it reinstalled some nvidia-like stuff. And it
rebuild sth and auto launched many times UPDATE INITRAMFS.

later I tried APT INSTALL *amdgpu* (luckily the de-globbing
of wildcards produced the hoped effect) and again it
installed a lot of stuff, though far less than It removed
before, among which a newer PYTHON version.
It again built sth for AMD cpu and relaunched UPDATE INITRAMFS.

I am not sure if i did sth else before rebooting. Maybe
CHKBOOT (at some point I was informed some grup config had
been updated, which required to run chkboot as root).

I rebooted and the GUI was up and roaring again !

I am making some update and upgrade with synaptic (I still
have non blocking errors, even in repo configuration : some
entries seem to no longer exist, some others are listed
multiple times), but I found 348 package to update.
Later I will try to align the kernel to 6.2, maybe with EHS
or AHS (enhanced/advanced hardware support), since the
machine is new.

Again, I'd like to thank you all for the precise help and
good advices.
No choice in my life was as good as the switching to linux
world and joining the community of solidaristic people like
the ones on this NG.
I have been an user for the last 6 years, but despite of the
time I still remain a non skilled user, so for me this kind
of suggestions are still very precious !
You have avoided more than a couple of weeks of work of
reinstalling and reconfiguring, and a restoration
incomplete. This way I have recovered ALL and can decide
what to keep and what to discard in great calm.
Great. Tnx !

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 3/31/2023 5:13 AM, MarioCPPP wrote:
> First of all, I am glad to thank all who gave their advices : my old Debian Bullseye was revived successfully ! Geeee
> I try to resume the path in case sb else might need my incomplete notes.
>
> the output of the suggested command (sudo dmesg | grep -i firmware) contained roughly
> amdgpu firmware :
>     direct-loading firmware amdgpu/renoir_sdma.bin
>     direct-loading firmware amdgpu/renoir_asd.bin
>     direct-loading firmware amdgpu/renoir_ta.bin
>     direct-loading firmware amdgpu/renoir_fpf.bin
>     direct-loading firmware amdgpu/renoir_me.bin
>     direct-loading firmware amdgpu/renoir_ce.bin
>     direct-loading firmware amdgpu/renoir_rcl.bin
>     direct-loading firmware amdgpu/renoir_mec.bin
>     direct-loading firmware amdgpu/renoir_mec2.bin
>     direct-loading firmware amdgpu/renoir_dmcub.bin
>     direct-loading firmware amdgpu/renoir_vcm.bin
> amdgpu : will use PSP to load VCN firmware
>
> then some further errors related to "r8169" (which, If I got it right, is some network card)
> r8169 : FAILED TO LOAD rtl_nic/rtl8168h-2.fw (-2)
> r8169 unable to load firmware rtl_nic/rtl8168h-2.fw returned error code 2
>
> --------------------------------------------------------------------------------
>
> the output of the other suggested command (sudo dpkg -l | grep -i nvidia) contained roughly
> possible missing firmware rtl_nic/rtl8168h-2.fw for module r8169
> and a lot of very similar entries like
> /lib/firmware/amdgpu/arcturus_ta.bin
> /lib/firmware/amdgpu/arcturus_asd.bin
> /lib/firmware/amdgpu/arcturus_sos.bin
> /lib/firmware/amdgpu/arcturus_rcl.bin
> /lib/firmware/amdgpu/arcturus_mec2.bin
> /lib/firmware/amdgpu/arcturus_mec.bin
> /lib/firmware/amdgpu/arcturus_sdma.bin
> /lib/firmware/amdgpu/arcturus_smc.bin
> /lib/firmware/amdgpu/navy_flounder_rcl.bin
> /lib/firmware/amdgpu/navy_flounder_mec2.bin
> /lib/firmware/amdgpu/navy_flounder_mec.bin
> /lib/firmware/amdgpu/navy_flounder_me.bin
> /lib/firmware/amdgpu/navy_flounder_fpf.bin
> /lib/firmware/amdgpu/navy_flounder_ce.bin
> /lib/firmware/amdgpu/navy_flounder_sdma.bin
> /lib/firmware/amdgpu/navy_flounder_smc.bin
> /lib/firmware/amdgpu/navy_flounder_dmcub.bin
>
> ------------------------------------------------------------------------
>
> now, what I am able to recall I tried to solve
>
> I failed to run dpkg. Then I tried apt list *nvidia* and, later
> APT REMOVE (or UNINSTALL ? dunno :\) *nvidia*
> APT listed some not installed packages (not removed) and removed all nvidia-related packages. It automatically installed OTHER packages.
> Apparently it reinstalled some nvidia-like stuff. And it rebuild sth and auto launched many times UPDATE INITRAMFS.
>
> later I tried APT INSTALL *amdgpu* (luckily the de-globbing of wildcards produced the hoped effect) and again it installed a lot of stuff, though far less than It removed before, among which a newer PYTHON version.
> It again built sth for AMD cpu and relaunched UPDATE INITRAMFS.
>
> I am not sure if i did sth else before rebooting. Maybe CHKBOOT (at some point I was informed some grup config had been updated, which required to run chkboot as root).
>
> I rebooted and the GUI was up and roaring again !
>
> I am making some update and upgrade with synaptic (I still have non blocking errors, even in repo configuration : some entries seem to no longer exist, some others are listed multiple times), but I found 348 package to update.
> Later I will try to align the kernel to 6.2, maybe with EHS or AHS (enhanced/advanced hardware support), since the machine is new.
>
> Again, I'd like to thank you all for the precise help and good advices.
> No choice in my life was as good as the switching to linux world and joining the community of solidaristic people like the ones on this NG.
> I have been an user for the last 6 years, but despite of the time I still remain a non skilled user, so for me this kind of suggestions are still very precious !
> You have avoided more than a couple of weeks of work of reinstalling and reconfiguring, and a restoration incomplete. This way I have recovered ALL and can decide what to keep and what to discard in great calm.
> Great. Tnx !

Normally, the thing that trips people up, is the blacklisting.
And because you're using a different brand of GPU, that is
probably why what you just did, worked. Nouveau is probably
still blacklisted, but because you now have an AMDGPU, there is no
blacklist inserted for that.

This shows you the potential location of such things.

https://linuxconfig.org/how-to-disable-blacklist-nouveau-nvidia-driver-on-ubuntu-22-04-jammy-jellyfish-linux

/etc/modprobe.d/blacklist-nvidia-nouveau.conf

Paul

On Fri, 31 Mar 2023 11:13:37 +0200, MarioCPPP wrote:
> Snip

> Again, I'd like to thank you all for the precise help and good advices.
> No choice in my life was as good as the switching to linux world and
> joining the community of solidaristic people like the ones on this NG.
> I have been an user for the last 6 years, but despite of the time I
> still remain a non skilled user, so for me this kind of suggestions are
> still very precious !
> You have avoided more than a couple of weeks of work of reinstalling and
> reconfiguring, and a restoration incomplete. This way I have recovered
> ALL and can decide what to keep and what to discard in great calm.
> Great. Tnx !

Good job Mario!!! You have come a long way....

--
Pull my finger