| 1 |
On 05/05/2016 12:22, JingYuan Chen wrote: |
| 2 |
> When grub or new kernel was installed in boot partition, their |
| 3 |
> permission can be determined by umask. |
| 4 |
|
| 5 |
That is incorrect. Permissions are what you see with ls -l or stat. |
| 6 |
umask is nothing more than a convenience for the user to set a default |
| 7 |
|
| 8 |
> |
| 9 |
> Why set boot partition as noauto or ro in fstab ? What's the advantage ? |
| 10 |
|
| 11 |
Because many people do not want /boot mounted at all during use. That |
| 12 |
volume is only ever needed in 2 cases: |
| 13 |
|
| 14 |
1. During boot when a kernel is loaded |
| 15 |
2. Installing a new kernel image and updating a boot loader or config |
| 16 |
|
| 17 |
Many people like to keep /boot unmounted during normal use when updating |
| 18 |
is a deliberate action and the sysadmin must do it. It helps prevent |
| 19 |
accidental mistakes and wayward processes doing stupid things. |
| 20 |
It's a good viewpoint and you'll see why folks do it the next time you |
| 21 |
render your own machine unbootable |
| 22 |
|
| 23 |
|
| 24 |
|
| 25 |
> |
| 26 |
> On May 5, 2016 1:46 AM, "James" <wireless@×××××××××××.com |
| 27 |
> <mailto:wireless@×××××××××××.com>> wrote: |
| 28 |
> |
| 29 |
> Neil Bothwick <neil <at> digimed.co.uk <http://digimed.co.uk>> writes: |
| 30 |
> |
| 31 |
> |
| 32 |
> > > Therefore, I check the configuration of grub2 and fstab. Then I |
| 33 |
> found |
| 34 |
> > > that I forgot to modify mount options in fstab. |
| 35 |
> > > The option of my boot partition was set as noauto. So that I |
| 36 |
> don't use |
| 37 |
> > > the kernel compiled by myself at all. |
| 38 |
> |
| 39 |
> > We've all done that. Now I mount /boot as ro in fstab. That way, if I |
| 40 |
> > forget to remount it before installing a kernel I get an error |
| 41 |
> message |
| 42 |
> > instead of the kernel just disappearing. |
| 43 |
> |
| 44 |
> |
| 45 |
> |
| 46 |
> Perhaps a documentation bug should be filed against the handbook or |
| 47 |
> other |
| 48 |
> gentoo doc explaining some of the security and other approaches |
| 49 |
> and *why* various approaches are used with mounting strategies for |
| 50 |
> /boot/ is |
| 51 |
> warranted? |
| 52 |
> |
| 53 |
> That way, if folks miss it, we can just refer them to the docs and |
| 54 |
> elaborate |
| 55 |
> a bit. Me, I like to keep lots of kernels around for a variety |
| 56 |
> of reasons. Maybe in the GSoC effort (Kernelconfig) is a better place to |
| 57 |
> implement some explanation on the choices of what to do with /boot/ |
| 58 |
> ? [1] |
| 59 |
> |
| 60 |
> |
| 61 |
> Anyway, I'm glad to hear that all is fine now. |
| 62 |
> |
| 63 |
> James |
| 64 |
> |
| 65 |
> |
| 66 |
> [1] |
| 67 |
> https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas/kernelconfig |
| 68 |
> |
| 69 |
> |
| 70 |
> |
Archives