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

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 715 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Luca Barbato]

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

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 920 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 913 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 502 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: busybox[sep-usr] support for mounting /usr w/out hassle

[Duncan]

Mike Frysinger posted on Tue, 01 May 2012 12:13:27 -0400 as excerpted:
> On Tuesday 01 May 2012 11:45:01 Mike Frysinger wrote:

>> based on past behavior, i assumed it was operating as indented
> 
> blah, swap that 't' & 'd'

I thought for SURE that was a deliberate play on words.  Mind if I borrow 
the phrase?  "Operating as indented!"  Indeed!  Sounds like a bit too 
much "percussive maintenance"!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

On Tue, May 01, 2012 at 11:45:01AM -0400, 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
> 
> > > 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 /.

Hmm, if I do that I would also have to put it back ro after I modify
issue because fsck hasn't run yet...

Do we want to mess around with the fs before fsck is run?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1226 bytes --]

On Tuesday 01 May 2012 12:51:55 William Hubbs wrote:
> On Tue, May 01, 2012 at 11:45:01AM -0400, 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:
> > > > 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 /.
> 
> Hmm, if I do that I would also have to put it back ro after I modify
> issue because fsck hasn't run yet...
> 
> Do we want to mess around with the fs before fsck is run?

the previous cases made sense in context (they had to modify / anyways), so if 
you wanted to skip that step, it's probably fine.  i'm not too worried about 
fsck as many nowadays recover their journal gracefully at mount time ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Luca Barbato]

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

On 01/05/12 09:51, William Hubbs wrote:
> Hmm, if I do that I would also have to put it back ro after I modify
> issue because fsck hasn't run yet...
> 
> Do we want to mess around with the fs before fsck is run?

We could play it safe and store the messages somewhere in tmpfs and
write them to issue right before giving a shell.

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+gvZMACgkQ6Ex4woTpDjQeZwCeMfp6r41zDcTGcOpfeJDQEjlF
GIsAoNVx0cGwV7jcVJA6N6DpIbDeXxRk
=UvEC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Ulrich Mueller]

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

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 663 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Ulrich Mueller]

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

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1115 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Ulrich Mueller]

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

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Maxim Kammerer]

On Mon, Apr 30, 2012 at 05:00, Mike Frysinger <vapier@gentoo.org> 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)

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 883 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Maxim Kammerer]

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)

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 867 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Maxim Kammerer]

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)

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 450 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Walter Dnes]

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>

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 594 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Tony "Chainsaw" Vroon]

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@linx.net

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[Rich Freeman]

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.

> 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

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]