5 ms·

There are a number of disadvantages too, though. The firmware provides no stable ABI, and a lot of the calls it provides are not documented. The firmware files

There are a number of disadvantages too, though. The firmware provides no stable ABI, and a lot of the calls it provides are not documented. The firmware files themselves are large, in the range of 20-30MB, and two of them are required for any given device. That significantly bloats a system's /boot directory and initramfs image (which must provide every version of the firmware that the kernel might need), and forces the Nouveau developers to be strict and careful about picking up firmware updates. Is 20-30Mb of /boot space really a concern for someone running an nvidia graphics card?

mike_hock 3y ago
I don't get why this has to be in the initrd. Just run in legacy text mode until the root partition has been mounted and then load the firmware from there.
- doubled112 3y ago
  They worked hard to make boot nicer, at least for Intel GPUs: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot https://fedoraproject.org/wiki/Changes/FlickerFreeBoot Also, the earlier I get the GPU up, the better. My monitor won't display some resolutions used in BIOS screens and text modes.
- fulafel 3y ago
  You can do better than text too before the driver load, even Grub uses high res and has a background image these days.
ogurechny 3y ago
“Every version” probably means 20-30 MB for each GPU series that can potentially appear in the PCI-e slot after power on (if still supported by the driver). Or the user has to juggle the firmware before hardware change (or the driver has to implement the juggling instead).
gavinsyancey 3y ago
My /boot partition is 256MB because that was the default in the Ubuntu installer way back when I installed it. I can't easily resize it because my primary partition starts right after it. I am constantly running out of space in /boot because Apt doesn't fully clean up after old kernel versions automatically. An extra 20-30MB (per kernel version, at least) is absolutely a huge deal.
- jml78 3y ago
  I am in the same boat as you. I still haven’t found a solution for keeping it clean in an automated and safe way.
  - orra 3y ago
    However, you could consider shrinking your main partition using gparted live. Then put a new /boot at the end. Of course, you'd lose the original /boot partition space, however.
    - aidenn0 3y ago
      I don't know if any tools support moving partitions, but you can use "dd" to move a partition backwards if you are very careful. I'm not recommending this on any system that you don't have good backups for, but it is possible.
      - simcop2387 3y ago
        gparted supports this and it's relatively easy to do after shrinking the original partition
    - simcop2387 3y ago
      Why not just use gparted to move the partition instead? Just three steps 1. Shrink the main partition 2. Move the main partition to the right, leaving free space between it and /boot 3. Resize /boot to fit into the newly freed space That's what I did at one point to make my /boot 2gb or so, haven't had issues since.
ianlevesque 3y ago
These tiny boot partitions are such a self-inflicted wound in linux distributions. I do agree there's a lot of people in the same boat, but maybe the solution is to offer some sort of migration out of that state.
- yjftsjthsd-h 3y ago
  What would that migration look like? The traditional route, which is being discussed in this thread, involves moving your entire root partition around so you have enough room to grow the boot partition. But that's not exactly a process I would want to run on any system without current backups, to put it lightly. The other thought that occurred while I was reading here was that you could create a new boot partition at the end of the disk, which might work if you synchronize everything perfectly and can shrink the rest of the partitions to give you enough room, but we're still talking about fairly delicate tinkering with the boot process and I'm just not seeing a way to do that that's not dangerous at any significant scale.
  - charcircuit 3y ago
    >What would that migration look like? cp -r /boot /boot2 umount /boot mv /boot2 /boot
    - yjftsjthsd-h 3y ago
      I'm pretty sure unless you just forgot to write the part where you fuss with the partition flags and possibly EFI variables, you just rendered the machine unbootable. Also, where did boot2 come from? Because a lot of these machines don't have free space sitting around, and some of them are still using MBR partitions and don't even have the ability to create a new partition. (You might well object that nobody even makes machines with bios boot anymore and surely everybody must be using GPT, at which point I get to gesture at the astonishing number of cloud virtual machines that are somehow not even capable of UEFI booting) Edit: s/on bootable/unbootable/
      - 3y ago

mike_hock 3y ago

I don't get why this has to be in the initrd. Just run in legacy text mode until the root partition has been mounted and then load the firmware from there.

doubled112 3y ago
They worked hard to make boot nicer, at least for Intel GPUs: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot https://fedoraproject.org/wiki/Changes/FlickerFreeBoot Also, the earlier I get the GPU up, the better. My monitor won't display some resolutions used in BIOS screens and text modes.
fulafel 3y ago
You can do better than text too before the driver load, even Grub uses high res and has a background image these days.

ogurechny 3y ago

“Every version” probably means 20-30 MB for each GPU series that can potentially appear in the PCI-e slot after power on (if still supported by the driver). Or the user has to juggle the firmware before hardware change (or the driver has to implement the juggling instead).

gavinsyancey 3y ago

My /boot partition is 256MB because that was the default in the Ubuntu installer way back when I installed it. I can't easily resize it because my primary partition starts right after it. I am constantly running out of space in /boot because Apt doesn't fully clean up after old kernel versions automatically. An extra 20-30MB (per kernel version, at least) is absolutely a huge deal.

jml78 3y ago
I am in the same boat as you. I still haven’t found a solution for keeping it clean in an automated and safe way.
- orra 3y ago
  However, you could consider shrinking your main partition using gparted live. Then put a new /boot at the end. Of course, you'd lose the original /boot partition space, however.
  - aidenn0 3y ago
    I don't know if any tools support moving partitions, but you can use "dd" to move a partition backwards if you are very careful. I'm not recommending this on any system that you don't have good backups for, but it is possible.
    - simcop2387 3y ago
      gparted supports this and it's relatively easy to do after shrinking the original partition
  - simcop2387 3y ago
    Why not just use gparted to move the partition instead? Just three steps 1. Shrink the main partition 2. Move the main partition to the right, leaving free space between it and /boot 3. Resize /boot to fit into the newly freed space That's what I did at one point to make my /boot 2gb or so, haven't had issues since.

ianlevesque 3y ago

These tiny boot partitions are such a self-inflicted wound in linux distributions. I do agree there's a lot of people in the same boat, but maybe the solution is to offer some sort of migration out of that state.

yjftsjthsd-h 3y ago
What would that migration look like? The traditional route, which is being discussed in this thread, involves moving your entire root partition around so you have enough room to grow the boot partition. But that's not exactly a process I would want to run on any system without current backups, to put it lightly. The other thought that occurred while I was reading here was that you could create a new boot partition at the end of the disk, which might work if you synchronize everything perfectly and can shrink the rest of the partitions to give you enough room, but we're still talking about fairly delicate tinkering with the boot process and I'm just not seeing a way to do that that's not dangerous at any significant scale.
- charcircuit 3y ago
  >What would that migration look like? cp -r /boot /boot2 umount /boot mv /boot2 /boot
  - yjftsjthsd-h 3y ago
    I'm pretty sure unless you just forgot to write the part where you fuss with the partition flags and possibly EFI variables, you just rendered the machine unbootable. Also, where did boot2 come from? Because a lot of these machines don't have free space sitting around, and some of them are still using MBR partitions and don't even have the ability to create a new partition. (You might well object that nobody even makes machines with bios boot anymore and surely everybody must be using GPT, at which point I get to gesture at the astonishing number of cloud virtual machines that are somehow not even capable of UEFI booting) Edit: s/on bootable/unbootable/
    - 3y ago