Hacker News Reader

Comment by calvinmorrison | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

gparted supports this and it's relatively easy to do after shrinking the original partition

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.

Does moving the main partition like that have potential weirdness with some filesystems, or does this gparted approach rewrite the entire partition to a new (offset) location?

I've never ran into anything weird, since it moves the whole partition's address rather than the filesystem within the partition or anything like that.

Yes, that works, but I didn't suggest it because it's riskier and takes way longer.

The whole filesystem has to be moved, instead of just the excess data.

Although this is usually successful, my advice would be: don't have a power outage if you're moving the whole filesystem.

NixOS

I run out of space on /boot semi-regularly on one of my nixos machines; if anything, I would argue that it's worse at handling the situation if you don't regularly delete old generations

It does that on its own, set a reasonable limit on generations and enable auto gc.

I moved my /boot to a USB thumb drive when I ended up in a similar situation.

Perhaps Ubuntu and its derivatives but mine (now Mint) has been removing the fourth kernel for probably five years.

May need to run autoremove (haha) however.

I swear Debian only keeps two versions ie current and the previous. Is keeping four a Ubuntu thing?

Keeps three and when the fourth arrives the oldest gets the heave-ho. Probably configurable.

You can resize your primary partition, move it to a larger offset, then resize /boot. You can also move /boot to the end of your disk. gparted supports this stuff pretty well.

There's no way. You cannot just relocate a Linux partition while it's running like you can macOS, unless gparted somehow supports moving a live system into a tmpfs while the operation is performed.

Windows software that does this has to completely reboot into a dedicated executable that does the work before the system is actually started.

Not while it's running obviously... you boot into gparted live and do it.

And btw, yes you can move partitions while linux is running.

> you boot into gparted live and do it.

This is not the same as simply running gparted from the partition to be resized.

> And btw, yes you can move partitions while linux is running.

Not your root partition, unless you can manage to unmount it without having a fatal system crash.

> This is not the same as simply running gparted from the partition to be resized.

Nobody said you have to run it from that filesystem/partition?

> Not your root partition, unless you can manage to unmount it without having a fatal system crash.

You can resize your root partition using fdisk/partprobe without unmounting it, then move /boot to be after root.

I'm sure there are many other ways to do it as well (pivot_root, etc).

You just need to run off a live distro to do it.

That's my point. You can't just download and run gparted to resize your root partition, you need to boot from somewhere else in order to do that.

You can also set up gparted live to be bootable from GRUB from the same drive.

That's true, it's not uncommon for me to install Linux by flashing the installer to a small partition on the same disk as the actual install destination. Quite useful for dual/triple-boot without actually requiring any USB flash drives.

Is it really that hard to boot from external media on the odd occasion of doing stuff like this?

No, no it's not.

Ubuntu is configured that way. Most other apt-based systems are configured correctly.

You can still create and use an XBOOTLDR partition.

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.

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.

>What would that migration look like?

  cp -r /boot /boot2
  umount /boot
  mv /boot2 /boot

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/

>you just rendered the machine unbootable.

Only because Linux bootloaders suck as they completely fall over when misconfigured. It was implied that you update the configuration of the bootloader to be able to find the new partition that holds /boot. You would also want to format the former boot partition so that you can reuse for other stuff.

>Also, where did boot2 come from?

The cp command creates it

I don't think we're understanding each other. A cp command can populate a filesystem, but it won't create a new partition (or filesystem), which is what I was asking about. You can't just handwave away "make a new boot partition", because part of the problem is that systems in the wild are unlikely to have free disk space sitting around for you to create a new partition in.

> Only because Linux bootloaders suck as they completely fall over when misconfigured.

Have you got a bootloader that doesn't do awful things when it has no configuration? I mean, I guess you could write a bootloader that searched through available filesystems and tried to find something it could boot, but that seems like a great way for unexpected surprises on boot (what, you didn't want to default to booting this 6-month-old backup kernel?)

(And it's not just the bootloader config that you have to deal with - like I said, you have to do something to tell the firmware to even run that bootloader)

>I don't think we're understanding each other.

Then let me explain with English:

Move all of your files from the boot partition into the main partition. Then setup the system to boot from the main partition. Since there is likely gigabytes to terabytes free you will not need to worry about a few 30 MiB files being added to the /boot directory.

That restricts you to using root filesystem that the bootloader can read, which excludes many modern filesystems, btra, f2fs, etc.. Also you would then need a separate efi partition instead of a combined boot and efi setup as is typical these days.

So use a bootloader that can read them then.

You still have an extra partition, and there just plain aren't any bootloaders that can load those filesystems. You'd pretty much be stuck with ext4 as your most modern filesystem option. Really the kernel should have a better system for loading firmware from the root drive after the bool state that the root drive becomes accessible. Not for everything of course, but many of the biggest firmware blobs are fine as late loaders

>You still have an extra partition

Which can be reused to store other files.

>You'd pretty much be stuck with ext4 as your most modern filesystem option.

What do you mean? You can grub boot from a partition that even uses LUKS and ZFS.

Bootloaders support all the common root filesystems now, and even less common like zfs & btrfs. Just leave the bootloader where it is and use a directory in root for the kernel & initramfs.

Most of my systems avoid a boot partition, boot process is BIOS/UEFI -> grub (from EFI partition or MBR block) -> linux (from /boot in root).

However I do got one where UEFI boots the linux kernel directly, /boot is the EFI parition. And there it feels like a bit of a waste to have to expand /boot or insert a bootloader into the boot process because initramfs is getting bloated with files that aren't critical to mounting root.

It does sound sort of elegant to me too, but then I remember that the EFI partition is FAT32 and the desire to use it fades.

i just set mine to 1gb on creation and have never had space issues besides one time when i had to have an obscene number of different kernels bc reasons. not sure why distros default to spending less than 0.1% of disk space on a boot part.

“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).

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.

They worked hard to make boot nicer, at least for Intel GPUs: 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.

You can do better than text too before the driver load, even Grub uses high res and has a background image these days.

Reply on news.ycombinator.com