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

Mailing List Archive: Gentoo: User

InitRAMFS - boot expert sought

 

 

First page Previous page 1 2 3 4 Next page Last page  View All Gentoo user RSS feed   Index | Next | Previous | View Threaded


rdalek1967 at gmail

Mar 29, 2012, 10:36 AM

Post #76 of 90 (504 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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"


neil at digimed

Mar 29, 2012, 11:06 AM

Post #77 of 90 (501 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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


peterk2 at coolmail

Mar 29, 2012, 11:54 AM

Post #78 of 90 (503 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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


alan.mckinnon at gmail

Mar 29, 2012, 1:55 PM

Post #79 of 90 (504 views)
Permalink
Re: Re: InitRAMFS - boot expert sought [In reply to]

On Thu, 29 Mar 2012 14:05:30 +0200
Nicolas Sebrecht <nsebrecht [at] piing> wrote:

> The 29/03/12, Alan McKinnon wrote:
> > On Thu, 29 Mar 2012 00:20:04 +0100
> > David W Noon <dwnoon [at] ntlworld> 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 [at] gmail


alan.mckinnon at gmail

Mar 29, 2012, 1:58 PM

Post #80 of 90 (499 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

On Thu, 29 Mar 2012 13:01:49 +0100
David W Noon <dwnoon [at] ntlworld> 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 [at] ntlworld> 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 [at] gmail


peterk2 at coolmail

Mar 29, 2012, 2:20 PM

Post #81 of 90 (502 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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


kutulu at kutulu

Mar 29, 2012, 3:10 PM

Post #82 of 90 (506 views)
Permalink
RE: Re: InitRAMFS - boot expert sought [In reply to]

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

> 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


neil at digimed

Mar 29, 2012, 4:10 PM

Post #83 of 90 (504 views)
Permalink
Re: Re: InitRAMFS - boot expert sought [In reply to]

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


billk at iinet

Mar 29, 2012, 4:26 PM

Post #84 of 90 (505 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

On 29/03/2012, at 20:01, David W Noon <dwnoon [at] ntlworld> 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 [at] ntlworld> 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 [at] ntlworld (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


nsebrecht at piing

Mar 30, 2012, 12:23 AM

Post #85 of 90 (499 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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


joost at antarean

Mar 30, 2012, 12:56 AM

Post #86 of 90 (499 views)
Permalink
Re: Re: InitRAMFS - boot expert sought [In reply to]

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


dwnoon at ntlworld

Mar 30, 2012, 3:36 AM

Post #87 of 90 (501 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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

> On 29/03/2012, at 20:01, David W Noon <dwnoon [at] ntlworld> 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 [at] ntlworld (David W Noon)
======================================================================
Attachments: signature.asc (0.19 KB)


alan.mckinnon at gmail

Apr 3, 2012, 5:27 AM

Post #88 of 90 (483 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

On Thu, 29 Mar 2012 04:43:16 -0400
Allan Gottlieb <gottlieb [at] nyu> 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 [at] gmail


gottlieb at nyu

Apr 3, 2012, 6:15 AM

Post #89 of 90 (470 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

On Tue, Apr 03 2012, Alan McKinnon wrote:

> On Thu, 29 Mar 2012 04:43:16 -0400
> Allan Gottlieb <gottlieb [at] nyu> 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


Warp_7 at gmx

May 19, 2012, 6:33 AM

Post #90 of 90 (402 views)
Permalink
Re: InitRAMFS - boot expert sought [In reply to]

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.

First page Previous page 1 2 3 4 Next page Last page  View All Gentoo user RSS feed   Index | Next | Previous | View Threaded
 
 


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