Live data from Hacker News

Linux boot partitions and how to set them up

0pointer.net

61–70 of 184 posts

Re: Linux boot partitions and how to set them up

#61
post #32

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…

That is risky, since without a partition table, some operating systems and disk management tools will treat the disk as empty, making it easy to accidentally overwrite data. > 100% of the capacity, with no wasted sectors. You will never have that. SSDs have a large amount of reserved space, and even on HDDs, there are some reserved tracks for defect management.

By "some operating systems and disk management tools" you mean MS Windows and Windows tools.

Obviously, I do not use unpartitioned SSDs/HDDs with Windows. On the other hand, With Linux and *BSD systems they work perfectly fine, regardless whether they are internal or removable.

For interchange with Windows, I use only USB drives or SSDs that are partitioned and formatted as exFAT. On the unpartitioned SSDs/HDDs I use file systems like XFS, UFS or ZFS, which could not be used with Windows anyway.

Any SSD/HDD that uses non-Windows file systems should never be inserted in a Windows computer, even when it is partitioned. When a SSD/HDD is partitioned, it may be hoped that Windows will not alter a partition marked as type 0x83 (Linux), but Windows might still destroy the partition table and the boot sector of a FAT partition. It happens frequently that a bootable Linux USB drive is damaged when it is inserted in a Windows computer, so the boot loader must be reinstalled. So partitioning an USB drive or SSD does not protect them from Windows.

>> 100% of the capacity, with no wasted sectors. > You will never have that.

I thought that it is obvious that I have meant 100% of the capacity available for users, because there is no way to access the extra storage used by the drive controller and also no reason to want to access that, because it has a different purpose than storing user data, so your "correction" is pointless.

Re: Linux boot partitions and how to set them up

#62
post #40

Earlier quoted context omitted.

> This makes two partitions, one for GRUB to inject legacy BIOS boot code into and one for the ESP. Why do you still need the legacy BIOS boot logic?

For BIOS boot, the BIOS looks at the first couple of blocks on a hard drive for the boot code. This is the first GPT partition that gets created, and the future grub-install code injects the BIOS bootloader there. Thus, to support BIOS and UEFI, you need the BIOS bootloader at the beginning of the drive.

Yes, but why would you want the BIOS boot assuming you have a motherboard made in last 10 years and it has a UEFI implementation which isn't completely broken.

I might understand doing that just in case when preparing a bootable flash drive. Why complicate things for permanent installations where you know your current hardware and your next system after 5 years is unlikely to much worse than current one?

Re: Linux boot partitions and how to set them up

#63
post #62

Earlier quoted context omitted.

For BIOS boot, the BIOS looks at the first couple of blocks on a hard drive for the boot code. This is the first GPT partition that gets created, and the future grub-install code injects the BIOS bootloader there. Thus, to support BIOS and UEFI, you need the BIOS bootloader at the beginning of the drive.

Yes, but why would you want the BIOS boot assuming you have a motherboard made in last 10 years and it has a UEFI implementation which isn't completely broken. I might understand doing that just in case when preparing a bootable flash drive. Why complicate things for permanent installations where you know your current hardware and your next system after 5 years is unlikely to much worse than current one?

You wouldn't, this is more for cloud/virtual images where some providers support UEFI but most still only support BIOS.

Re: Linux boot partitions and how to set them up

#64
post #40

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…

> This makes two partitions, one for GRUB to inject legacy BIOS boot code into and one for the ESP. Why do you still need the legacy BIOS boot logic?

To provide more to the "why", although end-user devices have moved away from BIOS-only boot, there are large number of systems that have no alternative to BIOS, and the hardware cannot be upgraded, only the firmware and software.

Most of the systems I have ran into were in SCADA[0], PMS[1], and BMS[2].

[0]:https://en.wikipedia.org/wiki/SCADA

[1]:https://en.wikipedia.org/wiki/Power_management_system

[2]:https://en.wikipedia.org/wiki/Building_management_system

Re: Linux boot partitions and how to set them up

#65
This is excellent!

Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition)

The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable.

It's been somewhat frustrating for distributions to install GRUB, hijacking the previous prioritized boot PE, and have entries for other installed Linux distributions missing.

Re: Linux boot partitions and how to set them up

#66
post #36

AFAIK Debian still doesnt have any integration available for handling thee integration of systemd-boot & kernel packages: there's nothing to maintain the loader/entries files that systemd-boot expects! It's really a shame because systemd-boot is 10x simpler and 100x more plesant to work with than grub & it's multiple overlapping but different obtuse config handling shell scripts. Bootctl is excellent & understandable…

OTOH it's nice to have access to the boot loader via serial console. The system developers judgement is that it's up to the firmware to provide serial console access if needed. Well I'll just get my chequebook out then...

Also it would be nice to be able to interact with the boot loader on a modern laptop display without having to get out a magnifying glass. Another problem that is deigned to be the fault of the firmware.

One of the great things about open source operating systems is that people step up to provide these sorts of improvements and I think it's a shame that systemd-boot will cause regression here.

Re: Linux boot partitions and how to set them up

#67

Earlier quoted context omitted.

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

I guess that is fair. Most of my non-Android computers use U-Boot. One is some UEFI implementation. I don't know how it copes with growing the ESP. I don't see why it would freak, though.

Many of us have been burned by making the assumption that UEFI implementations behave sensibly. Most of the pain points have been ironed out by now, yes, but the lesson I've taken away is: don't assume.

Re: Linux boot partitions and how to set them up

#68

This is excellent! Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition) The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. It's been somewhat frustr…

> through systemd, and ensure all boot images are autodiscoverable and automatically bootable.

See systemd-boot and BootLoaderSpec, both mentioned in OP.

https://www.freedesktop.org/wiki/Software/systemd/systemd-bo... https://systemd.io/BOOT_LOADER_SPECIFICATION/

Re: Linux boot partitions and how to set them up

#69
So is this the first work Microsoft set Pottering to do? Kinda supports my personal conspiracy theory that Microsoft's aiming to make secure boot only possible with systemd-boot.

Or Microsoft is trying to make dual booting easier without using the simplest solution of making a larger ESP the default.

Post reply on HN