Steven Ringwald wrote:
Bob Chiodini wrote:
A thought about process ID's. What is the PID of bash?
I will have to look that up when I am in the "boot from target disk"
part of things again; have gotten side-tracked today on other things I
am supposed to have done, in addition to the flash. :-)
I had similar thoughts concerning the real-root-dev trying to setup a
bootable partition on a Disk-On-Chip a while back. After building a
kernel specific for the hardware, it seems that I had to run rdev to set
up the correct root device so that I did not need a ramdisk. It also
seems that real-root-dev needs to be the device prior to pivot_root if
you are using a ramdisk. Honestly, I don't know why I think that.
Hopefully someone will enlighten em.
After thinking for a while and not trying to repeat my past mistakes,
why not build the CF as Fedora or other distro's build a "real" disk?
Build your root partition into an ext2 formated partition on your CF
(say /dev/hda2), set up Grub in hda1 (/boot) and the MBR in /dev/hda,
make a vfat partition in hda3 for your other OS's. I think at this
point you can either set the root device of your embedded kernel with
rdev, or pass in the device with root=/dev/hda2 (e.g.). All of the
required device files would have to exist on your CF based root. You
would also need a busybox compatible /etc/inittab that runs the
appropriate startup scripts. Those scripts can then set up any
additional devices, do your mounting and start whatever services you
need.
Ok. So you are saying, basically, to use a ext2 filesystem natively to
boot off of and then just treat it like grub/Fedora normally treat
partitions? Or are you saying boot the flash, and then hop over to the
hard-drive? Problem with the latter; system has no hard-drive, and
adding one would increase its weight/cost/number of moving parts...
Design criteria is *very* strict on these points, and the
specification of "no hard-drive". :-)
If the former, the problem with that is we wanted to make it easy to
upgrade the flash image, rather than having to include bios upgrade
utility. Almost any system on the market right now can read/write vfat
(Mac/Linux/Windows/BeOS)...
I mean boot and run from the CF. It looks like a hard drive to Linux
anyway. I take it that you got a USB stick loaded with Linux to boot
and run. Is that image too large for the CF?
I have, BTW, gotten this part to work; I can boot the key in rw mode
with this method.
Then in theory your linuxrc can just be a link to busybox. This should
work whether your device is a CF or a USB stick. Use sda instead of
hda.
Or label the partition and mount with LABEL=/WHATEVER, if the mount
command within the initrd support it.
With an initrd, don't know about without.
Keep in mind that you should/must run rdev against a COPY of the kernel,
not the one running on your desktop.
You could alternately use syslinux as the boot loader instead of grub.
hda1 would need to to be DOS-like (I used FAT12) in this case.
Well, I guess I could do that. We thought that by making the grub
partition ext2, and the other partition vfat, we would minimize the
danger of accidentally overwriting the bootloader when a tech is
popping the key into a windows box.
You probably can't avoid accidently overwriting the bootloader. As I
did on the system here, a minimal, initrd-only, bootable partition had
the tools necessary to upgrade the primary system. My intent was to use
a USB stick. I don't think the partition type on the stick would
matter. Vfat should work as long as your initrd kernel supports it. My
PC/104 board could not boot from the stick. If something went horribly
wrong we could always replace the CF with a good one. If you're working
on some kind of avionics or similar then that luxury might not exist.
Bob...
Steve
