5 ms·

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 i

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/
    - charcircuit 3y ago
      >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
      - yjftsjthsd-h 3y ago
        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)
        charcircuit 3y ago
        >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.
        fyrn_ 3y ago
        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.
- ianlevesque 3y ago
  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.
  - srjek 3y ago
    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.
    - ianlevesque 3y ago
      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.
collegeburner 3y ago
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.

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/
  - charcircuit 3y ago
    >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
    - yjftsjthsd-h 3y ago
      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)
      - charcircuit 3y ago
        >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.
        fyrn_ 3y ago
        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.
ianlevesque 3y ago
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.
- srjek 3y ago
  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.
  - ianlevesque 3y ago
    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.

collegeburner 3y ago

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.