Mount the boot partition on the pi, for updating #1156
Conversation
If an updated package puts files into /boot, it'll be applied, but if you don't have /boot mounted, you'll end up with the TFTP boot not being in sync with the rest of the filesystem. For me, this recently manifested as USB devices [keyboard, mouse] not working after a kernel update. An couple alternative solutions are to serve TFTP directly out of the boot folder on the NFS-exported root, or use symlinks to point /tftpboot into /nfs/client1 on the server. But, in the spirit of keeping /boot separate for all the classic reasons [and, in my case, serving out of a NAS that made that setup nonobvious], I follow the rest of the instructions as-is, then mount the boot partition back into the filesystem via fstab
|
I need to check this further, as no idea what this is about, so have flagged it up for later work. Busy right now though. |
|
This change proposes adding an NFS share to a Pi boot server which exports the directory which would normally be mounted at /boot. The author ran into an issue where a kernel/firmware update applied on their net-booted Pi failed to update the kernel/firmware because the boot directory wasn't mounted. I'm not entirely sure why /boot wasn't being mounted - this may be the correct configuration for net booted Pi's. The proposed solution of opening up the boot files held on the boot server to read/write access via NFS clearly poses a security hazard, but only to those Pi's which share common a common boot directory on the boot server. |
It's my hypothesis that it's simply an oversight; everything had been working fine for me for months, suddenly one patch caused a failure. I assume the original author did everything here, had everything working for a while, and felt no need to make further modifications.
The configuration I documented for sharing it out exactly aligns with that of the root partition; I don't see any extra vulnerability being added this way. Separately, I generally would expect that most people wanting to net boot their Pi's probably have a pretty good notion of what they're signing up for; it seems reasonable to expect anyone taking this any further to take into account the security ramifications of, for example, sharing out to * [per the document] rather than a subnet. |
I agree that exporting the boot directory via NFS does not pose any more of a security risk than doing the same with the root filesystem. I think that this PR should be considered a bug fix, since the kernel and firmware packages expect to be able to update files within the boot directory, and as the author has discovered, bad things happen when this process fails. |
|
Is there some action that I need to take based on the idea that's a bugfix rather than a feature/etc? |
|
No. I was just meaning that the fact the instructions currently don't tell you to mount /boot is a mistake, so this PR is a correction rather than just an addition to the docs. It's not really a bug fix as such since this is not a piece of code. |
|
Sorry about the delay. Are we happy this is correct and should go to copy edit? |
|
Please do - the current page is wrong to not include NFS mounting the boot partition. |
|
ping also @liamfraser as he did a lot of the initial documentation of this. |
If an updated package puts files into /boot, it'll be applied, but if you don't have /boot mounted, you'll end up with the TFTP boot not being in sync with the rest of the filesystem.
For me, this recently manifested as USB devices [keyboard, mouse] not working after a kernel update.
An couple alternative solutions are to serve TFTP directly out of the boot folder on the NFS-exported root, or use symlinks to point /tftpboot into /nfs/client1 on the server.
But, in the spirit of keeping /boot separate for all the classic reasons [and, in my case, serving out of a NAS that made that setup nonobvious], I follow the rest of the instructions as-is, then mount the boot partition back into the filesystem via fstab