Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux boot partitions and how to set them up

0pointer.net

Post reply on HN
Print view View original

41–50 of 184 posts

Re: Linux boot partitions and how to set them up

#41

Post by yjftsjthsd-h »

jcranmer wrote: post #37
yjftsjthsd-h wrote: post #27

I'm not sold on using automount to reduce the time spent with the filesystems mounted. Unless I've missed something, having a filesystem mounted doesn't make it any more susceptible to damage; being "mounted" just means that the kernel populates its data structures in memory and adds it to the VFS, it doesn't incur any ongoing r/w access. What risks corruption is writing data... which this doesn't stop, because the m…

If things were set up to only mount the filesystems while they're being modified to update the kernel, I can see the value in that. I'm guessing that's not being proposed here, though, because it's too much friction to change the current boot system scripts, and automount doesn't incur the same friction?

Even then, what would it change? The only time those filesystems are being written to is for a new kernel, a new bootloader, or a bootloader config change. In every one of those cases, the filesystem still has to be mounted, so I'm not seeing what the benefit is of keeping things unmounted right up until you're going to write something. (Basically, I can't seem to see any version of this that reduces the actual total writes to the filesystem.)

Re: Linux boot partitions and how to set them up

#42

Post by Volundr »

adrian_b wrote: post #17
candiddevmike wrote: post #15

Earlier quoted context omitted.

You're talking about saving _at most_ 200MBish. That's a lot of work to maintain for little gain...

There is less work, not more work.

This sounds like work to me

> For booting the computers, I either boot them from Ethernet or I boot them from a small USB memory that uses a FAT file system for storing the OS kernel, either in the format required by UEFI booting, or, when booting Linux in legacy BIOS mode, together with syslinux, which loads the kernel.

Creating boot USB drives (which I think need partitions don't they?) or setting up a PXE boot server would take me a lot more effort than an extra minute with gdisk to create partitions before formatting the disk.

Re: Linux boot partitions and how to set them up

#43

Post by SoftTalker »

adrian_b wrote: post #13

There are many years since I no longer create partitions on any SSD or HDD, because I believe that this serves no useful purpose and it just wastes a part of the SSD/HDD. I format directly the raw unpartitioned SSD/HDD with a file system that uses 100% of the capacity, with no wasted sectors. At least on Linux and FreeBSD, there is no need of partitions. For booting the computers, I either boot them from Ethernet or…

I have taken this approach for secondary drives where I want to use the entire drive as a big filesystem for data.

For the system disk I have always partitioned it though. I generally create at least /, /var, /home, and /usr. That way it's less likely that a runaway process can fill up the entire disk, at worst it might fill up /home or /var.

And unless I'm really space-constrained, I'll leave some unpartitioned space as well, for later flexibility.

Re: Linux boot partitions and how to set them up

#44

Post by Volundr »

yjftsjthsd-h wrote: post #31
2OEH8eoCRo0 wrote: post #9

Earlier quoted context omitted.

ZFS is the "crypto solves this" of filesystems. Adding out of tree ZFS to the boot mix sounds hella complicated.

Interestingly, GRUB actually supports ZFS; it has the dubious distinction of being the only extant implementation of ZFS that's GPL licensed, but... probably because of that... it's separate from the main OpenZFS implementation is extremely feature-poor. This results in fun things like Ubuntu's root-on-ZFS layout creating 2 pools; a boot pool (bpool) that GRUB can read, and a root pool (rpool) with the OS. It's not t…

Interesting. I've never really wanted on boot on ZFS, and I definitely don't see the point if I'd need a dedicated pool for it.

Re: Linux boot partitions and how to set them up

#45

Post by AshamedCaptain »

yjftsjthsd-h wrote: post #27

I'm not sold on using automount to reduce the time spent with the filesystems mounted. Unless I've missed something, having a filesystem mounted doesn't make it any more susceptible to damage; being "mounted" just means that the kernel populates its data structures in memory and adds it to the VFS, it doesn't incur any ongoing r/w access. What risks corruption is writing data... which this doesn't stop, because the m…

In fact, I was bitten once by corruption because the _unmount_ operation was interrupted mid-write. Not that surprising considering it's a much less tested scenario on fs code.

Re: Linux boot partitions and how to set them up

#46

Post by yjftsjthsd-h »

Volundr wrote: post #44
yjftsjthsd-h wrote: post #31

Earlier quoted context omitted.

Interestingly, GRUB actually supports ZFS; it has the dubious distinction of being the only extant implementation of ZFS that's GPL licensed, but... probably because of that... it's separate from the main OpenZFS implementation is extremely feature-poor. This results in fun things like Ubuntu's root-on-ZFS layout creating 2 pools; a boot pool (bpool) that GRUB can read, and a root pool (rpool) with the OS. It's not t…

Interesting. I've never really wanted on boot on ZFS, and I definitely don't see the point if I'd need a dedicated pool for it.

It could be really cool; it would let you snapshot your boot filesystem and roll back to a previous configuration.

...I say, as someone who does in fact leave my boot filesystems on VFAT:)

Re: Linux boot partitions and how to set them up

#47

Post by yjftsjthsd-h »

AshamedCaptain wrote: post #45
yjftsjthsd-h wrote: post #27

I'm not sold on using automount to reduce the time spent with the filesystems mounted. Unless I've missed something, having a filesystem mounted doesn't make it any more susceptible to damage; being "mounted" just means that the kernel populates its data structures in memory and adds it to the VFS, it doesn't incur any ongoing r/w access. What risks corruption is writing data... which this doesn't stop, because the m…

In fact, I was bitten once by corruption because the _unmount_ operation was interrupted mid-write. Not that surprising considering it's a much less tested scenario on fs code.

Okay, that hadn't occurred to me. I did wonder if mounting was a problem, if VFAT has "last mounted time" or other metadata that gets written per-mount.

Re: Linux boot partitions and how to set them up

#48

Post by xearl »

Kwpolska wrote: post #39

I don’t really see the point in using the ESP for anything serious. Many of the arguments are also super weak, like the one about /boot/efi/ being nested (in how many cases is this actually important to anyone and anything?). The ESP size issue successfully prevents the real world adoption of this, since Linux kernels are 50-100 MB each, which means you could maybe fit one on your average ESP, and good luck convincin…

Your "different approach" sounds almost exactly like the approach proposed in the fine article for the "ESP too small" case (a case which you assume as a given).

Re: Linux boot partitions and how to set them up

#49

Post by GauntletWizard »

candiddevmike wrote: post #6

How to make one boot partition to rule them all (debian, secure boot disabled for UEFI due to weird bug with how files are laid out with removable flag): parted -s "${diskpath}" mklabel gpt parted -s "${diskpath}" mkpart primary 1MiB 2MiB parted -s "${diskpath}" set 1 bios_grub on parted -s "${diskpath}" mkpart primary 2Mib 202MiB parted -s "${diskpath}" set 2 esp on sleep 1 mkfs.fat -F 32 -n "boot" "${diskpath}2" mo…

The symlinking .bat files for initrd ended up completely bricking my Ubuntu installation a few months ago, so... take heed? I am unimpressed by the quality and robustness of that whole stuff, though, but ended up writing essentially this article into my notes for the next Arch installation I make, where I think there's a fair chance that EFI will live in /efi but be symlinked in /boot.

There's a whole other problem, though, of my wanting to use secure boot. Ubuntu was the easy out for that. At the moment, it's just disabled on my machines, which is far from optimal.

Re: Linux boot partitions and how to set them up

#50

Post by vetinari »

AshamedCaptain wrote: post #4

Even Windows has a separate, NTFS boot partition these days. Fail to see the point of this, and since the main take basically is "put your /boot inside the FAT ESP, or if not possible, make /boot a FAT partition", it's also bound to create a lot of disagreement.

Windows does not have a separate NTFS boot partition. MSR is not it (check the size and content). Windows Boot Manager and BCD are stored on the EFI partition. Windows Boot Manager itself does understand NTFS: it loads winload.efi, ntoskrnl.exe and core drivers from the system root itself. This way, Windows is not going to have the common linux problem ("update failed, /boot too small").

Two partitions are needed only for Bitlocker; one has to be unencrypted.

Similarly with Apple: they use APFS subvolume for boot files. They do not bother with multiple partitions and static allocations, guessing, what size is going to be OK. They can use as much or as little space as they need.

--

With Linux, I've been using btrfs subvolume for /boot. It works with "normal" distributions, grub complains (it cannot write there; I find that OK). The dynamic nature of the space used is great. It doesn't work with ostree-based distributions (Fedora Silverblue & its ilk); ostree cannot generate proper BLS and grub.cfg for subvolumes.

Post reply on HN