Mailing List Archive

On Wed, Jan 11, 2012 at 9:01 AM, Michał Górny <mgorny@gentoo.org> 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.

Your opinion is noted, but that doesn't make better or worse than
other folks ideas.

-A

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

Alec Warner wrote:
> On Wed, Jan 11, 2012 at 9:01 AM, Michał Górny<mgorny@gentoo.org> wrote:
>>
>> It is a hack.
> Your opinion is noted, but that doesn't make better or worse than
> other folks ideas.
>
> -A
>
>> --
>> Best regards,
>> Michał Górny

I agree. It doesn't break things that was working 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"

On Fri, 6 Jan 2012 20:05:47 +0100
Michał Górny <mgorny@gentoo.org> wrote:

[snip]

>
> You should consider taking like 1 or 2 hours of your precious time to
> read about the use and meaning of various directories in the
> filesystem.
>

The FHS gives different meaning to directories than the systemd folks
like it to be. Yes, it's unpleasant how far that sort of breakage
already progressed. However, by definition software not adhering to the
current standard is what is broken and not the other way around.

There is nothing wrong with changing an old standard if there is a need,
though until a new standard is approved / accepted there is no ground
to change anything and breaking the current standard on purpose is plain
stupid.

Btw, do you happen to know what is going on with FHS-3.0 and why
there are delays. Wasn't it supposed to be announced in summer 2011?

Then do you happen to know a technical paper which actually discuss the
advantage / disadvantages of changing the current standard. All I have
read on this topic so far looks like propaganda material only or lists
non arguments like "less top level directories".

On Thu, Jan 12, 2012 at 7:29 AM, Ralph Sennhauser <sera@gentoo.org> wrote:
> On Fri, 6 Jan 2012 20:05:47 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> [snip]
>
>>
>> You should consider taking like 1 or 2 hours of your precious time to
>> read about the use and meaning of various directories in the
>> filesystem.
>>
>
> The FHS gives different meaning to directories than the systemd folks
> like it to be. Yes, it's unpleasant how far that sort of breakage
> already progressed. However, by definition software not adhering to the
> current standard is what is broken and not the other way around.

We have never aimed to be FHS compliant, so citing the standard is not
likely to persuade some.
We follow them where we think they make sense and ignore the parts we
think are stupid.
Just like PMS :)

-A

>
> There is nothing wrong with changing an old standard if there is a need,
> though until a new standard is approved / accepted there is no ground
> to change anything and breaking the current standard on purpose is plain
> stupid.
>
> Btw, do you happen to know what is going on with FHS-3.0 and why
> there are delays. Wasn't it supposed to be announced in summer 2011?
>
> Then do you happen to know a technical paper which actually discuss the
> advantage / disadvantages of changing the current standard. All I have
> read on this topic so far looks like propaganda material only or lists
> non arguments like "less top level directories".

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?
>
Isn't it also a question of making sure the new "rootfs is initfs" metaphor
will always work, which requires all the standard utilities, plus any admin
stuff that might be required, to be available in cases of system-recovery?

The latter is already somewhat nebulous for a lot of people, which is why
it's nice when distributions do it for you (traditionally by making tools
available on the rootfs.)

Point is, those utilities all need to be kept up to date with any changes in
the underlying packages, which adds another layer of complexity (and may
require some static builds.)
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Michał Górny wrote:

> On Tue, 10 Jan 2012 12:56:11 -0600
> Dale <rdalek1967@gmail.com> wrote:
>> 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,
Seems to me for the average desktop user (who all this is aimed at, a
narrowing of scope which smacks of poor design) both partitions will be on
the same drive, so I don't know what you base that assertion on.

> and you have a pretty good opportunity now to
> experiment with it
Except we only have the tools we thought to include on the initramfs, not
everything our nice distro system packagers, who have experience and
feedback over a much broader spectrum than one user, provide for us on root.

>> 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'.
>
No, it was created by coders not really grokking why people used /usr,
finding it made integration tricky with dependent projects and then saying
"oh well no-one has a good reason for a separate /usr, let's just ban it."
Now the stance has changed to "a separate /usr can be cool for snapshots,
let's move *everything* there."

The shifting nature of the arguments and the solutions makes me more
uncomfortable that this hasn't been thought through even with the amount of
feedback, and more importantly proper consideration to that feedback,
required for a GLEP, let alone a change to base Linux filesystem
specifications.

Blanket dismissals of any conflicting opinion only worsens that feeling.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

On Tue, Jan 17, 2012 at 5:15 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> The shifting nature of the arguments and the solutions makes me more
> uncomfortable that this hasn't been thought through even with the amount of
> feedback, and more importantly proper consideration to that feedback,
> required for a GLEP, let alone a change to base Linux filesystem
> specifications.
>

Keep in mind that the main proponents of this do not intend to issue
any GLEPs (they don't use Gentoo), and they may or may not get around
to changing FHS/etc. They just intend to "do it" - and to some extent
they're already doing it. Unless projects like udev get forked, we're
going there whether we want to or not - apparently a
soon-to-be-introduced version of udev already breaks when /usr isn't
mounted at boot.

If people don't like this, they need to start writing code, otherwise
they're going to get it by default...

Rich

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

80Kbs? You sure about that? I somehow failed to mention this before.
I noticed it when I saw another reply to this post. Reality check:

root@fireball / # ls -al /boot/initramfs-3.*
-rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img
-rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img
root@fireball / #

That's using the dracut tool. Somehow, over 50Mbs is not anywhere close
to 80Kbs, or maybe my calculator is broken.

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, Jan 17, 2012 at 10:38 PM, 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?
>>
>
> 80Kbs?  You sure about that?  I somehow failed to mention this before.  I
> noticed it when I saw another reply to this post.  Reality check:
>
> root@fireball / # ls -al /boot/initramfs-3.*
> -rw-r--r-- 1 root root 5444240 Jan  1 07:24 /boot/initramfs-3.1.5-gentoo.img
> -rw-r--r-- 1 root root 5515132 Jan  9 07:57 /boot/initramfs-3.2.0-r1.img
> root@fireball / #
>
> That's using the dracut tool.  Somehow, over 50Mbs is not anywhere close to
> 80Kbs, or maybe my calculator is broken.
>

Your calculator is off by a power of 10.

Mike Gilbert wrote:
> On Tue, Jan 17, 2012 at 10:38 PM, 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?
>>>
>> 80Kbs? You sure about that? I somehow failed to mention this before. I
>> noticed it when I saw another reply to this post. Reality check:
>>
>> root@fireball / # ls -al /boot/initramfs-3.*
>> -rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img
>> -rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img
>> root@fireball / #
>>
>> That's using the dracut tool. Somehow, over 50Mbs is not anywhere close to
>> 80Kbs, or maybe my calculator is broken.
>>
> Your calculator is off by a power of 10.
>
>

It is. Still, 5Mbs is a lot larger than 80Kbs.

Thanks for the correction.

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, 17 Jan 2012 21:38:26 -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?
> >
>
> 80Kbs? You sure about that? I somehow failed to mention this
> before. I noticed it when I saw another reply to this post. Reality
> check:

80 KiB is enough for mounting plain /usr and booting with it. See
tiny-initramfs (but I haven't tested it thoroughly).

--
Best regards,
Michał Górny

Michał Górny wrote:
> On Tue, 17 Jan 2012 21:38:26 -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?
>>>
>> 80Kbs? You sure about that? I somehow failed to mention this
>> before. I noticed it when I saw another reply to this post. Reality
>> check:
> 80 KiB is enough for mounting plain /usr and booting with it. See
> tiny-initramfs (but I haven't tested it thoroughly).
>

My plan is to have /usr on lvm. I think it will end up larger and it
still adds one more thing to break.

I really wish someone would get a better plan. I think I see a garbage
dump ahead with lots of Linux distros headed that way.

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, 18 Jan 2012 01:20:03 -0600
Dale <rdalek1967@gmail.com> wrote:

> Michał Górny wrote:
> > On Tue, 17 Jan 2012 21:38:26 -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?
> >>>
> >> 80Kbs? You sure about that? I somehow failed to mention this
> >> before. I noticed it when I saw another reply to this post.
> >> Reality check:
> > 80 KiB is enough for mounting plain /usr and booting with it. See
> > tiny-initramfs (but I haven't tested it thoroughly).
> >
>
> My plan is to have /usr on lvm. I think it will end up larger and it
> still adds one more thing to break.
>
> I really wish someone would get a better plan. I think I see a
> garbage dump ahead with lots of Linux distros headed that way.

Better plan how? LVM requires udev for some reason. Letting rootfs grow
with data unnecessary for a number of users is no good plan either.
Just install that initramfs, be done with it and let us focus on actual
work rather than fixing random breakages.

We already usually have separate /boot to satisfy the needs of
bootloader. Then you want us to chain yet another filesystem to satisfy
the needs of another layer. Initramfs reuses /boot for that.

--
Best regards,
Michał Górny

Michał Górny wrote:
> On Wed, 18 Jan 2012 01:20:03 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> Michał Górny wrote:
>>> On Tue, 17 Jan 2012 21:38:26 -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?
>>>>>
>>>> 80Kbs? You sure about that? I somehow failed to mention this
>>>> before. I noticed it when I saw another reply to this post.
>>>> Reality check:
>>> 80 KiB is enough for mounting plain /usr and booting with it. See
>>> tiny-initramfs (but I haven't tested it thoroughly).
>>>
>>
>> My plan is to have /usr on lvm. I think it will end up larger and it
>> still adds one more thing to break.
>>
>> I really wish someone would get a better plan. I think I see a
>> garbage dump ahead with lots of Linux distros headed that way.
>
> Better plan how? LVM requires udev for some reason. Letting rootfs grow
> with data unnecessary for a number of users is no good plan either.
> Just install that initramfs, be done with it and let us focus on actual
> work rather than fixing random breakages.
>
> We already usually have separate /boot to satisfy the needs of
> bootloader. Then you want us to chain yet another filesystem to satisfy
> the needs of another layer. Initramfs reuses /boot for that.
>


The point is, I don't like initramfs. I don't want to use one. It's
funny how I never needed one before either but now things are being
broken. It's not LVM that is breaking it either. I wouldn't need the
initramfs even if It was on a regular partition until the recent so
called "improvements."

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 Sat, 21 Jan 2012 06:28:54 -0600
Dale <rdalek1967@gmail.com> wrote:

> Michał Górny wrote:
> > On Wed, 18 Jan 2012 01:20:03 -0600
> > Dale <rdalek1967@gmail.com> wrote:
> >
> >> Michał Górny wrote:
> >>> On Tue, 17 Jan 2012 21:38:26 -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?
> >>>>>
> >>>> 80Kbs? You sure about that? I somehow failed to mention this
> >>>> before. I noticed it when I saw another reply to this post.
> >>>> Reality check:
> >>> 80 KiB is enough for mounting plain /usr and booting with it. See
> >>> tiny-initramfs (but I haven't tested it thoroughly).
> >>>
> >>
> >> My plan is to have /usr on lvm. I think it will end up larger and
> >> it still adds one more thing to break.
> >>
> >> I really wish someone would get a better plan. I think I see a
> >> garbage dump ahead with lots of Linux distros headed that way.
> >
> > Better plan how? LVM requires udev for some reason. Letting rootfs
> > grow with data unnecessary for a number of users is no good plan
> > either. Just install that initramfs, be done with it and let us
> > focus on actual work rather than fixing random breakages.
> >
> > We already usually have separate /boot to satisfy the needs of
> > bootloader. Then you want us to chain yet another filesystem to
> > satisfy the needs of another layer. Initramfs reuses /boot for that.
> >
>
>
> The point is, I don't like initramfs. I don't want to use one.

And I don't like binaries on rootfs. I don't want to have ones.

So we're talking about taste...

> It's funny how I never needed one before either but now things are
> being broken. It's not LVM that is breaking it either. I wouldn't
> need the initramfs even if It was on a regular partition until the
> recent so called "improvements."

...and your main argument is 'long, long ago someone decided that it
should match the same taste as mine, so it should be like it forever'.
Of course, those times there were no such thing as an initramfs...

--
Best regards,
Michał Górny

Michał Górny wrote:
> On Sat, 21 Jan 2012 06:28:54 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> Michał Górny wrote:
>>> On Wed, 18 Jan 2012 01:20:03 -0600
>>> Dale <rdalek1967@gmail.com> wrote:
>>>
>>>> Michał Górny wrote:
>>>>> On Tue, 17 Jan 2012 21:38:26 -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?
>>>>>>>
>>>>>> 80Kbs? You sure about that? I somehow failed to mention this
>>>>>> before. I noticed it when I saw another reply to this post.
>>>>>> Reality check:
>>>>> 80 KiB is enough for mounting plain /usr and booting with it. See
>>>>> tiny-initramfs (but I haven't tested it thoroughly).
>>>>>
>>>>
>>>> My plan is to have /usr on lvm. I think it will end up larger and
>>>> it still adds one more thing to break.
>>>>
>>>> I really wish someone would get a better plan. I think I see a
>>>> garbage dump ahead with lots of Linux distros headed that way.
>>>
>>> Better plan how? LVM requires udev for some reason. Letting rootfs
>>> grow with data unnecessary for a number of users is no good plan
>>> either. Just install that initramfs, be done with it and let us
>>> focus on actual work rather than fixing random breakages.
>>>
>>> We already usually have separate /boot to satisfy the needs of
>>> bootloader. Then you want us to chain yet another filesystem to
>>> satisfy the needs of another layer. Initramfs reuses /boot for that.
>>>
>>
>>
>> The point is, I don't like initramfs. I don't want to use one.
>
> And I don't like binaries on rootfs. I don't want to have ones.
>
> So we're talking about taste...


Actually, we're talking about how things has worked so well for a VERY
long time and there is no need to reinvent the wheel.


>
>> It's funny how I never needed one before either but now things are
>> being broken. It's not LVM that is breaking it either. I wouldn't
>> need the initramfs even if It was on a regular partition until the
>> recent so called "improvements."
>
> ...and your main argument is 'long, long ago someone decided that it
> should match the same taste as mine, so it should be like it forever'.
> Of course, those times there were no such thing as an initramfs...
>


Then don't break that. Just because someone came up with a initramfs
doesn't mean everyone should be forced to use one.

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 01/21/2012 01:34 PM, Dale wrote:
> Michał Górny wrote:
>>> It's funny how I never needed one before either but now things are
>>> being broken. It's not LVM that is breaking it either. I wouldn't
>>> need the initramfs even if It was on a regular partition until the
>>> recent so called "improvements."
>>
>> ...and your main argument is 'long, long ago someone decided that it
>> should match the same taste as mine, so it should be like it forever'.
>> Of course, those times there were no such thing as an initramfs...
>>
>
>
> Then don't break that. Just because someone came up with a initramfs
> doesn't mean everyone should be forced to use one.

The old way imposes requirements that are no longer supported by
upstream software. So, you basically have three choices:

1) Use old software that supports the old way
2) Develop new software to support the old way
3) Use an initramfs or pre-init script to mount /usr if it must be on
a separate partition
--
Thanks,
Zac

On Sat, 21 Jan 2012 15:34:39 -0600
Dale <rdalek1967@gmail.com> wrote:

> Michał Górny wrote:
> > On Sat, 21 Jan 2012 06:28:54 -0600
> > Dale <rdalek1967@gmail.com> wrote:
> >
> >> Michał Górny wrote:
> >>> On Wed, 18 Jan 2012 01:20:03 -0600
> >>> Dale <rdalek1967@gmail.com> wrote:
> >>>
> >>>> Michał Górny wrote:
> >>>>> On Tue, 17 Jan 2012 21:38:26 -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?
> >>>>>>>
> >>>>>> 80Kbs? You sure about that? I somehow failed to mention this
> >>>>>> before. I noticed it when I saw another reply to this post.
> >>>>>> Reality check:
> >>>>> 80 KiB is enough for mounting plain /usr and booting with it.
> >>>>> See tiny-initramfs (but I haven't tested it thoroughly).
> >>>>>
> >>>>
> >>>> My plan is to have /usr on lvm. I think it will end up larger
> >>>> and it still adds one more thing to break.
> >>>>
> >>>> I really wish someone would get a better plan. I think I see a
> >>>> garbage dump ahead with lots of Linux distros headed that way.
> >>>
> >>> Better plan how? LVM requires udev for some reason. Letting rootfs
> >>> grow with data unnecessary for a number of users is no good plan
> >>> either. Just install that initramfs, be done with it and let us
> >>> focus on actual work rather than fixing random breakages.
> >>>
> >>> We already usually have separate /boot to satisfy the needs of
> >>> bootloader. Then you want us to chain yet another filesystem to
> >>> satisfy the needs of another layer. Initramfs reuses /boot for
> >>> that.
> >>>
> >>
> >>
> >> The point is, I don't like initramfs. I don't want to use one.
> >
> > And I don't like binaries on rootfs. I don't want to have ones.
> >
> > So we're talking about taste...
>
>
> Actually, we're talking about how things has worked so well for a VERY
> long time and there is no need to reinvent the wheel.

And required a considerable amount of work which increases due to
software getting more complex and users wanting more features.

And I don't get 'the wheel' here? What wheel? I'd say we rather want to
get rid of the useless fifth wheel.

> >> It's funny how I never needed one before either but now things are
> >> being broken. It's not LVM that is breaking it either. I wouldn't
> >> need the initramfs even if It was on a regular partition until the
> >> recent so called "improvements."
> >
> > ...and your main argument is 'long, long ago someone decided that it
> > should match the same taste as mine, so it should be like it
> > forever'. Of course, those times there were no such thing as an
> > initramfs...
> >
>
>
> Then don't break that. Just because someone came up with a initramfs
> doesn't mean everyone should be forced to use one.

And noone is forced to update the system either.

--
Best regards,
Michał Górny

Michał Górny wrote:
> On Sat, 21 Jan 2012 15:34:39 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> Michał Górny wrote:
>>> On Sat, 21 Jan 2012 06:28:54 -0600
>>> Dale <rdalek1967@gmail.com> wrote:
>>>
>>>> Michał Górny wrote:
>>>>> On Wed, 18 Jan 2012 01:20:03 -0600
>>>>> Dale <rdalek1967@gmail.com> wrote:
>>>>>
>>>>>> Michał Górny wrote:
>>>>>>> On Tue, 17 Jan 2012 21:38:26 -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?
>>>>>>>>>
>>>>>>>> 80Kbs? You sure about that? I somehow failed to mention this
>>>>>>>> before. I noticed it when I saw another reply to this post.
>>>>>>>> Reality check:
>>>>>>> 80 KiB is enough for mounting plain /usr and booting with it.
>>>>>>> See tiny-initramfs (but I haven't tested it thoroughly).
>>>>>>>
>>>>>>
>>>>>> My plan is to have /usr on lvm. I think it will end up larger
>>>>>> and it still adds one more thing to break.
>>>>>>
>>>>>> I really wish someone would get a better plan. I think I see a
>>>>>> garbage dump ahead with lots of Linux distros headed that way.
>>>>>
>>>>> Better plan how? LVM requires udev for some reason. Letting rootfs
>>>>> grow with data unnecessary for a number of users is no good plan
>>>>> either. Just install that initramfs, be done with it and let us
>>>>> focus on actual work rather than fixing random breakages.
>>>>>
>>>>> We already usually have separate /boot to satisfy the needs of
>>>>> bootloader. Then you want us to chain yet another filesystem to
>>>>> satisfy the needs of another layer. Initramfs reuses /boot for
>>>>> that.
>>>>>
>>>>
>>>>
>>>> The point is, I don't like initramfs. I don't want to use one.
>>>
>>> And I don't like binaries on rootfs. I don't want to have ones.
>>>
>>> So we're talking about taste...
>>
>>
>> Actually, we're talking about how things has worked so well for a VERY
>> long time and there is no need to reinvent the wheel.
>
> And required a considerable amount of work which increases due to
> software getting more complex and users wanting more features.
>
> And I don't get 'the wheel' here? What wheel? I'd say we rather want to
> get rid of the useless fifth wheel.



Actually, they are adding the fifth wheel.


>
>>>> It's funny how I never needed one before either but now things are
>>>> being broken. It's not LVM that is breaking it either. I wouldn't
>>>> need the initramfs even if It was on a regular partition until the
>>>> recent so called "improvements."
>>>
>>> ...and your main argument is 'long, long ago someone decided that it
>>> should match the same taste as mine, so it should be like it
>>> forever'. Of course, those times there were no such thing as an
>>> initramfs...
>>>
>>
>>
>> Then don't break that. Just because someone came up with a initramfs
>> doesn't mean everyone should be forced to use one.
>
> And noone is forced to update the system either.
>


Oh, that makes perfect sense. Thinks for the showing of brilliance
there. lol

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"

Zac Medico wrote:
> On 01/21/2012 01:34 PM, Dale wrote:
>> Michał Górny wrote:
>>>> It's funny how I never needed one before either but now things are
>>>> being broken. It's not LVM that is breaking it either. I wouldn't
>>>> need the initramfs even if It was on a regular partition until the
>>>> recent so called "improvements."
>>>
>>> ...and your main argument is 'long, long ago someone decided that it
>>> should match the same taste as mine, so it should be like it forever'.
>>> Of course, those times there were no such thing as an initramfs...
>>>
>>
>>
>> Then don't break that. Just because someone came up with a initramfs
>> doesn't mean everyone should be forced to use one.
>
> The old way imposes requirements that are no longer supported by
> upstream software. So, you basically have three choices:
>
> 1) Use old software that supports the old way
> 2) Develop new software to support the old way
> 3) Use an initramfs or pre-init script to mount /usr if it must be on
> a separate partition


So the solution is to break things because things are broken. Sort of
running in circles there. Pardon me, I'm dizzy.

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 01/21/2012 03:45 PM, Dale wrote:
> Zac Medico wrote:
>> On 01/21/2012 01:34 PM, Dale wrote:
>>> Michał Górny wrote:
>>>>> It's funny how I never needed one before either but now things are
>>>>> being broken. It's not LVM that is breaking it either. I wouldn't
>>>>> need the initramfs even if It was on a regular partition until the
>>>>> recent so called "improvements."
>>>>
>>>> ...and your main argument is 'long, long ago someone decided that it
>>>> should match the same taste as mine, so it should be like it forever'.
>>>> Of course, those times there were no such thing as an initramfs...
>>>>
>>>
>>>
>>> Then don't break that. Just because someone came up with a initramfs
>>> doesn't mean everyone should be forced to use one.
>>
>> The old way imposes requirements that are no longer supported by
>> upstream software. So, you basically have three choices:
>>
>> 1) Use old software that supports the old way
>> 2) Develop new software to support the old way
>> 3) Use an initramfs or pre-init script to mount /usr if it must be on
>> a separate partition
>
>
> So the solution is to break things because things are broken.

Well, option 2 means that people have to step up write software that
supports the old way. For most people, option 3 is probably the most
practical route.
--
Thanks,
Zac

Hi all!

Today I tryed masked version of udev and kmod. My setup has all on lvm2
and i have sepparate usr patrition. To generate initrd i use dracut and
genkernel branch from aidecoe. dracut since 0.14 has ability to mount
usr from initrd.

x201 ~ # lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
boot gentoo -wi-a- 128,00m
distfiles gentoo -wi-ao 15,00g
fscache gentoo -wi-ao 4,00g
home gentoo -wi-ao 200,00g
opt gentoo -wi-ao 5,00g
packages gentoo -wi-ao 2,00g
portage gentoo -wi-ao 512,00m
root gentoo -wi-ao 512,00m
swap gentoo -wi-ao 8,00g
tmp gentoo -wi-ao 5,00g
usr gentoo -wi-ao 20,00g
var gentoo -wi-ao 15,00g

So this setup is working and boots fine here. We might want to recomend
dracut as initrd solution in case of separate usr.
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

On Sat, Feb 4, 2012 at 11:31 AM, Alexey Shvetsov <alexxy@gentoo.org> wrote:
> So this setup is working and boots fine here. We might want to recomend
> dracut as initrd solution in case of separate usr.

I think it still needs some work, but it is getting there. I
documented my own solution at:
http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/

For less-complex setups dracut as-is probably would work, but then
again, for most less-complex setups you don't need an initramfs
anyway.

In any case, it could still use more documentation, and it needs to be
integrated into any howtos that pertain to using RAID/LVM/etc, and
perhaps even the handbook (perhaps just as a warning that more exotic
partitioning schemes potentially require it). I think all that really
needs to be in place before we move any further down this road (such
as with the most recent udev versions/etc).

On the other hand, anybody who has /usr running on lvm/etc is not what
I'd consider a casual user. As long as we give them enough info to
figure things out we don't need to go overboard with the hand-holding.
Some news items to alert the user to what is coming before they go
updating udev/etc would be a bare minimum though - at least give them
a chance to burn a rescue CD or something.

Rich