FC4 CF-based Router

Bob Chiodini rchiodin at bellsouth.net
Tue Dec 20 00:45:31 UTC 2005


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
>
>




More information about the fedora-list mailing list