Announcement

Collapse
No announcement yet.

Debian Improves Docs To Inform Users Their Systems Might Not Work Without Non-Free Firmware

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by ssokolow View Post

    Thanks. I wasn't aware of ethtool. I don't think I have the pre-release image anymore (I think I reused that flash drive already) but I'll see if it can get anything useful out of the NIC if I boot off a flash drive in legacy boot mode. Failing that, I guess just set up a bunch of different installers off USB sticks to see if I can re-locate one with a friendly firmware version.
    Please do remember that kernel.org firmware files are in a git repo. https://git.kernel.org/pub/scm/linux....git/refs/tags Yes with time frame archive files. So at worst you should be able to get a list of archives that cover the Ubuntu 21.04 pre-release.

    Yes this advantage of the debian standard install without firmware supporting firmware on a vfat drive. At times you can solve a problem like this with like 5 to 10 usb keys of different firmware and a boot per key.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    ethtool -i is a very useful tool in these case to use on connection to get the firmware version in use. Some cases you can use ethtool --get-dump to extract what the network cards current firmware is.

    That could be as simple as incompatible firmware file again ethtool -i on the one that works and check out what firmware versions the Lubuntu has. I do like that debian supports adding firmware in the install process when it suite. So custom USB matched to hardware is a option with debian.
    Thanks. I wasn't aware of ethtool. I don't think I have the pre-release image anymore (I think I reused that flash drive already) but I'll see if it can get anything useful out of the NIC if I boot off a flash drive in legacy boot mode. Failing that, I guess just set up a bunch of different installers off USB sticks to see if I can re-locate one with a friendly firmware version.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    That probably explains why my mother's old work laptop decided to force a decision between only accepting non-hard drive boot of Linux (Legacy boot mode) and giving Linux trouble initializing the onboard network adapter (UEFI boot mode) when they shredded the hard drive before letting her keep it.
    Some thing to remember here windows 11 system requirements to OEM no longer require legacy boot mode to exist. Yes legacy boot mode in a lot of cases will have loaded the firmware into the network adapter if it has it. But booting into EFI mode this is not required to happen. Firmware being placed in network card required to have happened if you happen to have booted from network with EFI but boot from install. Yes you can sometimes get the network card up with a boot order of boot from network EFI then boot from local EFI of course without network connected to get what the maker though the correct firmware version is.

    ethtool -i is a very useful tool in these case to use on connection to get the firmware version in use. Some cases you can use ethtool --get-dump to extract what the network cards current firmware is.

    The reality here the shreding the harddrive may have not be directly linked to the network adapter being trouble. Your trouble could be nothing more than the EFI standard the fact EFI does not mandate any hardware efi has not required in boot to be initialised. So if boot from network is turned off or after you boot from harddrive by UEFI there is no requirement to initialise the network card right. Yes Legacy boot mode says network card has to be initialised but this mode is going away.

    Originally posted by ssokolow View Post
    I'll have to see if I can find a factory restore image that I can start from if I can't figure out why the Ubuntu 21.04 pre-release test ISO seemed to get the LAN up fine in UEFI mode but the Lubuntu 21.04 final didn't.
    That could be as simple as incompatible firmware file again ethtool -i on the one that works and check out what firmware versions the Lubuntu has. I do like that debian supports adding firmware in the install process when it suite. So custom USB matched to hardware is a option with debian.

    The reality here modern path of EFI will see more and more hardware not initialised before the OS is started. This means the OS need firmware files to initialise the hardware and the hardware is not required to have large eeprom or rom.

    The reality here its will get harder and harder to install without the OS having firmware files. Because more and more key hardware will not be initialised or if initialised not be in useful way. Not in a useful way is like EFI GOP where the graphics is initialised but in a very functionally limited way.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    ssokolow we are in a very different world. The EFI specifications say that the EFI in the flash/rom only has to have enough drivers/functionality to get to the first system partition. That right you take the storage device out and put another one in and your EFI reconfiguration menu could be gone and this would be perfectly to specification as well.
    That probably explains why my mother's old work laptop decided to force a decision between only accepting non-hard drive boot of Linux (Legacy boot mode) and giving Linux trouble initializing the onboard network adapter (UEFI boot mode) when they shredded the hard drive before letting her keep it.

    I'll have to see if I can find a factory restore image that I can start from if I can't figure out why the Ubuntu 21.04 pre-release test ISO seemed to get the LAN up fine in UEFI mode but the Lubuntu 21.04 final didn't.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    Old firmware in socketed ROM or PROM of some kind. (I'm reminded of the netboot PROM socket on the 3com Etherlink III cards I still have kicking around for my retrocomputing hobby.)
    Yes but that one goes out of favour due to cost and reliability.

    I am not kidding there. Please note 3com moved their netboot PROM location on there board design 3 times due to the the PROM getting out of socket under particular conditions with the Etherlink III cards with the final recommendation from 3com be superglue the ROM into the socket most people end up using hot glue. I was doing a lot of network boot using 3com Etherlink cards at one point. One of the important things to remove if you had not glued the rom in was the harddrive because the harddrive vibrations was the biggest cause of the Etherlink III PROM chip working loss.

    Yes the modern day latch down on top of the CPU or using proper zero force sockets that have a lock in place to them. These get really expensive very quickly.

    Originally posted by ssokolow View Post
    Any of the later options, but with Flash memory like on the motherboard rather than with RAM so the damn thing boots just fine without the OS needing to bundle a copy of the blob.
    This is under point 2 eeprom from my last . Flash memory is just a form of eeprom.

    Something most people are not aware of is a lot of the EFI flash on your motherboards has less than 100 write cycles before being screwed. https://en.wikipedia.org/wiki/Flash_memory It is noted here but you can use the model numbers of your firmware chips on your motherboard and find this out because it in the specification sheets for the chips. Historically flash eeproms were socketed on motherboards due to their highly limited write endurance and no recovery if you botched a firmware update.

    Also you have missed how motherboard bios/efi flash memory is used. Motherboard bios/elf flash is i2c connected flash that is copied in fact into ram that replaced the old xt style bios chip that was big was to deal with problem of socket rom working self lose. 8 pin socket-ed appears to be small enough that vibrations don't work it lose. Notice something here 8 pin socked you don't have a high transfer rate so you now need on boot of card/motherboard to copy the contents from the flash to ram to get higher IO. So this is really not booting from the flash on the motherboard instead its in fact booting from the copy from the flash on the motherboard that was copied into ram.

    ssokolow there is a cost factor here. Both of the options you have put forwards cost more than ram with small rom boot strap(this is the setup where the OS drivers provide the firmware).

    Horrible right you fix the socket problem of rom/prom of working lose by making the socket smaller this results in you need the run from firmware copied in ram hardware.

    The cheapest and most durable solution from a hardware construction point of view is the OS drivers providing firmware that once provided will be in ram on the device.

    Please note a wide data bus flash/eeprom is a lot more expensive than rom and ram. Yes rom and ram solution(OS driver provided firmware) is cheaper than 100 write cycle eeprom for the same amount of firmware storage with massively more write cycles.

    There was a kind of solution proposed with EFI of using the "EFI (Extensible Firmware Interface) system partition" to store device firmware. There is a reason why Debian is looking at all vfat formatted partitions for missing firmware files. Because it is valid by EFI standard for system required firmware files to be sitting in the EFI partition on storage.

    Yes it also valid for EFI to have like it network boot driver sitting in the "EFI (Extensible Firmware Interface) system partition". EFI gets a lot more fun its not only OS allowed to load firmware files from storage. The EFI in your flash in your motherboard is also valid for it be loading firmware files from storage.

    ssokolow we are in a very different world. The EFI specifications say that the EFI in the flash/rom only has to have enough drivers/functionality to get to the first system partition. That right you take the storage device out and put another one in and your EFI reconfiguration menu could be gone and this would be perfectly to specification as well.


    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    Lets step though history
    1) old firmware in rom. To correct a firmware mistake it was replace the rom that could have soldered into the card that basically result in having to replace the complete card was turned out not to be that cost effective when a company had made like 1 million and goofed it.
    2) Firmware in eeprom. Ok you can replace this firmware but you have a restricted number of writes yes the more expensive the eeprom you buy the more writes it can do. Yes there is a insane eeprom that can only be written 3 times it is very cheap but screw up 3 times and you are back to problem 1.
    3) OS/Driver loaded firmware this get to able to put in ram that turns out to be cheaper than eeprom yet slightly more than rom in build cost. But this can be replace unlimited number of times.
    4) Introduction of signed firmware to prevent people from loading random firmware while still keeping the vendors means to replace it.
    You neglected two subtly different options which are superior:
    1. Old firmware in socketed ROM or PROM of some kind. (I'm reminded of the netboot PROM socket on the 3com Etherlink III cards I still have kicking around for my retrocomputing hobby.)
    2. Any of the later options, but with Flash memory like on the motherboard rather than with RAM so the damn thing boots just fine without the OS needing to bundle a copy of the blob.
    Last edited by ssokolow; 04 August 2021, 08:12 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Duff~ View Post
    Hopefully non-free stuff will never be 'default' for Debian.

    You can still add it VERY EASILY.
    In the end every distribution uses THE SAME FIRMWARE, only thing it varies is it's version/release date.

    I laugh hard when people who don't know the basics about firmware claim their distribution to have 'the best drivers'
    There are fun cases where performance very different due to just the OS driver code being different. Debian is different to use like linux-libre kernels when the kernel had been modified not to load firmware files at all that they have declared non-free worse part is some of their modifications with linux-libre is that where with a debian/stock Linux kernel that the missing firmware file would result in a kernel panic or driver not being loaded the linux-libre kernel proceeds forwards anyhow so at time silently falling back on firmware embedded in cards that is old and defective. Yes a fall back that the that drivers in stock Linux kernel would avoid due to the known problems with the card include firmware. Vendor of card has made sure at times the Linux mainline driver behaves this way because they know the firmware on the card is broken garbage.

    This is my problem people need to make up their mind. Either you are fully block third party closed blobs include the copies on the card or you are going to live with blobs.

    The middle location is not a good location its really simple to forgot why would the vendor bother donating a firmware image to the Linux kernel project if the version on the cards was ok. Reality you can fairly much bet a card with a firmware on it that then has another firmware for it in the Linux kernel firmware project is a case that the firmware on the card is busted the question how and do you want to find out.

    Leave a comment:


  • Duff~
    replied
    Hopefully non-free stuff will never be 'default' for Debian.

    You can still add it VERY EASILY.
    In the end every distribution uses THE SAME FIRMWARE, only thing it varies is it's version/release date.

    I laugh hard when people who don't know the basics about firmware claim their distribution to have 'the best drivers'

    Leave a comment:


  • oiaohm
    replied
    Originally posted by BaumKuchen View Post
    Funny to read all the comments. I'm wondering how long will it take for the Linux userbase to be fine with whole kernel being a binary blob.
    The answer is never. There are practical levels of nightmares. There are many cases where you need to customise the kernel. Please note we have moved away from firmware being roms in every device to where the OS with drivers loads the firmware into cards. This creates it own set of issues.

    Lets step though history
    1) old firmware in rom. To correct a firmware mistake it was replace the rom that could have soldered into the card that basically result in having to replace the complete card was turned out not to be that cost effective when a company had made like 1 million and goofed it.
    2) Firmware in eeprom. Ok you can replace this firmware but you have a restricted number of writes yes the more expensive the eeprom you buy the more writes it can do. Yes there is a insane eeprom that can only be written 3 times it is very cheap but screw up 3 times and you are back to problem 1.
    3) OS/Driver loaded firmware this get to able to put in ram that turns out to be cheaper than eeprom yet slightly more than rom in build cost. But this can be replace unlimited number of times.
    4) Introduction of signed firmware to prevent people from loading random firmware while still keeping the vendors means to replace it.

    Notice something here even for those making devices customisation/means to replace is a critical feature. The question more comes who will be allowed to replace it.

    You think about it there are a lot of Linux end users who will want the ability to rebuild their kernel for performance reasons. Yes you can get different performance in different work loads by build the kernel differently.

    The reality we have moved in the direction of customisation with replaceable firmware but the signed firmware is a step backwards. There is the problem that some areas due to regulations end user modification is not allowed. There are also cases where vendors want to prevent end user firmware modification so they can release the same product under different price points with different levels of performance. (firmware caused performance crippling)

    The reality here over time we are moving like 2 steps in the direction of more open with 1 step at times in the other direction. Its more of a question how long will it take us to get to the point where open firmware in at least source code is normal.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    The GNU idea is an ideological stance that, if it can be replaced, the user should have full freedom to write their own patches.
    I understand the ideological stance. There is the security side as well. Signed firmware was not something that existed when the GNU stance was created. Also the issues of software defined radio did not exist at that point either.

    Items like wifi where the device can be a software defined radio that depending on changes in laws can alter the allowed radio frequencies and to get permission for sale can required not to be user modifiable this is where signed firmware comes in. Yes its nice to have the freedom to patch but I would be just as happen with a reproducible build that I could not patch in some cases.

    The GNU idea with the ideological stance was developed before we had bluetooth and wifi. The GNU idea is flawed on the idea that if some in unchangeable that it has to be safe. Radio items being unchangeable due to government regulation changes are not safe from fines at times(for illegal broadcast) and at others become a security problem if using old firmware.

    The deblobbing idea is basically the wrong one. If you have removed the devices OS loaded firmware falling back on the shipped in device firmware is a mistake. Yes device include firmware will normally be older and more flawed and at times put you inline to get fined.

    The reality if a card is designed that it firmware will be replaced by the OS and vendor will not supply the means for you to make your own the GNU policy should have been that bit of hardware complete rejected. Not attempt to deblob and if it works and does not get a person into legal trouble this is being lucky.

    Does deblobbing give you the freedom to write you own patches no. Does it give you a more insecure/flawed system yes it does. The reality here is hardware with replaceable firmware on the fly has that for reasons and if you are not going to accept the replaceable firmware the best option is either remove or disable that hardware to keep your security risk low and your risks of fines low.

    I do have a power PC system here that has fully open source firmware where I can replace it all. Systems do exist that need more support that have full open source firmware.

    Leave a comment:

Working...
X