Hi Kris, I have spent some time trying to do that, but being alone, it basically went nowhere...
Yet, following are some comments/questions/remarks that I thought might make
some sense:
Do you plan on using the old initrd (ext2) ramdisk format, or the new initramfs
(cpio) format ? I did everything with initramfs, but
I was looking for a way to concatenate the kernel and that ramdisk *after*
compilation, and couldn't find a way. So basically my
bootloader was 2 files: a kernel and an initramfs. Grub (or syslinux in your
case) was telling the kernel to use that external
initramfs. It would be cleaner to have a single file, though...
As fas as I can see, the astlinux kernel needs to launch an initramfs as well
(because you need to setup things like unionFS).
Again, I had an external initramfs, and basically I did "cat kernel initramfs
rootfs > firmware". Now, in the bootloader, the kexec
needs to extract the kernel and the initramfs from the firmware file, so you
need to store the offsets somewhere. I did that at the
end of the firmware, by adding some magic patterns and ASCII text. What do you
think about it ?
The bootloader also needs to know which image to load. Where do you plan to
store that information ? In the KD or somewhere else ?
I also wanted to do something simple for the bootloader "interface". One of the
security appliance that I have worked with is using
single letter commands in its bootloader ("e" for erase flash, "l" for list
available firmware, "b" for boot, ...). Some commands
can take arguments. It can be created with a simple shell loop. If it makes
sense, I can probably find the manual for that
bootloader, so that we can get some "inspiration".
The last (and probably biggest) challenge is the config upgrade/downgrade when
changing the firmware... I admit that it would be
nice to have some "versioning" for the config, using UnionFS or something else.
I have even seen small appliances where the config
is stored in a local SVN repository ! The whole /etc is then populated at boot
time...
We also often see the "single config file" (think Cisco), which can be XML
based. However, due to Asterisk, that single file would
be huge.
Anyway, these are just some of the things that crossed my minds when reading
your e-mail. They're maybe not even worth $0.02 !
BR, - Patrick -
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Kristian Kielhofner
> Sent: lundi, 15. mai 2006 19:20
> To: Discussion of AstLinux - Asterisk on Compact Flash
> Subject: [Astlinux-users] New Image Format
>
> Hello Everyone,
>
> I would like to update everyone on the status of the
> new image format I
> am developing.
>
> It became obvious throughout the course of working with
> this new
> development environment that there would need to be some
> flexibility in
> the image format. I hope I have found a pretty good solution to that
> problem...
>
> Old image format:
>
> - writes directly to CF
> - uses GRUB
> - difficult to upgrade, re-partition, etc
>
> New Image format:
>
> - install AstLinux loader on vfat formatted CF
> - boot kexec kernel using syslinux
> - boot AstLinux kernel using kexec
> - mount root, kd, etc. filesystems using loopback/union
>
>
> Here is how it would look:
>
> CF:
>
> /bzImage (kexec kernel) - part of AstLinux loader
> /syslinux.cfg - AstLinux loader/AstLinux config file
> /AstLinux-0.4.0.img - AstLinux root filesystem
> /AstLinux-0.4.0.img.sha1 - checksum
> /kd.img - AstLinux keydisk (can be stored anywhere)
>
> In this scenario, to upgrade, all you would have to do
> is download a
> new AstLinux image:
>
> CF:
>
> /bzImage (kexec kernel) - part of AstLinux loader
> /syslinux.cfg - AstLinux loader/AstLinux config file
> /AstLinux-0.4.0.img - AstLinux root filesystem
> /AstLinux-0.4.0.img.sha1 - checksum
> /AstLinux-0.4.1.img - AstLinux root filesystem
> /AstLinux-0.4.1.img.sha1 - checksum
> /kd.img - AstLinux keydisk (can be stored anywhere)
>
> The AstLinux loader/kexec kernel (and it's initrd)
> would automatically
> find the newest AstLinux image and verify it's checksum. It
> would then
> mount the image and boot it for you automatically. Of course, your
> keydisk would remain compatible.
>
> There are several advantages to using kexec/syslinux:
>
> - Boot AstLinux over the network. While you could always do
> this with
> PXE, this is much more flexible because you can load the
> AstLinux image
> from anywhere (within the capabilities of the AstLinux loader). This
> includes FTP, TFTP, HTTP, NFS, etc.
>
> - No fixed image format. The actual CF/HD is always
> formatted vfat, so
> you don't have to worry about partition tables, etc.
>
> - Easy upgrades. This would not be possible without kexec.
>
> - Faster reboots. Most people use kexec just to speed up reboots.
> Sounds good to me!
>
> I should have this all working in the next day or so,
> but I would like
> everyone's input for suggestions, etc.
>
> --
> Kristian Kielhofner
> _______________________________________________
> Astlinux-users mailing list
> [email protected]
> http://lists.kriscompanies.com/mailman/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via
> PayPal to [EMAIL PROTECTED]
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Astlinux-users mailing list [email protected] http://lists.kriscompanies.com/mailman/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED]
