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

21–30 of 184 posts

Re: Linux boot partitions and how to set them up

#21

Post by yjftsjthsd-h »

CameronNemo wrote: post #10

As growing the size of an existing ESP is problematic (for example, because there’s no space available immediately after the ESP, or because some low-quality firmware reacts badly to the ESP changing size) Code quality of the firmware in typical systems is known to not always be great. When relying on the file system driver included in the firmware it’s hence a good idea to limit use to operations that have a better…

Because that's everyone? What computer are you using that has really high quality firmware?

Re: Linux boot partitions and how to set them up

#22

Post by deathanatos »

p_l wrote: post #18
ChuckNorris89 wrote: post #12

Earlier quoted context omitted.

Does it? On my Windows 11 install, the EFI partition is still FAT32. There are no other partitions than the C and the recovery partition. Am I missing something?

Windows has been setting up Reserved partitions with boot code for some time now - even (or especially) on systems without EFI

The OP is about a separate boot partition, which is normally where the kernel and associated data (on Linux, an initramfs, obviously Windows would differ a bit).

The "Reserved" partition on Windows machines isn't really a boot partition, for any meaningful definition of it. It's just … reserved, and MS being MS. On my machine, it's empty (unformatted, all 0s). It is lightly documented here: https://learn.microsoft.com/en-us/windows-hardware/manufactu...

(I'd expect your typical GPT Windows install to have about four partitions: the ESP, the empty "reserved" partition, a recovery partition, and the main NTFS partition.)

Re: Linux boot partitions and how to set them up

#23

Post by yjftsjthsd-h »

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…

> grub-mkconfig > "/boot/grub/grub.cfg"

Shell redirection is fine, but you could just use `grub-mkconfig -o` to set the output file.

Re: Linux boot partitions and how to set them up

#24

Post by freedinosaur »

CameronNemo wrote: post #7

"The Boot partition will also have to carry an emtpy "efi" directory that can be used as the inner mount point, and serves no other purpose." You could substitute Boot for Root in this sentence and flip it around on Poettering.

The root partition already contains a set of empty directories, and Lennart has been working on reducing those where possible (see usr-merge).

Re: Linux boot partitions and how to set them up

#26

Post by cesarb »

> For example, it’s probably worth mentioning that some distributions decided to put kernels onto the root file system of the OS itself. For this setup to work the boot loader itself [sic!] must implement a non-trivial part of the storage stack.

IIRC, older bootloaders like LILO used a simpler approach: after each kernel update, a userspace program asked the kernel for the list of sectors which contained the kernel file, and wrote the list to a map file; the bootloader then read that map file (its sector hardcoded into the bootloader by the same userspace program), and loaded the kernel by reading the sectors directly. Neither the bootloader nor its userspace installer needed to know anything about filesystems or other parts of the storage stack, and it worked perfectly with RAID 1.

Re: Linux boot partitions and how to set them up

#27

Post by yjftsjthsd-h »

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 moment anything tries to access it the OS will helpfully mount the filesystem again.

Re: Linux boot partitions and how to set them up

#28

Post by yjftsjthsd-h »

cesarb wrote: post #26

> For example, it’s probably worth mentioning that some distributions decided to put kernels onto the root file system of the OS itself. For this setup to work the boot loader itself [sic!] must implement a non-trivial part of the storage stack. IIRC, older bootloaders like LILO used a simpler approach: after each kernel update, a userspace program asked the kernel for the list of sectors which contained the kernel f…

That only works with simple filesystems, though; it'll fall apart if your root filesystem uses, say, compression, encryption, or possibly any RAID except mirroring (depending on the details and what the bootloader can handle).

Re: Linux boot partitions and how to set them up

#29

Post by cesarb »

deathanatos wrote: post #22
p_l wrote: post #18

Earlier quoted context omitted.

Windows has been setting up Reserved partitions with boot code for some time now - even (or especially) on systems without EFI

The OP is about a separate boot partition, which is normally where the kernel and associated data (on Linux, an initramfs, obviously Windows would differ a bit). The "Reserved" partition on Windows machines isn't really a boot partition, for any meaningful definition of it. It's just … reserved, and MS being MS. On my machine, it's empty (unformatted, all 0s). It is lightly documented here: https://learn.microsoft.co…

> The "Reserved" partition on Windows machines isn't really a boot partition, for any meaningful definition of it. It's just … reserved, and MS being MS. On my machine, it's empty (unformatted, all 0s). It is lightly documented here: https://learn.microsoft.com/en-us/windows-hardware/manufactu...

IIRC, that "reserved" partition is to allow converting the data partition which follows it to a "dynamic disk" (which AFAIK, is Microsoft's equivalent to a Linux LVM PV). That conversion needs to grow the partition backwards to prepend some headers, and that extra space comes from shrinking the reserved partition just before it.

Re: Linux boot partitions and how to set them up

#30

Post by p_l »

deathanatos wrote: post #22
p_l wrote: post #18

Earlier quoted context omitted.

Windows has been setting up Reserved partitions with boot code for some time now - even (or especially) on systems without EFI

The OP is about a separate boot partition, which is normally where the kernel and associated data (on Linux, an initramfs, obviously Windows would differ a bit). The "Reserved" partition on Windows machines isn't really a boot partition, for any meaningful definition of it. It's just … reserved, and MS being MS. On my machine, it's empty (unformatted, all 0s). It is lightly documented here: https://learn.microsoft.co…

On various BIOS-based systems, the reserved partition would contain files necessary for booting windows from its system volume, bridging the gap between what could be accessed by simplistic MBR boot code, the NTFS boot code block, and the NTFS-understanding, ARC emulating (for NT5) or EFI-emulating (NT6) boot system that would load target system.

Details on whether reserved partition would be created and what would be on it depend on hardware you're installing on, and if separate boot partition is necessary windows installer would inform you about need to create an extra partition.

Post reply on HN