On Sat, Jun 10, 2000 at 08:05:41PM -0700, Chris Baker wrote:
>
> Maybe I can stand to lose something else in there. I'm not insisting
> that anyone support my ideosyncrasies; I just want to know how to hack
> it together myself 8-)
there may already be enough space, im not sure, have not checked
lately.
however deleting most of the files there will do you no good since
most of them are hard links to /bin/busybox.
what you need to do is this:
gzip -dc root.bin > root.bin.nogz
mount -t ext2 -o loop root.bin.nogz /floppy
cp /sbin/nvsetenv /floppy/sbin/
umount /floppy
rm root.bin
gzip root.bin.nogz
mv root.bin.nogz.gz root.bin
dd if=/dev/zero of=/dev/fd0 bs=512 count=2880
dd if=root.bin of=/dev/fd0 bs=512
> > it would probably be better to integrate nvsetenv into busybox to save
> > the overhead of a fully linked executable. i think it does belong
> > there, perhaps for woody where we will hopefully be able to map /dev
> > nodes to OF devices.
>
> I trust you know what you're talking about, since I haven't faintest
> idea what this means....
;-)
busybox is a bunch of stripped down basic unix utilities, ls, chmod,
chown grep etc etc all compiled into ONE executable program. this
program changes its behaviour based on the name its called as, so what
you do is create a hard link from busybox to ls and run ls you get ls
behaviour, make another link chown, and run chown you get chown's
behaviour, etc.
so when you look around on the boot floppies you will find most of the
utilities have a link count of 60 or so, that is because they are all
hard links to busybox. hard links take no disk space at all (unlike
symlinks).
why would anyone do such a strange hack? heres why:
[eb@socrates eb]$ echo 'main(){}' > nothing.c
[eb@socrates eb]$ cat nothing.c
main(){}
[eb@socrates eb]$ gcc nothing.c -o nothing
[eb@socrates eb]$ ls -l nothing
-rwxr-x--- 1 eb eb 4706 Jun 10 19:27 nothing
[eb@socrates eb]$ strip nothing
[eb@socrates eb]$ ls -l nothing
-rwxr-x--- 1 eb eb 2972 Jun 10 19:27 nothing
[eb@socrates eb]$ ./nothing
[eb@socrates eb]$
even a program that does absolutly nothing, contains no real code at
all, has nearly 3K of overhead when stripped.
this is because the executable has other various information embedded,
such as the archecture and the shared library linking information,
even though nothing.c contains no real code it is still linked against
libc (main()):
[eb@socrates eb]$ ldd nothing
libc.so.6 => /lib/libc.so.6 (0x0feea000)
/lib/ld.so.1 => /lib/ld.so.1 (0x30000000)
[eb@socrates eb]$
what busybox does is eliminate all that redunancy by wrapping all the
base utilities into ONE executable.
you won't really need to do this probably, unless there is not enough
space, but the boot floppies people would assuming they decide to add
this. that is what they did for mktemp which i needed for
ybin/mkofboot to work.
as for mapping /dev nodes to OF devices, the problem is that even
though we know your root partition is /dev/hda2 on /dev/hda we have NO
IDEA what that translates to in OpenFirmware, and there is currently
no way to find out from the kernel. this means there can be no
automated way for quik (oldworld) or ybin (newworld) to set the
boot-device for you. (though on newworld its usually not necessary
since the defaults usually work fine)
> > you mean a non-miboot floppy? i think you can do that by putting a
>
> Yes, that's what I meant, but alternatives are welcome. I don't
> really know what miboot is. I suppose boot-hfs-image (or whatever
> it's called) is a miboot floppy, right? I just did a google search on
> miboot, which didn't really come up with much aside from benh's page.
> Are there any docs for it lying around?
not really, miboot is intended for boot floppies/CDs not so much for
disk bootstrap (which users are interested in) due to the problems
with macos. (it likes to ruin miboot partitions)
what miboot is is a fake System file, that actually contains boot
loader code. its designed to look and load like the MacOS System
file, this way the MacROM will load it like it would load macos and
end up loading a boot loader instead. moboot also requires the MacOS
boot blocks to be installed on the disk (in the fisrt 1K block of the
filesystem) for a miboot floppy to work your OF boot-device must be
/AAPL,ROM the hardware Mac ROM.
> > COFF format kernel on a floppy and doing a boot fd: or something. im
> > not sure i don't have an oldworld mac to tinker with, and newworlds
> > have an annoying lack of a floppy..
>
> Ah! This is starting to sound familiar. It needs to be in COFF
> format. How would one make such a thing? Let me guess: it's a
> propriatary Apple format which isn't supported except for some hacked
> together binutils from four years ago that everyone would just as soon
> forget ever existed. Am I close?
of course not! COFF is a standard executable format used by some
unices, including Digital UNIX. all that is required to get a COFF
format kernel is:
make config
make dep
make clean
make zImage
cp arch/ppc/coffboot/vmlinux.coff /floppy
i think if you create a HFS filesystem (hformat /dev/fd0) on the
floppy and copy the coff kernel to it you can do this:
boot fd:,vmlinux.coff
that of course assumes the COFF image will fit... kernel-package, the
debian utility for making kernel .debs makes .coff images by default
in addition to the ELF versions:
[eb@socrates eb]$ ls -l /boot/
total 3088
-r--r--r-- 1 root root 228111 May 24 20:35 System.map-2.2.15
-r--r--r-- 1 root root 10863 May 24 20:26 config-2.2.15
lrwxrwxrwx 1 root root 13 Apr 28 03:37 ofboot.b -> /etc/ofboot.b
lrwxrwxrwx 1 root root 20 May 24 20:45 vmlinux -> /boot/vmlinux-2.2.15
-r--r--r-- 1 root root 2091386 May 24 20:35 vmlinux-2.2.15
-r--r--r-- 1 root root 756861 May 24 20:35 vmlinux.coff-2.2.15
-r--r--r-- 1 root root 56828 Apr 25 18:41 yaboot
[eb@socrates eb]$
looks like one would indeed fit on a floppy, though i shut off all the
cruft i don't need in the kernel config. debian kernels are much
larger.
> Many thanks to all, especially Ethan who seems particularly well
> informed on this topic,
no problem.
--
Ethan Benson
http://www.alaska.net/~erbenson/
Attachment:
pgpOx9wGPLF5x.pgp
Description: PGP signature