Feature proposal: Rebootless Installer

Douglas McClendon dmc.fedora at filteredperception.org
Wed Jul 15 04:42:49 UTC 2009


Colin Walters wrote:
> On Tue, Jul 14, 2009 at 7:38 AM, Douglas
> McClendon<dmc.fedora at filteredperception.org> wrote:
> 
>>  If so, one way to describe the major
>> benefit of my rebootless installer, is that you get to boot the livecd/usb
>> environment, *then use it as such*, and at your option, desire, and
>> convenience, decide to permanently install the LiveOS you have just been
>> using and configuring, to disk.  And of course when done, just pop out the
>> livecd/usb, and your are done... and free to leave your system with a
>> continuingly increasing uptime :)
> 
> Wait, so it's persisting any changes you made to the target drive?

yup.

> That sounds quite cool actually, and I misunderstood the original
> post.  Concretely with your change, if I've connected to a wireless
> network with NetworkManager, that would get saved in the target
> drive's configuration in gconf and be there next time I boot?

yup.

> I know with the live images one problem we have is that data can sort
> of randomly disappear if you're running close to the memory limit; if

yes, and this is one motivation to possibly switch to a unionfs LiveOS 
architecture, which would preclude my feature from working.  Note that 
unionfs doesn't magically defeat this problem, it just suffers 
differently.  I.e. a different set (but similar kind) of tradeoffs, that 
clearly the ubuntu and lots of other folks think is better (maybe not by 
a lot, but by enough).

In any event, the current feature proposal does not address this (though 
I've suggested other ideas on fedora-livecd-list over the years on ways 
to mitigate the pain).

Really, the coolest way to mitigate the pain, would be if you could pass 
a boot cmdline flag to the kernel, such that ext3/4 would have a 
preference for block(?) allocation, i.e. always preferring blocks that 
have been used and freed, instead of blocks that had never been used. 
If that could be done, that would go _a long_ way in mitigating the pain 
of the devicemapper LiveOS architecture.  But I'm getting off track of 
the feature under consideration...

> we go with your architecture we should probably special-case things
> like ~/.gconf so say the Firefox http disk cache doesn't blow away
> your wireless config.

Uh... yes.  And if I understand you correctly, that is not limited to my 
new feature, and should just be done period, because it helps out just 
as much for normal LiveOS usage.  It would just have to be another one 
those things done in /etc/rc.d/init.d/livesys that my installer would 
have to undo at the end of installation.

peace...

-dmc





More information about the devel mailing list