[Live-demo] 4.5alpha1 Build has started

[Alex Mandel]

On 01/31/2011 11:32 PM, Hamish wrote:
> Alex wrote:
>> The method I'm using closely follows:
>> https://help.ubuntu.com/community/LiveCDCustomization
>>
>> There is no user account, this method specifically says you
>> can not have such a thing otherwise the live disc part will
>> fail. Instead you put all the things you want to show up in
>> the home dir into /etc/skel.
>>
>> When the live disc runs it will create the user and copy
>> the /etc/skel into it's home dir on-the-fly.
> 
> mmph, that seems like a bit of cheap and nasty way of getting
> the job done if you ask me. sucks if you want to create a second/
> fresh working user account on the USB stick or VM install (which
> I've been doing for sandbox purposes), but I guess I could live
> with that.   comments?
> 
>  
>> So yes anything that needs to be customized, xfce background,
>> firefox bookmarks, symlinks can just be placed into that folder.
>> To me this is a big change from the current scripts. Every
>> instance of something being put on the desktop or in the home
>> dir would need to be moved.
> 
> In setting up the menus etc I've tried to keep both system and
> /home/user copies separate, with stuff copied into /home as
> needed. I'm not too excited about abandoning that careful
> separation and hours of hard work, but not sure to what extent
> a bulk search and replace of /home/user/ to /etc/skel/ will
> matter to that, if at all.
>  
>> git svn and bzr svn are exactly what I was looking at. I
>> was thinking of stashing it on github or launchpad for others
>> to help, but that's when I started thinking maybe we should
>> just branch in svn.
> 
> I'd sort of prefer to just focus on this stabilization round
> until 4.5 is out the door, seems like a bad time to start ripping
> up all the floor boards in any major way. chasing moving targets
> and all that.
> 
> how about this: instead of branching, just go through the scripts
> and anywhere in the you see something copied to /home/user/ add
> a couple of lines. the first being some grepable "#for LiveCDCustomization" comment, and the second being a clone of
> the cp to /home but with the target as /etc/skel instead.
> with stuff copied to both /home/user and /etc/skel both ISO
> creation methods can be used without damaging the other.
> so no need to branch and no need to wait either.
> ?
> 
> Let's see.. in 4.0rc9 /home/user after a fresh boot contains
> 1.4mb after login. I don't mind duplicating that.
> 
> note gvSIG, AtlasStyler, gpsdrive should install base files to
> /usr/local/share/data/ and symlink, not /home directly. but they
> are all just 200 kb or so, so maybe not worth worrying about.
> 
> 
> The 'live-helper' build method (see wiki.debian.org) gives you
> a bit more control. there are chances to do run scripts and 
> install things both before and after the chroot.
> see
>  https://svn.osgeo.org/osgeo/livedvd/live-helper/trunk/README.txt
> 
> but hopefully the ubuntu method isn't too ugly. migrating to
> live-helper would be a major effort, although arguably cleaner
> once you're done. a downside is the install scripts couldn't be
> reused independently with only minor changes as they can be now.
> 
> 
>> though not sure what the difference between schroot,
>> dchroot and chroot is.
> 
> see 'apt-cache show dchroot':
> """
> Description: Execute commands in a chroot environment
>  dchroot allows users to execute commands or interactive shells in
>  different chroots.  A typical installation might provide 'stable',
>  'testing' and 'unstable' chroots.  Users can move between chroots as
>  necessary.
>  .
>  NOTE: the schroot package provides a better implementation of
>  dchroot.  In particular:
>   * dchroot quoting issues are not present.  dchroot runs commands in
>     the chroot with -c option of the user's default shell; when
>     multiple command options are used, the options are concatenated
>     together, separated by spaces.  This concatenation breaks shell
>     quoting.
>   * schroot implements fine-grained access controls based on users
>     and groups, either of which may be granted the ability to gain
>     root access to the chroot if required.
>  Using schroot will avoid these issues, as well as provide additional
>  functionality dchroot does not possess.
> """
> 
> 
> Hamish
> 
> 
> 
>       

There are 2 goals I'm trying to reaching by using this method.
1. The language selector option at boot like ubuntu live discs and the
easy to read/understand boot option menu (which is actually logo/color
customizable).
2. Hopefully by having a more officially done live disc the installer
will work properly. Apparently people are trying to setup workstations
based on the disc and it's having some issue when you do an install,
partly because the of 'user' existing. So essentially I'm trying to make
an true Ubuntu variant. I did look at one other method but had no idea
how to make it work with custom compiled options, will work once
everything is packages, something called "seeding".

So in that sense, if I can't get this method to work I'm just going to
stick with our vm based method. Live-helper is interesting but last time
I checked it does not meet the above 2 goals.

The reason I mention a branch is that it would keep the difference
cleanly separated and any other fixes can always be copied to the branch
every few days. That way it's just separate and if we don't want to work
on it right now we don't need to.

I'm going to try making a live iso off the failed build from last night
and boot in a VM to see how it went.

Yes, finding and replacing home/user to etc/skel and removing all calls
to chown user:user are probably most of what would be different.

Thanks,
Alex