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

A warning about 5.12-rc1

lwn.net

Post reply on HN
Print view View original

111–115 of 115 posts

Re: A warning about 5.12-rc1

#111

Post by dathinab »

encryptluks2 wrote: post #43
dathinab wrote: post #18

Earlier quoted context omitted.

While maybe not the most performant my favorite is LVM2 on top of a single large LUKS-encrypted partition (+no boot partition and a single (custom platform key) signed EFI bootable kernel blob containing the initram fs in the EFI partition). This: - Allows a encrypted swap partition (on in lvm2 on top of luks, sure not perfect but I don't really use swap) - Allows hibernation (which I don't really use tbh.) - Fully e…

You still need an unencrypted EFI partition given what you describe, and the signed unified kernel image lives there, which means that you do in fact have a boot partition. My /boot mount is my EFI partition. However, an alternative is having your EFI partition reside on a USB drive that in turn boots into your encrypted partition.

/boot is not the same as the efi system partition (ESP), sure you need to copy the signed kernel blob into the ESP but I still wouldn't recommend mounting ESP as /boot if your linux distro allows it.

The reason for this are many fold including that Linux assumes /boot is managed by it but the ESP isn't managed by Linux and might contain other EFI compatible programs. Another reason is that you want to make sure only the signed blob is in the ESP and nothing else, but depending on your distro and packages all kind of thinks might be put into /boot. Another reason is the dir structure. /boot is flat but ESP isn't meant to be flat e.g. in my case it's /EFI//

E.g. my /boot partition contains "initramfs-linux.img", "intel-ucode.img" and "vmlinuz-linux" but my /esp contains only linux-signed.efi which packs the necessary image files, linux kernel, kernel parameters, boot splash screen etc.

Still what you can do (with reasonable effort) depends a bit on the Linux Distro you run.

Also in many default setups you have a /boot parition and a ESP partition, in your case you just folded both into one. In my case I don't have a boot parition and could as far as I know tweak my system not not have a /boot folder at all as it's not really used, it's just not worth the effort to do so.

Re: A warning about 5.12-rc1

#112

Post by samus »

xodice wrote: post #108
samus wrote: post #62

Earlier quoted context omitted.

`/home` should be separate from the system so you can reinstall it without trouble. Same for `/var` (or subdirectories) if you value the data of particular services. Other than that, the bootloader and EFI must be able to access certain directories like `/boot` and `/boot/efi`. As long as it works for your use cases, everything is alright. Edit: A swap file has a little bit of overhead because of the underlying file…

The Linux kernel doesn't rely on the filesystem for swap files insuring no more overheard than swap partitions. It bypasses the filesystem and is told what blocks it can use, that's why some filesystems do not support swapfiles as there is additional plumbing to be done.

True, I realized when I read TA. After all, the kernel not considering the swap file's offset was precisely the defect in 5.12-rc1.

Re: A warning about 5.12-rc1

#113

Post by encryptluks2 »

dathinab wrote: post #111
encryptluks2 wrote: post #43

Earlier quoted context omitted.

You still need an unencrypted EFI partition given what you describe, and the signed unified kernel image lives there, which means that you do in fact have a boot partition. My /boot mount is my EFI partition. However, an alternative is having your EFI partition reside on a USB drive that in turn boots into your encrypted partition.

/boot is not the same as the efi system partition (ESP), sure you need to copy the signed kernel blob into the ESP but I still wouldn't recommend mounting ESP as /boot if your linux distro allows it. The reason for this are many fold including that Linux assumes /boot is managed by it but the ESP isn't managed by Linux and might contain other EFI compatible programs. Another reason is that you want to make sure only…

My apologies and thanks for the clarification. I suppose I could see how you'd want to create a hook to create the unified image, in which case /boot or whatever could simply be a directory that holds the non-unified images.

I guess the point I was trying to make, is whether you call the partition that holds your unified kernel images /boot or /esp or whatever.. it is still a separate unencrypted partition that most people would associate with a boot partition, whether it is mounted at /boot or /esp.

Re: A warning about 5.12-rc1

#114

Post by asymptosis »

muxator wrote: post #10
asymptosis wrote: post #7

Earlier quoted context omitted.

I recently ended up using swapfiles because I refactored my disk layout and it was just simpler to chuck the swap on an existing nvme partition. I realised an extra benefit: you can make it a sparse file, so it never even uses disk space at all until you actually need it, which could be never.

"refactoring" means changing the (often implicit) structure of code without changing its external behaviour. In this case "reorganized" or "repartitioned" could probably be more apt. If we'd talked about software here (and not disk layout), I'd have considered less leniently the use of "refactoring", and a hint of unclear intentions. Sorry for being so nitpicky, but this is a sore thumb from too many "refactorings" t…

Refactoring has the meaning that we impute to it. God didn't hand down golden tablets in the 60s with the words "thou shalt only use 'refactor' in these prescribed ways".

Instead of being sorry for being nitpicky, maybe just keep your nitpicks to yourself in future.

Re: A warning about 5.12-rc1

#115

Post by asymptosis »

cesarb wrote: post #86
asymptosis wrote: post #7

Earlier quoted context omitted.

I recently ended up using swapfiles because I refactored my disk layout and it was just simpler to chuck the swap on an existing nvme partition. I realised an extra benefit: you can make it a sparse file, so it never even uses disk space at all until you actually need it, which could be never.

> I realised an extra benefit: you can make it a sparse file, so it never even uses disk space at all until you actually need it, which could be never. AFAIK, this cannot work. The swap code does not go through the filesystem, it bypasses the filesystem (it only asks the filesystem code for the swap file extents during the "swapon" call), and it's the filesystem that would be responsible for allocating disk space whe…

I don't think I follow. Check it out:

$ du /swapfile

329696 /swapfile

$ du --apparent-size /swapfile

33554432 /swapfile

Looks to me like it's behaving as expected?

Post reply on HN