FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-30-2012, 04:54 PM
Ulrich Mueller
 
Default support for mounting /usr w/out hassle

>>>>> On Mon, 30 Apr 2012, Mike Frysinger wrote:

> On Monday 30 April 2012 12:14:19 Ulrich Mueller wrote:
>> >> > i've added a new USE=sep-usr flag to busybox. when enabled, this
>> >> > will install a static busybox at /ginit (and have the other busybox
>> >> > paths symlink to that so there's no overhead). this new applet has a
>> >> > hand written set of commands to automatically mount /dev /proc /sys
>> >> > /usr and seed /dev, and then execute the real init (defaulting to
>> >> > /sbin/init).
>> >>
>> >> Shouldn't it fsck the /usr partition before mounting it? I don't see
>> >> that in ginit.c.
>> >
>> > it mounts it read-only. fsck-ing is left to the normal init scripts.
>>
>> Which doesn't work, at least not for ext{2,3,4}. e2fsck contains
>> special handling for the root fs, but it refuses to repair any other
>> mounted file system (even if mounted read-only).

> i believe there's a bug open on the topic. it's not something i
> think belongs in the pre-/usr code.

Hm, bug 410605. I agree that the most systematic approach would be to
fix fsck.*. It should treat other read-only filesystems the same way
it treats the root fs.

Ulrich
 
Old 04-30-2012, 05:16 PM
Maxim Kammerer
 
Default support for mounting /usr w/out hassle

On Mon, Apr 30, 2012 at 19:03, Mike Frysinger <vapier@gentoo.org> wrote:
> i don't know what you mean by "OS functions", but the whole point is that this
> code *cannot* execute *any* external program by default.

I meant calling mount(2) directly instead of executing Busybox's
"mount" applet, etc. First /dev mount attempt in the code is supposed
to use /etc/fstab, but Busybox's mount options are not always
compatible with util-linux mount, so maybe that's not a good idea
anyway.

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
 
Old 04-30-2012, 05:32 PM
Mike Frysinger
 
Default support for mounting /usr w/out hassle

On Monday 30 April 2012 13:16:52 Maxim Kammerer wrote:
> On Mon, Apr 30, 2012 at 19:03, Mike Frysinger wrote:
> > i don't know what you mean by "OS functions", but the whole point is that
> > this code *cannot* execute *any* external program by default.
>
> I meant calling mount(2) directly instead of executing Busybox's
> "mount" applet, etc.

this was done on purpose to make maintenance much simpler, and to avoid re-
implementing non-trivial things like /etc/fstab parsing

> First /dev mount attempt in the code is supposed
> to use /etc/fstab, but Busybox's mount options are not always
> compatible with util-linux mount, so maybe that's not a good idea
> anyway.

i don't think it's a big deal ... busybox generally aims to be compatible with
the utils it replaces, so if there's bugs/missing stuff, file a bug to get it
added.
-mike
 
Old 04-30-2012, 05:56 PM
Maxim Kammerer
 
Default support for mounting /usr w/out hassle

On Mon, Apr 30, 2012 at 20:32, Mike Frysinger <vapier@gentoo.org> wrote:
> i don't think it's a big deal ... busybox generally aims to be compatible with
> the utils it replaces, so if there's bugs/missing stuff, file a bug to get it
> added.

I did file a couple, and never heard back. Although you are probably
right, since /dev fstab options are unlikely to hit the
incompatibilities (lack of iversion support and -o ro,loop oddity are
those that I noticed).

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
 
Old 04-30-2012, 08:27 PM
William Hubbs
 
Default support for mounting /usr w/out hassle

On Mon, Apr 30, 2012 at 12:00:59PM -0400, Rich Freeman wrote:
> On Mon, Apr 30, 2012 at 4:05 AM, Tony "Chainsaw" Vroon
> <chainsaw@gentoo.org> wrote:
> > Binaries that are essential for system boot, and must be available in
> > single user mode go in /bin and /sbin, with their libraries in /lib.
> > This allows for /usr to be:
> > 1) marked read-only for NFS mounts, which some of us rely on
> > 2) inside of an LVM2 container, allowing for / to be (very) small
> > 3) on a squashfs filesystem, in order to save space
>
> These are all things easily supported with an initramfs. In fact,
> initramfs-based solutions allow the same sorts of things to be done
> with all the other filesystems and not just /usr.

This is correct.

> > Trying to second-guess my motivation, and trying to undo unanimous
> > council votes simply because your opinion is different, really has to
> > stop.
>
> I don't think anybody is trying to undo council votes - people are
> just speculating as to what they voted on. The easiest solution is
> for somebody to say "I'm John Smith, and I am speaking officially for
> the council, and we agree that what was decided upon is X."

Yes, this is correct. I read the log over several times and it isn't
clear what the council actually voted on. Tony, it seems clear that you want to
mandate that gentoo in its default configuration will support separate
/usr without an initramfs. The thing that isn't clear is whether the
rest of the council wants to do that. In reading the log, there was
definite uncertainty about whether the vote was just to continue
supporting /usr as a separate configuration or to mandate how
separate /usr was going to be supported in the default configuration.

> It seems pretty clear that everybody wants to support a separate /usr.
> We even have multiple supported solutions, including an initramfs, a
> use flag on busybox, and I believe somebody posted a script that can
> be run during early boot to mount /usr. It sounds like the only thing
> that isn't supported is "doing nothing" - but with Gentoo if you "do
> nothing" you don't get an installed system that works on any
> configuration.

Rich, you are absolutely right. There is not an argument anywhere about
whether separate /usr is supported.

> > I feel a lot better about vapier's pragmatic approach then I do about
> > udev/systemd upstream's ability and motivation to support current
> > systems. If you had any doubts about whether udev was part of the
> > problem, consider what tarball you will have to extract it from in future.
>
> Well, if others feel differently about the direction udev is taking,
> they can of course just fork it.
>
> I can't say I'm terribly excited about the amount of vertical
> integration going on. I don't run Gnome, and I don't run Unity. I
> really do prefer the unix way.

I'm not excited about parts of the vertical integration either. Newer
versions of gnome are going to start requiring systemd from what I've
heard, and I disagree with that level of integration.

> However, I don't contribute much to those upstream projects, and I
> don't see much value in telling a bunch of people who do that they are
> doing it wrong. I don't like how Google develops Android in the dark,
> or that they bundle 1GB of third-party stuff in their Chromium source
> and distribute a favored binary-only derivative. However, I do like
> that they're giving me all of that stuff essentially for free, and so
> beyond the odd blog post I try not to give them too hard a time.
>
> In the same way I think we need to give the maintainers of these
> projects in Gentoo some slack, or join those projects and help them to
> address your needs. It is a lot easier to tell others what to do than
> to help make it happen, but a volunteer-based project like Gentoo
> needs the latter more than the former.

Agreed.

William
 
Old 05-01-2012, 02:57 AM
"Walter Dnes"
 
Default support for mounting /usr w/out hassle

On Sun, Apr 29, 2012 at 10:00:26PM -0400, Mike Frysinger wrote
> i've added a new USE=sep-usr flag to busybox. when enabled, this
> will install a static busybox at /ginit (and have the other busybox
> paths symlink to that so there's no overhead). this new applet has
> a hand written set of commands to automatically mount /dev /proc
> /sys /usr and seed /dev, and then execute the real init (defaulting
> to /sbin/init).
>
> to use it, update your kernel command line (in grub.conf or whatever) with:
> init=/ginit
> if you want to use a different init from /sbin/init, then just do:
> init=/ginit /some/other/init

Hi. I've done some rabble-rousing (and beta testing) about replacing
udev with mdev, and other people have picked up the cause at
https://wiki.gentoo.org/wiki/Mdev If you can automate 90% of the manual
process, please contribute the details to that wiki page.

The one thing I'm leary of is moving the actual app from /bin/busybox
to /ginit. IANACP (I Am Not A C Programmer), let alone a developer, so
I may be missing something. Is there an overwhelming reason to depart
from the standard location for busybox? Why move the binary to /ginit,
rather than make a symlink from /bin/busybox to /ginit?

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 05-01-2012, 04:10 AM
Mike Frysinger
 
Default support for mounting /usr w/out hassle

On Monday 30 April 2012 22:57:29 Walter Dnes wrote:
> The one thing I'm leary of is moving the actual app from /bin/busybox
> to /ginit. IANACP (I Am Not A C Programmer), let alone a developer, so
> I may be missing something. Is there an overwhelming reason to depart
> from the standard location for busybox? Why move the binary to /ginit,

please read the rest of my e-mail. you snipped the part that explained why.

> rather than make a symlink from /bin/busybox to /ginit?

i think you have this reversed. the current ebuild does symlink /bin/busybox
to /ginit.
-mike
 
Old 05-01-2012, 04:18 AM
Mike Frysinger
 
Default support for mounting /usr w/out hassle

On Monday 30 April 2012 12:03:48 Mike Frysinger wrote:
> On Monday 30 April 2012 06:35:20 Maxim Kammerer wrote:
> > there is still no need to mount /proc and parse
> > /proc/mounts in order to find out whether a directory is a mount
> > point, since Busybox has a "mountpoint" applet (and of course, one
> > could stat the directory and its parent, and compare device IDs, but
> > again...).
>
> thanks, i'll take a look

deployed
-mike
 
Old 05-01-2012, 03:06 PM
William Hubbs
 
Default support for mounting /usr w/out hassle

On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote:
> the fact that the script leaves your system in a hard to recover state is what
> i'm whining about, not that udev requires devtmpfs.

So why did you decide to whine instead of opening a bug?

> /dev/pts isn't created, thus devpts doesn't get mounted, thus you cannot log
> in to your system to fix it. would also be trivial to run the all of three
> commands so people could recover:
> mount -t tmpfs dev /dev
> busybox mdev -s
> mkdir /dev/pts

Yes, I could do this.

> we already have examples of the init scripts modifying /etc/issue to notify
> login entry points that their system needs manual attention to recover.

This part can't happen in the udev init script since / is ro when it is
run. Doing something in udev-postmount is also eroneous because that
assumes that the user is booting to the default runlevel which they may
not be.

The best thing I can think of to do is to just log a message about it in
udev-mount and fail which will cause udev to fail.

William
 
Old 05-01-2012, 03:45 PM
Mike Frysinger
 
Default support for mounting /usr w/out hassle

On Tuesday 01 May 2012 11:06:42 William Hubbs wrote:
> On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote:
> > the fact that the script leaves your system in a hard to recover state is
> > what i'm whining about, not that udev requires devtmpfs.
>
> So why did you decide to whine instead of opening a bug?

based on past behavior, i assumed it was operating as indented

> > we already have examples of the init scripts modifying /etc/issue to
> > notify login entry points that their system needs manual attention to
> > recover.
>
> This part can't happen in the udev init script since / is ro when it is
> run. Doing something in udev-postmount is also eroneous because that
> assumes that the user is booting to the default runlevel which they may
> not be.

in the past, we would `mount -o remount,rw /`, but that was because we needed
to add missing dirs in /.
-mike
 

Thread Tools




All times are GMT. The time now is 09:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org