From: Goffredo Baroncelli <kreijack@libero.it>
To: helmut@hullen.de
Cc: Helmut Hullen <Hullen@t-online.de>, linux-btrfs@vger.kernel.org
Subject: Re: R: Re: Subvolumes and /proc/self/mountinfo
Date: Wed, 20 Jun 2012 22:22:10 +0200 [thread overview]
Message-ID: <4FE230F2.7060406@libero.it> (raw)
In-Reply-To: <CBFXBeteCXB@helmut.hullen.de>
On 06/20/2012 09:15 PM, Helmut Hullen wrote:
> Hallo, Goffredo,
Hi Helmut,
>
> Du meintest am 20.06.12:
>
> [...]
>
>> 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 ?
>
> Where is the big problem?
> I use separate subdirectories for different kernels, p.e. "/boot/
> 2.6.38.4" or "/boot/3.3.4" or "/boot/3.3.4-big". And these subdirs
> contain (p.e.) ".config", "vmlinuz", "initrd", "System.map".
>
> It's a very clear design. No incredibly long filenames.
Let me to explain my set-up.
My filesystem is in a subvolume; only /boot is in another filesystem.
Every time I upgrade, remove, or change the system I take a snapshot,
and regenerate the grub.cfg in order to take in account the new/old
subvolume (a script generates a menu entry for every subvolume, so I am
theoretically able to launch last kernel on every subvolume).
The point is that every snapshot could have a different set of kernel
module, depending by the upgrade history. Often the latest kernel cannot
boot^w work properly with old snapshot.
I am sure that there would be a lot of solutions, like:
- the script could be more smart, adding a grub menu entry only for
valid kernel/subvolume pairs
- the /boot filesystem could have a subdir for each subvolume
[...]
To me it seems that make sense to put the kernel near the /lib/modules
directories: the kernel is coupled with the modules, so why put them in
different three ? Today the modern bootloader could address the full
filesystem, so I don't see any reason to mandate the kernel to be under
/boot.
May be that there is another more rationale solution to my problem. I am
open to suggestions.
To me it was more traumatic the (re)moval of /sbin,/bin,/lib to
/usr/sbin,/usr/sbin,/usr/lib :-) [*]
Thanks
G.Baroncelli
[*] http://fedoraproject.org/wiki/Features/UsrMove
>
> Viele Gruesse!
> Helmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> .
>
next prev parent reply other threads:[~2012-06-20 20:22 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
2012-06-20 19:15 ` Helmut Hullen
2012-06-20 20:22 ` Goffredo Baroncelli [this message]
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=4FE230F2.7060406@libero.it \
--to=kreijack@libero.it \
--cc=Hullen@t-online.de \
--cc=helmut@hullen.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.