I thing it's a great idea. Cisco, Avaya and other "big guys" use pretty much the same kinda scheme to boot up their network appliances for many years. There is always a boot loader and then an image or several different images. It is much easier to upgrade (remotely or even when you screwed up and flashed the wrong image) using this kinda setup and as far as it works as you described ;) AstLinux should only benefit from it. My questions are:
1. All network appliances that use this kinda setup usually keep images compressed and then boot loader decompresses it and loads into RAM. Is it gonna work in the same kinda fasion for AstLinux as well? 2. Can we also incorporate UnionFS on top of the mounted/decompressed image and keep all updates to the mounted FS in a separate file? With UnionFS it should be easy to do. It will give us number of benefits. First of all we still going to keep our main image with firmware intact, but with UnionFS can make the FS looking writable to the end user. One can make any chages to any config files and "write" them, but if something goes wrong you just reboot and have you original configuration. On the other hand if everything works good you can run "write mem" script and it will actually save all changes in a separate file (you now how UnionFS works, right). Then after reboot you mount you image and saved changes from the file with UnionFS and it looks like all the changes were actually saved on disk. We can even keep up to 3-5 separate transactions and roll the system back in time if we ever need to do so. I now it sounds messy and complicated, but I hope you got the idea. I love Cisco's run config/start config concept and it saved my ass not one time ;) I think AstLinux would only benefit from same kinda concept should we implement it. My only major concert is compatibility. It is not the case for big companies with proprietary OSs and extensive testing, but with open source and lots of guys customizing images to their need it is going to be very hard to keep KD working with all newer versions of AstLinux main image. As far as I know every time you flash a Cisco appliance with a newer version of firmware, it rips the older config file and tests it for compatibility issues. Puts default settings for everything missing and ignores the stuff which is not compatible with the newer version... Could we implement something similar it'll be great, but that's a lot of work and lots of team effort :) Dmitry Lebedev -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristian Kielhofner Sent: Monday, May 15, 2006 12:20 PM 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] _______________________________________________ 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]
