RE: initramfs programs (was [RFC] klibc requirements)

RE: initramfs programs (was [RFC] klibc requirements)

[Torrey Hoffman]

The interesting thing that I currently do with initrd support is a
custom network-booted Linux installer for an embedded system. 

I'd like to be able to do this with initramfs too.  It needs:

- busybox, of course
- sfdisk  (scripted fdisk)
- mkreiserfs
- lilo
- dhcpcd
- A utility to display images in the framebuffer, like "fbv".

Torrey Hoffman

Re: initramfs programs (was [RFC] klibc requirements)

[Tom Rini]

On Wed, Jan 09, 2002 at 09:54:28AM -0800, Torrey Hoffman wrote:

> The interesting thing that I currently do with initrd support is a
> custom network-booted Linux installer for an embedded system. 
> 
> I'd like to be able to do this with initramfs too.  It needs:
[snip]

Er, for this particular application, why would you use klibc, if
existant?  The initramfs stuff could work with glibc, if you didn't mind
a big enough image, it sounds like.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: initramfs programs (was [RFC] klibc requirements)

[Greg KH]

On Wed, Jan 09, 2002 at 09:54:28AM -0800, Torrey Hoffman wrote:
> - lilo

lilo?  Am I missing something, or why would you want to run lilo running
before the rest of your kernel has started up?

greg k-h

Re: initramfs programs (was [RFC] klibc requirements)

[Tom Rini]

On Wed, Jan 09, 2002 at 10:28:17AM -0800, Greg KH wrote:
> On Wed, Jan 09, 2002 at 09:54:28AM -0800, Torrey Hoffman wrote:
> > - lilo
> 
> lilo?  Am I missing something, or why would you want to run lilo running
> before the rest of your kernel has started up?

He's talking about an installer, for presumably x86, embedded hw.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: initramfs programs (was [RFC] klibc requirements)

[Oliver Xymoron]

On Wed, 9 Jan 2002, Eric S. Raymond wrote:

> greg k-h:
> >What does everyone else need/want there?
>
> dmidecode, so the init script can dump a DMI report in a known
> location such as /var/run/dmi.

No, this belongs in a distribution's init scripts. Initramfs is stuff that
is needed before mounting real root, not everything that must be done
before we have a login prompt.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: initramfs programs (was [RFC] klibc requirements)

[Pavel Machek]

Hi!

> > > We've been over this already.  No, the configurator user should *not*
> > > have to su at any point before actual kernel installation.  Bad
> > > practice, no doughnut.
> > 
> > Why bad practice?  Anyway, you can:
> > 
> > 	if [ /proc/ -nt /var/run/dmidecode ]; then
> > 		echo We need to run some code as root.
> > 		echo -n Enter root\'s> > 		su -c 'dmidecode > /var/run/dmidecode'
> > 	fi
> > 
> > Which provides at least a way to have your config tool
> > work without having to bloat the initramfs.
> 
> OK.  One more time.
> 
> The autoconfigurator is *not* mean to be run at boot time, or as root.
> 
> It is intended to be run by ordinary users, after system boot time.
> This is so they can configure and experimentally build kernels without
> incurring the "oops..." risks of going root.
> 
> Therefore, the above 'solution' is not acceptable.

Therefore, autoconfigurator is not acceptable. Tada.

You can't go around saying "my autoconfigurator needs this so put it into
kernel". autoconfigurator is not important enough to touch kernel/initrd.
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: initramfs programs (was [RFC] klibc requirements)

[Pavel Machek]

Hi!

> You're right, I don't need this to be done at kernel level.  I do need it to
> be done *everywhere*.  I'm not sure how else to guarantee this will happen. 

Ehm? autoconfig is not good enough reason to force *everyone* to do dmi
scanning. I don't give a damn about autoconfig, and you are not going
to force it to my machines. Stop trying.

It may be reasonable if you wanted major distros to have that. Just don't
say *everyone*.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Followup to:  <200201102155.g0ALtkA22362@snark.thyrsus.com>
By author:    Rob Landley <landley@trommello.org>
In newsgroup: linux.dev.kernel
> >
> > Er, 'rdev' is an x86-only program, so lets not add common functionality
> > to that.  And I'd rather not throw something onto the end of the
> > 'zImage' since I just got done removing annoying/broken things like
> > that.
> 
> You want it to be an ELF section then?
> 

initrd.  It's already supported on all architectures; initramfs uses
the same buffer-transfer architecture, which means you can use
unmodified bootloaders.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: initramfs programs (was [RFC] klibc requirements)

[Tom Rini]

On Thu, Jan 10, 2002 at 09:09:01AM -0500, Rob Landley wrote:
> On Wednesday 09 January 2002 09:42 pm, Tom Rini wrote:
> > On Thu, Jan 10, 2002 at 01:38:56AM +0100, Andreas Ferber wrote:
> > > On Wed, Jan 09, 2002 at 05:25:07PM -0700, Tom Rini wrote:
> > > > > This could be done anyway: just replace the initramfs image built by
> > > > > the kernel build with anotherone built from another source tree. It
> > > > > would be helpful though if the tools were distributed both standalone
> > > > > and included into the kernel tree.
> > > >
> > > > If the kernel is going to build an initramfs option, it also needs a
> > > > way to be given one.  The issue I'm thinking of is I know of a few
> > > > platforms where the initramfs archive will have to be part of the
> > > > 'zImage' file (much like they do for ramdisks now).
> > >
> > > Append it to the zImage and let the kernel look for it there. Plus add
> > > a tool to util-linux (or maybe an option to rdev?) to let you replace
> > > the embedded initramfs in a {,b}zImage with a customized one.
> >
> > Er, 'rdev' is an x86-only program, so lets not add common functionality
> > to that.  And I'd rather not throw something onto the end of the
> > 'zImage' since I just got done removing annoying/broken things like
> > that.
> 
> You want it to be an ELF section then?

I want it to be implementation specific.  The running kernel shouldn't
care how it got the image, just that it did.

And yes, on PPC it will either be given one by a 'real' bootloader
(yaboot, ppcboot) or an ELF section like the kernel itself, ramdisk and
sometimes System.map are.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: initramfs programs (was [RFC] klibc requirements)

[Dave Jones]

On Thu, 10 Jan 2002, H. Peter Anvin wrote:

> Right, which is why you should look at the SSE feature flag and nothing
> else.

Agreed.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Dave Jones wrote:

> 
> If every combination for a given cpuid translates to the same CONFIG_
> option, fine. I'm just not sure from memory if thats the case or not.
> The various Celeron/PIII's for example, some have SSE, some don't.
> Assuming Intel cpuid xxx translates to CONFIG_PENTIUMIII would break if
> thats the case.
> 


Right, which is why you should look at the SSE feature flag and nothing 
else.

	-hpa

Re: initramfs programs (was [RFC] klibc requirements)

[Dave Jones]

On Thu, 10 Jan 2002, H. Peter Anvin wrote:

> > (Also, some implementations allow for this string to be changed,
> >  some folks have it set to "PenguinPowered" and the likes 8-)
> Sure, but if you do that you're *asking*, in a very literal way, for
> your CPU to misidentified.  In fact, a major reason for making this
> string modifiable is due to certain vendors who hard-code CPUID strings
> in their code.

Absolutely, no argument from me there.

> > Asides from the above issues, multiple CPUs have the same
> > cpuid sometimes, meaning you have to check things like
> > cache size as well (though most (all?) of these should
> > end up with the same CONFIG_ option iirc, so this shouldn't
> > be an issue -- you should check to be sure though)
> Why -- if it doesn't change anything, all you're doing is making it
> confusing when the next derivative appears.  Remember that we *do* need,
>   as much as possible, to be forward compatible with future CPUs.

If every combination for a given cpuid translates to the same CONFIG_
option, fine. I'm just not sure from memory if thats the case or not.
The various Celeron/PIII's for example, some have SSE, some don't.
Assuming Intel cpuid xxx translates to CONFIG_PENTIUMIII would break if
thats the case.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: initramfs programs (was [RFC] klibc requirements)

[Alan Cox]

> Surelly I will not maintain the DMI table!

Quite

> This is a call for help: how to write a table
> CPU - CONFIG_SYMBOL ?
> Now I use Vendor/Name/Family/Stepping/, but
> maybe with Vendor + flags (CPUID flags) the result
> will be more correct?

You need the family/model information to get the right optimisations. Its
often not that the instruction set is different but that the cpu
implementation is different that determines the choice. With a couple of 
exceptions cpu type is actually not too important and accidentally using
486 will make little difference
 

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Dave Jones wrote:

> 
> It's worse than you think.
> Distinguishing between XP and MP athlon for example needs
> capability bit testing.  (And some XP's _are_ now multiprocessor
> capable, just to confuse the issue some more), so relying on
> the cpuid identity string isn't foolproof.
> (Also, some implementations allow for this string to be changed,
>  some folks have it set to "PenguinPowered" and the likes 8-)
> 


Sure, but if you do that you're *asking*, in a very literal way, for 
your CPU to misidentified.  In fact, a major reason for making this 
string modifiable is due to certain vendors who hard-code CPUID strings 
in their code.

> 
> Asides from the above issues, multiple CPUs have the same
> cpuid sometimes, meaning you have to check things like
> cache size as well (though most (all?) of these should
> end up with the same CONFIG_ option iirc, so this shouldn't
> be an issue -- you should check to be sure though)
> 


Why -- if it doesn't change anything, all you're doing is making it 
confusing when the next derivative appears.  Remember that we *do* need, 
  as much as possible, to be forward compatible with future CPUs.


> x86info's identify.c files should give you a fairly
> comprehensive guide to the various types.


	-hpa

Re: initramfs programs (was [RFC] klibc requirements)

[Dave Jones]

On Thu, 10 Jan 2002, Giacomo Catenazzi wrote:

> It is already difficult to maintain the database of CPU.
> The newer CPUs have name stored directly in CPU and no more
> in kernel :-(

It's worse than you think.
Distinguishing between XP and MP athlon for example needs
capability bit testing.  (And some XP's _are_ now multiprocessor
capable, just to confuse the issue some more), so relying on
the cpuid identity string isn't foolproof.
(Also, some implementations allow for this string to be changed,
 some folks have it set to "PenguinPowered" and the likes 8-)

> This is a call for help: how to write a table
> CPU - CONFIG_SYMBOL ?
> Now I use Vendor/Name/Family/Stepping/, but
> maybe with Vendor + flags (CPUID flags) the result
> will be more correct?

Asides from the above issues, multiple CPUs have the same
cpuid sometimes, meaning you have to check things like
cache size as well (though most (all?) of these should
end up with the same CONFIG_ option iirc, so this shouldn't
be an issue -- you should check to be sure though)

x86info's identify.c files should give you a fairly
comprehensive guide to the various types.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Alan Cox wrote:

>>Surelly I will not maintain the DMI table!
>>
> 
> Quite
> 
> 
>>This is a call for help: how to write a table
>>CPU - CONFIG_SYMBOL ?
>>Now I use Vendor/Name/Family/Stepping/, but
>>maybe with Vendor + flags (CPUID flags) the result
>>will be more correct?
>>
> 
> You need the family/model information to get the right optimisations. Its
> often not that the instruction set is different but that the cpu
> implementation is different that determines the choice. With a couple of 
> exceptions cpu type is actually not too important and accidentally using
> 486 will make little difference
>  


Something I'd really like to see would be to split "optimize for..." and 
"run on..." for CPU type; just like gcc has -mmach= and -march=.

	-hpa

Re: initramfs programs (was [RFC] klibc requirements)

[Giacomo Catenazzi]

Dave Jones wrote:

> On Thu, 10 Jan 2002, Alan Cox wrote:
> 
>>We've also proved the DMI data is too unreliable to be used, so the entire
>>problem space is irrelevant
>>
> 
> That's not a problem, remember Eric volunteered to maintain the
> enormous black list 8-)
> 


Surelly I will not maintain the DMI table!
It is already difficult to maintain the database of CPU.
The newer CPUs have name stored directly in CPU and no more
in kernel :-(

(
This is a call for help: how to write a table
CPU - CONFIG_SYMBOL ?
Now I use Vendor/Name/Family/Stepping/, but
maybe with Vendor + flags (CPUID flags) the result
will be more correct?

Other suggestions?

	giacomo

 

Re: initramfs programs (was [RFC] klibc requirements)

[Rob Landley]

On Wednesday 09 January 2002 09:42 pm, Tom Rini wrote:
> On Thu, Jan 10, 2002 at 01:38:56AM +0100, Andreas Ferber wrote:
> > On Wed, Jan 09, 2002 at 05:25:07PM -0700, Tom Rini wrote:
> > > > This could be done anyway: just replace the initramfs image built by
> > > > the kernel build with anotherone built from another source tree. It
> > > > would be helpful though if the tools were distributed both standalone
> > > > and included into the kernel tree.
> > >
> > > If the kernel is going to build an initramfs option, it also needs a
> > > way to be given one.  The issue I'm thinking of is I know of a few
> > > platforms where the initramfs archive will have to be part of the
> > > 'zImage' file (much like they do for ramdisks now).
> >
> > Append it to the zImage and let the kernel look for it there. Plus add
> > a tool to util-linux (or maybe an option to rdev?) to let you replace
> > the embedded initramfs in a {,b}zImage with a customized one.
>
> Er, 'rdev' is an x86-only program, so lets not add common functionality
> to that.  And I'd rather not throw something onto the end of the
> 'zImage' since I just got done removing annoying/broken things like
> that.

You want it to be an ELF section then?

Rob

Re: initramfs programs (was [RFC] klibc requirements)

[Giacomo Catenazzi]

Matthew Kirkwood wrote:

> On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> 
>>The autoconfigurator is *not* mean to be run at boot time, or as root.
>>
> 
> Under normal circumstances.
> 


???? Could you tell me about an 'anormal' circumstance that
need autoconfigurator at boot time ?


> 
>>It is intended to be run by ordinary users, after system boot time.
>>This is so they can configure and experimentally build kernels without
>>incurring the "oops..." risks of going root.
>>
> 
> Then ship it in a separate package with initscripts.  Either
> CML2 is well enough designed that the autoconfigurator will
> not need to change as the kernel does, or all your
> overengineering was for nought.


No problem. Autoconfigurator can live without important files.
I.e. no /proc/bus/{pci,usb}, autoconfigurator will ignore such
detections. (it would not say: no PCI cards, but unfortunatelly
it will find only few PCI cards (via /proc/{devices,misc}, if you
have luke)).

BTW: IMHO I can complete the detection, also with ISA cards,
before Eric will start including dmi.
How to handle a driver db with dmi strings and kernel configurations?
It seems to me to complex to try it. We need every possible machine
to extract data.

	giacomo

Re: initramfs programs (was [RFC] klibc requirements)

[Dave Jones]

On Thu, 10 Jan 2002, Alan Cox wrote:

> > We have also been over the fact that dmidecode, if written
> > appropriately, could be setuid, or call a "dmicat" setuid program.
> > This is a dmidecode implementation detail.
> We've also proved the DMI data is too unreliable to be used, so the entire
> problem space is irrelevant

That's not a problem, remember Eric volunteered to maintain the
enormous black list 8-)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: initramfs programs (was [RFC] klibc requirements)

[Matthew Kirkwood]

On Wed, 9 Jan 2002, Eric S. Raymond wrote:

> > 	if [ /proc/ -nt /var/run/dmidecode ]; then
> > 		echo We need to run some code as root.
> > 		echo -n Enter root\'s\
> > 		su -c 'dmidecode > /var/run/dmidecode'
> > 	fi

> The autoconfigurator is *not* mean to be run at boot time, or as root.

Under normal circumstances.

> It is intended to be run by ordinary users, after system boot time.
> This is so they can configure and experimentally build kernels without
> incurring the "oops..." risks of going root.

Then ship it in a separate package with initscripts.  Either
CML2 is well enough designed that the autoconfigurator will
not need to change as the kernel does, or all your
overengineering was for nought.

> Therefore, the above 'solution' is not acceptable.

To who?  It provides as way for your configurator to function
out-of-the-box until distributions choose whether it's worth
their while to support your scheme.

Matthew.

Re: initramfs programs (was [RFC] klibc requirements)

[Tom Rini]

On Thu, Jan 10, 2002 at 01:38:56AM +0100, Andreas Ferber wrote:
> On Wed, Jan 09, 2002 at 05:25:07PM -0700, Tom Rini wrote:
> > > 
> > > This could be done anyway: just replace the initramfs image built by 
> > > the kernel build with anotherone built from another source tree. It
> > > would be helpful though if the tools were distributed both standalone
> > > and included into the kernel tree.
> > If the kernel is going to build an initramfs option, it also needs a way
> > to be given one.  The issue I'm thinking of is I know of a few platforms
> > where the initramfs archive will have to be part of the 'zImage' file
> > (much like they do for ramdisks now).
> 
> Append it to the zImage and let the kernel look for it there. Plus add
> a tool to util-linux (or maybe an option to rdev?) to let you replace
> the embedded initramfs in a {,b}zImage with a customized one.

Er, 'rdev' is an x86-only program, so lets not add common functionality
to that.  And I'd rather not throw something onto the end of the
'zImage' since I just got done removing annoying/broken things like
that.  Mind you I don't think x86 will take advantage (or have reason
to, really) embedded the initramfs image into the bzImage/zImage, unless
we're going to let them run w/o a bootloader still.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: initramfs programs (was [RFC] klibc requirements)

[Andreas Ferber]

On Wed, Jan 09, 2002 at 05:25:07PM -0700, Tom Rini wrote:
> > 
> > This could be done anyway: just replace the initramfs image built by 
> > the kernel build with anotherone built from another source tree. It
> > would be helpful though if the tools were distributed both standalone
> > and included into the kernel tree.
> If the kernel is going to build an initramfs option, it also needs a way
> to be given one.  The issue I'm thinking of is I know of a few platforms
> where the initramfs archive will have to be part of the 'zImage' file
> (much like they do for ramdisks now).

Append it to the zImage and let the kernel look for it there. Plus add
a tool to util-linux (or maybe an option to rdev?) to let you replace
the embedded initramfs in a {,b}zImage with a customized one.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: initramfs programs (was [RFC] klibc requirements)

[Tom Rini]

On Wed, Jan 09, 2002 at 11:15:28PM +0100, Andreas Ferber wrote:
> On Wed, Jan 09, 2002 at 09:55:34PM +0000, Anton Altaparmakov wrote:
> > 
> > I would think that is a good idea but I am not sure that is what is planned 
> > / will happen. Keeping it outside would have the advantage that a newer 
> > partition recognizer (or whatever other code) can be applied to any 
> > existing kernel version (that supports initramfs).
> 
> This could be done anyway: just replace the initramfs image built by 
> the kernel build with anotherone built from another source tree. It
> would be helpful though if the tools were distributed both standalone
> and included into the kernel tree.

If the kernel is going to build an initramfs option, it also needs a way
to be given one.  The issue I'm thinking of is I know of a few platforms
where the initramfs archive will have to be part of the 'zImage' file
(much like they do for ramdisks now).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: initramfs programs (was [RFC] klibc requirements)

[Alan Cox]

> We have also been over the fact that dmidecode, if written
> appropriately, could be setuid, or call a "dmicat" setuid program.
> This is a dmidecode implementation detail.

We've also proved the DMI data is too unreliable to be used, so the entire
problem space is irrelevant

Re: initramfs programs (was [RFC] klibc requirements)

[Tom Rini]

On Wed, Jan 09, 2002 at 12:25:37PM -0800, Torrey Hoffman wrote:
 
> One of the neat things about moving a lot of this formerly in-kernel
> boot stuff to userspace is that it will be easier to do interesting
> customization of the boot process, without having to hack the kernel.

Right.  But in doing this we also don't want to bloat the very small
programs/functionality we currently hack directly in

> I'm sure that this will be used in lots of innovative ways that people
> haven't even thought of yet.  

Yes, but how many of these require a 'klibc' ?  One of the other tiny
libcs is probably a better bet for any sort of 'large' project.  IMHO,
the klibc stuff should be just big enough to support the 'normal' cases,
ie stuff we do now and related.

> So, I guess what I'd like to see with the initramfs build system is a 
> easy way to build little apps like sfdisk and mkreiserfs against the 
> libc it (normally) uses and add them to the ramdisk.

Well, occording to the spec file hpa posted, it's just a cpio(1)
archive, so anything is possible.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Followup to:  <20020109182902.A2804@thyrsus.com>
By author:    "Eric S. Raymond" <esr@thyrsus.com>
In newsgroup: linux.dev.kernel
> 
> OK.  One more time.
> 
> The autoconfigurator is *not* mean to be run at boot time, or as root.
> 
> It is intended to be run by ordinary users, after system boot time.
> This is so they can configure and experimentally build kernels without
> incurring the "oops..." risks of going root.
> 
> Therefore, the above 'solution' is not acceptable.
> 

If /var/run/dmidata [or whatever you call it] isn't available, put an
error box on the screen and say "complain to your distribution
vendor."

End of story.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: initramfs programs (was [RFC] klibc requirements)

[Andreas Ferber]

On Wed, Jan 09, 2002 at 04:56:58PM -0500, Eric S. Raymond wrote:

> > That's the way it works for network daemons etc. for years.
> This sounds like good advice.  The autoconfigurator is part of CML2,
> which I expect to be distributed with the kernel.  Does that change 
> your advice at all?

Yes, a little bit. Make dmidecode (or whatever you also need for
preparation steps that have to be done as root) a separate package,
which has to be installed before "make autoconfig" works, and write
that down in Documentation/Changes.

This gives you several benefits:

- you don't depend on the version of the /running/ kernel for "make
  autoconfig" to work (/dev/kmem is available for a /long/ time now).
- you can install and run dmidecode on one machine, copy the retrieved
  data to another machine and autoconfigure/build the kernel there.

Distributions can install the package by default, to make it work for
your grandmother as well, if that's what you want.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: initramfs programs (was [RFC] klibc requirements)

[Matthew Kirkwood]

On Wed, 9 Jan 2002, Eric S. Raymond wrote:

> > > The underlying problem is that dmidecode needs access to kmem, and I
> > > can't assume that the person running my configurator will be root.
> >
> > But you can "su -c" (also sudo, I suppose).  If that person
> > doesn't have root, then building a kernel isn't going to do
> > them much good.
>
> We've been over this already.  No, the configurator user should *not*
> have to su at any point before actual kernel installation.  Bad
> practice, no doughnut.

Why bad practice?  Anyway, you can:

	if [ /proc/ -nt /var/run/dmidecode ]; then
		echo We need to run some code as root.
		echo -n Enter root\'s\
		su -c 'dmidecode > /var/run/dmidecode'
	fi

Which provides at least a way to have your config tool
work without having to bloat the initramfs.

Matthew.

Re: initramfs programs (was [RFC] klibc requirements)

[Eric S. Raymond]

Matthew Kirkwood <matthew@hairy.beasts.org>:
> > We've been over this already.  No, the configurator user should *not*
> > have to su at any point before actual kernel installation.  Bad
> > practice, no doughnut.
> 
> Why bad practice?  Anyway, you can:
> 
> 	if [ /proc/ -nt /var/run/dmidecode ]; then
> 		echo We need to run some code as root.
> 		echo -n Enter root\'s\
> 		su -c 'dmidecode > /var/run/dmidecode'
> 	fi
> 
> Which provides at least a way to have your config tool
> work without having to bloat the initramfs.

OK.  One more time.

The autoconfigurator is *not* mean to be run at boot time, or as root.

It is intended to be run by ordinary users, after system boot time.
This is so they can configure and experimentally build kernels without
incurring the "oops..." risks of going root.

Therefore, the above 'solution' is not acceptable.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A man who has nothing which he is willing to fight for, nothing 
which he cares about more than he does about his personal safety, 
is a miserable creature who has no chance of being free, unless made 
and kept so by the exertions of better men than himself. 
	-- John Stuart Mill, writing on the U.S. Civil War in 1862

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Followup to:  <20020109174637.A1742@thyrsus.com>
By author:    "Eric S. Raymond" <esr@thyrsus.com>
In newsgroup: linux.dev.kernel
>
> Matthew Kirkwood <matthew@hairy.beasts.org>:
> > > The underlying problem is that dmidecode needs access to kmem, and I
> > > can't assume that the person running my configurator will be root.
> > 
> > But you can "su -c" (also sudo, I suppose).  If that person
> > doesn't have root, then building a kernel isn't going to do
> > them much good.
> 
> We've been over this already.  No, the configurator user should *not* have
> to su at any point before actual kernel installation.  Bad practice, 
> no doughnut.
> 

We have also been over the fact that dmidecode, if written
appropriately, could be setuid, or call a "dmicat" setuid program.
This is a dmidecode implementation detail.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Followup to:  <20020109165658.A31246@thyrsus.com>
By author:    "Eric S. Raymond" <esr@thyrsus.com>
In newsgroup: linux.dev.kernel
>
> Andreas Ferber <aferber@techfak.uni-bielefeld.de>:
> > Then add an init script and include installation of it to the
> > installation steps of your autoconfigurator (it has to be installed
> > anyway). If a distributor packages your program, he will include the
> > init script into his package and enable it according to his init
> > policy, or write an own init script, if your provided one doesn't
> > fit.
> > 
> > That's the way it works for network daemons etc. for years.
> 
> This sounds like good advice.  The autoconfigurator is part of CML2,
> which I expect to be distributed with the kernel.  Does that change 
> your advice at all?
> 

The program at hand is actually dmiparse or whatever it's called.  If
dmiparse isn't available, or its input data, print an eror message.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: initramfs programs (was [RFC] klibc requirements)

[Eric S. Raymond]

Matthew Kirkwood <matthew@hairy.beasts.org>:
> > The underlying problem is that dmidecode needs access to kmem, and I
> > can't assume that the person running my configurator will be root.
> 
> But you can "su -c" (also sudo, I suppose).  If that person
> doesn't have root, then building a kernel isn't going to do
> them much good.

We've been over this already.  No, the configurator user should *not* have
to su at any point before actual kernel installation.  Bad practice, 
no doughnut.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create...."
	-- Chief Justice John Marshall, 1819.

Re: initramfs programs (was [RFC] klibc requirements)

[Matthew Kirkwood]

On Wed, 9 Jan 2002, Eric S. Raymond wrote:

> The underlying problem is that dmidecode needs access to kmem, and I
> can't assume that the person running my configurator will be root.

But you can "su -c" (also sudo, I suppose).  If that person
doesn't have root, then building a kernel isn't going to do
them much good.

Matthew.

Re: initramfs programs (was [RFC] klibc requirements)

[Andreas Ferber]

On Wed, Jan 09, 2002 at 09:55:34PM +0000, Anton Altaparmakov wrote:
> 
> I would think that is a good idea but I am not sure that is what is planned 
> / will happen. Keeping it outside would have the advantage that a newer 
> partition recognizer (or whatever other code) can be applied to any 
> existing kernel version (that supports initramfs).

This could be done anyway: just replace the initramfs image built by 
the kernel build with anotherone built from another source tree. It
would be helpful though if the tools were distributed both standalone
and included into the kernel tree.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: initramfs programs (was [RFC] klibc requirements)

[Alex Bligh - linux-kernel]

--On Wednesday, 09 January, 2002 9:34 PM +0000 Anton Altaparmakov 
<aia21@cam.ac.uk> wrote:

>> seriously point: ls /sbin gives a /maximum/ range I'd
>> have thought.
>
> Partition discovery is currently done within the kernel itself. The code
> will effectively 'just' move out into user space.

Apologies - of course; I meant ls /sbin union {anything moved
out of kernel} gives a maximum range. I could find rationales,
some more questionable than others, for about half the stuff
in /sbin (for instance, if you are mounting NFS over IP, you
/might/ want to have iptables support in there before you start
playing with ip operations which without them might cause
a comprimized root to be mounted - I said /might/).

--
Alex Bligh

Re: initramfs programs (was [RFC] klibc requirements)

[Andreas Ferber]

On Wed, Jan 09, 2002 at 03:44:25PM -0500, Eric S. Raymond wrote:
> 
> You're right, I don't need this to be done at kernel level.  I do need it to
> be done *everywhere*.  I'm not sure how else to guarantee this will happen. 

Then add an init script and include installation of it to the
installation steps of your autoconfigurator (it has to be installed
anyway). If a distributor packages your program, he will include the
init script into his package and enable it according to his init
policy, or write an own init script, if your provided one doesn't
fit.

That's the way it works for network daemons etc. for years.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: initramfs programs (was [RFC] klibc requirements)

[Eric S. Raymond]

Andreas Ferber <aferber@techfak.uni-bielefeld.de>:
> Then add an init script and include installation of it to the
> installation steps of your autoconfigurator (it has to be installed
> anyway). If a distributor packages your program, he will include the
> init script into his package and enable it according to his init
> policy, or write an own init script, if your provided one doesn't
> fit.
> 
> That's the way it works for network daemons etc. for years.

This sounds like good advice.  The autoconfigurator is part of CML2,
which I expect to be distributed with the kernel.  Does that change 
your advice at all?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Those who make peaceful revolution impossible 
will make violent revolution inevitable."
	-- John F. Kennedy

Re: initramfs programs (was [RFC] klibc requirements)

[Anton Altaparmakov]

At 21:40 09/01/2002, Greg KH wrote:
>On Wed, Jan 09, 2002 at 09:34:34PM +0000, Anton Altaparmakov wrote:
> > Partition discovery is currently done within the kernel itself. The code
> > will effectively 'just' move out into user space. As such it is not 
> present
> > in /sbin now but it will be in initramfs. The same is true for various
> > other code I can imagine moving out of kernel mode into initramfs...
>
>For this code, I can see it staying in the kernel source tree, and being
>built as part of the kernel build process, right?

I would think that is a good idea but I am not sure that is what is planned 
/ will happen. Keeping it outside would have the advantage that a newer 
partition recognizer (or whatever other code) can be applied to any 
existing kernel version (that supports initramfs).

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: initramfs programs (was [RFC] klibc requirements)

[Greg KH]

On Wed, Jan 09, 2002 at 09:34:34PM +0000, Anton Altaparmakov wrote:
> Partition discovery is currently done within the kernel itself. The code 
> will effectively 'just' move out into user space. As such it is not present 
> in /sbin now but it will be in initramfs. The same is true for various 
> other code I can imagine moving out of kernel mode into initramfs...

For this code, I can see it staying in the kernel source tree, and being
built as part of the kernel build process, right?

greg k-h

Re: initramfs programs (was [RFC] klibc requirements)

[Anton Altaparmakov]

At 21:15 09/01/2002, Alex Bligh - linux-kernel wrote:
>>>Here's what I want to have in my initramfs:
>>>         - /sbin/hotplug
>>>         - /sbin/modprobe
>>>         - modules.dep (needed for modprobe, but is a text file)
>>>
>>>What does everyone else need/want there?
>>
>>It is planned to move partition discovery to userspace which would then
>>instruct the kernel of the positions of various partitions.
>>
>>The program(s) to do this will need to be in pretty much everyones
>>initramfs...
>
>What with mounting root via NFS, hence having to set up
>IP et al, mounting various different
>partition types, avoiding the kludge of fsck etc.,
>being able to recover from a corrupted root, you
>might as well just cpio up your /sbin and stick
>that in, and be able to run single user mode without
>a 'normal' root. <FX: ducks & runs>
>
>seriously point: ls /sbin gives a /maximum/ range I'd
>have thought.

Partition discovery is currently done within the kernel itself. The code 
will effectively 'just' move out into user space. As such it is not present 
in /sbin now but it will be in initramfs. The same is true for various 
other code I can imagine moving out of kernel mode into initramfs...

Best regards,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: initramfs programs (was [RFC] klibc requirements)

[Alex Bligh - linux-kernel]

>> Here's what I want to have in my initramfs:
>>         - /sbin/hotplug
>>         - /sbin/modprobe
>>         - modules.dep (needed for modprobe, but is a text file)
>>
>> What does everyone else need/want there?
>
> It is planned to move partition discovery to userspace which would then
> instruct the kernel of the positions of various partitions.
>
> The program(s) to do this will need to be in pretty much everyones
> initramfs...

What with mounting root via NFS, hence having to set up
IP et al, mounting various different
partition types, avoiding the kludge of fsck etc.,
being able to recover from a corrupted root, you
might as well just cpio up your /sbin and stick
that in, and be able to run single user mode without
a 'normal' root. <FX: ducks & runs>

seriously point: ls /sbin gives a /maximum/ range I'd
have thought.

--
Alex Bligh

Re: initramfs programs (was [RFC] klibc requirements)

[Doug McNaught]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> You're right, I don't need this to be done at kernel level.  I do need it to
> be done *everywhere*.  I'm not sure how else to guarantee this will happen. 

Time to call in your chits with Red Hat and the other distributors. ;)

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

Re: initramfs programs (was [RFC] klibc requirements)

[Patrick Mochel]

On Wed, 9 Jan 2002, Eric S. Raymond wrote:

> greg k-h:
> >What does everyone else need/want there?
>
> dmidecode, so the init script can dump a DMI report in a known
> location such as /var/run/dmi.

Why do you need that during that stage of the boot process? The DMI tables
won't go away.

Besides, is there a way to put them in such a place that when mounting the
real root partition, they won't go away? Or, is the initramfs partition
going to persist during runtime?

However, we may needs parsers to do IRQ routing. Yes, that means (dramatic
horror music) an ACPI interpreter and/or PIRQ table parser.

Which brings me to the question about initramfs configurability. Different
systems have different needs during that process. It seems that we need a
generic way to build applications for initramfs (and link them against the
libc that's used) and build initramfs images.

If building the image is part of the kernel build process, then it's
not an issue. But, it would be nice, IMHO, to separate the two; so you
could build a new initramfs image and tack it on to an already built
kernel...

	-pat

Re: initramfs programs (was [RFC] klibc requirements)

[Eric S. Raymond]

Patrick Mochel <mochel@osdl.org>:
> 
> On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> 
> > greg k-h:
> > >What does everyone else need/want there?
> >
> > dmidecode, so the init script can dump a DMI report in a known
> > location such as /var/run/dmi.
> 
> Why do you need that during that stage of the boot process? The DMI tables
> won't go away.

I know.  My proposal to put dmidecode in initramfs is an alternative to
/proc/dmi, one which won't involve having dmidecode run in kernelspace.

The underlying problem is that dmidecode needs access to kmem, and I can't
assume that the person running my configurator will be root.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The whole of the Bill [of Rights] is a declaration of the right of the
people at large or considered as individuals...  It establishes some
rights of the individual as unalienable and which consequently, no
majority has a right to deprive them of.
         -- Albert Gallatin, Oct 7 1789

Re: initramfs programs (was [RFC] klibc requirements)

[Eric S. Raymond]

Doug McNaught <doug@wireboard.com>:
> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> 
> > greg k-h:
> > >What does everyone else need/want there?
> > 
> > dmidecode, so the init script can dump a DMI report in a known
> > location such as /var/run/dmi.  
> > 
> > I want this for autoconfiguration purposes.  If I can have it, I
> > won't need /proc/dmi.
> 
> Why can't this happen inside the regular startup scripts?  They know
> where to put such files; the kernel-level stuff doesn't--I can't think
> of any current situation where the kernel writes to an arbitrary file
> in the filesystem as it boots.  Sure, /var/run is in the FHS, but that
> doesn't mean every system will have it.
> 
> IMHO, since /var/run/dmi is not needed by any stage of the kernel
> boot, it should be created in the regular startup scripts (invoked by
> init(8)). 

You're right, I don't need this to be done at kernel level.  I do need it to
be done *everywhere*.  I'm not sure how else to guarantee this will happen. 
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The American Republic will endure, until politicians realize they can
bribe the people with their own money.
	-- Alexis de Tocqueville

Re: initramfs programs (was [RFC] klibc requirements)

[Doug McNaught]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

> greg k-h:
> >What does everyone else need/want there?
> 
> dmidecode, so the init script can dump a DMI report in a known
> location such as /var/run/dmi.  
> 
> I want this for autoconfiguration purposes.  If I can have it, I
> won't need /proc/dmi.

Why can't this happen inside the regular startup scripts?  They know
where to put such files; the kernel-level stuff doesn't--I can't think
of any current situation where the kernel writes to an arbitrary file
in the filesystem as it boots.  Sure, /var/run is in the FHS, but that
doesn't mean every system will have it.

IMHO, since /var/run/dmi is not needed by any stage of the kernel
boot, it should be created in the regular startup scripts (invoked by
init(8)). 

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

RE: initramfs programs (was [RFC] klibc requirements)

[Torrey Hoffman]

Tom Rini wrote:
> On Wed, Jan 09, 2002 at 09:54:28AM -0800, Torrey Hoffman wrote:
> 
> > The interesting thing that I currently do with initrd support is a
> > custom network-booted Linux installer for an embedded system. 
> > 
> > I'd like to be able to do this with initramfs too.  It needs:
> [snip]
> 
> Er, for this particular application, why would you use klibc, if
> existant?  The initramfs stuff could work with glibc, if you 
> didn't mind
> a big enough image, it sounds like.

You are correct, the size of glibc is not a major problem for me right 
now and that's what I'm using.  However, it is the largest thing in my
initrd, which goes across the net using tftp, and glibc just keeps 
getting bigger...  I'm thinking of switching to ulibc when I get time.

One of the neat things about moving a lot of this formerly in-kernel
boot stuff to userspace is that it will be easier to do interesting
customization of the boot process, without having to hack the kernel.

I'm sure that this will be used in lots of innovative ways that people
haven't even thought of yet.  

So, I guess what I'd like to see with the initramfs build system is a 
easy way to build little apps like sfdisk and mkreiserfs against the 
libc it (normally) uses and add them to the ramdisk.

I'm not so worried for myself, but for an overworked sysadmin trying 
to customize the boot it could end up being very confusing... 

Torrey

initramfs programs (was [RFC] klibc requirements)

[Eric S. Raymond]

greg k-h:
>What does everyone else need/want there?

dmidecode, so the init script can dump a DMI report in a known
location such as /var/run/dmi.  

I want this for autoconfiguration purposes.  If I can have it, I
won't need /proc/dmi.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

I cannot undertake to lay my finger on that article of the
Constitution which grant[s] a right to Congress of expending, on
objects of benevolence, the money of their constituents.
	-- James Madison, 1794

Re: initramfs programs (was [RFC] klibc requirements)

[Andreas Ferber]

On Wed, Jan 09, 2002 at 05:29:51PM +0100, Pavel Machek wrote:
> 
> But that means that I'll need partition discovery code twice. Once on
> initrd, and once on my root, because if I insert PCMCIA harddrive on
> runtime, I'll need same detection.

Where is the problem? Generally I think you will have /every/ piece of
code on the initramfs also somewhere on your normal fs, to build the
initramfs image from. Also, who says that you have to abandon your
initramfs after the switch to the real root fs?

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: initramfs programs (was [RFC] klibc requirements)

[Pavel Machek]

Hi!

> > > >> How many programs are we talking about here?  And what should they do?
> > > >
> > > >Very good question that we should probably answer first (I'll follow up
> > > >to your other points in a separate message).
> > > >
> > > >Here's what I want to have in my initramfs:
> > > >        - /sbin/hotplug
> > > >        - /sbin/modprobe
> > > >        - modules.dep (needed for modprobe, but is a text file)
> > > >
> > > >What does everyone else need/want there?
> > >
> > > It is planned to move partition discovery to userspace which would then
> > > instruct the kernel of the positions of various partitions.
> >
> > Hmm, and when you insert PCMCIA harddrive, what happens?
> 
> If you're booting from that hard drive, you make sure you have the modules
> to talk to the drive. In general, you only need to modules to mount the
> real root partition, right?

But that means that I'll need partition discovery code twice. Once on
initrd, and once on my root, because if I insert PCMCIA harddrive on
runtime, I'll need same detection.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: initramfs programs (was [RFC] klibc requirements)

[Greg KH]

On Wed, Jan 09, 2002 at 08:04:44AM -0800, Patrick Mochel wrote:
> 
> Will we need cardmgr in the future, or will be able to get away with
> /sbin/hotplug?

Hopefully only /sbin/hotplug if the pcmcia port to the kernel is ever
finished (some people were working on it.)  If not, then we will need
cardmgr for some cards.

greg k-h

Re: initramfs programs (was [RFC] klibc requirements)

[Patrick Mochel]

On Wed, 9 Jan 2002, Pavel Machek wrote:

> Hi!
>
> > >> How many programs are we talking about here?  And what should they do?
> > >
> > >Very good question that we should probably answer first (I'll follow up
> > >to your other points in a separate message).
> > >
> > >Here's what I want to have in my initramfs:
> > >        - /sbin/hotplug
> > >        - /sbin/modprobe
> > >        - modules.dep (needed for modprobe, but is a text file)
> > >
> > >What does everyone else need/want there?
> >
> > It is planned to move partition discovery to userspace which would then
> > instruct the kernel of the positions of various partitions.
>
> Hmm, and when you insert PCMCIA harddrive, what happens?

If you're booting from that hard drive, you make sure you have the modules
to talk to the drive. In general, you only need to modules to mount the
real root partition, right?

Will we need cardmgr in the future, or will be able to get away with
/sbin/hotplug?

	-pat

Re: initramfs programs (was [RFC] klibc requirements)

[Pavel Machek]

Hi!

> >> How many programs are we talking about here?  And what should they do?
> >
> >Very good question that we should probably answer first (I'll follow up
> >to your other points in a separate message).
> >
> >Here's what I want to have in my initramfs:
> >        - /sbin/hotplug
> >        - /sbin/modprobe
> >        - modules.dep (needed for modprobe, but is a text file)
> >
> >What does everyone else need/want there?
> 
> It is planned to move partition discovery to userspace which would then 
> instruct the kernel of the positions of various partitions.

Hmm, and when you insert PCMCIA harddrive, what happens?

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: initramfs programs (was [RFC] klibc requirements)

[Anton Altaparmakov]

At 04:34 09/01/02, Greg KH wrote:
>On Wed, Jan 09, 2002 at 05:23:31AM +0100, Felix von Leitner wrote:
> >
> > How many programs are we talking about here?  And what should they do?
>
>Very good question that we should probably answer first (I'll follow up
>to your other points in a separate message).
>
>Here's what I want to have in my initramfs:
>         - /sbin/hotplug
>         - /sbin/modprobe
>         - modules.dep (needed for modprobe, but is a text file)
>
>What does everyone else need/want there?

It is planned to move partition discovery to userspace which would then 
instruct the kernel of the positions of various partitions.

The program(s) to do this will need to be in pretty much everyones initramfs...

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: initramfs programs (was [RFC] klibc requirements)

[Erik Andersen]

On Tue Jan 08, 2002 at 08:34:47PM -0800, Greg KH wrote:
> On Wed, Jan 09, 2002 at 05:23:31AM +0100, Felix von Leitner wrote:
> > 
> > How many programs are we talking about here?  And what should they do?
> 
> Very good question that we should probably answer first (I'll follow up
> to your other points in a separate message).
> 
> Here's what I want to have in my initramfs:
> 	- /sbin/hotplug
> 	- /sbin/modprobe
> 	- modules.dep (needed for modprobe, but is a text file)
> 
> What does everyone else need/want there?

I think you want a staticly linked multi-call binary, a 
trivial shell, and some kernel modules...
    http://www.uwsg.indiana.edu/hypermail/linux/kernel/0112.2/0681.html

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: initramfs programs (was [RFC] klibc requirements)

[Kai Germaschewski]

On Tue, 8 Jan 2002, Greg KH wrote:

> On Wed, Jan 09, 2002 at 05:23:31AM +0100, Felix von Leitner wrote:
> > 
> > How many programs are we talking about here?  And what should they do?
> 
> Very good question that we should probably answer first (I'll follow up
> to your other points in a separate message).
> 
> Here's what I want to have in my initramfs:
> 	- /sbin/hotplug
> 	- /sbin/modprobe
> 	- modules.dep (needed for modprobe, but is a text file)
> 
> What does everyone else need/want there?

Provision to mount the real root, i.e.
- mount

Mount the real root via NFS
- ifconfig/dhcpcd/pump
- portmap?

Or did I get that wrong?

--Kai

Re: initramfs programs (was [RFC] klibc requirements)

[H. Peter Anvin]

Followup to:  <20020109061037.GB18024@kroah.com>
By author:    Greg KH <greg@kroah.com>
In newsgroup: linux.dev.kernel
>
> On Tue, Jan 08, 2002 at 08:34:47PM -0800, Greg KH wrote:
> > 
> > Here's what I want to have in my initramfs:
> > 	- /sbin/hotplug
> > 	- /sbin/modprobe
> > 	- modules.dep (needed for modprobe, but is a text file)
> 
> Forgot the modules themselves.  That would be helpful...
> 

Sure, but those are data files as far as the (k)libc is concerned.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: initramfs programs (was [RFC] klibc requirements)

[Greg KH]

On Tue, Jan 08, 2002 at 08:34:47PM -0800, Greg KH wrote:
> 
> Here's what I want to have in my initramfs:
> 	- /sbin/hotplug
> 	- /sbin/modprobe
> 	- modules.dep (needed for modprobe, but is a text file)

Forgot the modules themselves.  That would be helpful...

greg k-h

initramfs programs (was [RFC] klibc requirements)

[Greg KH]

On Wed, Jan 09, 2002 at 05:23:31AM +0100, Felix von Leitner wrote:
> 
> How many programs are we talking about here?  And what should they do?

Very good question that we should probably answer first (I'll follow up
to your other points in a separate message).

Here's what I want to have in my initramfs:
	- /sbin/hotplug
	- /sbin/modprobe
	- modules.dep (needed for modprobe, but is a text file)

What does everyone else need/want there?

greg k-h