Jim Connors wrote:
> Toying around with using a minimal RAM-resident version of OpenSolaris 
> (currently 80MB) as an appliance platform.   The idea here would be that the 
> OS would be real small, would boot real fast (from flash), would have no disk 
> footprint, and most importantly -- be stateless.   The stateless part is 
> where it gets tricky.  For some use cases, state must be preserved across 
> boots.   As one example, (storage appliance) a kludge here would be to have a 
> small private zfs zpool called SYS which keeps state and gets mounted early 
> in the boot process.   I've played around with creating a zfs-kludge SMF 
> service which, as its name implies, is kludgy, but seems to accomplish this 
> OK.
>
> Continuing down this path, I now realize that the SMF repository will need to 
> be preserved across boots also.  At minimum, the repository will change, for 
> example,  as shares are administered.   I've read a few of the blog entries 
> explaining the interaction with boot and SMF, and am wondering if I could add 
> some additional kludgery.   Would it be possible to have a service which, 
> upon reaching some kind of milestone, switches repositories from the static 
> one found in the flash boot image to one that could be modified and preserved?
>
> The Solaris 10 smf_bootstrap(5) manpage suggests that the present version of  
> smf(5)  does  not  support  multiple repositories.
>   

   Session preservation work is already being done for BeleniX. Anil 
Gulecha already
   has some scriptery to preserve state onto a USB thumb drive when 
shutting down
   and restore it on bootup. SMF repository is not yet tackled, but it 
is easy to do.
   Already in BeleniX 0.6.1 /sbin/init is a shell script that does some 
custom boot
   argument parsing and then execs the real init.

   It is planned to enhance it to also do the CD/USB mounting thus moving
   even more stuff onto the media and reducing miniroot size further. So 
this copying
   of the repository.db can be done in the modified init since at that 
time SMF is not
   yet active.

Regards,
Moinak.

> Thanks,
> -- Jim C
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>   


_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to