Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

busybox[sep-usr] support for mounting /usr w/out hassle

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


vapier at gentoo

Apr 29, 2012, 7:00 PM

Post #1 of 29 (1659 views)
Permalink
busybox[sep-usr] support for mounting /usr w/out hassle

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

this code does not require an initramfs, but if you happen to use one anyways,
it should be handled automatically. same goes for any other automatic mount
aspects of the boot process.

this also address the /usr-merge issue since busybox has all the programs it
executes built into itself (it's a multicall binary). this is where the
openrc early-init scripts failed (they still relied on things in /bin etc...).

this also keeps intact the rescue shell scenario. the new applet allows you
to execute other applets. so booting the kernel with a command line like so:
init=/ginit bb
will launch our standard static rescue shell. since it's static, you quite
literally don't need any other path in the system other than /.

finally, since the recent udev-mount init.d script is completely brain dead and
refuses to execute unless devtmpfs is enabled, this code will also
automatically mount+seed /dev (via mdev) if need be.

note: the automatic mounting of /usr applies only to filesystems that (1) the
kernel can natively mount (i.e. no module autoloading) and (2) do not require
external mount helpers (i.e. `mount.ntfs3g` or `mount.cifs`). i don't think
either of these are a big deal. if they are, well, use an initramfs :P.

this should address the council's requirement (sep-/usr w/out initramfs) while
allowing the general craziness to proceed w/out forking projects ourselves.

this is all in busybox-1.20.0 which is now in the tree. if people want to try
it out before i unmask it, that'd be great. seems to work in my qemu setup,
and on the s390/s390x systems which really don't have a choice when it comes
to a sep-/usr (due to limitations in the s390 hardware env).
-mike
Attachments: signature.asc (0.82 KB)


williamh at gentoo

Apr 29, 2012, 9:31 PM

Post #2 of 29 (1647 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Sun, Apr 29, 2012 at 10:00:26PM -0400, Mike Frysinger wrote:
> finally, since the recent udev-mount init.d script is completely brain dead and
> refuses to execute unless devtmpfs is enabled, this code will also
> automatically mount+seed /dev (via mdev) if need be.

The recent udev-mount script goes with >=udev-182 which *requires*
devtmpfs, so I don't see why you think the the udev-mount script is
braindead.

> this should address the council's requirement (sep-/usr w/out initramfs) while
> allowing the general craziness to proceed w/out forking projects ourselves.

Correction here; as far as I know the council did not mandate separate
/usr without initramfs. They just said that separate /usr is a
supported configuration.

William


vapier at gentoo

Apr 29, 2012, 9:48 PM

Post #3 of 29 (1649 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Monday 30 April 2012 00:31:52 William Hubbs wrote:
> On Sun, Apr 29, 2012 at 10:00:26PM -0400, Mike Frysinger wrote:
> > finally, since the recent udev-mount init.d script is completely brain
> > dead and refuses to execute unless devtmpfs is enabled, this code will
> > also automatically mount+seed /dev (via mdev) if need be.
>
> The recent udev-mount script goes with >=udev-182 which *requires*
> devtmpfs, so I don't see why you think the the udev-mount script is
> braindead.

it leaves your system in a hard to recover state because you happened to
forget to check a filesystem option (which ironically isn't under Filesystems
in the kernel). it's piss-poor user facing behavior.
-mike
Attachments: signature.asc (0.82 KB)


lu_zero at gentoo

Apr 29, 2012, 10:20 PM

Post #4 of 29 (1640 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/04/12 21:48, Mike Frysinger wrote:
>> The recent udev-mount script goes with >=udev-182 which *requires*
>> devtmpfs, so I don't see why you think the the udev-mount script is
>> braindead.
>
> it leaves your system in a hard to recover state because you happened to
> forget to check a filesystem option (which ironically isn't under Filesystems
> in the kernel). it's piss-poor user facing behavior.

Many already stated that regarding that version of udev, no reason to
restate it again.

lu

- --

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+eISMACgkQ6Ex4woTpDjSxkQCgpJr9IpurwaVnmKUu6X169LRA
w70AoJ7D+PGd3ALftmNmko0Nqmc7icUN
=bI0z
-----END PGP SIGNATURE-----


williamh at gentoo

Apr 29, 2012, 10:28 PM

Post #5 of 29 (1640 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Mon, Apr 30, 2012 at 12:48:55AM -0400, Mike Frysinger wrote:
> it leaves your system in a hard to recover state because you happened to
> forget to check a filesystem option (which ironically isn't under Filesystems
> in the kernel). it's piss-poor user facing behavior.

Here's the situation.

Udev-182 mandates that a devtmpfs be mounted on /dev.
Udev-mount attempts to do this, and if it can't, it fails.
Since udev-mount fails, udev has to fail.

I would rather have had >=udev-182 refuse to merge if you don't have
config_devtmpfs in your kernel, but I was informed that is not allowed
because of build hosts.

If there is another way to handle this I'm all ears.

Thanks,

William


ulm at gentoo

Apr 29, 2012, 11:34 PM

Post #6 of 29 (1640 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

>>>>> On Sun, 29 Apr 2012, 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).

Shouldn't it fsck the /usr partition before mounting it? I don't see
that in ginit.c.

Ulrich


chainsaw at gentoo

Apr 30, 2012, 1:05 AM

Post #7 of 29 (1642 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On 30/04/12 05:31, William Hubbs wrote:
> Correction here; as far as I know the council did not mandate
> separate /usr without initramfs. They just said that separate /usr
> is a supported configuration.

Separate /usr is a supported configuration, which blocks the armwaving
about "oh just use an initramfs then" as a solution. As apparently
lessons about filesystem layout have been unlearned:
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

My deployment relies on option 2, other sysadmins rely on option 1.
Some of our users are very happy with option 3.

Trying to second-guess my motivation, and trying to undo unanimous
council votes simply because your opinion is different, really has to
stop.

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.

Regards,
--
Tony Vroon
Server systems manager
London Internet Exchange Ltd, Trinity Court, Trinity Street,
Peterborough, PE1 1DA
Registered in England number 3137929
E-Mail: tony [at] linx


mk at dee

Apr 30, 2012, 3:35 AM

Post #8 of 29 (1634 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Mon, Apr 30, 2012 at 05:00, Mike Frysinger <vapier [at] gentoo> wrote:
> this is all in busybox-1.20.0 which is now in the tree.  if people want to try
> it out before i unmask it, that'd be great.

If you insist on calling other applets from C instead of using OS
functions, 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...).

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)


vapier at gentoo

Apr 30, 2012, 8:59 AM

Post #9 of 29 (1632 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Monday 30 April 2012 01:28:58 William Hubbs wrote:
> On Mon, Apr 30, 2012 at 12:48:55AM -0400, Mike Frysinger wrote:
> > it leaves your system in a hard to recover state because you happened to
> > forget to check a filesystem option (which ironically isn't under
> > Filesystems in the kernel). it's piss-poor user facing behavior.
>
> Here's the situation.

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.

/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
we already have examples of the init scripts modifying /etc/issue to notify
login entry points that their system needs manual attention to recover.
-mike
Attachments: signature.asc (0.82 KB)


vapier at gentoo

Apr 30, 2012, 9:00 AM

Post #10 of 29 (1631 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Monday 30 April 2012 02:34:18 Ulrich Mueller wrote:
> >>>>> On Sun, 29 Apr 2012, 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).
>
> 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.
-mike
Attachments: signature.asc (0.82 KB)


rich0 at gentoo

Apr 30, 2012, 9:00 AM

Post #11 of 29 (1629 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Mon, Apr 30, 2012 at 4:05 AM, Tony "Chainsaw" Vroon
<chainsaw [at] gentoo> 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.

> 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."

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.

>
> 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.

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.

Rich


vapier at gentoo

Apr 30, 2012, 9:03 AM

Post #12 of 29 (1627 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Monday 30 April 2012 06:35:20 Maxim Kammerer wrote:
> On Mon, Apr 30, 2012 at 05:00, Mike Frysinger wrote:
> > this is all in busybox-1.20.0 which is now in the tree. if people want
> > to try it out before i unmask it, that'd be great.
>
> If you insist on calling other applets from C instead of using OS
> functions

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. in a /usr-merged and
/usr-sep world, there will literally be no other programs in / to execute.

> 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
-mike
Attachments: signature.asc (0.82 KB)


ulm at gentoo

Apr 30, 2012, 9:14 AM

Post #13 of 29 (1629 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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

> On Monday 30 April 2012 02:34:18 Ulrich Mueller wrote:
>> >>>>> On Sun, 29 Apr 2012, 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).
>>
>> 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).

Ulrich


vapier at gentoo

Apr 30, 2012, 9:40 AM

Post #14 of 29 (1628 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Monday 30 April 2012 12:14:19 Ulrich Mueller wrote:
> >>>>> On Mon, 30 Apr 2012, Mike Frysinger wrote:
> > On Monday 30 April 2012 02:34:18 Ulrich Mueller wrote:
> >> >>>>> On Sun, 29 Apr 2012, 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).
> >>
> >> 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.
-mike
Attachments: signature.asc (0.82 KB)


ulm at gentoo

Apr 30, 2012, 9:54 AM

Post #15 of 29 (1633 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

>>>>> 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


mk at dee

Apr 30, 2012, 10:16 AM

Post #16 of 29 (1631 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Mon, Apr 30, 2012 at 19:03, Mike Frysinger <vapier [at] gentoo> 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)


vapier at gentoo

Apr 30, 2012, 10:32 AM

Post #17 of 29 (1653 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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
Attachments: signature.asc (0.82 KB)


mk at dee

Apr 30, 2012, 10:56 AM

Post #18 of 29 (1628 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Mon, Apr 30, 2012 at 20:32, Mike Frysinger <vapier [at] gentoo> 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)


williamh at gentoo

Apr 30, 2012, 1:27 PM

Post #19 of 29 (1633 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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 [at] gentoo> 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


waltdnes at waltdnes

Apr 30, 2012, 7:57 PM

Post #20 of 29 (1640 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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 [at] waltdnes>


vapier at gentoo

Apr 30, 2012, 9:10 PM

Post #21 of 29 (1629 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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
Attachments: signature.asc (0.82 KB)


vapier at gentoo

Apr 30, 2012, 9:18 PM

Post #22 of 29 (1633 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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
Attachments: signature.asc (0.82 KB)


williamh at gentoo

May 1, 2012, 8:06 AM

Post #23 of 29 (1631 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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? :p

> /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


vapier at gentoo

May 1, 2012, 8:45 AM

Post #24 of 29 (1630 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

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? :p

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
Attachments: signature.asc (0.82 KB)


vapier at gentoo

May 1, 2012, 9:13 AM

Post #25 of 29 (1636 views)
Permalink
Re: busybox[sep-usr] support for mounting /usr w/out hassle [In reply to]

On Tuesday 01 May 2012 11:45:01 Mike Frysinger wrote:
> 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? :p
>
> based on past behavior, i assumed it was operating as indented

blah, swap that 't' & 'd'
-mike
Attachments: signature.asc (0.82 KB)

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.