Mailing List Archive

Am Freitag 06 Januar 2012, 17:07:20 schrieb Alex Alexander:
> On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote:
> > On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander <wired@gentoo.org> wrote:
> > > If people are really interested in keeping a tight, self contained
> > > root, we need to:
> > >
> > > - establish a [tight] list of software we consider critical for /
> > > - fix/patch software in that list so it can run without /usr there
> > > - create /bin => /usr/bin/ symlinks for above software (simplifies
> > > things if packages start hardcoding /usr/bin here and there)
> > > - move everything else in /usr/bin/
> >
> > You're missing one thing:
> >
> > - establish a list of all the configurations that will actually work
> > with this self-contained root
> >
> > I think this is why there is so much disagreement over whether this is
> > a good move. If you have a really simple configuration, then the
> > self-contained root concept works reasonably well (though apparently
> > we'll have to heavily patch newer versions of udev or abandon it to
> > sustain this).
> >
> > However, if you have a very complex configuration the current
> > self-contained root is already broken and you need an initramfs
> > anyway. For in-between cases things might work now but that is likely
> > to change as upstream moves on.
> >
> > The binary distros don't have users tweaking their kernels and init
> > scripts, so they basically have to design for worst-case. Gentoo can
> > get away with designing for more of an average case since we just tell
> > anybody with a complex case to go read a howto and configure what is
> > necessary (and we like to do that stuff anyway).
> >
> > We can choose not to like it, but it sounds like maintaining a
> > self-contained root for even the typical case will become untenable.
> > Those who argue that having /usr on a separate partition simply
> > shouldn't be supported are basically just saying that our
> > "self-contained root" should include everything in /usr which seems to
> > defeat the whole point of a "self-contained root" anyway.
> >
> > It seems to me that the most reasonable approach is to not force the
> > issue, but not deviate greatly from upstream either. That means
> > accepting that over time the rootfs will become less and less capable
> > of working on its own, and immediately improving tools like dracut to
> > overcome these limitations. Users who can get away with it can avoid
> > using an initramfs, at least for a time.
> >
> > Sure, it is all open source, and Gentoo can swim upstream if we REALLY
> > want to. However, this only works if developers are willing to spend
> > the time constantly fixing upstream's tools. It sounds to me like the
> > maintainers of packages like udev/systemd/etc want to actually move in
> > the same direction as upstream so in practice I don't see that
> > happening.
> >
> > Now, Gentoo is about choice, so one thing we should try to do as much
> > as possible is understand the limitations of the various
> > configurations and make it clear to users when they do and don't need
> > an initramfs. To be honest, tight coupling worries me more than the
> > /usr move, since that has a lot more potential to constrain the
> > choices we can offer our users (which is a great deal of the value
> > that Gentoo offers). I understand its advantages, but it seems
> > somewhat contrary to "the unix way."
>
> That's why I wrote "tight list". I do not expect the self-contained root
> to be able to handle everything /usr (or a complete initramfs) would.
> What it could and couldn't do is something that needs to be decided, but
> some work is already done there - it's just a bit messy and incomplete
> and because most people don't care it keeps getting worse.
>
> The important thing here is to make a clear definition of where we draw
> the line and make sure things work the way we want them to.
>
> I agree with you in that at some point patching may become too time
> consuming, but I still believe that if we do this properly, with a
> well-defined plan and list of packages we want to keep in / (with
> symlinks to be compatible with whatever others are trying to do), we
> won't be alone in this. Gentoo may be one of the most hardcore
> power-user distros out there, but we're certainly not the only one.
>
> Now, if only we had people interested enough in doing this... :)

I'm interested in everything which prevents such kind of insanity from Gentoo.
So count me in as volunteer keeping /bin, /sbin and /lib in Gentoo and systemd
away from it.
As long as we keep trying and working hard I'm sure we can do the workload
that might come across when blind upstreams start adopting those foolish
systemd/GnomeOS ideas...

--
Lars Wendler (Polynomial-C)

On Sun, 8 Jan 2012 00:47:21 +0100
Lars Wendler <polynomial-c@gentoo.org> wrote:

> Am Freitag 06 Januar 2012, 17:07:20 schrieb Alex Alexander:
> > On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote:
> > > On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander <wired@gentoo.org>
> > > wrote:
> > > > If people are really interested in keeping a tight, self
> > > > contained root, we need to:
> > > >
> > > > - establish a [tight] list of software we consider critical
> > > > for /
> > > > - fix/patch software in that list so it can run without /usr
> > > > there
> > > > - create /bin => /usr/bin/ symlinks for above software
> > > > (simplifies things if packages start hardcoding /usr/bin here
> > > > and there)
> > > > - move everything else in /usr/bin/
> > >
> > > You're missing one thing:
> > >
> > > - establish a list of all the configurations that will actually
> > > work with this self-contained root
> > >
> > > I think this is why there is so much disagreement over whether
> > > this is a good move. If you have a really simple configuration,
> > > then the self-contained root concept works reasonably well
> > > (though apparently we'll have to heavily patch newer versions of
> > > udev or abandon it to sustain this).
> > >
> > > However, if you have a very complex configuration the current
> > > self-contained root is already broken and you need an initramfs
> > > anyway. For in-between cases things might work now but that is
> > > likely to change as upstream moves on.
> > >
> > > The binary distros don't have users tweaking their kernels and
> > > init scripts, so they basically have to design for worst-case.
> > > Gentoo can get away with designing for more of an average case
> > > since we just tell anybody with a complex case to go read a howto
> > > and configure what is necessary (and we like to do that stuff
> > > anyway).
> > >
> > > We can choose not to like it, but it sounds like maintaining a
> > > self-contained root for even the typical case will become
> > > untenable. Those who argue that having /usr on a separate
> > > partition simply shouldn't be supported are basically just saying
> > > that our "self-contained root" should include everything in /usr
> > > which seems to defeat the whole point of a "self-contained root"
> > > anyway.
> > >
> > > It seems to me that the most reasonable approach is to not force
> > > the issue, but not deviate greatly from upstream either. That
> > > means accepting that over time the rootfs will become less and
> > > less capable of working on its own, and immediately improving
> > > tools like dracut to overcome these limitations. Users who can
> > > get away with it can avoid using an initramfs, at least for a
> > > time.
> > >
> > > Sure, it is all open source, and Gentoo can swim upstream if we
> > > REALLY want to. However, this only works if developers are
> > > willing to spend the time constantly fixing upstream's tools. It
> > > sounds to me like the maintainers of packages like
> > > udev/systemd/etc want to actually move in the same direction as
> > > upstream so in practice I don't see that happening.
> > >
> > > Now, Gentoo is about choice, so one thing we should try to do as
> > > much as possible is understand the limitations of the various
> > > configurations and make it clear to users when they do and don't
> > > need an initramfs. To be honest, tight coupling worries me more
> > > than the /usr move, since that has a lot more potential to
> > > constrain the choices we can offer our users (which is a great
> > > deal of the value that Gentoo offers). I understand its
> > > advantages, but it seems somewhat contrary to "the unix way."
> >
> > That's why I wrote "tight list". I do not expect the self-contained
> > root to be able to handle everything /usr (or a complete initramfs)
> > would. What it could and couldn't do is something that needs to be
> > decided, but some work is already done there - it's just a bit
> > messy and incomplete and because most people don't care it keeps
> > getting worse.
> >
> > The important thing here is to make a clear definition of where we
> > draw the line and make sure things work the way we want them to.
> >
> > I agree with you in that at some point patching may become too time
> > consuming, but I still believe that if we do this properly, with a
> > well-defined plan and list of packages we want to keep in / (with
> > symlinks to be compatible with whatever others are trying to do), we
> > won't be alone in this. Gentoo may be one of the most hardcore
> > power-user distros out there, but we're certainly not the only one.
> >
> > Now, if only we had people interested enough in doing this... :)
>
> I'm interested in everything which prevents such kind of insanity
> from Gentoo. So count me in as volunteer keeping /bin, /sbin and /lib
> in Gentoo and systemd away from it.
> As long as we keep trying and working hard I'm sure we can do the
> workload that might come across when blind upstreams start adopting
> those foolish systemd/GnomeOS ideas...

From which point this was systemd/GnomeOS ideas? As far I can see, this
was completely irrelevant, separate Fedora idea. But with scapegoat,
everything seems better, doesn't it?

Does working hard involve compiling even more packages statically?
Considering that we all know the drawbacks of static linkage, this is
definitely not insanity.

--
Best regards,
Michał Górny

On Sat, Jan 07, 2012 at 08:01:17PM +0100, Enrico Weigelt wrote

> Great. Perhaps you could create some unusual setups (perhaps in a
> full-VM), so we can build an test platform on it.
>
> IIRC the main problem are scenarios where /usr is not available
> at boot, eg. has to be mounted from somewhere else (eg. NFS).
> So, our test platform should have such setups.

I run with an "interesting" setup at home which could be a "torture
test" for mounting. fdisk shows...

Device Boot Start End Blocks Id System
/dev/sda1 63 976768064 488384001 5 Extended
/dev/sda5 126 996029 497952 83 Linux
/dev/sda6 996093 8819684 3911796 82 Linux swap / Solaris
/dev/sda7 8819748 976768064 483974158+ 83 Linux

sda1 is the entire harddrive
sda5 is the 250 megabyte / partition using ext2fs (YES!)
sda6 is the swap partition
sda7 is the rest of the harddrive using reiserfs

/opt, /var, /usr, and /tmp are are bindmounted from /home like so...

/dev/sda5 / ext2 noatime,nodiratime,async 0 1
/dev/sda7 /home reiserfs noatime,nodiratime,async,notail 0 1
/home/bindmounts/opt /opt auto bind 0 0
/home/bindmounts/var /var auto bind 0 0
/home/bindmounts/usr /usr auto bind 0 0
/home/bindmounts/tmp /tmp auto bind 0 0

This allows me to...
* use a really small / partition, without resorting to LVM
* not worry about running out of space in other partitions
* I started using it years ago when I had not decided which distro to
use. I could wipe the contents of /opt, /var, /usr, and /tmp but keep
my data, emails, etc, in my user directory and install another distro
without blowing away my data.

--
Walter Dnes <waltdnes@waltdnes.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

do you need udevd in runlevel boot at all (for sysvinit)?

Given either your kernel knows its root hardware device driver or has
an initrd to load needed modules to mount the root filesystem.

You can have CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y and let the
kernel create all the /dev/{sd,sr,hd}? device files needed for
/etc/init.d/{fsck,bootmisc,localmount} to check and mount /usr.

Normally you can start udevd after localmount and just right before
network, to persistent-network rename the interfaces.

On NFS_ROOT setups, you either have network by CONFIG_IP_PNP
(kernel-level ip autoconfiguration) and get your root fs from the DHCP
or you have an initrd which can mount /usr.

So, all you need udevd for is fancy-permissions/groups once a non-root
plugs in an USB drive (which is an multiuser-nightmare by itself).

It should be sufficient to load udevd after localmount has mounted
/usr udevd replays all the discoveries read from the kernel and
applies the permission/ownership rules.

Concern is to sustain the freedom of choice that brought me to Gentoo.

Please provide systemd as an option.
And provide sysvinit/openrc as an option.
Do __not__ make an initrd mandatory.

/* skip __ALL__ the systemd rants */

Thanks.

- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk8KH60ACgkQknrdDGLu8JANDwD/V+MvWXtn/yXcE1/nTQT7ZlMh
g+K/EHomildn5cuTNssA/1eu83i6vQee6YbOoGouyWOfKvAxMRM33nhrPc3qXOqc
=txiD
-----END PGP SIGNATURE-----

On 01/08/2012 02:58 PM, Michael Weber wrote:
> Hi,
>
> do you need udevd in runlevel boot at all (for sysvinit)?
>
> Given either your kernel knows its root hardware device driver or has
> an initrd to load needed modules to mount the root filesystem.
>
> You can have CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y and let the
> kernel create all the /dev/{sd,sr,hd}? device files needed for
> /etc/init.d/{fsck,bootmisc,localmount} to check and mount /usr.
>
> Normally you can start udevd after localmount and just right before
> network, to persistent-network rename the interfaces.
>
> On NFS_ROOT setups, you either have network by CONFIG_IP_PNP
> (kernel-level ip autoconfiguration) and get your root fs from the DHCP
> or you have an initrd which can mount /usr.
>
> So, all you need udevd for is fancy-permissions/groups once a non-root
> plugs in an USB drive (which is an multiuser-nightmare by itself).
>
> It should be sufficient to load udevd after localmount has mounted
> /usr udevd replays all the discoveries read from the kernel and
> applies the permission/ownership rules.
>
> Concern is to sustain the freedom of choice that brought me to Gentoo.
>
> Please provide systemd as an option.
> And provide sysvinit/openrc as an option.
> Do __not__ make an initrd mandatory.

In any case, you won't need an initramfs unless /usr is on a separate
partition. Assuming that /usr is mounted before init starts, doesn't it
make sense to start udevd as early as possible, before modules, before
lvm, and before localmount? If we start udevd after localmount as you
suggest, wouldn't that imply that we don't support modular kernels?
--
Thanks,
Zac

On Sun, 08 Jan 2012 23:58:53 +0100
Michael Weber <xmw@gentoo.org> wrote:

> Concern is to sustain the freedom of choice that brought me to Gentoo.
>
> Please provide systemd as an option.
> And provide sysvinit/openrc as an option.
> Do __not__ make an initrd mandatory.

And I'd like to have the freedom of having a clean rootfs and system
free of random static executables needed to mount /usr with random
filesystems.

Static linking is IMHO worse than making _initramfs_ mandatory.
Or maybe do you have method to force rebuilds of packages dependant
on static libraries?

--
Best regards,
Michał Górny

On Mon, Jan 9, 2012 at 12:22 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 08 Jan 2012 23:58:53 +0100
> Michael Weber <xmw@gentoo.org> wrote:
>
>> Concern is to sustain the freedom of choice that brought me to Gentoo.
>>
>> Please provide systemd as an option.
>> And provide sysvinit/openrc as an option.
>> Do __not__ make an initrd mandatory.
>
> And I'd like to have the freedom of having a clean rootfs and system
> free of random static executables needed to mount /usr with random
> filesystems.
>
> Static linking is IMHO worse than making _initramfs_ mandatory.
> Or maybe do you have method to force rebuilds of packages dependant
> on static libraries?

Do you have a method to force rebuilds of the initramfs?

The argument you used against static linking was that my statically
linked binary has a library with a data corruption bug and thus when I
go to rescue my machine I might inadvertently delete everything. How
is having the library in my initramfs any different (even dynamically
linked?)

-A

>
> --
> Best regards,
> Michał Górny

* Micha?? Górny <mgorny@gentoo.org> schrieb:

> Does working hard involve compiling even more packages statically?

I guess, he means keeping udev in / ?


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

On Tue, 10 Jan 2012 19:14:52 +0100
Enrico Weigelt <weigelt@metux.de> wrote:

> * Micha?? Górny <mgorny@gentoo.org> schrieb:
>
> > Does working hard involve compiling even more packages statically?
>
> I guess, he means keeping udev in / ?

Because adding 80 KiB of initramfs hurts so much? We should then put
more work just to ensure that admin doesn't have to waste 15 minutes to
recompile the kernel (if necessary), create an initramfs and add it to
bootloader config?

--
Best regards,
Michał Górny

Michał Górny wrote:
> On Tue, 10 Jan 2012 19:14:52 +0100
> Enrico Weigelt<weigelt@metux.de> wrote:
>
>> * Micha?? Górny<mgorny@gentoo.org> schrieb:
>>
>>> Does working hard involve compiling even more packages statically?
>> I guess, he means keeping udev in / ?
> Because adding 80 KiB of initramfs hurts so much? We should then put
> more work just to ensure that admin doesn't have to waste 15 minutes to
> recompile the kernel (if necessary), create an initramfs and add it to
> bootloader config?
>


Took me days to get dracut to work. Where does 15 minutes come from?
How much time does it take when the initramfs fails? I keep hoping that
all the smart people involved in this will see the mess it is creating.
I'm not the sharpest tool in the shed but I'm sharp enough to see the
mess this is going to create and I'm just a desktop user. I feel sorry
for people with more complicated systems or remote ones.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On Tue, 10 Jan 2012 12:56:11 -0600
Dale <rdalek1967@gmail.com> wrote:

> Michał Górny wrote:
> > On Tue, 10 Jan 2012 19:14:52 +0100
> > Enrico Weigelt<weigelt@metux.de> wrote:
> >
> >> * Micha?? Górny<mgorny@gentoo.org> schrieb:
> >>
> >>> Does working hard involve compiling even more packages statically?
> >> I guess, he means keeping udev in / ?
> > Because adding 80 KiB of initramfs hurts so much? We should then put
> > more work just to ensure that admin doesn't have to waste 15
> > minutes to recompile the kernel (if necessary), create an initramfs
> > and add it to bootloader config?
> >
>
>
> Took me days to get dracut to work. Where does 15 minutes come
> from?

I just took the time I needed to write an initramfs from scratch
and divided it by two, assuming using an already-made tool is simpler.

> How much time does it take when the initramfs fails?

The same when rootfs fails? Only the fact that initramfs is less likely
to break than rootfs, and you have a pretty good opportunity now to
experiment with it while nothing on your system made it useless without
one.

> I keep hoping that all the smart people involved in this will see the
> mess it is creating. I'm not the sharpest tool in the shed but I'm
> sharp enough to see the mess this is going to create and I'm just a
> desktop user. I feel sorry for people with more complicated systems
> or remote ones.

The mess was created by people shouting 'hey, real men use
separate /usr for no good reason! Be awesome like us'.

--
Best regards,
Michał Górny

On Tue, Jan 10, 2012 at 1:56 PM, Dale <rdalek1967@gmail.com> wrote:
> Took me days to get dracut to work.  Where does 15 minutes come from?  How
> much time does it take when the initramfs fails?

I've used dracut on a few VMs now and on my main Gentoo box. My
experience has been that it didn't take long to figure out, and it is
trivially easy to install.

Now, whether it works is a separate issue. Most of the time it works
just fine, and it is no harder to deploy than typing genkernel all.

When it doesn't work then you're going to spend a whole lot more time
trying to fix it - I'm still tweaking mine. Granted, its failure mode
is only disastrous in an unattended system in my case since I can just
type one line at the dash shell and exit and it boots fine. I just
need to get unlazy and debug the script...

Rich

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

On 10.01.2012 19:56, Dale wrote:
> Michał Górny wrote:
>> On Tue, 10 Jan 2012 19:14:52 +0100 Enrico
>> Weigelt<weigelt@metux.de> wrote:
>>
>>> * Micha?? Górny<mgorny@gentoo.org> schrieb:
>>>
>>>> Does working hard involve compiling even more packages
>>>> statically?
>>> I guess, he means keeping udev in / ?
>> Because adding 80 KiB of initramfs hurts so much? We should then
>> put more work just to ensure that admin doesn't have to waste 15
>> minutes to recompile the kernel (if necessary), create an
>> initramfs and add it to bootloader config?
>>
>
>
> Took me days to get dracut to work. Where does 15 minutes come
> from? How much time does it take when the initramfs fails? I keep
> hoping that all the smart people involved in this will see the mess
> it is creating. I'm not the sharpest tool in the shed but I'm sharp
> enough to see the mess this is going to create and I'm just a
> desktop user. I feel sorry for people with more complicated
> systems or remote ones.
>
> Dale
>
> :-) :-)
>

If you have got it working once, it should take less than 15 minutes
(I've made myself a bashscript with the exact dracut commandline
parameters needed for my system).

But I have to agree with you, that exotic setups (I have encypted root
on my laptop) are very bad documented.
If dracut shall become standard for Gentoo (alternative: genkernel can
build an initramfs) someone will have to write an exact howto with the
most important (or better all) commandline arguments and kernel
commandline parameters.

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

iQEcBAEBAgAGBQJPDIzWAAoJEJwwOFaNFkYccIUH/2sPXpD/nOyrMZi34eUgV8qp
NVa/JvVUEiSdxpETJoahwNTT1tOilxXA5ospLK3FShDyMqmngaFtTp8dqaiojOwg
OOcNkmq8/W6GUVrRUOfBjM1LORVOcGkGWAQ2RNkah388M7HCXe98bgKSd7vLJtbd
E5deIZ8ETLaJ2+tQh1L3Af6D7hUlZolbwwmUGl7b81o6O1YFjkvaZFiNBBoSQ8rD
h+OXxnsXn72xFIqek/egpPkUqHDRhtO4hvo6fJR5JZGpF8r1HeS3y4Fa/jFPVrtV
EUsdkCulW5ZDQt0pXbWDOugMhEFtkJ3NMlZKUiqdKYiiZmJcmp1Rgu0NQYlw0uY=
=bupg
-----END PGP SIGNATURE-----

Michał Górny wrote:
> On Tue, 10 Jan 2012 12:56:11 -0600
> Dale<rdalek1967@gmail.com> wrote:
>
>> Michał Górny wrote:
>>> On Tue, 10 Jan 2012 19:14:52 +0100
>>> Enrico Weigelt<weigelt@metux.de> wrote:
>>>
>>>> * Micha?? Górny<mgorny@gentoo.org> schrieb:
>>>>
>>>>> Does working hard involve compiling even more packages statically?
>>>> I guess, he means keeping udev in / ?
>>> Because adding 80 KiB of initramfs hurts so much? We should then put
>>> more work just to ensure that admin doesn't have to waste 15
>>> minutes to recompile the kernel (if necessary), create an initramfs
>>> and add it to bootloader config?
>>>
>>
>> Took me days to get dracut to work. Where does 15 minutes come
>> from?
> I just took the time I needed to write an initramfs from scratch
> and divided it by two, assuming using an already-made tool is simpler.

Wish it was like that for me. I never got one made from scratch to work.

>
>> How much time does it take when the initramfs fails?
> The same when rootfs fails? Only the fact that initramfs is less likely
> to break than rootfs, and you have a pretty good opportunity now to
> experiment with it while nothing on your system made it useless without
> one.

Funny, I never had the rootfs fail before. I have had init thingys fail
many many times. They lead to a reinstall since I had no idea how to
fix it.


>
>> I keep hoping that all the smart people involved in this will see the
>> mess it is creating. I'm not the sharpest tool in the shed but I'm
>> sharp enough to see the mess this is going to create and I'm just a
>> desktop user. I feel sorry for people with more complicated systems
>> or remote ones.
> The mess was created by people shouting 'hey, real men use
> separate /usr for no good reason! Be awesome like us'.
>

I think it is more like people do that when they have a good reason to
do so. I plan to put mine on /usr when I get the chance and know that
this init crap isn't going to break my rig. It's not being "awesome"
either.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Rich Freeman wrote:
> On Tue, Jan 10, 2012 at 1:56 PM, Dale<rdalek1967@gmail.com> wrote:
>> Took me days to get dracut to work. Where does 15 minutes come from? How
>> much time does it take when the initramfs fails?
> I've used dracut on a few VMs now and on my main Gentoo box. My
> experience has been that it didn't take long to figure out, and it is
> trivially easy to install.
>
> Now, whether it works is a separate issue. Most of the time it works
> just fine, and it is no harder to deploy than typing genkernel all.
>
> When it doesn't work then you're going to spend a whole lot more time
> trying to fix it - I'm still tweaking mine. Granted, its failure mode
> is only disastrous in an unattended system in my case since I can just
> type one line at the dash shell and exit and it boots fine. I just
> need to get unlazy and debug the script...
>
> Rich
>
>

I finally got dracut to work, I think it is anyway. I asked on the user
list but no one knows I guess since there are no replies.

I tried genkernel when I first installed Gentoo. I found it MUCH easier
to do my own kernel. Genkernel never built a bootable kernel for my
rig. I don't recall the errors now but it didn't work and I tried many
times. I still do my kernels by hand.

The thing about me is that I left my previous distro because of the init
thingy CONSTANTLY failing and rpm dependency issues. Now, here I am
again. By the way, I didn't mess with the init thingy either. It broke
all on its own. This makes me wonder if the dependency issues has
gotten sorted out. My brothers Kubuntu seems to work fine. It just
makes me wonder.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Hinnerk van Bruinehsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10.01.2012 19:56, Dale wrote:
>> Michał Górny wrote:
>>> On Tue, 10 Jan 2012 19:14:52 +0100 Enrico
>>> Weigelt<weigelt@metux.de> wrote:
>>>
>>>> * Micha?? Górny<mgorny@gentoo.org> schrieb:
>>>>
>>>>> Does working hard involve compiling even more packages
>>>>> statically?
>>>> I guess, he means keeping udev in / ?
>>> Because adding 80 KiB of initramfs hurts so much? We should then
>>> put more work just to ensure that admin doesn't have to waste 15
>>> minutes to recompile the kernel (if necessary), create an
>>> initramfs and add it to bootloader config?
>>>
>>
>> Took me days to get dracut to work. Where does 15 minutes come
>> from? How much time does it take when the initramfs fails? I keep
>> hoping that all the smart people involved in this will see the mess
>> it is creating. I'm not the sharpest tool in the shed but I'm sharp
>> enough to see the mess this is going to create and I'm just a
>> desktop user. I feel sorry for people with more complicated
>> systems or remote ones.
>>
>> Dale
>>
>> :-) :-)
>>
> If you have got it working once, it should take less than 15 minutes
> (I've made myself a bashscript with the exact dracut commandline
> parameters needed for my system).
>
> But I have to agree with you, that exotic setups (I have encypted root
> on my laptop) are very bad documented.
> If dracut shall become standard for Gentoo (alternative: genkernel can
> build an initramfs) someone will have to write an exact howto with the
> most important (or better all) commandline arguments and kernel
> commandline parameters.
>
> Hinnerk
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPDIzWAAoJEJwwOFaNFkYccIUH/2sPXpD/nOyrMZi34eUgV8qp
> NVa/JvVUEiSdxpETJoahwNTT1tOilxXA5ospLK3FShDyMqmngaFtTp8dqaiojOwg
> OOcNkmq8/W6GUVrRUOfBjM1LORVOcGkGWAQ2RNkah388M7HCXe98bgKSd7vLJtbd
> E5deIZ8ETLaJ2+tQh1L3Af6D7hUlZolbwwmUGl7b81o6O1YFjkvaZFiNBBoSQ8rD
> h+OXxnsXn72xFIqek/egpPkUqHDRhtO4hvo6fJR5JZGpF8r1HeS3y4Fa/jFPVrtV
> EUsdkCulW5ZDQt0pXbWDOugMhEFtkJ3NMlZKUiqdKYiiZmJcmp1Rgu0NQYlw0uY=
> =bupg
> -----END PGP SIGNATURE-----
>
>

If I recall correctly, it took me at least three or four web sites and
the man page to get dracut to work. This is something that needs to be
worked on hugely before this goes to much farther. Gentoo doesn't need
to lose its status on the docs. I tried to follow the Gentoo doc and it
would not even boot. I tried everything I could find but it still
didn't work. Out of date, maybe. I dunno. It just didn't work for
me. Thing is, my current setup doesn't even need one. I plan to have a
separate /usr on LVM as soon as I can get me one more large drive. I'll
have to have one then.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On Tue, 10 Jan 2012 16:40:01 -0600
Dale <rdalek1967@gmail.com> wrote:

> >> I keep hoping that all the smart people involved in this will see
> >> the mess it is creating. I'm not the sharpest tool in the shed but
> >> I'm sharp enough to see the mess this is going to create and I'm
> >> just a desktop user. I feel sorry for people with more
> >> complicated systems or remote ones.
> > The mess was created by people shouting 'hey, real men use
> > separate /usr for no good reason! Be awesome like us'.
> >
>
> I think it is more like people do that when they have a good reason
> to do so. I plan to put mine on /usr when I get the chance and know
> that this init crap isn't going to break my rig. It's not being
> "awesome" either.

Remind me of a single good reason. Last time I heard those were mostly
hacks and laziness.

--
Best regards,
Michał Górny

On Wed, 11 Jan 2012 08:41:04 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Remind me of a single good reason. Last time I heard those were mostly
> hacks and laziness.

Here's one: ability to share disk space automatically between /usr
and /home (implication: must be same filesystem; useful because these
are the two largest filesystems in most of my installs;
substitute /var if you prefer for servers), ability to take consistent
backups without stopping activity (implication: /home must be on LVM for
snapshots; implication: /usr must also be on LVM due to sharing
filesystem with /home), ability to not use an initramfs (implication:
root must not be on LVM).

Unless you'd like to suggest a better way to achieve all three of these
goals?

Chris

>>>>> On Wed, 11 Jan 2012, Micha³ Górny wrote:

>> I think it is more like people do that when they have a good reason
>> to do so. I plan to put mine on /usr when I get the chance and know
>> that this init crap isn't going to break my rig. It's not being
>> "awesome" either.

> Remind me of a single good reason. Last time I heard those were
> mostly hacks and laziness.

/usr can be mounted readonly, while / and /var cannot?

Ulrich

Michał Górny wrote:
> On Tue, 10 Jan 2012 16:40:01 -0600
> Dale<rdalek1967@gmail.com> wrote:
>
>>>> I keep hoping that all the smart people involved in this will see
>>>> the mess it is creating. I'm not the sharpest tool in the shed but
>>>> I'm sharp enough to see the mess this is going to create and I'm
>>>> just a desktop user. I feel sorry for people with more
>>>> complicated systems or remote ones.
>>> The mess was created by people shouting 'hey, real men use
>>> separate /usr for no good reason! Be awesome like us'.
>>>
>> I think it is more like people do that when they have a good reason
>> to do so. I plan to put mine on /usr when I get the chance and know
>> that this init crap isn't going to break my rig. It's not being
>> "awesome" either.
> Remind me of a single good reason. Last time I heard those were mostly
> hacks and laziness.
>


I already stated the reason. I'm going to put /usr on LVM. That is not
only a good reason, it is a GREAT reason. I see others have also posted
their reason as well.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On Wed, 11 Jan 2012 10:34:34 -0600
Dale <rdalek1967@gmail.com> wrote:

> Michał Górny wrote:
> > On Tue, 10 Jan 2012 16:40:01 -0600
> > Dale<rdalek1967@gmail.com> wrote:
> >
> >>>> I keep hoping that all the smart people involved in this will see
> >>>> the mess it is creating. I'm not the sharpest tool in the shed
> >>>> but I'm sharp enough to see the mess this is going to create and
> >>>> I'm just a desktop user. I feel sorry for people with more
> >>>> complicated systems or remote ones.
> >>> The mess was created by people shouting 'hey, real men use
> >>> separate /usr for no good reason! Be awesome like us'.
> >>>
> >> I think it is more like people do that when they have a good reason
> >> to do so. I plan to put mine on /usr when I get the chance and
> >> know that this init crap isn't going to break my rig. It's not
> >> being "awesome" either.
> > Remind me of a single good reason. Last time I heard those were
> > mostly hacks and laziness.
> >
>
>
> I already stated the reason. I'm going to put /usr on LVM. That is
> not only a good reason, it is a GREAT reason.

It is a hack.

--
Best regards,
Michał Górny

On Wed, 11 Jan 2012 09:44:31 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Wed, 11 Jan 2012, Michał Górny wrote:
>
> >> I think it is more like people do that when they have a good reason
> >> to do so. I plan to put mine on /usr when I get the chance and
> >> know that this init crap isn't going to break my rig. It's not
> >> being "awesome" either.
>
> > Remind me of a single good reason. Last time I heard those were
> > mostly hacks and laziness.
>
> /usr can be mounted readonly, while / and /var cannot?

What is the point of mounting the less important part of the system
read-only while the more important one is writable?

Also, it should be possible to mount rootfs read-only with
separate /var. Of course, that would require the software to be
actually FHS-compliant and not put runtime-written files in /etc.

--
Best regards,
Michał Górny

On Wed, 11 Jan 2012 18:03:50 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Wed, 11 Jan 2012 09:44:31 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
> > >>>>> On Wed, 11 Jan 2012, Michał Górny wrote:
> >
> > >> I think it is more like people do that when they have a good
> > >> reason to do so. I plan to put mine on /usr when I get the
> > >> chance and know that this init crap isn't going to break my
> > >> rig. It's not being "awesome" either.
> >
> > > Remind me of a single good reason. Last time I heard those were
> > > mostly hacks and laziness.
> >
> > /usr can be mounted readonly, while / and /var cannot?
>
> What is the point of mounting the less important part of the system
> read-only while the more important one is writable?
>
> Also, it should be possible to mount rootfs read-only with
> separate /var. Of course, that would require the software to be
> actually FHS-compliant and not put runtime-written files in /etc.
>

security?

--
Matthew Thode (prometheanfire)

Michał Górny wrote:
> On Wed, 11 Jan 2012 10:34:34 -0600
> Dale<rdalek1967@gmail.com> wrote:
>
>> Michał Górny wrote:
>>> On Tue, 10 Jan 2012 16:40:01 -0600
>>> Dale<rdalek1967@gmail.com> wrote:
>>>
>>>>>> I keep hoping that all the smart people involved in this will see
>>>>>> the mess it is creating. I'm not the sharpest tool in the shed
>>>>>> but I'm sharp enough to see the mess this is going to create and
>>>>>> I'm just a desktop user. I feel sorry for people with more
>>>>>> complicated systems or remote ones.
>>>>> The mess was created by people shouting 'hey, real men use
>>>>> separate /usr for no good reason! Be awesome like us'.
>>>>>
>>>> I think it is more like people do that when they have a good reason
>>>> to do so. I plan to put mine on /usr when I get the chance and
>>>> know that this init crap isn't going to break my rig. It's not
>>>> being "awesome" either.
>>> Remind me of a single good reason. Last time I heard those were
>>> mostly hacks and laziness.
>>>
>>
>> I already stated the reason. I'm going to put /usr on LVM. That is
>> not only a good reason, it is a GREAT reason.
> It is a hack.
>

How is putting /usr, /var, /home and such on LVM a hack? Your
definition of hack must have some really low standards. Does installing
Linux fall into your "hack" category to?

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On Wed, Jan 11, 2012 at 10:31 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Wed, 11 Jan 2012 10:34:34 -0600
> Dale <rdalek1967@gmail.com> wrote:
>> I already stated the reason.  I'm going to put /usr on LVM.  That is
>> not only a good reason, it is a GREAT reason.
>
> It is a hack.
>

https://fedoraproject.org/wiki/Features/UsrMove#Benefit_to_Fedora

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team