Subject: Re: shareable distro?

Hops Error, Line 21, alcoholi.c from_blfs.10.defermentmullkegmalt at spamgourmet.com
Sun Jan 17 13:11:36 PST 2010


> Message: 1
> Date: Sat, 16 Jan 2010 22:18:08 +1300
> From: Simon Geard <delgarde at ihug.co.nz>
> Subject: Re: Subject: Re: shareable distro?
> To: blfs-support at linuxfromscratch.org
> Message-ID: <1263633488.1515.2.camel at aiglos.home>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, 2010-01-15 at 14:54 +0000, Hops Error, Line 21, alcoholi.c
> wrote:
>> Just this, from bitter experience: build everything so it boots from a
>> USB stick first, and then write just your filesystem to a non-bootable
>> CD second.
>
> In fact, not all that much reason to worry about CD boot these days. 1GB
> or 2GB flash drives are dirt-cheap, easier to deal with, and can be used
> on machines with no CD/DVD drive (netbooks, for example).
>
> Simon.

Too true. CDs have the advantage of being read-only, and thus
indespensable for back-ups. But all CDs have this advantage, not just
livecds. If having a read-only copy of some software you want to keep
in a certain state is an attractive option, you can use mkisofs to
make a cd image of just that software and burn it onto CD or DVD or (a
neat trick I found on accident) burn an ext2 or ext3 filesystem image
directly onto a DVD- linux WILL actually read it.

If you do end up loading things from CD, you might want to look at
either unionfs or aufs too. It acts like a transparancy sheet you can
put over a read-only filesystem image, that you can color on with
markers and white-out. It's nice being able to delete and write stuff
to a temporary copy of a CD without actually burning a new one. You
can save the transparancies so that the next time you boot your
computer, your CD or DVD will be in exactly the same state it was in.

http://www.filesystems.org/project-unionfs.html

http://aufs.sourceforge.net/

One other thing: package managers are awesome. The two I can reccomend
are rpm, and a combination of slackware's pkgtools and checkinstall.
That way you can install software from source or grab a ready-made
package from the internet, and then make a package that automatically
gets reinstalled when you boot up your computer, without having to
burn a new CD or DVD. The difference between this and saving
transparencies, is that it's closer to being read-only. If you go the
RPM route and do everything from scratch, it's simpler to use --nodeps
a lot than it is to try to build your own database. The plus side, is
that it's really easy to turn most book chapters directly into spec
files.

And if I didn't just get the digest I wouldn't have repeated all that
stuff about the virtues of using an initrd :p



More information about the blfs-support mailing list