[gentoo-user] InitRAMFS - boot expert sought

[gentoo-user] InitRAMFS - boot expert sought

[Helmut Jarausch]

Hi,

I've been looking for simple method to create a simple initramfs to  
just mount the /usr partition.

I've found
http://wiki.gentoo.org/wiki/Basic_initramfs_used_to_check_and_mount_/usr

which didn't work for me. So, I've modified it, see

http://www.igpm.rwth-aachen.de/jarausch/Temp/InitRAMFS/

The last lines of the file 'script_init.sh' are

# ====================== end doing stuff

mount -o remount,rw /mnt/root     ### WHY are
cp /proc/mounts /mnt/root/mtab    ### these two lines necessary

# clean up. The init process will remount proc sys and dev later
umount /proc
umount /sys
# umount /dev   # fails, since it's automounted by the kernel

# switch to the real root and execute init
exec switch_root /mnt/root /sbin/init "$@"


I first tried this with the lines marked by '###' removed.
This worked on one machine but not on another one. There I got
'Remounting root filesystem read/write failed'
'mount: / not mounted or bad option'

If I replace line 26 of /etc/init.d/root (openrc-0.9.9.3)
mount -n -o remount,rw /

by

mount /dev/root -n -o remount,rw /

it works, as well, i.e. without the two marked lines above.
The first mount command finds the mount options in /etc/mtab .
Why are the marked lines above necessary on only one of two machines
(both of which run the same version of openrc)?

Many thanks for a hint,
Helmut.

Re: [gentoo-user] InitRAMFS - boot expert sought

[Mike Edenfield]

On 3/27/2012 6:36 AM, Helmut Jarausch wrote:
> Hi,
>
> I've been looking for simple method to create a simple
> initramfs to just mount the /usr partition.
>
> I've found
> http://wiki.gentoo.org/wiki/Basic_initramfs_used_to_check_and_mount_/usr

If this is all you need, I recommend you use dracut. The 
default installation (no use-flags or optional modules) will 
product an initramfs that loads whatever you current rootfs 
and /usr partitions are.

I've been working on updating the wiki with more detailed 
instructions; for your case what's there now ought to be plenty:

http://wiki.gentoo.org/wiki/Dracut

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Tue, Mar 27, 2012 at 9:19 AM, Mike Edenfield <kutulu@kutulu.org> wrote:
> On 3/27/2012 6:36 AM, Helmut Jarausch wrote:
>>
>> Hi,
>>
>> I've been looking for simple method to create a simple
>> initramfs to just mount the /usr partition.
>>
>> I've found
>> http://wiki.gentoo.org/wiki/Basic_initramfs_used_to_check_and_mount_/usr
>
>
> If this is all you need, I recommend you use dracut. The default
> installation (no use-flags or optional modules) will product an initramfs
> that loads whatever you current rootfs and /usr partitions are.
>
> I've been working on updating the wiki with more detailed instructions; for
> your case what's there now ought to be plenty:
>
> http://wiki.gentoo.org/wiki/Dracut

Dracut is masked on ~amd64. Bugs me, as I'd rather use something like
that than genkernel (I very much like building my own kernels; it
helps me keep things lean, and keeps me familiar with the capabilities
of current and future systems). But now I have to find time to learn
how to use Genkernel.

If we're going to be shoved into tight space like this, I'd be nice if
the "you can just use $x" tools work on stable. I've got three
previously-working systems at home I can't risk rebooting right now
because of this udev+/usr nonsense. I almost invariably put /usr and
/home on top of LVM, RAID or both.

-- 
:wq

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 09:30:41 -0400, Michael Mol wrote:

> If we're going to be shoved into tight space like this, I'd be nice if
> the "you can just use $x" tools work on stable. I've got three
> previously-working systems at home I can't risk rebooting right now
> because of this udev+/usr nonsense. I almost invariably put /usr and
> /home on top of LVM, RAID or both.

Only the testing udev needs an initramfs now, so it doesn't really matter
yet. However, it would be nice if dracut were stabilised at least a week
before udev-18* to give time to play with it. It certainly needs to be
stabilised before the news announcement of udev-18* going stable.


-- 
Neil Bothwick

The horizon of many people is a circle with a radius of zero. They call
this their point of view.
		-- Albert Einstein

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[covici]

Neil Bothwick <neil@digimed.co.uk> wrote:

> On Tue, 27 Mar 2012 09:30:41 -0400, Michael Mol wrote:
> 
> > If we're going to be shoved into tight space like this, I'd be nice if
> > the "you can just use $x" tools work on stable. I've got three
> > previously-working systems at home I can't risk rebooting right now
> > because of this udev+/usr nonsense. I almost invariably put /usr and
> > /home on top of LVM, RAID or both.
> 
> Only the testing udev needs an initramfs now, so it doesn't really matter
> yet. However, it would be nice if dracut were stabilised at least a week
> before udev-18* to give time to play with it. It certainly needs to be
> stabilised before the news announcement of udev-18* going stable.
> 

With the latest genkernel, my initrd mounts /usr, however the fsck is
never done because its mounted -- any solution for this?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 11:20:44 -0400, covici@ccs.covici.com wrote:

> With the latest genkernel, my initrd mounts /usr, however the fsck is
> never done because its mounted -- any solution for this?

ISTR this coming up recently and the solution being to run fsck from the
shutdown runlevel.


-- 
Neil Bothwick

FINE: Tax for doing wrong. Tax: fine for doing fine.

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

RE: [gentoo-user] InitRAMFS - boot expert sought

[Mike Edenfield]

> > If this is all you need, I recommend you use dracut. The default
> > installation (no use-flags or optional modules) will product an
> > initramfs that loads whatever you current rootfs and /usr partitions are.
> >
> > I've been working on updating the wiki with more detailed
> > instructions; for your case what's there now ought to be plenty:
> >
> > http://wiki.gentoo.org/wiki/Dracut
> 
> Dracut is masked on ~amd64. Bugs me, as I'd rather use something like that
> than genkernel (I very much like building my own kernels; it helps me keep
> things lean, and keeps me familiar with the capabilities of current and future
> systems). But now I have to find time to learn how to use Genkernel.
> 
> If we're going to be shoved into tight space like this, I'd be nice if the "you
> can just use $x" tools work on stable. I've got three previously-working
> systems at home I can't risk rebooting right now because of this udev+/usr
> nonsense. I almost invariably put /usr and /home on top of LVM, RAID or
> both.

I'm pretty sure that a stable Dracut is a prerequisite for a stable udev-182+. Hopefully with more people taking interest in using an initramfs it will stabilize quickly. It's working for me on all of the systems I'm tried it, so I'm going to try switching a couple of servers at work over to using it. But none of them have anything particularly complex (no net boots, for example) so I don't know how much of a test case they'll be :)

--Mike

 

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mike Edenfield wrote:
>>> If this is all you need, I recommend you use dracut. The default
>>> installation (no use-flags or optional modules) will product an
>>> initramfs that loads whatever you current rootfs and /usr partitions are.
>>>
>>> I've been working on updating the wiki with more detailed
>>> instructions; for your case what's there now ought to be plenty:
>>>
>>> http://wiki.gentoo.org/wiki/Dracut
>>
>> Dracut is masked on ~amd64. Bugs me, as I'd rather use something like that
>> than genkernel (I very much like building my own kernels; it helps me keep
>> things lean, and keeps me familiar with the capabilities of current and future
>> systems). But now I have to find time to learn how to use Genkernel.
>>
>> If we're going to be shoved into tight space like this, I'd be nice if the "you
>> can just use $x" tools work on stable. I've got three previously-working
>> systems at home I can't risk rebooting right now because of this udev+/usr
>> nonsense. I almost invariably put /usr and /home on top of LVM, RAID or
>> both.
> 
> I'm pretty sure that a stable Dracut is a prerequisite for a stable udev-182+. Hopefully with more people taking interest in using an initramfs it will stabilize quickly. It's working for me on all of the systems I'm tried it, so I'm going to try switching a couple of servers at work over to using it. But none of them have anything particularly complex (no net boots, for example) so I don't know how much of a test case they'll be :)
> 
> --Mike
> 


I'm still trying to figure out why my dracut init thingy isn't working
right.  If I use the init thingy, I can't su to root from a user.  If I
don't use the init thingy, I can su just fine.  By the way, I boot the
exact same kernel either way I boot.

So, the fix doesn't seem to work for me and I have no plans of using
genkernel.

I dunno.

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"

RE: [gentoo-user] InitRAMFS - boot expert sought

[Mike Edenfield]

> From: Dale [mailto:rdalek1967@gmail.com]

> Mike Edenfield wrote:

> > I'm pretty sure that a stable Dracut is a prerequisite for a stable
> > udev-182+. Hopefully with more people taking interest in using an
> > initramfs it will stabilize quickly. It's working for me on all of the
> > systems I'm tried it, so I'm going to try switching a couple of
> > servers at work over to using it. But none of them have anything
> > particularly complex (no net boots, for example) so I don't know how
> > much of a test case they'll be :)

> I'm still trying to figure out why my dracut init thingy isn't working right.  If I
> use the init thingy, I can't su to root from a user.  If I don't use the init thingy,
> I can su just fine.  By the way, I boot the exact same kernel either way I boot.

So, just to make sure I'm understanding you here (cuz it sounds kinda crazy)

If you specify a dracut-created inittramfs in your grub.conf, your machine boots, but using 'su' to go from root -> non-root fails? 
If you remove the initrd line from grub.conf and boot the exact same kernel, 'su' works fine?
What's the error? Cuz once the pivot_root step happens and the real init is running, things in user-space should be *exactly* the same as if you had no initramfs.

--Mike

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mike Edenfield wrote:
>> From: Dale [mailto:rdalek1967@gmail.com]
> 
>> Mike Edenfield wrote:
> 
>>> I'm pretty sure that a stable Dracut is a prerequisite for a stable
>>> udev-182+. Hopefully with more people taking interest in using an
>>> initramfs it will stabilize quickly. It's working for me on all of the
>>> systems I'm tried it, so I'm going to try switching a couple of
>>> servers at work over to using it. But none of them have anything
>>> particularly complex (no net boots, for example) so I don't know how
>>> much of a test case they'll be :)
> 
>> I'm still trying to figure out why my dracut init thingy isn't working right.  If I
>> use the init thingy, I can't su to root from a user.  If I don't use the init thingy,
>> I can su just fine.  By the way, I boot the exact same kernel either way I boot.
> 
> So, just to make sure I'm understanding you here (cuz it sounds kinda crazy)
> 
> If you specify a dracut-created inittramfs in your grub.conf, your machine boots, but using 'su' to go from root -> non-root fails? 
> If you remove the initrd line from grub.conf and boot the exact same kernel, 'su' works fine?
> What's the error? Cuz once the pivot_root step happens and the real init is running, things in user-space should be *exactly* the same as if you had no initramfs.
> 
> --Mike
> 
> 
> 


The other way around.  When I boot using the init thingy, if I login as
a user, dale in this case, I can not su to root.  I think the error was
something like authentication failed or something to that effect.

I can reboot the exact same kernel but omit the init part, everything
works fine.  I even tried different kernels and it still does it.

The reason it is a issue for me is that I use Konsole within KDE to
emerge, edit config files and such.  When I use the init thingy, none of
those work.  I get a error about paths being wrong or incorrect
password.  If I reboot without the init thingy, it works fine.  I can't
find any difference other than the init thingy being used.

Weird, yea, but it sure doesn't work here.  I found me another drive the
other day.  May be trying Kubuntu here pretty soon.  This udev and /usr
crap is just getting on my nerves.  I don't have a lot of them left and
I need to save the few I do have.  At least by using something else, I
don't have to fiddle with the crap and installs to fix things are a LOT
quicker.  I mentioned this before but it is just getting closer and
closer.  First time my system fails to boot because of this mess, it's
decision time.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Sebastian Beßler]

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

On 27.03.2012 20:30, Dale wrote:
> May be trying Kubuntu here pretty soon.  

Be prepared for hard times using Kubuntu as it is now no major part of
the Ubuntu family anymore. That means much less money and much less
manpower. And if this issue with a init-thingy bothers you, Kubuntu will
be living hell. As long as (K)Ubuntu works everything is fine, but in
case of an error you just can't fix it. Everything is close tight to
everything else. Change on thing and all fails.

Greetings

Sebastian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Sebastian Beßler wrote:
> On 27.03.2012 20:30, Dale wrote:
>> May be trying Kubuntu here pretty soon.  
> 
> Be prepared for hard times using Kubuntu as it is now no major part of
> the Ubuntu family anymore. That means much less money and much less
> manpower. And if this issue with a init-thingy bothers you, Kubuntu will
> be living hell. As long as (K)Ubuntu works everything is fine, but in
> case of an error you just can't fix it. Everything is close tight to
> everything else. Change on thing and all fails.
> 
> Greetings
> 
> Sebastian
> 


Well, based on my experience with Mandrake back in the day, the init
thingy is going to break for me here just like it did there.  I'm
thinking about Kubuntu but I may actually decide on something else.
Thing is, it appears Gentoo is going to break my system so I may as well
find something that I can install lots quicker to fix what is broke.
Kubuntu is just one option.  I installed it for my brother and it works
fine, SO FAR.

I may be jumping out of the frying pan into a fire but I think I need to
at least try something else.  This is very true if I continue to have
issues with the init thingy and not being able to su to root.  I know
how to use a console but I only use it when needed.  That's not very
often and I sort of like it that way.

Barring that, I could just put everything on / and just hope nothing
goes bonkers and fills it up with useless errors or something in the
messages file.  I have had this happen before and /var was full, I mean
FULL.  I divide things so that I don't get conquered when it hits the fan.

One thing about Linux, it has a LOT of options.

Oh, there is talk of moving more things on -dev.  If I didn't know
better, I'd think someone was trying to just change Gentoo until it
doesn't work any more.  I dunno.   Maybe I'm ready for a Apple now.  o_O

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Tue, Mar 27, 2012 at 4:04 PM, Dale <rdalek1967@gmail.com> wrote:
> Sebastian Beßler wrote:
>> On 27.03.2012 20:30, Dale wrote:
>>> May be trying Kubuntu here pretty soon.
>>
>> Be prepared for hard times using Kubuntu as it is now no major part of
>> the Ubuntu family anymore. That means much less money and much less
>> manpower. And if this issue with a init-thingy bothers you, Kubuntu will
>> be living hell. As long as (K)Ubuntu works everything is fine, but in
>> case of an error you just can't fix it. Everything is close tight to
>> everything else. Change on thing and all fails.
>>
>> Greetings
>>
>> Sebastian
>>
>
>
> Well, based on my experience with Mandrake back in the day, the init
> thingy is going to break for me here just like it did there.  I'm
> thinking about Kubuntu but I may actually decide on something else.
> Thing is, it appears Gentoo is going to break my system so I may as well
> find something that I can install lots quicker to fix what is broke.
> Kubuntu is just one option.  I installed it for my brother and it works
> fine, SO FAR.
>
> I may be jumping out of the frying pan into a fire but I think I need to
> at least try something else.  This is very true if I continue to have
> issues with the init thingy and not being able to su to root.  I know
> how to use a console but I only use it when needed.  That's not very
> often and I sort of like it that way.
>
> Barring that, I could just put everything on / and just hope nothing
> goes bonkers and fills it up with useless errors or something in the
> messages file.  I have had this happen before and /var was full, I mean
> FULL.  I divide things so that I don't get conquered when it hits the fan.
>
> One thing about Linux, it has a LOT of options.
>
> Oh, there is talk of moving more things on -dev.  If I didn't know
> better, I'd think someone was trying to just change Gentoo until it
> doesn't work any more.  I dunno.   Maybe I'm ready for a Apple now.  o_O

The reason I like Gentoo (and why I've moved so much stuff to it) is
because it lets me get in and have much finer _optional_ control over
many things with minimal fuss. Ubuntu-derived distributions make it
very, very difficult to change very, very many things, while retaining
an update-stable setup. As long as you don't have to stray to far from
their One True Way, Ubuntu (or most Linux distros, actually) should be
fine. The annoying thing about Ubuntu is how their One True Way
changes dramatically every six months to a year.

-- 
:wq

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Michael Mol wrote:
> On Tue, Mar 27, 2012 at 4:04 PM, Dale <rdalek1967@gmail.com> wrote:
>> Sebastian Beßler wrote:
>>> On 27.03.2012 20:30, Dale wrote:
>>>> May be trying Kubuntu here pretty soon.
>>>
>>> Be prepared for hard times using Kubuntu as it is now no major part of
>>> the Ubuntu family anymore. That means much less money and much less
>>> manpower. And if this issue with a init-thingy bothers you, Kubuntu will
>>> be living hell. As long as (K)Ubuntu works everything is fine, but in
>>> case of an error you just can't fix it. Everything is close tight to
>>> everything else. Change on thing and all fails.
>>>
>>> Greetings
>>>
>>> Sebastian
>>>
>>
>>
>> Well, based on my experience with Mandrake back in the day, the init
>> thingy is going to break for me here just like it did there.  I'm
>> thinking about Kubuntu but I may actually decide on something else.
>> Thing is, it appears Gentoo is going to break my system so I may as well
>> find something that I can install lots quicker to fix what is broke.
>> Kubuntu is just one option.  I installed it for my brother and it works
>> fine, SO FAR.
>>
>> I may be jumping out of the frying pan into a fire but I think I need to
>> at least try something else.  This is very true if I continue to have
>> issues with the init thingy and not being able to su to root.  I know
>> how to use a console but I only use it when needed.  That's not very
>> often and I sort of like it that way.
>>
>> Barring that, I could just put everything on / and just hope nothing
>> goes bonkers and fills it up with useless errors or something in the
>> messages file.  I have had this happen before and /var was full, I mean
>> FULL.  I divide things so that I don't get conquered when it hits the fan.
>>
>> One thing about Linux, it has a LOT of options.
>>
>> Oh, there is talk of moving more things on -dev.  If I didn't know
>> better, I'd think someone was trying to just change Gentoo until it
>> doesn't work any more.  I dunno.   Maybe I'm ready for a Apple now.  o_O
> 
> The reason I like Gentoo (and why I've moved so much stuff to it) is
> because it lets me get in and have much finer _optional_ control over
> many things with minimal fuss. Ubuntu-derived distributions make it
> very, very difficult to change very, very many things, while retaining
> an update-stable setup. As long as you don't have to stray to far from
> their One True Way, Ubuntu (or most Linux distros, actually) should be
> fine. The annoying thing about Ubuntu is how their One True Way
> changes dramatically every six months to a year.
> 


I like, even love, Gentoo.  Thing is, if it gets to where it doesn't
work like it should for me, there's no point in me using it.  If I
wanted a OS that doesn't work well for me, I'd be buying M$'s crap.
Hey, it does install fairly fast but it is pretty crappy.  LOL

I have said this about meeting a new lady, time tells.  If I get to the
point where I have to use a init thingy and I can't get one to work,
Gentoo is no longer for me.  Working is a must have thing for my OS.  I
don't mind putting in the effort to have a great install or putting in
the effort to update it but it has to boot and work.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Mark Knecht]

On Tue, Mar 27, 2012 at 1:46 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
> I like, even love, Gentoo.  Thing is, if it gets to where it doesn't
> work like it should for me, there's no point in me using it.  If I
> wanted a OS that doesn't work well for me, I'd be buying M$'s crap.
> Hey, it does install fairly fast but it is pretty crappy.  LOL
>

What? Me worry?

Chill Dale. The Gentoo devs will get it there.

And what will you do if Ubuntu doesn't boot? Learn another distro? Nahh... ;-)

- Mark

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mark Knecht wrote:
> On Tue, Mar 27, 2012 at 1:46 PM, Dale <rdalek1967@gmail.com> wrote:
> <SNIP>
>> I like, even love, Gentoo.  Thing is, if it gets to where it doesn't
>> work like it should for me, there's no point in me using it.  If I
>> wanted a OS that doesn't work well for me, I'd be buying M$'s crap.
>> Hey, it does install fairly fast but it is pretty crappy.  LOL
>>
> 
> What? Me worry?
> 
> Chill Dale. The Gentoo devs will get it there.
> 
> And what will you do if Ubuntu doesn't boot? Learn another distro? Nahh... ;-)
> 
> - Mark
> 
> 


That's why I want something that I can install fast.  Gentoo certainly
isn't the right choice for that.  If Kubuntu fails, I can just reinstall
and not format /home.  It doesn't take to long and I'll be back up and
running.  I already keep a fairly up to date sysrescue so having
something for some other distro wouldn't be a huge issue.

Right now, if Gentoo fails to boot because of the init thingy, I have no
idea how to fix it.  None at all.  I know the basics of what it does but
no idea how to fix it when it breaks.  That's where I am now with regard
to my other post.  I can't su to root when using the init thingy but can
when I don't use the init thingy.  I have no clue where to even start to
fix it.  Is it dracut itself?  Is it some script?  Is it some option I
gave it that conflicts with something else?  I have absolutely no idea
why but I know it has something to do with me using the init thingy
since it works fine without it.

Me clueless since this is something I tried to avoid in the past and not
sure why it is needed now either.

More questions than answers for sure.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Tue, 27 Mar 2012 16:43:38 -0500
Dale <rdalek1967@gmail.com> wrote:

> Mark Knecht wrote:
> > On Tue, Mar 27, 2012 at 1:46 PM, Dale <rdalek1967@gmail.com> wrote:
> > <SNIP>
> >> I like, even love, Gentoo.  Thing is, if it gets to where it
> >> doesn't work like it should for me, there's no point in me using
> >> it.  If I wanted a OS that doesn't work well for me, I'd be buying
> >> M$'s crap. Hey, it does install fairly fast but it is pretty
> >> crappy.  LOL
> >>
> > 
> > What? Me worry?
> > 
> > Chill Dale. The Gentoo devs will get it there.
> > 
> > And what will you do if Ubuntu doesn't boot? Learn another distro?
> > Nahh... ;-)
> > 
> > - Mark
> > 
> > 
> 
> 
> That's why I want something that I can install fast.  Gentoo certainly
> isn't the right choice for that.  If Kubuntu fails, I can just
> reinstall and not format /home.  It doesn't take to long and I'll be
> back up and running.  I already keep a fairly up to date sysrescue so
> having something for some other distro wouldn't be a huge issue.

See this mountain peak you think you see in front of you? The one you
call Everest?

You got it wrong about that mountain Dale. It's a little mole hill in
the back yard.

Make / big enough to contain /usr as well. Move stuff over and delete
the /usr partition.

Everything you fear about udev instantly ceases to exist and is no
longer a problem. Sorted.





> 
> Right now, if Gentoo fails to boot because of the init thingy, I have
> no idea how to fix it.  None at all.  I know the basics of what it
> does but no idea how to fix it when it breaks.  That's where I am now
> with regard to my other post.  I can't su to root when using the init
> thingy but can when I don't use the init thingy.  I have no clue
> where to even start to fix it.  Is it dracut itself?  Is it some
> script?  Is it some option I gave it that conflicts with something
> else?  I have absolutely no idea why but I know it has something to
> do with me using the init thingy since it works fine without it.
> 
> Me clueless since this is something I tried to avoid in the past and
> not sure why it is needed now either.
> 
> More questions than answers for sure.
> 
> Dale
> 
> :-)  :-)
> 



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Alan McKinnon wrote:
> On Tue, 27 Mar 2012 16:43:38 -0500
> Dale <rdalek1967@gmail.com> wrote:
> 
>> Mark Knecht wrote:
>>> On Tue, Mar 27, 2012 at 1:46 PM, Dale <rdalek1967@gmail.com> wrote:
>>> <SNIP>
>>>> I like, even love, Gentoo.  Thing is, if it gets to where it
>>>> doesn't work like it should for me, there's no point in me using
>>>> it.  If I wanted a OS that doesn't work well for me, I'd be buying
>>>> M$'s crap. Hey, it does install fairly fast but it is pretty
>>>> crappy.  LOL
>>>>
>>>
>>> What? Me worry?
>>>
>>> Chill Dale. The Gentoo devs will get it there.
>>>
>>> And what will you do if Ubuntu doesn't boot? Learn another distro?
>>> Nahh... ;-)
>>>
>>> - Mark
>>>
>>>
>>
>>
>> That's why I want something that I can install fast.  Gentoo certainly
>> isn't the right choice for that.  If Kubuntu fails, I can just
>> reinstall and not format /home.  It doesn't take to long and I'll be
>> back up and running.  I already keep a fairly up to date sysrescue so
>> having something for some other distro wouldn't be a huge issue.
> 
> See this mountain peak you think you see in front of you? The one you
> call Everest?
> 
> You got it wrong about that mountain Dale. It's a little mole hill in
> the back yard.
> 
> Make / big enough to contain /usr as well. Move stuff over and delete
> the /usr partition.
> 
> Everything you fear about udev instantly ceases to exist and is no
> longer a problem. Sorted.
> 
> 

But what about using LVM?  People was all for me using it a while back
and I want to use it, see other post, but now because of this, I'm not
supposed to.

Look left, look right, look left, look right.  Get the idea?  ROFL

Dale

:-)  :-)

Re: [gentoo-user] InitRAMFS - boot expert sought

[David W Noon]

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

On Tue, 27 Mar 2012 17:28:17 -0500, Dale wrote about Re: [gentoo-user]
InitRAMFS - boot expert sought:

> Alan McKinnon wrote:
[snip]
>> Everything you fear about udev instantly ceases to exist and is no
>> longer a problem. Sorted.

And /var ??

> But what about using LVM?  People was all for me using it a while back
> and I want to use it, see other post, but now because of this, I'm not
> supposed to.

I promised you (plural) an easy initramfs solution a few months back.

I have an initramfs image of 1.6MiB that supports LVM and
mounts /usr, /var and any other LVM volume or partition you wish.  I
have been able to boot with it since about January (hardware issues on
my development box permitting).  I will release a Python script to
build it from a single command in the next 10 days or 2 weeks.  The
real chore will be writing the documentation (as with most software
development efforts).

For me, the best part is its diminutive size, as my /boot partitions
are only 32MiB each.  The fact that it works every time should make you
feel secure against whatever the udev developers can throw at us.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

David W Noon wrote:
> On Tue, 27 Mar 2012 17:28:17 -0500, Dale wrote about Re: [gentoo-user]
> InitRAMFS - boot expert sought:
> 
>> Alan McKinnon wrote:
> [snip]
>>> Everything you fear about udev instantly ceases to exist and is no
>>> longer a problem. Sorted.
> 
> And /var ??
> 
>> But what about using LVM?  People was all for me using it a while back
>> and I want to use it, see other post, but now because of this, I'm not
>> supposed to.
> 
> I promised you (plural) an easy initramfs solution a few months back.
> 
> I have an initramfs image of 1.6MiB that supports LVM and
> mounts /usr, /var and any other LVM volume or partition you wish.  I
> have been able to boot with it since about January (hardware issues on
> my development box permitting).  I will release a Python script to
> build it from a single command in the next 10 days or 2 weeks.  The
> real chore will be writing the documentation (as with most software
> development efforts).
> 
> For me, the best part is its diminutive size, as my /boot partitions
> are only 32MiB each.  The fact that it works every time should make you
> feel secure against whatever the udev developers can throw at us.


The reason I want to use dracut is because that is what is supposed to
be supported by Gentoo.  I also read where others have used it with no
problems.  I was also hoping to learn how it works, or is supposed to
work, so that if something happens I can figure out a fix for it.  So
far, I broke it.  lol

I know genkernel is another approach but I just learned to hate that a
long time ago.  While not as bad as hal, it's a close second.

I might also add, mine does boot, it's just that the system doesn't work
right when I do boot with it.  From what I understand, it doesn't make
sense as to why it doesn't work.  In a way what it does is really
simple.  Mount /, then mount /usr and whatever else, then switch to the
new / and boot.  I have no idea why that makes me unable to su to root.
 From what I have read, once it does the switch root thing, it's done
and should work the same.

Well, I'm going to go have a good soak in the tub on this mess.  Sooth
my nerves a bit.  :/

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Wed, 28 Mar 2012 01:20:23 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> On Tue, 27 Mar 2012 17:28:17 -0500, Dale wrote about Re: [gentoo-user]
> InitRAMFS - boot expert sought:
> 
> > Alan McKinnon wrote:
> [snip]
> >> Everything you fear about udev instantly ceases to exist and is no
> >> longer a problem. Sorted.
> 
> And /var ??

What about /var?

The thread is about initramfs and putting /usr onto the / volume to get
around early-boot prolems.

Surely you do not need the content of /var during early boot?


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[David W Noon]

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

On Wed, 28 Mar 2012 23:40:27 +0200, Alan McKinnon wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:

> On Wed, 28 Mar 2012 01:20:23 +0100
> David W Noon <dwnoon@ntlworld.com> wrote:
> 
> > On Tue, 27 Mar 2012 17:28:17 -0500, Dale wrote about Re:
> > [gentoo-user] InitRAMFS - boot expert sought:
> > 
> > > Alan McKinnon wrote:
> > [snip]
> > >> Everything you fear about udev instantly ceases to exist and is
> > >> no longer a problem. Sorted.
> > 
> > And /var ??
> 
> What about /var?
> 
> The thread is about initramfs and putting /usr onto the / volume to
> get around early-boot prolems.
> 
> Surely you do not need the content of /var during early boot?

With the pending changes to udev scripts, you could well need /var --
and anything else -- before udev starts.  So it is in the same category
as /usr.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Wed, 28 Mar 2012 23:01:24 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> On Wed, 28 Mar 2012 23:40:27 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
> 
> > On Wed, 28 Mar 2012 01:20:23 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
> > 
> > > On Tue, 27 Mar 2012 17:28:17 -0500, Dale wrote about Re:
> > > [gentoo-user] InitRAMFS - boot expert sought:
> > > 
> > > > Alan McKinnon wrote:
> > > [snip]
> > > >> Everything you fear about udev instantly ceases to exist and is
> > > >> no longer a problem. Sorted.
> > > 
> > > And /var ??
> > 
> > What about /var?
> > 
> > The thread is about initramfs and putting /usr onto the / volume to
> > get around early-boot prolems.
> > 
> > Surely you do not need the content of /var during early boot?
> 
> With the pending changes to udev scripts, you could well need /var --
> and anything else -- before udev starts.  So it is in the same
> category as /usr.

Maybe, maybe not.

However, no-one apart from you is even suggesting such a thing. For my
part I'm going to ignore that possibility and concentrate on those
things that are being seriously suggested.



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[David W Noon]

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

On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:

> On Wed, 28 Mar 2012 23:01:24 +0100
> David W Noon <dwnoon@ntlworld.com> wrote:
[snip]
> > With the pending changes to udev scripts, you could well need /var
> > -- and anything else -- before udev starts.  So it is in the same
> > category as /usr.
> 
> Maybe, maybe not.
> 
> However, no-one apart from you is even suggesting such a thing. For my
> part I'm going to ignore that possibility and concentrate on those
> things that are being seriously suggested.

The Gentoo developers have been discussing just that.  The reason is
that many of the daemons that can be started by udev scripts require
work files on /var, so we could well need /var mounted too.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

David W Noon wrote:
> On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
> 
>> On Wed, 28 Mar 2012 23:01:24 +0100
>> David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
>>> With the pending changes to udev scripts, you could well need /var
>>> -- and anything else -- before udev starts.  So it is in the same
>>> category as /usr.
>>
>> Maybe, maybe not.
>>
>> However, no-one apart from you is even suggesting such a thing. For my
>> part I'm going to ignore that possibility and concentrate on those
>> things that are being seriously suggested.
> 
> The Gentoo developers have been discussing just that.  The reason is
> that many of the daemons that can be started by udev scripts require
> work files on /var, so we could well need /var mounted too.


Yep.  I notice my LVM starts twice.  It fails the first time because it
can't find files in /var then tries again later on after everything is
mounted, except the LVM stuff of course.  So, this is most likely coming
and is one reason I am considering different options.

This is also another reason I want to get some sort of init thingy
working.  I already have /var on its own regular partition but also want
/usr and /var on LVM.  Right now, that could cause a problem since LVM
looks to have issues coming up without /var being mounted.

Luckily for me, I only have a data partition that contains video files
on LVM.  It has nothing to do with the OS itself.

That is one reason this is causing me concerns.  It's not just what is
already getting screwed up but also what is about to get screwed up that
makes it even worse.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Thu, 29 Mar 2012 00:20:04 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
> 
> > On Wed, 28 Mar 2012 23:01:24 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
> > > With the pending changes to udev scripts, you could well need /var
> > > -- and anything else -- before udev starts.  So it is in the same
> > > category as /usr.
> > 
> > Maybe, maybe not.
> > 
> > However, no-one apart from you is even suggesting such a thing. For
> > my part I'm going to ignore that possibility and concentrate on
> > those things that are being seriously suggested.
> 
> The Gentoo developers have been discussing just that.  The reason is
> that many of the daemons that can be started by udev scripts require
> work files on /var, so we could well need /var mounted too.

Which begs the obvious question,

Why on earth is udev launching daemons in EARLY BOOT?

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[David W Noon]

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

On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:

> On Thu, 29 Mar 2012 00:20:04 +0100
> David W Noon <dwnoon@ntlworld.com> wrote:
[snip]
> > The Gentoo developers have been discussing just that.  The reason is
> > that many of the daemons that can be started by udev scripts require
> > work files on /var, so we could well need /var mounted too.
> 
> Which begs the obvious question,
> 
> Why on earth is udev launching daemons in EARLY BOOT?

Your guess is as good as mine!

At present, the first thing I see when udev starts is a failed attempt
to run /usr/sbin/alsactl to restore the audio levels on my sound card.
This occurs before localmount or any other services in the sysinit
run-level have been started.  Just why anybody wants sound before the
disk volumes have been mounted baffles me; I guess people are just
desperate for the comforts of stereo.  Perhaps my mind simply lacks the
sophistication to understand the design of udev.

I guess I'll just stick to my 80-column Hollerith cards.  ... :-)
-- 
Regards,

Dave  [RLU #314465]
======================================================================
dwnoon@ntlworld.com (David W Noon)
======================================================================

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Thu, 29 Mar 2012 13:01:49 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
> 
> > On Thu, 29 Mar 2012 00:20:04 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
> > > The Gentoo developers have been discussing just that.  The reason
> > > is that many of the daemons that can be started by udev scripts
> > > require work files on /var, so we could well need /var mounted
> > > too.
> > 
> > Which begs the obvious question,
> > 
> > Why on earth is udev launching daemons in EARLY BOOT?
> 
> Your guess is as good as mine!
> 
> At present, the first thing I see when udev starts is a failed attempt
> to run /usr/sbin/alsactl to restore the audio levels on my sound card.
> This occurs before localmount or any other services in the sysinit
> run-level have been started.  Just why anybody wants sound before the
> disk volumes have been mounted baffles me; I guess people are just
> desperate for the comforts of stereo.  

Perhaps the ability to hear the computer go "bing" when volumes
mount is a killer marketing feature....

Reminds me of Sigourney Weaver's character in Galaxy Quest - she was
the bimbo who announced to the room whenever the computer went bing


> Perhaps my mind simply lacks
> the sophistication to understand the design of udev.
> 
> I guess I'll just stick to my 80-column Hollerith cards.  ... :-)



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[pk]

On 2012-03-29 22:58, Alan McKinnon wrote:

> Reminds me of Sigourney Weaver's character in Galaxy Quest - she was
> the bimbo who announced to the room whenever the computer went bing

:-D

An underrated movie which contains a lot of geek and "Star Trek"/"SciFi
in general" parody... Thumbs up! :-D

Best regards

Peter K

Re: [gentoo-user] InitRAMFS - boot expert sought

[Frank Steinmetzger]

On Thu, Mar 29, 2012 at 10:58:18PM +0200, Alan McKinnon wrote:

Sorry for necro-posting, but I wanted to “add my mustard”, as we say over
here.

> > > Why on earth is udev launching daemons in EARLY BOOT?
> > 
> > Your guess is as good as mine!
> > […]
> 
> Perhaps the ability to hear the computer go "bing" when volumes
> mount is a killer marketing feature....
> 
> Reminds me of Sigourney Weaver's character in Galaxy Quest - she was
> the bimbo who announced to the room whenever the computer went bing

Her character was the personification of GNU (from memory): “I only have one
job on this damn ship. It is stupid, but I do it.“ And she does it well. :-)

-- 
Gruß | Greetings | Qapla'
Please do not share anything from, with or about me with any Facebook service.

Give me your passport, and I tell you who you are.

Re: [gentoo-user] InitRAMFS - boot expert sought

[wdk@moriah]

On 29/03/2012, at 20:01, David W Noon <dwnoon@ntlworld.com> wrote:

> On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
> 
>> On Thu, 29 Mar 2012 00:20:04 +0100
>> David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
>>> The Gentoo developers have been discussing just that.  The reason is
>>> that many of the daemons that can be started by udev scripts require
>>> work files on /var, so we could well need /var mounted too.
>> 
>> Which begs the obvious question,
>> 
>> Why on earth is udev launching daemons in EARLY BOOT?
> 
> Your guess is as good as mine!
> 
> At present, the first thing I see when udev starts is a failed attempt
> to run /usr/sbin/alsactl to restore the audio levels on my sound card.
> This occurs before localmount or any other services in the sysinit
> run-level have been started.  Just why anybody wants sound before the
> disk volumes have been mounted baffles me; I guess people are just
> desperate for the comforts of stereo.  Perhaps my mind simply lacks the
> sophistication to understand the design of udev.
> 
> I guess I'll just stick to my 80-column Hollerith cards.  ... :-)
> -- 
> Regards,
> 
> Dave  [RLU #314465]
> ======================================================================
> dwnoon@ntlworld.com (David W Noon)
> ======================================================================

that error was what clued me up to genkernels initramfs failing to mount /usr - the mount failure wasnt on screen long enough to see ...

error reporting for the initramfs method needs fixing so users can faultfind problems more easily.  flashing something on screen for a second and immediately pushing it offscreen doesnt count when there is lo logging to dmesg etc.

par for the course - run an initramfs (complexity) means more WILL go wrong so ways to fix it for normal users need to be in place..

BillK

Re: [gentoo-user] InitRAMFS - boot expert sought

[David W Noon]

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

On Fri, 30 Mar 2012 07:26:43 +0800, wdk@moriah wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:

> On 29/03/2012, at 20:01, David W Noon <dwnoon@ntlworld.com> wrote:
[snip]
> > At present, the first thing I see when udev starts is a failed
> > attempt to run /usr/sbin/alsactl to restore the audio levels on my
> > sound card. This occurs before localmount or any other services in
> > the sysinit run-level have been started.
[snip]
> that error was what clued me up to genkernels initramfs failing to
> mount /usr - the mount failure wasnt on screen long enough to see ...
> 
> error reporting for the initramfs method needs fixing so users can
> faultfind problems more easily.  flashing something on screen for a
> second and immediately pushing it offscreen doesnt count when there
> is lo logging to dmesg etc.

The machine in question is not currently running an initramfs.  This
one reason why the udev developers believe that having /usr physically
separate from / is "broken".

No error messages from udev or any of its scripts are logged.  Perhaps
dmesg logging is "broken" too.

> par for the course - run an initramfs (complexity) means more WILL go
> wrong so ways to fix it for normal users need to be in place..

Yes, it is a chore, debugging an initramfs.
-- 
Regards,

Dave  [RLU #314465]
======================================================================
dwnoon@ntlworld.com (David W Noon)
======================================================================

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

[gentoo-user] Re: InitRAMFS - boot expert sought

[Nicolas Sebrecht]

The 29/03/12, Alan McKinnon wrote:
> On Thu, 29 Mar 2012 00:20:04 +0100
> David W Noon <dwnoon@ntlworld.com> wrote:

> > The Gentoo developers have been discussing just that.  The reason is
> > that many of the daemons that can be started by udev scripts require
> > work files on /var, so we could well need /var mounted too.
> 
> Which begs the obvious question,
> 
> Why on earth is udev launching daemons in EARLY BOOT?

udev launches nothing. udev scripts do. These scripts are not part of
udev.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Thu, 29 Mar 2012 14:05:30 +0200, Nicolas Sebrecht wrote:

> > Why on earth is udev launching daemons in EARLY BOOT?  
> 
> udev launches nothing. udev scripts do. These scripts are not part of
> udev.

That is true, but udev provides no control over when these scripts are
run. udev starts in early boot, because /some/ of its function is needed
then, and it then tries to run rules for all detected hardware. This is a
flaw in udev.


-- 
Neil Bothwick

In possession of a mind not merely twisted, but actually sprained.

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

Re: [gentoo-user] Re: InitRAMFS - boot expert sought

[Alan McKinnon]

On Thu, 29 Mar 2012 14:05:30 +0200
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> The 29/03/12, Alan McKinnon wrote:
> > On Thu, 29 Mar 2012 00:20:04 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
> 
> > > The Gentoo developers have been discussing just that.  The reason
> > > is that many of the daemons that can be started by udev scripts
> > > require work files on /var, so we could well need /var mounted
> > > too.
> > 
> > Which begs the obvious question,
> > 
> > Why on earth is udev launching daemons in EARLY BOOT?
> 
> udev launches nothing. udev scripts do. These scripts are not part of
> udev.
> 

OK, semantics. Let me re-phrase:

Why is a third party script, running in the context of the udev
universe, indiscriminately allowed to launch daemons at early boot
time?

I don't think I agree with Neil in that this is a udev design flaw (as
any "fix" will be worse than the "flaw"). Instead it looks to me like
a classic case of

"You are free to do anything you want but if you break it you keep the
pieces. If you do something stupid, it's not my problem and you're on
your own."

I see nothing wrong with udev applying some reasonable constraints such
as clearly documenting at what point in the boot process udev is in a
position to arbitrarily run anything. Earlier than that point,
"anything" does not actually apply.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

RE: [gentoo-user] Re: InitRAMFS - boot expert sought

[Mike Edenfield]

> From: Alan McKinnon [mailto:alan.mckinnon@gmail.com]

> OK, semantics. Let me re-phrase:
> 
> Why is a third party script, running in the context of the udev universe,
> indiscriminately allowed to launch daemons at early boot time?
> 
> I don't think I agree with Neil in that this is a udev design flaw (as any
"fix" will
> be worse than the "flaw"). Instead it looks to me like a classic case of
> 
> "You are free to do anything you want but if you break it you keep the
> pieces. If you do something stupid, it's not my problem and you're on your
> own."

This is, unfortunately, the biggest drawback to having a commercial entity
in charge of doing the software development: this kind of attitude stops
applying. Gentoo's developers, for example, would really like for people to
use Gentoo, and work hard to make Gentoo useable, but if you start with the
threats of "I'm gonna stop using your OS unless you fix this RIGHT NOW!"
they'll probably just roll their eyes and ignore you. RedHat has a
*commercial* interest in people using RedHat, even the non-commercial
versions, and if their *customers* start filing bugs like "I cannot make my
Bluetooth keyboard work with my nfs mounted /usr that plays a ring tone
through alsa when I mount it", they are much more motivated to fix it.

> I see nothing wrong with udev applying some reasonable constraints such as
> clearly documenting at what point in the boot process udev is in a
position to
> arbitrarily run anything. Earlier than that point, "anything" does not
actually
> apply.

I don't think it's a design flaw, as much as it's a possible point of
improvement for udev. It would be useful if udev could somehow distinguish
between "early" and "late" devices. This doesn't eliminate the problem
entirely: nothing is stopping you from, say, telling udev that mounting /usr
requires /usr/mountme. But if you did something that silly, it would
obviously be your fault.

I think there are some options for how udev could be better here, it's just
that they all seem to be a lot of risk; as much risk or more as just saying
"don't do that or use an initramfs." Off the top of my head:

* udev could enforce that point you mention, and allow device scripts to
explicitly say "defer trying to configure me until after $KEYPOINT has been
reached."
* udev could keep track of dependencies between devices or device scripts
and allow one to say "don't run me until $DEVICE is also present"
* udev could keep track of prerequisite triggers for device scripts, and
allow one to say "don't run me until /usr/bin/alsaconf exists, but run me as
soon as that appears."
* udev could keep track of failed devices, and include a command-line switch
like --reprocess; the init process could launch udev, allow whatever fails
to fail, mount /usr, then tell udev to try again.

As I understand it, the architecture of udev (and the kernel) makes many of
these difficult; udev events are processed individually, isolated from each
other. It has no concept of things like "when I'm done configuring devices"
or "devices that are waiting to be configured after this one". Though
keeping track of failed devices seems like it would not be terribly
difficult, as long as you could distinguish btween devices that are fatal
failures vs. transient ones.

Again, I'm not faulting the udev team for not doing those things. They
either do a lot of work to update the behavior of udev to support a
configuration they think is invalid and broken, or they simply tell people
to stop using the invalid or broken configuration. If there were a clear
consensus that the configuration was not, in fact, broken, then I could
possibly see where they might be expected (from a /community/ perspective,
clearly they have no /formal/ obligations to any of us) to put in that
effort. But the consensus seems largely weighted towards agreeing with them,
or at least not caring either way.

--Mike

Re: [gentoo-user] Re: InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Thu, 29 Mar 2012 22:55:42 +0200, Alan McKinnon wrote:

> I don't think I agree with Neil in that this is a udev design flaw (as
> any "fix" will be worse than the "flaw"). Instead it looks to me like
> a classic case of
> 
> "You are free to do anything you want but if you break it you keep the
> pieces. If you do something stupid, it's not my problem and you're on
> your own."
> 
> I see nothing wrong with udev applying some reasonable constraints such
> as clearly documenting at what point in the boot process udev is in a
> position to arbitrarily run anything. Earlier than that point,
> "anything" does not actually apply.

The reason I think it is a flaw is that udev is capable of doing some
very clever stuff with nothing more than a simple device rule, but such
clever stuff has no place in early boot. On the other hand, it also does
basic stuff, like creating device nodes, that certainly does belong in
early boot. The problem is that udev provides no way to distinguish
between the early boot essentials and the clever stuff.

Only a small subset of its work should be done when it is first started,
possibly by tagging those rules, or simply postponing any rules with a
RUN command. Or maybe a separate command (or invocation of the same
command) that just creates device nodes, and any specified symlinks, much
like mdev does, then kick in the full version later.

However, as I type this, I can think of all sorts of arguments about what
should be run early and what not. I'm beginning to understand why the
devs decided "if you want all this clever stuff, you'll just have to
make /usr available".


-- 
Neil Bothwick

Windows Error:01F Reserved for future mistakes.

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Doug Hunley]

On Wed, Mar 28, 2012 at 19:20, David W Noon <dwnoon@ntlworld.com> wrote:
> On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
>
>> On Wed, 28 Mar 2012 23:01:24 +0100
>> David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
>> > With the pending changes to udev scripts, you could well need /var
>> > -- and anything else -- before udev starts.  So it is in the same
>> > category as /usr.
>>
>> Maybe, maybe not.
>>
>> However, no-one apart from you is even suggesting such a thing. For my
>> part I'm going to ignore that possibility and concentrate on those
>> things that are being seriously suggested.
>
> The Gentoo developers have been discussing just that.  The reason is
> that many of the daemons that can be started by udev scripts require
> work files on /var, so we could well need /var mounted too.

But wait, that's what having /var/run being a link to /run was all
about. This problem is supposed to be *solved* already, damnit
-- 
Douglas J Hunley (doug.hunley@gmail.com)
Twitter: @hunleyd                                               Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

Re: [gentoo-user] InitRAMFS - boot expert sought

[David W Noon]

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

On Thu, 29 Mar 2012 10:08:40 -0400, Doug Hunley wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:

> On Wed, Mar 28, 2012 at 19:20, David W Noon <dwnoon@ntlworld.com>
> wrote:
[snip]
> > The Gentoo developers have been discussing just that.  The reason is
> > that many of the daemons that can be started by udev scripts require
> > work files on /var, so we could well need /var mounted too.
> 
> But wait, that's what having /var/run being a link to /run was all
> about. This problem is supposed to be *solved* already, damnit

That's okay for PID files, but udev scripts are supposed to be allowed
to run *anything*.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Mark Knecht]

On Tue, Mar 27, 2012 at 2:43 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
>
> Right now, if Gentoo fails to boot because of the init thingy, I have no
> idea how to fix it.  None at all.

I understand. My question is why are you even using the initrd?
There's no requirement to use it today, at least on stable. There's
not even a discussion I've seen that says we _ever_ have to use it if
we don't use a separate /usr, so I'm not understanding where the
problem is.

This is just my 2 cents, but assuming you have a lot of disk space why
not do a second Gentoo install, use initrd there to learn about it,
and just STOP doing updates to your current environment. If you don't
update it then it's not going to fail due to an update, right?

I'm not picking on you or anything like that. It just seems to me that
you're worrying about the worst instead of doing the easiest. Let's
let the heavy lifters do some work, watch people get through it, and
only then decide what to do. No reason to cause problems with our
systems. I've masked a few packages and am being careful about
updates.

Good luck,
Mark

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mark Knecht wrote:
> On Tue, Mar 27, 2012 at 2:43 PM, Dale <rdalek1967@gmail.com> wrote:
> <SNIP>
>>
>> Right now, if Gentoo fails to boot because of the init thingy, I have no
>> idea how to fix it.  None at all.
> 
> I understand. My question is why are you even using the initrd?
> There's no requirement to use it today, at least on stable. There's
> not even a discussion I've seen that says we _ever_ have to use it if
> we don't use a separate /usr, so I'm not understanding where the
> problem is.
> 
> This is just my 2 cents, but assuming you have a lot of disk space why
> not do a second Gentoo install, use initrd there to learn about it,
> and just STOP doing updates to your current environment. If you don't
> update it then it's not going to fail due to an update, right?
> 
> I'm not picking on you or anything like that. It just seems to me that
> you're worrying about the worst instead of doing the easiest. Let's
> let the heavy lifters do some work, watch people get through it, and
> only then decide what to do. No reason to cause problems with our
> systems. I've masked a few packages and am being careful about
> updates.
> 
> Good luck,
> Mark
> 
> 


Right now it won't be a problem but when I get my set up like I want it,
it will be.  I'm trying to learn it on a system that doesn't care right
now.  As posted elsewhere, if I boot with the init thingy then I can't
su to root.  My solution right now was to boot without the init thingy.
 However, if I get to where I can set up my system like I want, that
would be a problem for me.  This is holding me back from doing several
things on my system and one of them is using LVM for everything but /
and /boot.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Mark Knecht]

On Tue, Mar 27, 2012 at 3:35 PM, Dale <rdalek1967@gmail.com> wrote:
> Mark Knecht wrote:
>> On Tue, Mar 27, 2012 at 2:43 PM, Dale <rdalek1967@gmail.com> wrote:
>> <SNIP>
>>>
>>> Right now, if Gentoo fails to boot because of the init thingy, I have no
>>> idea how to fix it.  None at all.
>>
>> I understand. My question is why are you even using the initrd?
>> There's no requirement to use it today, at least on stable. There's
>> not even a discussion I've seen that says we _ever_ have to use it if
>> we don't use a separate /usr, so I'm not understanding where the
>> problem is.
>>
>> This is just my 2 cents, but assuming you have a lot of disk space why
>> not do a second Gentoo install, use initrd there to learn about it,
>> and just STOP doing updates to your current environment. If you don't
>> update it then it's not going to fail due to an update, right?
>>
>> I'm not picking on you or anything like that. It just seems to me that
>> you're worrying about the worst instead of doing the easiest. Let's
>> let the heavy lifters do some work, watch people get through it, and
>> only then decide what to do. No reason to cause problems with our
>> systems. I've masked a few packages and am being careful about
>> updates.
>>
>> Good luck,
>> Mark
>>
>>
>
>
> Right now it won't be a problem but when I get my set up like I want it,
> it will be.  I'm trying to learn it on a system that doesn't care right
> now.  As posted elsewhere, if I boot with the init thingy then I can't
> su to root.  My solution right now was to boot without the init thingy.
>  However, if I get to where I can set up my system like I want, that
> would be a problem for me.  This is holding me back from doing several
> things on my system and one of them is using LVM for everything but /
> and /boot.
>
> Dale

I understand. Like they say 'in war all the plans change when you fire
the first bullet'. Just make new plans. Do the easy thing for awhile.
Do nothing. Just read, watch, learn but most important don't do
updates. Just wait. Patience is a virtue!

Cheers,
Mark

Re: [gentoo-user] InitRAMFS - boot expert sought

[J. Roeleveld]

On Wed, March 28, 2012 12:49 am, Mark Knecht wrote:

<snipped>

> Do nothing. Just read, watch, learn but most important don't do
> updates. Just wait. Patience is a virtue!

I wonder how many threads we'll get with "I haven't updated my Gentoo for
over a year, how do I best do the upgrade?" from people following this
advice?

--
Joost

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

J. Roeleveld wrote:
> 
> On Wed, March 28, 2012 12:49 am, Mark Knecht wrote:
> 
> <snipped>
> 
>> Do nothing. Just read, watch, learn but most important don't do
>> updates. Just wait. Patience is a virtue!
> 
> I wonder how many threads we'll get with "I haven't updated my Gentoo for
> over a year, how do I best do the upgrade?" from people following this
> advice?
> 
> --
> Joost
> 
> 
> 


I was thinking about that.  My system works right now.  I could just not
update for a good long while before doing any updates.  Maybe the udev
dev will do like the hal guy, admit he screwed up and fix it so that it
runs as it should and leave it like it used to be.

Also, it is getting warm here.  I don't need the extra heat from
compiling anyway.  ;-)

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"

[gentoo-user] Re: InitRAMFS - boot expert sought

[Nicolas Sebrecht]

The 29/03/12, J. Roeleveld wrote:
> 
> On Wed, March 28, 2012 12:49 am, Mark Knecht wrote:
> 
> <snipped>
> 
> > Do nothing. Just read, watch, learn but most important don't do
> > updates. Just wait. Patience is a virtue!
> 
> I wonder how many threads we'll get with "I haven't updated my Gentoo for
> over a year, how do I best do the upgrade?" from people following this
> advice?

I think there is a better thing to do. Use an initramfs.

This is not hell! ;-)

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: InitRAMFS - boot expert sought

[J. Roeleveld]

On Fri, March 30, 2012 9:23 am, Nicolas Sebrecht wrote:
> The 29/03/12, J. Roeleveld wrote:
>>
>> On Wed, March 28, 2012 12:49 am, Mark Knecht wrote:
>>
>> <snipped>
>>
>> > Do nothing. Just read, watch, learn but most important don't do
>> > updates. Just wait. Patience is a virtue!
>>
>> I wonder how many threads we'll get with "I haven't updated my Gentoo
>> for
>> over a year, how do I best do the upgrade?" from people following this
>> advice?
>
> I think there is a better thing to do. Use an initramfs.
>
> This is not hell! ;-)

I'm not saying it is or isn't.

I just don't understand why "not upgrading for a while" is given as an
option considering the issues people will encounter when they try
upgrading a Gentoo installation that hasn't been updated in a long time.


-- 
Joost

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 16:43:38 -0500, Dale wrote:

> That's why I want something that I can install fast.  Gentoo certainly
> isn't the right choice for that.  If Kubuntu fails, I can just reinstall
> and not format /home.

That's why ${DEITY} gave us backups: no need to reinstall just roll back
to the last working version. Even if your backup is a couple of weeks
old, it with be more up to date than any distro CD.

> Right now, if Gentoo fails to boot because of the init thingy, I have no
> idea how to fix it.  None at all.  I know the basics of what it does but
> no idea how to fix it when it breaks.  That's where I am now with regard
> to my other post.  I can't su to root when using the init thingy but can
> when I don't use the init thingy.  I have no clue where to even start to
> fix it.

Why not post the details of it? All an initramfs is is an init script and
a few binaries. Extract the init script, the initramfs file is a plain
cpio archive, and post it here.

> Me clueless since this is something I tried to avoid in the past and not
> sure why it is needed now either.

Because upstream decided to work this way to avoid the problems caused by
the anachronistic separation of / and /usr. This is not so much a
decision by the udev devs as an acceptance that the current filesystem
organisation was becoming ever more unworkable in the general case.


-- 
Neil Bothwick

"Self-explanatory": technospeak for "Incomprehensible & undocumented"

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Neil Bothwick wrote:
> On Tue, 27 Mar 2012 16:43:38 -0500, Dale wrote:
> 
>> That's why I want something that I can install fast.  Gentoo certainly
>> isn't the right choice for that.  If Kubuntu fails, I can just reinstall
>> and not format /home.
> 
> That's why ${DEITY} gave us backups: no need to reinstall just roll back
> to the last working version. Even if your backup is a couple of weeks
> old, it with be more up to date than any distro CD.

I don't have the space for a backup, certainly not a full back up of
even just the OS.  I might could do one without all the KDE and other
extras but that's not a whole lot better than just reinstalling.  I keep
copies of /etc and my world file on a stick thingy.


> 
>> Right now, if Gentoo fails to boot because of the init thingy, I have no
>> idea how to fix it.  None at all.  I know the basics of what it does but
>> no idea how to fix it when it breaks.  That's where I am now with regard
>> to my other post.  I can't su to root when using the init thingy but can
>> when I don't use the init thingy.  I have no clue where to even start to
>> fix it.
> 
> Why not post the details of it? All an initramfs is is an init script and
> a few binaries. Extract the init script, the initramfs file is a plain
> cpio archive, and post it here.

I did post it a week or so ago in another thread.  I thought it was a
KDE issue at first since I first noticed it in KDE.  After a few other
tests, I found out it did the same outside of KDE.  I went back to see
what was updated and didn't find anything that I thought could cause
such a thing so I thought I would try a older kernel, with no init
thingy.  It worked.  Then I tried the exact same kernel as I was using
before but removed the init options.  It worked then.  So far the only
way I can get it to fail is to boot with the inti thingy.  That is even
tho I used the exact same kernel.  Confuses me too.

> 
>> Me clueless since this is something I tried to avoid in the past and not
>> sure why it is needed now either.
> 
> Because upstream decided to work this way to avoid the problems caused by
> the anachronistic separation of / and /usr. This is not so much a
> decision by the udev devs as an acceptance that the current filesystem
> organisation was becoming ever more unworkable in the general case.
> 
> 

Yea, I know all that.  They are breaking one thing to fix something else
so that they don't have to deal with fixing what they broke.  I got that
a long time ago.  ;-)

When I reboot, I'll use the init thingy and post all this in a new thread.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 18:47:06 -0500, Dale wrote:

> > Why not post the details of it? All an initramfs is is an init script
> > and a few binaries. Extract the init script, the initramfs file is a
> > plain cpio archive, and post it here.  
> 
> I did post it a week or so ago in another thread. 

The init script? I didn't see it, which thread?

> Yea, I know all that.  They are breaking one thing to fix something else
> so that they don't have to deal with fixing what they broke.  I got that
> a long time ago.  ;-)

I'm coming round to the point of view that the breakage predates udev by
many years. The whole idea of having four directories for binaries and
two for libraries is an inelegance that I have come to accept over the
years but only because it is "the way we have always done it"


-- 
Neil Bothwick

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Canek Peláez Valdés]

On Wed, Mar 28, 2012 at 1:51 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 27 Mar 2012 18:47:06 -0500, Dale wrote:
>
>> > Why not post the details of it? All an initramfs is is an init script
>> > and a few binaries. Extract the init script, the initramfs file is a
>> > plain cpio archive, and post it here.
>>
>> I did post it a week or so ago in another thread.
>
> The init script? I didn't see it, which thread?
>
>> Yea, I know all that.  They are breaking one thing to fix something else
>> so that they don't have to deal with fixing what they broke.  I got that
>> a long time ago.  ;-)
>
> I'm coming round to the point of view that the breakage predates udev by
> many years. The whole idea of having four directories for binaries and
> two for libraries is an inelegance that I have come to accept over the
> years but only because it is "the way we have always done it"

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Wed, 28 Mar 2012 08:51:23 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Tue, 27 Mar 2012 18:47:06 -0500, Dale wrote:
> 
> > > Why not post the details of it? All an initramfs is is an init
> > > script and a few binaries. Extract the init script, the initramfs
> > > file is a plain cpio archive, and post it here.  
> > 
> > I did post it a week or so ago in another thread. 
> 
> The init script? I didn't see it, which thread?
> 
> > Yea, I know all that.  They are breaking one thing to fix something
> > else so that they don't have to deal with fixing what they broke.
> > I got that a long time ago.  ;-)
> 
> I'm coming round to the point of view that the breakage predates udev
> by many years. The whole idea of having four directories for binaries
> and two for libraries is an inelegance that I have come to accept
> over the years but only because it is "the way we have always done it"

four and two?  You're the lucky one.

I have six and three minimally on every server, plus however many the
proprietary fellows felt like sticking in /opt....


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 13:30:41 -0500, Dale wrote:

> The other way around.  When I boot using the init thingy, if I login as
> a user, dale in this case, I can not su to root.  I think the error was
> something like authentication failed or something to that effect.
> 
> I can reboot the exact same kernel but omit the init part, everything
> works fine.  I even tried different kernels and it still does it.

What is in the init script in your initramfs?


-- 
Neil Bothwick

Headline: "Explosion At Sperm Bank, Nurses Overcome"

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Hampicke]

> Dracut is masked on ~amd64. Bugs me, as I'd rather use something like
> that than genkernel (I very much like building my own kernels; it
> helps me keep things lean, and keeps me familiar with the capabilities
> of current and future systems). But now I have to find time to learn
> how to use Genkernel.

I don't understand why people always say that they hate genkernel
because they like to build the kernel on their own. You still can do
this with genkernel. I've been doing it for years.

This is my workflow after I merged a new kernel

# copy old config to new kernel sources
% zcat /proc/config.gz > /usr/src/linux/.config

# enter source dir
% cd /usr/src/linux

# run make oldconfig (help you keep things lean, keeps you familiar with
the capabilities of current and future systems.....)
% make oldconfig

# compile kernel and modules, generate initrd, install to /boot and
/lib/modules, create symlinks in /boot
% genkernel all

# recompile 3rd party modules
% module-rebuild rebuild

You just have to tell genkernel not to "make mrproper" in
/etc/genkernel.conf - so that it actually uses your kernel config, and
in essence, let's you "build your own kernel". I also tell genkernel not
to run "make clean" - for a faster recompile if I have changed my kernel
config.

I love genkernel, it just makes life so much easier, you don't have
enter every command manually. And still keeps it the gentoo-way: you can
configure everything so that it does exactly what you wan't.

Just take a look at /etc/genkernel.conf
genkernel can do even more stuff for you.
For example include a copy of /etc/mdadm.conf into your initramfs so
that the initramfs can mount your software raid (even with metadata
higher than 0.90 :) - this is where the kernel raid auto assembly fails).
Or enable a splash theme for a graphical boot - if you like that sort of
thing.

I'm sure you're gonna love it to after you have used it for some time.

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Tue, Mar 27, 2012 at 12:18 PM, Michael Hampicke <gentoo-user@hadt.biz> wrote:
>> Dracut is masked on ~amd64. Bugs me, as I'd rather use something like
>> that than genkernel (I very much like building my own kernels; it
>> helps me keep things lean, and keeps me familiar with the capabilities
>> of current and future systems). But now I have to find time to learn
>> how to use Genkernel.
>
> I don't understand why people always say that they hate genkernel
> because they like to build the kernel on their own. You still can do
> this with genkernel. I've been doing it for years.
>
> This is my workflow after I merged a new kernel
>
> # copy old config to new kernel sources
> % zcat /proc/config.gz > /usr/src/linux/.config
>
> # enter source dir
> % cd /usr/src/linux
>
> # run make oldconfig (help you keep things lean, keeps you familiar with
> the capabilities of current and future systems.....)
> % make oldconfig
>
> # compile kernel and modules, generate initrd, install to /boot and
> /lib/modules, create symlinks in /boot
> % genkernel all
>
> # recompile 3rd party modules
> % module-rebuild rebuild
>
> You just have to tell genkernel not to "make mrproper" in
> /etc/genkernel.conf - so that it actually uses your kernel config, and
> in essence, let's you "build your own kernel". I also tell genkernel not
> to run "make clean" - for a faster recompile if I have changed my kernel
> config.
>
> I love genkernel, it just makes life so much easier, you don't have
> enter every command manually. And still keeps it the gentoo-way: you can
> configure everything so that it does exactly what you wan't.
>
> Just take a look at /etc/genkernel.conf
> genkernel can do even more stuff for you.
> For example include a copy of /etc/mdadm.conf into your initramfs so
> that the initramfs can mount your software raid (even with metadata
> higher than 0.90 :) - this is where the kernel raid auto assembly fails).
> Or enable a splash theme for a graphical boot - if you like that sort of
> thing.
>
> I'm sure you're gonna love it to after you have used it for some time.

Sounds useful. At least parts of your workflow belong in the gentoo
installation guide...

-- 
:wq

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Michael Hampicke wrote:
>> Dracut is masked on ~amd64. Bugs me, as I'd rather use something like
>> that than genkernel (I very much like building my own kernels; it
>> helps me keep things lean, and keeps me familiar with the capabilities
>> of current and future systems). But now I have to find time to learn
>> how to use Genkernel.
> 
> I don't understand why people always say that they hate genkernel
> because they like to build the kernel on their own. You still can do
> this with genkernel. I've been doing it for years.
> 
> This is my workflow after I merged a new kernel
> 
> # copy old config to new kernel sources
> % zcat /proc/config.gz > /usr/src/linux/.config
> 
> # enter source dir
> % cd /usr/src/linux
> 
> # run make oldconfig (help you keep things lean, keeps you familiar with
> the capabilities of current and future systems.....)
> % make oldconfig
> 
> # compile kernel and modules, generate initrd, install to /boot and
> /lib/modules, create symlinks in /boot
> % genkernel all
> 
> # recompile 3rd party modules
> % module-rebuild rebuild
> 
> You just have to tell genkernel not to "make mrproper" in
> /etc/genkernel.conf - so that it actually uses your kernel config, and
> in essence, let's you "build your own kernel". I also tell genkernel not
> to run "make clean" - for a faster recompile if I have changed my kernel
> config.
> 
> I love genkernel, it just makes life so much easier, you don't have
> enter every command manually. And still keeps it the gentoo-way: you can
> configure everything so that it does exactly what you wan't.
> 
> Just take a look at /etc/genkernel.conf
> genkernel can do even more stuff for you.
> For example include a copy of /etc/mdadm.conf into your initramfs so
> that the initramfs can mount your software raid (even with metadata
> higher than 0.90 :) - this is where the kernel raid auto assembly fails).
> Or enable a splash theme for a graphical boot - if you like that sort of
> thing.
> 
> I'm sure you're gonna love it to after you have used it for some time.
> 
> 


I tried genkernel and it was a miserable failure for me.  So, for me, I
have no desire to use it.  I have also read where others have the same
experience so it is not just me.  It may work fine for some but for
others it does not.

I plan to keep making mine the manual way.  You can keep using genkernel
if you want.

BTW, mine is like this:

copy old config
make oldconfig
make all && make modules_install
copy kernel to /boot

That to me seems a LOT easier and it also works very well for me.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Mark Knecht]

On Tue, Mar 27, 2012 at 9:57 AM, Dale <rdalek1967@gmail.com> wrote:
> Michael Hampicke wrote:
<SNIP>
>>
>> I don't understand why people always say that they hate genkernel
>> because they like to build the kernel on their own. You still can do
>> this with genkernel. I've been doing it for years.
<SNIP>
>
>
> I tried genkernel and it was a miserable failure for me.  So, for me, I
> have no desire to use it.  I have also read where others have the same
> experience so it is not just me.  It may work fine for some but for
> others it does not.
>
> I plan to keep making mine the manual way.  You can keep using genkernel
> if you want.
>
> BTW, mine is like this:
>
> copy old config
> make oldconfig
> make all && make modules_install
> copy kernel to /boot
>
> That to me seems a LOT easier and it also works very well for me.
>
> Dale
>
> :-)  :-)

Until you add in the work of doing the initrd for each new kernel. I
think that's Michael's point.

I agree with you Dale. I do it the same way as you, except if I build
an initrd I've done it completely by hand, building the whole
directory structure, etc, then building it into the binary. That's a
lot of work. Today we have two tools I know of, genkernel & dracut,
that are represented as doing this work for us. I'm interested in what
genkernel did wrong for you, as well as how to use both tools
successfully.

- Mark

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 10:09:23 -0700, Mark Knecht wrote:

> > copy old config
> > make oldconfig
> > make all && make modules_install
> > copy kernel to /boot

make all modules_install install

does everything the last two lines do in a single command.
> >
> > That to me seems a LOT easier and it also works very well for me.

> Until you add in the work of doing the initrd for each new kernel. I
> think that's Michael's point.

make all with build the initramfs, just set the source path in the kernel
config.

> I agree with you Dale. I do it the same way as you, except if I build
> an initrd I've done it completely by hand, building the whole
> directory structure, etc, then building it into the binary. That's a
> lot of work.

Yes it is, I now I used to waste my time like that. Now I have a config
file that lists what needs to go into the initramfs and the kernel build
automatically pulls everything in for me. The only other thing I need is
the init script. So I get the benefit of hand crafting everything with
the ease of automated building.


-- 
Neil Bothwick

"Meow" <SPLAT!>  "Woof" <SPLAT!>    Jeez, it's really raining today.

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

RE: [gentoo-user] InitRAMFS - boot expert sought

[Mike Edenfield]

> From: Neil Bothwick [mailto:neil@digimed.co.uk]
 
> Yes it is, I now I used to waste my time like that. Now I have a config
file that
> lists what needs to go into the initramfs and the kernel build
automatically
> pulls everything in for me. The only other thing I need is the init
script. So I
> get the benefit of hand crafting everything with the ease of automated
> building.

Are you saying your kernel build automatically rebuilds your initramfs for
you?

I'm using dracut now and I'm looking for a way to automate the rebuild and
installation of the initramfs image. I have them manually symlinked in /boot
to /boot/initramfs.img and /boot/initramgs.img.old, to match the vmlinuz and
vmlinuz.old symlinks from `make install`. Unfortunately I have to manage
those by hand, now, or the initramfs images get out of sync. I guess I could
write my own shell script to do it but is there an existing mechanism to
hook into for this?

--Mike

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 17:20:45 -0400, Mike Edenfield wrote:

> > From: Neil Bothwick [mailto:neil@digimed.co.uk]  
>  
> > Yes it is, I now I used to waste my time like that. Now I have a
> > config  
> file that
> > lists what needs to go into the initramfs and the kernel build  
> automatically
> > pulls everything in for me. The only other thing I need is the init  
> script. So I
> > get the benefit of hand crafting everything with the ease of automated
> > building.  
> 
> Are you saying your kernel build automatically rebuilds your initramfs
> for you?

Yes. The image is built into the kernel file so there are no extra files
or grub lines to manage. It also means that even if I screw up the
initramfs on a new kernel, the old one will still work exactly as before.

See /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt


-- 
Neil Bothwick

Time is the best teacher; unfortunately it kills all its students.

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mark Knecht wrote:
> On Tue, Mar 27, 2012 at 9:57 AM, Dale <rdalek1967@gmail.com> wrote:
>> Michael Hampicke wrote:
> <SNIP>
>>>
>>> I don't understand why people always say that they hate genkernel
>>> because they like to build the kernel on their own. You still can do
>>> this with genkernel. I've been doing it for years.
> <SNIP>
>>
>>
>> I tried genkernel and it was a miserable failure for me.  So, for me, I
>> have no desire to use it.  I have also read where others have the same
>> experience so it is not just me.  It may work fine for some but for
>> others it does not.
>>
>> I plan to keep making mine the manual way.  You can keep using genkernel
>> if you want.
>>
>> BTW, mine is like this:
>>
>> copy old config
>> make oldconfig
>> make all && make modules_install
>> copy kernel to /boot
>>
>> That to me seems a LOT easier and it also works very well for me.
>>
>> Dale
>>
>> :-)  :-)
> 
> Until you add in the work of doing the initrd for each new kernel. I
> think that's Michael's point.
> 
> I agree with you Dale. I do it the same way as you, except if I build
> an initrd I've done it completely by hand, building the whole
> directory structure, etc, then building it into the binary. That's a
> lot of work. Today we have two tools I know of, genkernel & dracut,
> that are represented as doing this work for us. I'm interested in what
> genkernel did wrong for you, as well as how to use both tools
> successfully.
> 
> - Mark
> 
> 


Thing is, I can't get dracut to boot a system as I use it.  See my other
post.  Right now, my plan is to mask udev at what it is and either
switch to another distro, hope someone figures out why dracut isn't
working or just move everything to / and hope it doesn't ever screw up
right after I go to bed and full up / with errors in the messages file.
 I had this happen once.  Having /var on it's own partition was the only
thing that saved my butt.

The thing about switching to a distro that uses a init thingy, I don't
have to mess with it.  Someone else makes the stupid thing.

Just weighing out my options.  There are lots of things to weigh 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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Mark Knecht]

On Tue, Mar 27, 2012 at 1:36 PM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
 Right now, my plan is to mask udev at what it is and either
> switch to another distro
<SNIP>

Just remember, with distros it's the device you know for the devil you
don't know...

I don't understand why any of this /usr /udev stuff is bothering you.
Do you really use a separate /usr? Aren't you on stable like me or are
you on ~amd64?

Good luck. I'm positive you'll come to your senses about this Ubuntu
nonsense! ;-)))

Cheers,
Mark

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mark Knecht wrote:
> On Tue, Mar 27, 2012 at 1:36 PM, Dale <rdalek1967@gmail.com> wrote:
> <SNIP>
>  Right now, my plan is to mask udev at what it is and either
>> switch to another distro
> <SNIP>
> 
> Just remember, with distros it's the device you know for the devil you
> don't know...
> 
> I don't understand why any of this /usr /udev stuff is bothering you.
> Do you really use a separate /usr? Aren't you on stable like me or are
> you on ~amd64?
> 
> Good luck. I'm positive you'll come to your senses about this Ubuntu
> nonsense! ;-)))
> 
> Cheers,
> Mark
> 
> 


My plan was to put / on ext4, /boot on ext2 and everything else on LVM.
 That would incluse /usr, /usr/portage, /var and /home.  I have not done
that yet because doing it would force me to make a choice very soon
since this mess is coming pretty soon.

The reason it is bothering me is because of the mess it is creating for
me.  If I am the only one it bothers, then maybe it is time for me to
use something else.  That way everyone else can be happy and not have to
listen to me grumble about it.  I would like to make this work and have
been missing with it for a month at least.  I'm not making any progress
tho.

Right now, given the issues that I am already having, this is looking to
be a deal breaker.  It reminds me of when my ex kept lying to me about
things.  I can deal with it for a while but at some point you have to
decide if it is something you want to put up with or time to leave.  I
left my ex, that's why she is called my ex.  I didn't like making the
decision since we had a lot of other things in common but I hate being
lied to even worse.  I like Gentoo a lot but it may not work for what I
want in the near future.

Also, this makes me thing back to hal.  The only things is, there were
ways to get rid of hal.  There is not many options on this mess.  If I'm
going to make this work, it's going to have to be a long term solution,
supporting /var on a separate partition as well.   That will be next I
suspect.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Tue, 27 Mar 2012 16:59:30 -0500
Dale <rdalek1967@gmail.com> wrote:

> Mark Knecht wrote:
> > On Tue, Mar 27, 2012 at 1:36 PM, Dale <rdalek1967@gmail.com> wrote:
> > <SNIP>
> >  Right now, my plan is to mask udev at what it is and either
> >> switch to another distro
> > <SNIP>
> > 
> > Just remember, with distros it's the device you know for the devil
> > you don't know...
> > 
> > I don't understand why any of this /usr /udev stuff is bothering
> > you. Do you really use a separate /usr? Aren't you on stable like
> > me or are you on ~amd64?
> > 
> > Good luck. I'm positive you'll come to your senses about this Ubuntu
> > nonsense! ;-)))
> > 
> > Cheers,
> > Mark
> > 
> > 
> 
> 
> My plan was to put / on ext4, /boot on ext2 and everything else on
> LVM. That would incluse /usr, /usr/portage, /var and /home.  I have
> not done that yet because doing it would force me to make a choice
> very soon since this mess is coming pretty soon.

That's easy to fix. It takes a while and it's mind-numbingly boring,
but it's easy.

All you need is a decent amount of free disk space as you will shuffle
things around just like in that 15 pieces game.

Assuming / is the first (or second) partition on a disk:

Measure how much data is on the file system.
Measure how much data is on the /usr file system.
Move partitions after / on the disk out of the way creating enough free
space to contain current / and /usr.
Enlarge / partition, enlarge the file system on it, copy contents
of /usr there.
Arrange the rest of your disk the way you want it (either with or
without LVM, both are easy enough to do).
Move the rest of your data back to it's final destination.
Delete any last remnants of the old /usr partition.

And all your worries about initramfs will go away. Trust me (no, not
because I sell used cars, but because I do this for a living and have
done it several times)

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Alan McKinnon wrote:
> On Tue, 27 Mar 2012 16:59:30 -0500
> Dale <rdalek1967@gmail.com> wrote:
> 
>> Mark Knecht wrote:
>>> On Tue, Mar 27, 2012 at 1:36 PM, Dale <rdalek1967@gmail.com> wrote:
>>> <SNIP>
>>>  Right now, my plan is to mask udev at what it is and either
>>>> switch to another distro
>>> <SNIP>
>>>
>>> Just remember, with distros it's the device you know for the devil
>>> you don't know...
>>>
>>> I don't understand why any of this /usr /udev stuff is bothering
>>> you. Do you really use a separate /usr? Aren't you on stable like
>>> me or are you on ~amd64?
>>>
>>> Good luck. I'm positive you'll come to your senses about this Ubuntu
>>> nonsense! ;-)))
>>>
>>> Cheers,
>>> Mark
>>>
>>>
>>
>>
>> My plan was to put / on ext4, /boot on ext2 and everything else on
>> LVM. That would incluse /usr, /usr/portage, /var and /home.  I have
>> not done that yet because doing it would force me to make a choice
>> very soon since this mess is coming pretty soon.
> 
> That's easy to fix. It takes a while and it's mind-numbingly boring,
> but it's easy.
> 
> All you need is a decent amount of free disk space as you will shuffle
> things around just like in that 15 pieces game.
> 
> Assuming / is the first (or second) partition on a disk:
> 
> Measure how much data is on the file system.
> Measure how much data is on the /usr file system.
> Move partitions after / on the disk out of the way creating enough free
> space to contain current / and /usr.
> Enlarge / partition, enlarge the file system on it, copy contents
> of /usr there.
> Arrange the rest of your disk the way you want it (either with or
> without LVM, both are easy enough to do).
> Move the rest of your data back to it's final destination.
> Delete any last remnants of the old /usr partition.
> 
> And all your worries about initramfs will go away. Trust me (no, not
> because I sell used cars, but because I do this for a living and have
> done it several times)
> 


Right now, I doubt my current / partition can hold all the /usr stuff.
It would require a complete undoing then redoing, like you just laid
out.  I have done this before but I would like to only have to do it
once and be done.  That is why I want to use LVM for everything but /
but if I could get this to work right, I wouldn't mind having / on LVM
too.

Right now, I have very little confidence in this init thingy and me
getting it to work much less able to fix it even it doesn't boot for
some reason.

< sighs >

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Tue, 27 Mar 2012 17:31:06 -0500
Dale <rdalek1967@gmail.com> wrote:

> Alan McKinnon wrote:
> > On Tue, 27 Mar 2012 16:59:30 -0500
> > Dale <rdalek1967@gmail.com> wrote:
> > 
> >> Mark Knecht wrote:
> >>> On Tue, Mar 27, 2012 at 1:36 PM, Dale <rdalek1967@gmail.com>
> >>> wrote: <SNIP>
> >>>  Right now, my plan is to mask udev at what it is and either
> >>>> switch to another distro
> >>> <SNIP>
> >>>
> >>> Just remember, with distros it's the device you know for the devil
> >>> you don't know...
> >>>
> >>> I don't understand why any of this /usr /udev stuff is bothering
> >>> you. Do you really use a separate /usr? Aren't you on stable like
> >>> me or are you on ~amd64?
> >>>
> >>> Good luck. I'm positive you'll come to your senses about this
> >>> Ubuntu nonsense! ;-)))
> >>>
> >>> Cheers,
> >>> Mark
> >>>
> >>>
> >>
> >>
> >> My plan was to put / on ext4, /boot on ext2 and everything else on
> >> LVM. That would incluse /usr, /usr/portage, /var and /home.  I have
> >> not done that yet because doing it would force me to make a choice
> >> very soon since this mess is coming pretty soon.
> > 
> > That's easy to fix. It takes a while and it's mind-numbingly boring,
> > but it's easy.
> > 
> > All you need is a decent amount of free disk space as you will
> > shuffle things around just like in that 15 pieces game.
> > 
> > Assuming / is the first (or second) partition on a disk:
> > 
> > Measure how much data is on the file system.
> > Measure how much data is on the /usr file system.
> > Move partitions after / on the disk out of the way creating enough
> > free space to contain current / and /usr.
> > Enlarge / partition, enlarge the file system on it, copy contents
> > of /usr there.
> > Arrange the rest of your disk the way you want it (either with or
> > without LVM, both are easy enough to do).
> > Move the rest of your data back to it's final destination.
> > Delete any last remnants of the old /usr partition.
> > 
> > And all your worries about initramfs will go away. Trust me (no, not
> > because I sell used cars, but because I do this for a living and
> > have done it several times)
> > 
> 
> 
> Right now, I doubt my current / partition can hold all the /usr stuff.
> It would require a complete undoing then redoing, like you just laid
> out.  I have done this before but I would like to only have to do it
> once and be done.  That is why I want to use LVM for everything but /
> but if I could get this to work right, I wouldn't mind having / on LVM
> too.

/ on LVM isn't all that useful, simply because it's size doesn't change
much and there's no real need to grow it. It's not like /var.

Binary distros put LVm on / not because it's a good idea but because
they like to have consistency. You don't need that because you know
what you built and it doesn't need to be supported by a corporate
employee far away.

You are worrying yourself needlessly about this init thing.

Just take some small measures to ensure that it will never be a factor.



> Right now, I have very little confidence in this init thingy and me
> getting it to work much less able to fix it even it doesn't boot for
> some reason.
> 
> < sighs >
> 
> Dale
> 
> :-)  :-)
> 
> 



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Alan McKinnon wrote:
> On Tue, 27 Mar 2012 17:31:06 -0500
> Dale <rdalek1967@gmail.com> wrote:
> 
>> Alan McKinnon wrote:
>>> On Tue, 27 Mar 2012 16:59:30 -0500
>>> Dale <rdalek1967@gmail.com> wrote:
>>>
>>>> Mark Knecht wrote:
>>>>> On Tue, Mar 27, 2012 at 1:36 PM, Dale <rdalek1967@gmail.com>
>>>>> wrote: <SNIP>
>>>>>  Right now, my plan is to mask udev at what it is and either
>>>>>> switch to another distro
>>>>> <SNIP>
>>>>>
>>>>> Just remember, with distros it's the device you know for the devil
>>>>> you don't know...
>>>>>
>>>>> I don't understand why any of this /usr /udev stuff is bothering
>>>>> you. Do you really use a separate /usr? Aren't you on stable like
>>>>> me or are you on ~amd64?
>>>>>
>>>>> Good luck. I'm positive you'll come to your senses about this
>>>>> Ubuntu nonsense! ;-)))
>>>>>
>>>>> Cheers,
>>>>> Mark
>>>>>
>>>>>
>>>>
>>>>
>>>> My plan was to put / on ext4, /boot on ext2 and everything else on
>>>> LVM. That would incluse /usr, /usr/portage, /var and /home.  I have
>>>> not done that yet because doing it would force me to make a choice
>>>> very soon since this mess is coming pretty soon.
>>>
>>> That's easy to fix. It takes a while and it's mind-numbingly boring,
>>> but it's easy.
>>>
>>> All you need is a decent amount of free disk space as you will
>>> shuffle things around just like in that 15 pieces game.
>>>
>>> Assuming / is the first (or second) partition on a disk:
>>>
>>> Measure how much data is on the file system.
>>> Measure how much data is on the /usr file system.
>>> Move partitions after / on the disk out of the way creating enough
>>> free space to contain current / and /usr.
>>> Enlarge / partition, enlarge the file system on it, copy contents
>>> of /usr there.
>>> Arrange the rest of your disk the way you want it (either with or
>>> without LVM, both are easy enough to do).
>>> Move the rest of your data back to it's final destination.
>>> Delete any last remnants of the old /usr partition.
>>>
>>> And all your worries about initramfs will go away. Trust me (no, not
>>> because I sell used cars, but because I do this for a living and
>>> have done it several times)
>>>
>>
>>
>> Right now, I doubt my current / partition can hold all the /usr stuff.
>> It would require a complete undoing then redoing, like you just laid
>> out.  I have done this before but I would like to only have to do it
>> once and be done.  That is why I want to use LVM for everything but /
>> but if I could get this to work right, I wouldn't mind having / on LVM
>> too.
> 
> / on LVM isn't all that useful, simply because it's size doesn't change
> much and there's no real need to grow it. It's not like /var.
> 
> Binary distros put LVm on / not because it's a good idea but because
> they like to have consistency. You don't need that because you know
> what you built and it doesn't need to be supported by a corporate
> employee far away.
> 
> You are worrying yourself needlessly about this init thing.
> 
> Just take some small measures to ensure that it will never be a factor.
> 
> 

So throw out my plans and just do it their way?  In that case, I may as
well use Fedora since it sort of started there.  Maybe that is what they
wanted and planned.  Screw everyone using a source based distro and they
will just come use ours.  This is starting to make me paranoid now.  ROFL

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Tue, 27 Mar 2012 18:50:04 -0500, Dale wrote:

> So throw out my plans and just do it their way?  In that case, I may as
> well use Fedora since it sort of started there.  Maybe that is what they
> wanted and planned.

According to Greg K-H, who I tend to trust, this did not come from Red
Hat. It's just that a couple of the devs are employed by them. Others are
not.


-- 
Neil Bothwick

...Advert for restaurant:
  "Exotic foods for all occasions. Police balls a speciality."

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

RE: [gentoo-user] InitRAMFS - boot expert sought

[Mike Edenfield]

> From: Neil Bothwick [mailto:neil@digimed.co.uk]


> On Tue, 27 Mar 2012 18:50:04 -0500, Dale wrote:
> 
> > So throw out my plans and just do it their way?  In that case, I may
> > as well use Fedora since it sort of started there.  Maybe that is what
> > they wanted and planned.
> 
> According to Greg K-H, who I tend to trust, this did not come from Red
Hat.
> It's just that a couple of the devs are employed by them. Others are not.

I was particularly interested to find out that Solaris started merging / and
/usr 15 years ago, so in reality, the "true UNIX way" that Linux is
following has long since been abandoned by UNIX :)

--Mike

Re: [gentoo-user] InitRAMFS - boot expert sought

[pk]

On 2012-03-28 20:29, Mike Edenfield wrote:

> I was particularly interested to find out that Solaris started merging / and
> /usr 15 years ago, so in reality, the "true UNIX way" that Linux is
> following has long since been abandoned by UNIX :)

Yep, next up is transitioning to a more modern handling of device naming
(starts with c:). I certainly hope they can persuade all the other UNIX
vendors in this, one true way(tm)! And certainly the *BSD must be forced
to follow suit... Come to think of it, why not scrap all operating
systems except the one and only "Lord of the OS"? :-|

The true UNIX way is that there is no "true UNIX way"... Solaris is no
more UNIX than AIX or HP-UX or even BSD (which Solaris is based on).
There's only a poor way of doing things and a good way of doing things
(guess which way I think Linux is going). There's a lot of talk like so:
"I think this therefore it must be the best way". _Noone_ has
rationalised _why_ this change has to happen except: "Oh, my bluetooth
keyboard doesn't work during boot, therefore everyone has to suffer" or
"a modern desktop requires this" (without explaining why a modern
desktop requires could be considered "hand waving" - for the record, I
consider my desktop quite modern with the exception of "whistles and
bells" but I wouldn't want to force going without on anyone).
All this talk about different directories is a matter of "taste"; there
is no technical reason (shared libraries aside) that some tools should
be in a directory (named after whatever); it's just a matter of
organisation and I happen to be on the side which thinks the FHS
rationalisation for /bin, /sbin, /lib is a neat one. Others thinks the
neatest solution is to put everything into one directory (whatever that
may be) and that's fine too, if there was a choice...

As for what Neil Bothwick said:
>According to Greg K-H, who I tend to trust, this did not come from Red
>Hat. It's just that a couple of the devs are employed by them. Others
>are not.

Redhat are in control (maintaining or main contributor) of a whole lot
of core software:
https://fedoraproject.org/wiki/Red_Hat_contributions#Upstream_Focus

So maybe it's in their (Redhats) best interest to only support their way
of doing things? Or it may be that the devs themselves are so "tight"
that they are working in this direction on their own accord. Or maybe
it's all coincidental... But the facts remain and that is that the Linux
"landscape" are changing dramatically (for the worse from my point of view).

This is only speculation of course but I see the software (systemd,
udev, avahi, dbus, glib, gtk+, pulseaudio etc.) Redhat support/maintain
interlinking with each other, creating ever growing dependencies (not
very "UNIXy" in my opinion); I wouldn't be surprised if, in a few years,
the (abomination) Gnome desktop system would be a hard dependency for
running a Linux system...
Or maybe Oracle (Solaris) is behind all this with their Gnome derived
JDS? Oh, the gnomes are out to get me! ;-)

A little bit more on topic perhaps: An initrd is a redundancy in my
point of view; a hassle that is needed by binary distributions with
modules for everything from the moon to the sun. It's yet another step
that is needed to restore what once was without gaining _anything_ for
it... (I don't use modules for devices that should be available during
boot).

Best regards

Peter K

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Wed, 28 Mar 2012 23:58:23 +0200, pk wrote:

> organisation and I happen to be on the side which thinks the FHS
> rationalisation for /bin, /sbin, /lib is a neat one. Others thinks the
> neatest solution is to put everything into one directory (whatever that
> may be) and that's fine too, if there was a choice...

I'm in favour of /bin and /lib, and I see the pros and cons of /sbin and
am not too bothered about how that is done. But having two (or more) of
each of these is an artificial mess that is a solution to a problem that
ceased to exist decades ago.

> As for what Neil Bothwick said:
> >According to Greg K-H, who I tend to trust, this did not come from Red
> >Hat. It's just that a couple of the devs are employed by them. Others
> >are not.  
> 
> Redhat are in control (maintaining or main contributor) of a whole lot
> of core software:
> https://fedoraproject.org/wiki/Red_Hat_contributions#Upstream_Focus

> So maybe it's in their (Redhats) best interest to only support their way
> of doing things? Or it may be that the devs themselves are so "tight"
> that they are working in this direction on their own accord. Or maybe
> it's all coincidental... 

Red Hat employ devs working on many aspects of Linux, and we should be
grateful for this (or do you prefer the Ubuntu approach of taking with
little giving back?). One of the reasons Greg K-H left SUSE to work for
the Linux Foundation was so that he could be completely
distro-independent. AFAIK he has never worked for Red Hat.


-- 
Neil Bothwick

PCMCIA: People Can't Memorize Computer Industry Acronyms

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[pk]

On 2012-03-29 01:20, Neil Bothwick wrote:

> I'm in favour of /bin and /lib, and I see the pros and cons of 
> /sbin and am not too bothered about how that is done. But having 
> two (or more) of each of these is an artificial mess that is a 
> solution to a problem that

As I said, it's a matter of taste.

> Red Hat employ devs working on many aspects of Linux, and we
> should be grateful for this (or do you prefer the Ubuntu approach
> of taking with little giving back?). One of the reasons Greg K-H
> left SUSE to work for

I did say that my writing was speculative? And I never claimed Greg
K-H is/was working for Redhat. Anyway, for the record I have always
had a great respect and admiration for both Redhat and Greg K-H (which
I see as a very good and knowledgeable kernel hacker) but this latest
debacle has taken it down a few notches... On the other hand I would
prefer Ubuntus approach to someone (anyone) pushing bad designs any
day ("speaking" hypothetically and generally without pointing out
anyone or any company). But this is quite pointless (my whining)
since, as someone else mentioned, "code talks...". Perhaps some day I
can find the time to hack my own solution (which of course will be
perfection ;-) ).

:-)

Best regards

Peter K

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Thu, 29 Mar 2012 19:14:31 +0200, pk wrote:

> But this is quite pointless (my whining)
> since, as someone else mentioned, "code talks...". Perhaps some day I
> can find the time to hack my own solution (which of course will be
> perfection ;-) ).

I wait with bated breath. Even if less than perfect, it will be better
than mine :)


-- 
Neil Bothwick

Found my .sig, it was in behind the cushion on the settee.

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[pk]

On 2012-03-29 20:06, Neil Bothwick wrote:

> I wait with bated breath. Even if less than perfect, it will be
> better than mine :)

I'll be sure to let you know if I find "perfection"... Perhaps an AI
system that takes care of it self and serves me drinks (with or
without an umbrella) while I lay on my couch doing whatever I see fit
(since the bots controlled by the AI have taken over the boring chores
I have all this free time)? On the other hand such a solution would
most likely malfunction and hit me on the head with the shaker, pour
it's contents all over me and chase me around with something sharp... ;-)

Best regards

Peter K

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Wed, Mar 28, 2012 at 2:29 PM, Mike Edenfield <kutulu@kutulu.org> wrote:
>> From: Neil Bothwick [mailto:neil@digimed.co.uk]
>
>
>> On Tue, 27 Mar 2012 18:50:04 -0500, Dale wrote:
>>
>> > So throw out my plans and just do it their way?  In that case, I may
>> > as well use Fedora since it sort of started there.  Maybe that is what
>> > they wanted and planned.
>>
>> According to Greg K-H, who I tend to trust, this did not come from Red
> Hat.
>> It's just that a couple of the devs are employed by them. Others are not.
>
> I was particularly interested to find out that Solaris started merging / and
> /usr 15 years ago, so in reality, the "true UNIX way" that Linux is
> following has long since been abandoned by UNIX :)

There is so much BS being spewed around this topic, I'm genuinely
disgusted. It's enough to lead me to suspect that Linux, as a
platform, is *dying*. Given that Linux has been my primary platform
for most of my life, that bothers me no small amount.


The "true UNIX way" is about KISS philosophy. Keep it Simple, Stupid.
Keep things small, well-defined and modular. Break things into
components, keep the components small and relatively well-defined. A
*system* can be complex, but as long as it's well-organized,
sufficiently large pieces of it may be grokked independently of
others.

Some packages eschewed that philosophy. Rather than say "fix your
crap", the udev developers threw their hands in the air and said "we
don't care; it's the responsibility of the distro maintainer to make
sure that thinks are in shape before we get launched." Except that the
only kind of distro for which it'd work reliably would be distros
which don't have a rolling release behavior; the maintaners can get
everything organized for a release, and then set things in stone.
Gentoo, Arch, Debian/testing and Mint/Debian are in for a bumpy ride,
for as long as this crap lasts. Well, either that, or understanding
initramfs, symbol versioning and dynamic linking is going to become a
more important a skill than shell scripting. All aid tools will break
at one time or another, and we'll be have to learn how to fix them, or
give up operating configurations that our own experience have taught
us were the best for our circumstances.

-- 
:wq

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Thu, Mar 29, 2012 at 5:02 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 28 Mar 2012 22:21:11 -0400, Michael Mol wrote:
>
>> There is so much BS being spewed around this topic, I'm genuinely
>> disgusted. It's enough to lead me to suspect that Linux, as a
>> platform, is *dying*.
>
> It's not dying, it's evolving - with the associated growing pains. Of
> course, that's not to say it couldn't evolve the way of the dodo.

The problem is the lack of engineering sense.

>
>> The "true UNIX way" is about KISS philosophy. Keep it Simple, Stupid.
>> Keep things small, well-defined and modular. Break things into
>> components, keep the components small and relatively well-defined.
>
> That, IMO, is the problem with the current filesystem layout. The split
> between / and /usr is anything but well-defined. Putting things in
> different boxes based on their function is good practice. Doing it based
> on some arbitrary size limit on the box is not.

Except that's not what people are doing. According to what I've read,
that was the original rationale a couple decades ago, but that hasn't
been the driving case for it for a long time, and pointing to it in a
modern context is silly. These days, you put things on different mount
points because you want different underlying characteristics either in
the filesystem or its underlying block device.

The gripe about the filesystem layout strikes me as a "it works, but
it isn't clean or elegant" complaint. That means changing it is change
for change's sake. And we're going to experience these growing pains
tenfold as the consequences of that play out. If I was comfortable
with *any* other platform as much as I've been with Gentoo these past
couple years, I'd be jumping ship immediately.

>
> It makes me think of Ubuntu's insistence on fitting their installer on a
> single CD, even if it means omitting useful software or having the
> installer sneakily download components in the background.

-- 
:wq

Re: [gentoo-user] InitRAMFS - boot expert sought

[Neil Bothwick]

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

On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote:

> > That, IMO, is the problem with the current filesystem layout. The
> > split between / and /usr is anything but well-defined. Putting things
> > in different boxes based on their function is good practice. Doing it
> > based on some arbitrary size limit on the box is not.  
> 
> Except that's not what people are doing. According to what I've read,
> that was the original rationale a couple decades ago, but that hasn't
> been the driving case for it for a long time, and pointing to it in a
> modern context is silly.

No, that's not the reason for doing it now. The reason for doing it now
has been applied to the previous solution (generally a bad idea) and is
aimed at making / a self-contained bootable system, which is a movable
target as hardware evolves.

> These days, you put things on different mount
> points because you want different underlying characteristics either in
> the filesystem or its underlying block device.

And for the vast majority of use cases, separating /bin and /usr/bin does
not make much sense.

> The gripe about the filesystem layout strikes me as a "it works, but
> it isn't clean or elegant" complaint. That means changing it is change
> for change's sake. And we're going to experience these growing pains
> tenfold as the consequences of that play out. 

It's never been clean or elegant, but it was tolerated and worked around.
Now those that are trying to work around it have said they are no longer
going to do so, which is their choice. If the separate /usr had been
allowed to die when 20MB hard disks were around, this whole situation
would never have arisen.

The trouble with shit hitting the fan is that the longer you wait the
more there is to spread around :(


-- 
Neil Bothwick

Oxymoron: Clearly Misunderstood.

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

Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Thu, Mar 29, 2012 at 10:43 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote:
>
>> > That, IMO, is the problem with the current filesystem layout. The
>> > split between / and /usr is anything but well-defined. Putting things
>> > in different boxes based on their function is good practice. Doing it
>> > based on some arbitrary size limit on the box is not.
>>
>> Except that's not what people are doing. According to what I've read,
>> that was the original rationale a couple decades ago, but that hasn't
>> been the driving case for it for a long time, and pointing to it in a
>> modern context is silly.
>
> No, that's not the reason for doing it now.

For the sake of sane conversation, then, don't use phrases like
"Putting things in different boxes based on their function is good
practice. Doing it based on some arbitrary size limit on the box is
not." unless it has present context. Referencing an environmental
constraint from twenty years ago in current-context discussion about
system engineering only clouds the issue.

This is part of the problem around this whole conversation dating back
to *last summer*; things are referenced outside of their useful
context, are presumed to be part of the current context, and get mixed
in. It all becomes a confusing mess.

> The reason for doing it now
> has been applied to the previous solution (generally a bad idea) and is
> aimed at making / a self-contained bootable system, which is a movable
> target as hardware evolves.

I don't think I've seen this adequately described or explained,
honestly. How is the target moving? If someone wants to put / on a
filesystem that the kernel doesn't have automagic support for, I can
see that. Otherwise...not really.

>
>> These days, you put things on different mount
>> points because you want different underlying characteristics either in
>> the filesystem or its underlying block device.
>
> And for the vast majority of use cases, separating /bin and /usr/bin does
> not make much sense.

For the vast majority of use cases, having more than one display or
keyboard doesn't make sense, either. For the vast majority of use
cases, one shouldn't need more than one desktop environment installed.
 For the vast majority of use cases, one shouldn't need more than one
optical drive, or more than one USB stick, or more than one
authentication backend.

That doesn't mean those use cases should be discarded. It means the
system should be designed to be flexible.

It makes about exactly as much sense for /bin and /usr/bin to be
separate directories as it makes sense to mirror the bulk of an OS
into a cpio blob that will be loaded into RAM. The initramfs likely
won't even fit into some production systems' RAM. I know a talented
professional sysadmin/IT guy who has most of his production VMs
running some variant of RHEL or CentOS, with only 64M of RAM apiece.
Because that makes *sense* when physical RAM may be cheap, but your
virtualization vendor bilks you for the difference.

So, OK. System bloats again, we can deal. We've been dealing with
increasing RAM, disk and CPU requirements for decades. We've even
stopped deriding Microsoft for having a bloated platform, given that
we can't fend off the bloat ourselves. We eat some crow and move on.
Apple and Android's lightweight-by-comparison 'our way or the highway'
platform mentalities gain traction and outperform us.

So where do we go from here? We have an initramfs which is painfully
difficult to keep up to date by hand, as more and more uber-cool
things will evolve dependencies on being present early-on. We'll
*need* an automated means of keeping the initramfs up-to-date, because
not everything supports static linking, and hand-walking the dynamic
linking chain is crazy talk.

Which means automated tools. These automated tools are going to have
to deal with at least as bad an issue of moving targets as keeping /
bootable was; they're a full layer of abstraction away from the main
system than / was.

>
>> The gripe about the filesystem layout strikes me as a "it works, but
>> it isn't clean or elegant" complaint. That means changing it is change
>> for change's sake. And we're going to experience these growing pains
>> tenfold as the consequences of that play out.
>
> It's never been clean or elegant, but it was tolerated and worked around.
> Now those that are trying to work around it have said they are no longer
> going to do so, which is their choice.

I love how this is described as "hey, the decision has been made. It's
here to stay." I love how the people described as They are treated as
infallible, and the decisions perfect and final.

There have been dozens of intelligent suggestions coming from
intelligent and well-meaning people, including people making arguments
in good faith. They were told they have to either bend over or code.
And when they started coding, they got mocked.

It's really only going to be upstream's choice until someone takes the
choice away from them, either from users migrating away to the point
where their paycheck is in danger, or the codebase forking and having
the stupid thing done *right*.

> If the separate /usr had been
> allowed to die when 20MB hard disks were around, this whole situation
> would never have arisen.

Perhaps. But then perhaps the dozens of incredibly useful systems and
new use cases would never have cropped up, either.

> The trouble with shit hitting the fan is that the longer you wait the
> more there is to spread around :(

It was all very nicely concentrated in one place. It could have been
dealt with in one place, where a bunch of people very aware of the
bulk of the picture could try to find a good solution to a sticky
problem.

Instead of cleaning up all the shit while it sat in a concentrated
place, it got flung out in all directions, increasing the burden on
everyone who's actively involved in the bleeding edge areas of system
usage and software development.

This is going to slow down use and development of anything that
depends on those bleeding edges, which is where interesting and new
things happen. This will definitely be killing off things which held
promise.

-- 
:wq

Re: [gentoo-user] InitRAMFS - boot expert sought

[Allan Gottlieb]

On Tue, Mar 27 2012, Alan McKinnon wrote:

> All you need is a decent amount of free disk space as you will shuffle
> things around just like in that 15 pieces game.

This sounds encouraging.  My disk is less than half full so space is not
an issue.

> Assuming / is the first (or second) partition on a disk:

Question. For me, / is actually /dev/sda5 (sda4 is the extended
partition, the three in front are one dell's special, and two for
windows, the latter only used when contacting dell for diagnostics).
But I think this difference is not material.

> Measure how much data is on the file system.
> Measure how much data is on the /usr file system.

Right

> Move partitions after / on the disk out of the way creating enough free
> space to contain current / and /usr.

Question.  /dev/sda7 is LVM and that is used for /usr, /local, et al.
How do I move an LVM partition?  I could make plain partitions and just
copy /usr, /opt, et al., each to a separate partition.  Is that the way?

> Enlarge / partition, enlarge the file system on it, copy contents
> of /usr there.

/ is ext3, which I believe can be extended live.  Or do you recommend
using a gentoo install CD (or equivalent)?

> Arrange the rest of your disk the way you want it (either with or
> without LVM, both are easy enough to do).
> Move the rest of your data back to it's final destination.
> Delete any last remnants of the old /usr partition.

This part seems straight forward and not scary since I still would have
the newly created and copied /usr, /opt, et al. partitions in case
something goes wrong.

So the result would be

/ (including /usr) on one partition (not LVM)
/local, /opt et al.,  each as separate LVs on my recreated LVM partition

I believe this is one of the configurations others have adopted, which I
consider a plus.  The other favored configuration is to keep the current
partition scheme and use an initramfs via genkernel, dracut, or Neil's
"in kernel config" soln.

I would suspect there are second order improvements such as moving
/usr/portage and /usr/src to LVM with symlinks left behind in /usr, but
I am now just concerned to see if I have the basic plan correct.
Have I?

thanks,
allan

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alex Schuster]

Allan Gottlieb writes:

> On Tue, Mar 27 2012, Alan McKinnon wrote:

> > Move partitions after / on the disk out of the way creating enough
> > free space to contain current / and /usr.
> 
> Question.  /dev/sda7 is LVM and that is used for /usr, /local, et al.
> How do I move an LVM partition?  I could make plain partitions and just
> copy /usr, /opt, et al., each to a separate partition.  Is that the way?

So you have free space after /dev/sda7? Just create some more partitions,
use pvcreate to make them physical volumes, then vgextend to add them to
your LVM. Then use pvmirror to move stuff over.
Assuming you create two more partitions /dev/sda8 and /dev/sda9:
	pvcreate /dev/sda[89]
	vgextend myvg /dev/sda[89]
	pvmove /dev/sda7
	vgreduce myvg /dev/sda7

When I use LVM, I always use many small partitions for it, instead of one
large one. This gives more flexibility in case on needs to enlarge a
standard partition, or to add such a partition in case something else has
to be installed alongside Gentoo. pvmove then allows to free a partition.

> > Enlarge / partition, enlarge the file system on it, copy contents
> > of /usr there.
> 
> / is ext3, which I believe can be extended live.  Or do you recommend
> using a gentoo install CD (or equivalent)?

ext3 can be enlargend while in use, but your partition can not. You can
enlarge the root partition after the contents of /dev/sda7 have been
moved, using [c]fdisk or whatever tool you like, but you need to reboot
for the kernel to see the new size. That would be no problem with root on
LVM, but then you also need an initramfs :)
BTW, I just had this problem when installing Ubuntu desktop on a big
server. For the first time in my life, I simply let the installer decide
about partitioning. What could possibly go wrong, it's a 73G drive, a
single root partition would do, user data is mounted via NFS. But that
night at home I got an email that the root FS was full after installing
some packages. The installer created a 5G partition only, and 68G of swap,
probably because the machine has 64G of RAM. The Ubuntu installer does
not know of LVM, so I had to manually reboot the machine the next day.

> > Arrange the rest of your disk the way you want it (either with or
> > without LVM, both are easy enough to do).
> > Move the rest of your data back to it's final destination.
> > Delete any last remnants of the old /usr partition.
> 
> This part seems straight forward and not scary since I still would have
> the newly created and copied /usr, /opt, et al. partitions in case
> something goes wrong.

pvmove seems to be considered safe. Just reboot after enlarging the root
partition, then use resize2fs /dev/sda5 to make the FS larger. Then
copy /usr over:
	mount -o bind / /mnt
	mount -o remount,ro /usr
	cp -a /usr/* /mnt/
The bind moun t makes the root FS appear in a 2nd place, without /usr
being populated by the content of your /usr partition.
Don't forget to remove /usr from /etc/fstab.

> I believe this is one of the configurations others have adopted, which I
> consider a plus.  The other favored configuration is to keep the current
> partition scheme and use an initramfs via genkernel, dracut, or Neil's
> "in kernel config" soln.

That's how I do it, but that's mainly because my whole system is
encrypted. BTW, this does not seem to be supported at this moment, at
least not with genkernel, there is no option to mount an encrypted /usr.
So I just created another LVM, unencrypted, and copied my /usr there.
Encrypting /usr does not make too much sense anyway. I also have the
problem now that I see an error while booting because /usr cannot be
fscked, but I will care about this later.

> I would suspect there are second order improvements such as moving
> /usr/portage and /usr/src to LVM with symlinks left behind in /usr, but
> I am now just concerned to see if I have the basic plan correct.
> Have I?

Sort of.
I also have portage stuff on another partition (well, on two, the tree
has its tiny extra partition), using /var/portage. I don't use symlinks,
but changed the portage paths in /etc/make.conf, and
re-created /etc/make.profile.

	Wonko

Re: [gentoo-user] InitRAMFS - boot expert sought

[Simon]

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

>
> Then
> copy /usr over:
>        mount -o bind / /mnt
>        mount -o remount,ro /usr
>        cp -a /usr/* /mnt/
> The bind moun t makes the root FS appear in a 2nd place, without /usr
> being populated by the content of your /usr partition.
> Don't forget to remove /usr from /etc/fstab.
>

I can recommend using rsync instead of cp.  Main advantage is rsync can be
stopped (ie. killed) mid-way and resumed later.  No big deal, but if your
/usr is as large as mine, you might like this!  If transfering very large
files, instead of restarting the large file from scratch, using the
--append option will write the partial data in the destination file.  If
killed and resumed, rsync will find the dst file is smaller than it should
and will continue from where it left.  If the data is absolutely crictical
important, you can also use the -c option to force rsync to do a checksum
of the files to compare, it will recopy anything that's not right.  I
normally use a -c check if I used --append and had to kill it (because I'm
paranoid AND patient).  Although I have seen zero cases where the -c found
errors.

Note the slashes at end of directories mean something with rsync, in my
example below, it means make usr and mnt identical, having rsync /usr /mnt/
means copy usr into /mnt/ (giving /mnt/usr/).

So "cp -a /usr/* /mnt/" becomes:
rsync -ah --progress /usr/ /mnt/

Enjoy!

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Wed, 28 Mar 2012 11:20:25 -0400
Allan Gottlieb <gottlieb@nyu.edu> wrote:

> On Tue, Mar 27 2012, Alan McKinnon wrote:
> 
> > All you need is a decent amount of free disk space as you will
> > shuffle things around just like in that 15 pieces game.
> 
> This sounds encouraging.  My disk is less than half full so space is
> not an issue.
> 
> > Assuming / is the first (or second) partition on a disk:
> 
> Question. For me, / is actually /dev/sda5 (sda4 is the extended
> partition, the three in front are one dell's special, and two for
> windows, the latter only used when contacting dell for diagnostics).
> But I think this difference is not material.
> 
> > Measure how much data is on the file system.
> > Measure how much data is on the /usr file system.
> 
> Right
> 
> > Move partitions after / on the disk out of the way creating enough
> > free space to contain current / and /usr.
> 
> Question.  /dev/sda7 is LVM and that is used for /usr, /local, et al.
> How do I move an LVM partition?  I could make plain partitions and
> just copy /usr, /opt, et al., each to a separate partition.  Is that
> the way?
> 
> > Enlarge / partition, enlarge the file system on it, copy contents
> > of /usr there.
> 
> / is ext3, which I believe can be extended live.  Or do you recommend
> using a gentoo install CD (or equivalent)?
> 
> > Arrange the rest of your disk the way you want it (either with or
> > without LVM, both are easy enough to do).
> > Move the rest of your data back to it's final destination.
> > Delete any last remnants of the old /usr partition.
> 
> This part seems straight forward and not scary since I still would
> have the newly created and copied /usr, /opt, et al. partitions in
> case something goes wrong.
> 
> So the result would be
> 
> / (including /usr) on one partition (not LVM)
> /local, /opt et al.,  each as separate LVs on my recreated LVM
> partition
> 
> I believe this is one of the configurations others have adopted,
> which I consider a plus.  The other favored configuration is to keep
> the current partition scheme and use an initramfs via genkernel,
> dracut, or Neil's "in kernel config" soln.
> 
> I would suspect there are second order improvements such as moving
> /usr/portage and /usr/src to LVM with symlinks left behind in /usr,
> but I am now just concerned to see if I have the basic plan correct.
> Have I?

What you describe sounds ok, but I'd still hesitate to give a definite
answer without a little more data.

If you send over the output of 

df -h
du -shx for each partition you have
fdisk -l
pvdisplay
vgdisplay
lvdisplay

I'll be happy to go over the numbers and offer an opinion.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Allan Gottlieb]

On Wed, Mar 28 2012, Alan McKinnon wrote:

> What you describe sounds ok, but I'd still hesitate to give a definite
> answer without a little more data.
>
> If you send over the output of 
>
> df -h
> du -shx for each partition you have
> fdisk -l
> pvdisplay
> vgdisplay
> lvdisplay
>
> I'll be happy to go over the numbers and offer an opinion.

Wow.  I get a detailed lvm recipe (with warnings) from wonko (thank you
very much) and from alan I get "an offer I can't refuse".  Definitely a
good day!

allan 

ajglap gottlieb # df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                5.0G  534M  4.2G  12% /
/dev/root             5.0G  534M  4.2G  12% /
rc-svcdir             1.0M   92K  932K   9% /lib64/rc/init.d
cgroup_root            10M     0   10M   0% /sys/fs/cgroup
udev                   10M  660K  9.4M   7% /dev
shm                   3.9G  304K  3.9G   1% /dev/shm
/dev/mapper/vg-usr     20G   14G  5.7G  70% /usr
/dev/mapper/vg-local  9.9G  7.3G  2.1G  79% /local
/dev/mapper/vg-var     15G  466M   14G   4% /var
/dev/mapper/vg-tmp    5.0G  307M  4.4G   7% /tmp
/dev/mapper/vg-opt    5.0G  285M  4.4G   6% /opt
/dev/mapper/vg-a       35G   16G   18G  48% /a


ajglap gottlieb # for i in / /usr /local /var /tmp /opt /a; do du -shx $i; done
395M	/
13G	/usr
7.2G	/local
313M	/var
168M	/tmp
147M	/opt
16G	/a


ajglap gottlieb # pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda7
  VG Name               vg
  PV Size               100.01 GiB / not usable 2.50 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              25601
  Free PE               2561
  Allocated PE          23040
  PV UUID               NW7PkL-9uTd-FpVs-CBQ5-23uN-zXmP-S93rUr
   

ajglap gottlieb # vgdisplay
  --- Volume group ---
  VG Name               vg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  9
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                6
  Open LV               6
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               100.00 GiB
  PE Size               4.00 MiB
  Total PE              25601
  Alloc PE / Size       23040 / 90.00 GiB
  Free  PE / Size       2561 / 10.00 GiB
  VG UUID               Qu7Lml-xaZ6-RjDF-3Pu4-Q0im-aStB-AWKGwD


ajglap gottlieb # lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg/usr
  LV Name                usr
  VG Name                vg
  LV UUID                PsU87T-o3vy-k2wj-15wU-tOZk-2csz-1gmDwz
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                20.00 GiB
  Current LE             5120
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:0
   
  --- Logical volume ---
  LV Path                /dev/vg/local
  LV Name                local
  VG Name                vg
  LV UUID                h05KfH-xF4U-A5ii-diWd-SZ4P-bWQD-U8Gly2
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                10.00 GiB
  Current LE             2560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:1
   
  --- Logical volume ---
  LV Path                /dev/vg/var
  LV Name                var
  VG Name                vg
  LV UUID                860txl-vddH-nF5m-2cZz-6uco-eZ4v-IvSeh6
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                15.00 GiB
  Current LE             3840
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2
   
  --- Logical volume ---
  LV Path                /dev/vg/tmp
  LV Name                tmp
  VG Name                vg
  LV UUID                a2RKmz-If71-cF9p-QE3E-kjQO-sYW2-VopkEO
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                5.00 GiB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:3
   
  --- Logical volume ---
  LV Path                /dev/vg/opt
  LV Name                opt
  VG Name                vg
  LV UUID                0zUFgs-I0UE-j3ue-eVtY-9snn-noho-uDNOBk
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                5.00 GiB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:4
   
  --- Logical volume ---
  LV Path                /dev/vg/a
  LV Name                a
  VG Name                vg
  LV UUID                QHqc9a-JLRy-01Oe-W61Y-SO1y-aPdJ-utDoqh
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                35.00 GiB
  Current LE             8960
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:5
   

Re: [gentoo-user] InitRAMFS - boot expert sought

[Allan Gottlieb]

I forgot one of the commands alan wanted to see.  Here it is.
allan

ajglap gottlieb # fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4f809fec

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63       80324       40131   de  Dell Utility
/dev/sda2   *       81920    30801919    15360000    7  HPFS/NTFS/exFAT
/dev/sda3        30801920   114667519    41932800    7  HPFS/NTFS/exFAT
/dev/sda4       114667520   976768064   431050272+   5  Extended
/dev/sda5       114667583   125162414     5247416   83  Linux
/dev/sda6       125162478   146143304    10490413+  82  Linux swap / Solaris
/dev/sda7       146143368   355871879   104864256   8e  Linux LVM
/dev/sda8       355873928   460731527    52428800   83  Linux

Disk /dev/mapper/vg-usr: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg-usr doesn't contain a valid partition table

Disk /dev/mapper/vg-local: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg-local doesn't contain a valid partition table

Disk /dev/mapper/vg-var: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders, total 31457280 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg-var doesn't contain a valid partition table

Disk /dev/mapper/vg-tmp: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders, total 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg-tmp doesn't contain a valid partition table

Disk /dev/mapper/vg-opt: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders, total 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg-opt doesn't contain a valid partition table

Disk /dev/mapper/vg-a: 37.6 GB, 37580963840 bytes
255 heads, 63 sectors/track, 4568 cylinders, total 73400320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg-a doesn't contain a valid partition table

Re: [gentoo-user] InitRAMFS - boot expert sought

[Alan McKinnon]

On Thu, 29 Mar 2012 04:43:16 -0400
Allan Gottlieb <gottlieb@nyu.edu> wrote:

> I forgot one of the commands alan wanted to see.  Here it is.
> allan


I really did want to look at this thoroughly for you, but I've been
flat on my back with some illness or other for a few days.

Do you still need my eyeballs on this problem?



> 
> ajglap gottlieb # fdisk -l
> 
> Disk /dev/sda: 500.1 GB, 500107862016 bytes
> 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x4f809fec
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1              63       80324       40131   de  Dell Utility
> /dev/sda2   *       81920    30801919    15360000    7
> HPFS/NTFS/exFAT /dev/sda3        30801920   114667519    41932800
> 7  HPFS/NTFS/exFAT /dev/sda4       114667520   976768064
> 431050272+   5  Extended /dev/sda5       114667583   125162414
> 5247416   83  Linux /dev/sda6       125162478   146143304
> 10490413+  82  Linux swap / Solaris /dev/sda7       146143368
> 355871879   104864256   8e  Linux LVM /dev/sda8       355873928
> 460731527    52428800   83  Linux
> 
> Disk /dev/mapper/vg-usr: 21.5 GB, 21474836480 bytes
> 255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Disk /dev/mapper/vg-usr doesn't contain a valid partition table
> 
> Disk /dev/mapper/vg-local: 10.7 GB, 10737418240 bytes
> 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Disk /dev/mapper/vg-local doesn't contain a valid partition table
> 
> Disk /dev/mapper/vg-var: 16.1 GB, 16106127360 bytes
> 255 heads, 63 sectors/track, 1958 cylinders, total 31457280 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Disk /dev/mapper/vg-var doesn't contain a valid partition table
> 
> Disk /dev/mapper/vg-tmp: 5368 MB, 5368709120 bytes
> 255 heads, 63 sectors/track, 652 cylinders, total 10485760 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Disk /dev/mapper/vg-tmp doesn't contain a valid partition table
> 
> Disk /dev/mapper/vg-opt: 5368 MB, 5368709120 bytes
> 255 heads, 63 sectors/track, 652 cylinders, total 10485760 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Disk /dev/mapper/vg-opt doesn't contain a valid partition table
> 
> Disk /dev/mapper/vg-a: 37.6 GB, 37580963840 bytes
> 255 heads, 63 sectors/track, 4568 cylinders, total 73400320 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Disk /dev/mapper/vg-a doesn't contain a valid partition table
> 



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] InitRAMFS - boot expert sought

[Allan Gottlieb]

On Tue, Apr 03 2012, Alan McKinnon wrote:

> On Thu, 29 Mar 2012 04:43:16 -0400
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
>
>> I forgot one of the commands alan wanted to see.  Here it is.
>> allan
>
>
> I really did want to look at this thoroughly for you, but I've been
> flat on my back with some illness or other for a few days.
>
> Do you still need my eyeballs on this problem?

First and most important.  Get well soon.

I am fairly confident that it is a safe policy either with
new partitions or new pv added to my vg and then pvmove.

So you should save your efforts to more important tasks, first on that
list is getting better.

Sincerely,
allan gottlieb

RE: [gentoo-user] InitRAMFS - boot expert sought

[Mike Edenfield]

> From: Dale [mailto:rdalek1967@gmail.com]
 
> Thing is, I can't get dracut to boot a system as I use it.  See my other post.
> Right now, my plan is to mask udev at what it is and either switch to another
> distro, hope someone figures out why dracut isn't working or just move
> everything to / and hope it doesn't ever screw up right after I go to bed and
> full up / with errors in the messages file.

>  I had this happen once.  Having /var on it's own partition was the only thing
> that saved my butt.

Ok, silly question time: if this is a concern for you, why not leave /var on its own partition? Just merge / and /usr and leave it at that?

--Mike

Re: [gentoo-user] InitRAMFS - boot expert sought

[Dale]

Mike Edenfield wrote:
>> From: Dale [mailto:rdalek1967@gmail.com]
>  
>> Thing is, I can't get dracut to boot a system as I use it.  See my other post.
>> Right now, my plan is to mask udev at what it is and either switch to another
>> distro, hope someone figures out why dracut isn't working or just move
>> everything to / and hope it doesn't ever screw up right after I go to bed and
>> full up / with errors in the messages file.
> 
>>  I had this happen once.  Having /var on it's own partition was the only thing
>> that saved my butt.
> 
> Ok, silly question time: if this is a concern for you, why not leave /var on its own partition? Just merge / and /usr and leave it at that?
> 
> --Mike
> 
> 
> 


Post crossing but I wanted to put / on ext4, /boot on ext2 and
everything else on LVM.  I been wanting to do that for a long while but
wanted to learn LVM pretty well first.  I'm trying to learn this init
thingy to but it's not working to well so far.

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"

Re: [gentoo-user] InitRAMFS - boot expert sought

[William Kenworthy]

On Tue, 2012-03-27 at 18:18 +0200, Michael Hampicke wrote:
> > Dracut is masked on ~amd64. Bugs me, as I'd rather use something like
....
> 
> I love genkernel, it just makes life so much easier, you don't have
> enter every command manually. And still keeps it the gentoo-way: you can
> configure everything so that it does exactly what you wan't.
> 
> Just take a look at /etc/genkernel.conf
> genkernel can do even more stuff for you.
> For example include a copy of /etc/mdadm.conf into your initramfs so
> that the initramfs can mount your software raid (even with metadata
> higher than 0.90 :) - this is where the kernel raid auto assembly fails).
> Or enable a splash theme for a graphical boot - if you like that sort of
> thing.
> 
> I'm sure you're gonna love it to after you have used it for some time.
> 

There are two problems with genkernel - historicly it was greeted with
enthusiasm ... until you got an unbootable system which with early
versions happened all too often - thats why I dropped it and have only
just started to experiment with it again because of the /usr changes.

Secondly, it handles only simple cases and cant do (for instance)
in-kernel suspend to disk without manual intervention - there are
probably a number of other cases too.

BillK

Re: [gentoo-user] InitRAMFS - boot expert sought

[du yang]

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

On Tuesday 03/27/12 21:19:00 CST, Mike Edenfield wrote:
> On 3/27/2012 6:36 AM, Helmut Jarausch wrote:
> > Hi,
> >
> > I've been looking for simple method to create a simple
> > initramfs to just mount the /usr partition.
> >
> > I've found
> > http://wiki.gentoo.org/wiki/Basic_initramfs_used_to_check_and_mount_/usr
> 
> If this is all you need, I recommend you use dracut. The 
> default installation (no use-flags or optional modules) will 
> product an initramfs that loads whatever you current rootfs 
> and /usr partitions are.
> 
> I've been working on updating the wiki with more detailed 
> instructions; for your case what's there now ought to be plenty:
> 
> http://wiki.gentoo.org/wiki/Dracut
> 

This guide looks a bit more simple.

It doesn't need any other tools except some basic commands.

http://en.gentoo-wiki.com/wiki/Initramfs

-- 
oooO:::::::::
(..):::::::::
:\.(:::Oooo::
::\_)::(..)::
:::::::)./:::
::::::(_/::::

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