From: Goffredo Baroncelli <kreijack@libero.it>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: kreijack@inwind.it, cwillu <cwillu@cwillu.com>,
helmut@hullen.de, linux-btrfs@vger.kernel.org
Subject: Re: R: Re: Subvolumes and /proc/self/mountinfo
Date: Wed, 20 Jun 2012 20:06:44 +0200 [thread overview]
Message-ID: <4FE21134.9090501@libero.it> (raw)
In-Reply-To: <4FE20B3D.5060704@zytor.com>
HI,
On 06/20/2012 07:41 PM, H. Peter Anvin wrote:
> On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote:
>>
>> At the first I tough that having the /boot separate could be a good
>> thing. Unfortunately /boot contains both the bootloader code and the
>> kernel image. The kernel image should be in sync with the contents of
>> /lib/modules/....
>>
>> This is the tricky point. If I handle /boot inside the filesystem
>> submodule a de-sync between the bootloader code and the boot sector
>> could happens. In I handle /boot as separate subvolume/filesystem a
>> de-sync between the kernel image and the modules could happens.
>>
>> Anyway, from a bootloader POV I think that /boot should be handle
>> separately (or as filesystem or as subvolume identified by specific ID).
>> The best could be move the kernel in the same subvolume as /lib/modules,
>> so a switch of the subvolume as root filesystem would be coherent.
>>
>
> You're not really answering the question. "The best could be move the
> kernel in the same subvolume as /lib/modules" isn't really going to
> happen... the whole *point* of /boot is that /boot contains everything
> needed to get to the point of kernel initialization.
??
Am not saying that we *should* move the kernel away from /boot. I am
only saying that having the kernel near /lib/modules *has* some advantages.
Few year ago there are some gains to have a separate /boot (ah, the time
when the bios were unable to address the bigger disk), where there are
the minimum things to bootstrap the system.
Now we have the possibility to move the kernel near the modules, and
this could lead some interesting possibility: think about different
linux installations, with an own kernel version and an own modules
version; what are the reasons to put together under /boot different
kernel which potential conflicting names ? de facto standard ?
historical reasons ? Nothing wrong here; but also the idea to moving the
kernel under /lib/modules is not so wrong.
> So, sorry, you're out to sea here...
True, the sea is far away from my house :-)
>
> -hpa
>
> .
>
next prev parent reply other threads:[~2012-06-20 18:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 12:02 R: Re: Subvolumes and /proc/self/mountinfo Goffredo Baroncelli <kreijack@libero.it>
2012-06-20 15:37 ` H. Peter Anvin
2012-06-20 16:34 ` Goffredo Baroncelli
2012-06-20 17:41 ` H. Peter Anvin
2012-06-20 18:06 ` Goffredo Baroncelli [this message]
2012-06-20 19:15 ` Helmut Hullen
2012-06-20 20:22 ` Goffredo Baroncelli
2012-06-20 21:49 ` H. Peter Anvin
2012-06-21 5:47 ` Goffredo Baroncelli
2012-06-21 11:46 ` Martin Steigerwald
2012-06-21 17:05 ` Goffredo Baroncelli
2012-06-21 13:38 ` H. Peter Anvin
2012-06-21 17:05 ` Goffredo Baroncelli
2012-06-21 17:11 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2012-06-20 12:10 Goffredo Baroncelli <kreijack@libero.it>
2012-06-20 11:51 Goffredo Baroncelli <kreijack@libero.it>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE21134.9090501@libero.it \
--to=kreijack@libero.it \
--cc=cwillu@cwillu.com \
--cc=helmut@hullen.de \
--cc=hpa@zytor.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).