This isn't what the radeon driver does for AMD gpu's, and hasn't for years: loading the driver automatically enables the full rendering engine and disables the VESA modes, even if no firmware has been loaded. Which means that on a normal system with radeon.ko present but not the firmware files, you get a few seconds of kernel output followed by a black screen. For the systems where I don't want the firmware (servers), I must be very careful to blacklist the radeon driver or I completely lose the local console.

This has been the case since the SI chipsets in 2012. I'm not sure if the fault lies fully with the driver, maybe the hardware doesn't allow querying the state of the engine firmware before enabling the engine.

The Radeon module works on non-accelerated mode with the modesetting driver instead of the xorg Radeon one.

At /usr/share/X11/xorg.conf.d/10-radeon.conf:

     Section "Device"
 identifier "Radeon"
 Driver "modesetting"
    EndSection

Bugs may arise, maybe it could be a good idea to disable the Composite extension too.

I guess I confused the issue by referring it as the "radeon driver", but I meant to implicate the radeon.ko kernel module, not the radeon(4) Xorg driver. The servers I'm talking about don't even have X installed (they're Ceph OSD nodes).

Linux libre here. I ran Trisquel on TTY mode to debug issues, I modprobed the radeon module and KMS switched the resolution to a native one in a laptop. Starting X with the radeon driver for X messes everything garbled up. The modesetting driver works, but no GL.

TTY works well before and after KMS.

Because of the very common issue with network card firmware (wired&wireless) I have taken to always providing initial network access during install through me hooking up my phone via USB-tethering. No Firmware needed.

Then select "expert mode", enable "non-free" repo, maybe "backports", go through base install only, reboot, re-enable USB-tethering a last time on the phone, install needed network card firmware, reboot, disconnect phone, run "tasksel", select whatever you want to install to finish install.

Having done this "detour" for many years now, it's "automatic" for me, and takes barely 3 minutes longer than the "normal" install from the IsoWithNonFree. I usually want "backports" enabled, so going into "expert mode" is required anyway.

This is such a solvable issue it deeply disturbs me you need to dance this dance. Whilst you might not be complaining about it, this is exactly the kind of stuff that deters people from using more FOSS. Not only are selecting non-default options every time you install a debian system, you've also spent the time to learn this ritual and you've had to comprehend the complexities of what, how and why to do this. Just to install an OS. I understand the FOSS advocacy angle, but this is impractically stupid. You're not the only one who has learned to deal with this, so I'd wager there's months if not years of waking hours lost to what could easily be automated away.

The other reason I do it like this, is because many years ago I got a comment from an auditor about an item on the install-log: "Used CD-Image from https://cdimage...", because he spotted the "/unofficial/non-free/" part of the URL. The resulting discussion is what I wanted to avoid in future.

That must have been a nasty discussion you had there.

Not nasty, but unnessesary, for the both of us. He was a non-technical auditor, and was hoping to put something damning on his report to justify the expense. He "cleared" that item after discussion, but I did not want to have that talk about the "unofficial.iso" again. And since I +-always take expert mode for other reasons anyway, having to select "non-free" repo on devices with non-free components from inside the standard installer is no big detour.

This kind of attitude is what makes FOSS good compared to (for example) ChromeOS though. It's hard to see when you've got one singular problem in front of you but once you abandon your principles and change all these things you're left with what is essentially Windows lite. It might be popular but it's hardly an improvement.

I don't think equating FOSS with tedious rituals does any good to any one. You can still have Debian installers be the way they are, with the addition of having a button that enabled non-free firmware to remove the need for USB tethering and three reboots. FOSS has a problem with UX design, and this is definitely one symptom.

>You can still have Debian installers be the way they are, with the addition of having a button that enabled non-free firmware

Like I said, each thing is just "fix this one thing by compromising principles." If you do that with all the UX problems you literally end up with ChromeOS. Different distros are on different places along the spectrum between Debian and ChromeOS. Ubuntu is further along for example, so you get applications in containers and other things like that.

Allowing one to make the choice in a pragmatic manner instead of wasting time dancing around to praise the FOSS gods to achieve the same end goal is stupid. Just having an option in the installer to allow non-free firmware and drivers won't move Debian to be any closer to ChromeOS. It will make it easier to use for a lot of people. Stop with this false dichotomy that bad UX implies giving up freedoms. All I'm arguing for is allowing users to make their choices about their own freedoms easier.

>Compromising on freedom doesn't result in a loss of freedom

This is an immediate and direct contradiction.

The freedom is already lost, it just takes users more time to get their machine to have a working network connection.

If you don't jump the hoops you're just left with a machine that only runs windows.

The choice is literally between the non free firmware or your wifi and ethernet cards will not work.

You're correct, there might be a text-mode fallback. It's just that it is effectively useless for me. If I don't have network access, how am I going to install the firmware for the network card?

That's why I believe the most common firmware .deb packages should be cached during installation so that they are on-disk in case they are needed.

In some cases there might be bugs there.

Back in my early Linux days I had an issue where the default Ubuntu/Debian installer would come up with a garbled display and I'd have to use `vga=...` or `nomodeset` (or similar, can't remember) to get a proper console going. Once installed I would install a package and it would "just work".

A way to directly boot into an environment with non-free firmware available could help and the user doesn't lose any more freedom if they're already determined to use non-free firmware post-install anyway.

They even should all be supporting efifb?