Re: Updates to ash and busybox
On Tue Oct 19, 1999 at 02:05:49AM -0400, Adam Di Carlo wrote:
> Erik Andersen <andersen@xmission.com> writes:
>
> > On Sat Sep 25, 1999 at 01:18:34AM -0400, Adam Di Carlo wrote:
> > > Well, I dunno. I'll look thru the boot-floppies bug reports and see
> > > what is to be seen.
>
> Argh... sorry I didn't do this.
Ok, if you get a chance I'd like to know of anything you come across.
> > So, any more busybox feature requests?
>
> /bin/true and /bin/false can be smaller, and be shell scripts....
Hmm. Smaller than:
extern int
true_main(int argc, char** argv)
{
return( TRUE);
}
extern int
false_main(int argc, char** argv)
{
return( FALSE);
}
??? (I already trashed the useless uage info). :-) I'm not sure how to
make them smaller w/o writing them in asm and losing portability...
> I don't know if mkswap is fully sparc compatible yet... Something
> about v1 vs v2 filesystems.
Ok, I'll take a look at it and merge w/ the latest and greatest upstream
source. We definately want unlimited swap size (not 128 meg limits).
[---snip---]
> > To integrate this new version into the boot-floppies there where will
> > need to be a few changes made though... For example, rather than
> > hacking init in busybox, it would be much better to run dbootstrap from
> > /etc/init.d/rcS, which init runs on boot. In some cases the syntax of
> > some of the busybox commands has changed to be like the GNU versions.
>
> This sounds good... make it configurable, because debian uses
> /etc/rc.boot, not /etc/rc.S IIRC.
Hmm. I thought /etc/rc.boot/* was depricated (I got a bug filed against
me last time I installed something there). I took a look through
the sysvinit package earlier, and it appeared that it currently runs
/etc/init.d/rcS first unless you are in "emergency" mode, so I adopted that
for busybox' init. If you can point me to something authoritative like
a policy or some init code or someting that states where the first init
script should be, I'll gladly change it.
I'll make it an #ifndef <foo> #define <foo> thing anyways...
> > Thanks, sorry I've taken so long to get back to you. Busybox has been
> > on my plate at work -- along with a bunch of other stuff... It is now
> > on the top of my plate though. Anyway, I'd dearly love to get this
> > integrated into the latest and greatest debian boot-floppies. My version
> > is exactly the same size (63k) for the same command set (plus grep, plus
> > chroot, plus a new tar implementation that doesn't suck). I can't tell
> > you how many times I've wish chroot was on the recue disk... You know,
> > chroot could even be used for a reboot-free install -- just chroot to
> > the newly installed partition...
>
> Amazing convergance! We were recently talking about having init have
> the ability to exec/chroot? If we had this, we could conceivably have
> a "bootless installation" -- once you've installed the base system,
> you could just chroot your init over to the target system, and keep
> chugging...
Yup, that is what Caldera Open Linux 2.3 does on boot, just chroots
so you never need the reboot. Their install is pretty slick that way.
Hmm. I wonder how to do this right though... I guess the busybox init
would need to chroot to the new /, and then run the sysvinit init
program which would then boot up from the new install... Hmm. How do
we inform init it is time to chroot and where to chroot? I suppose I
could hard code some file like /tmp/newroot, and I could stat() it
when the rc script process exits, and if it exists and contains some
magic, I could then parse it and chroot to the specified directory and
execve("/sbin/init",...), and the old init goes away, and the new one
would then boot the system... Shouldn't be too hard to do really (famous
last words).
-Erik
--
Erik B. Andersen Web: http://www.xmission.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
Reply to: