DIY: Live CD/DVD (update 2)
Douglas Mayne
http://groups.google.com/group/alt.os.linux.slackware/msg/576d263eea5b5f07
http://groups.google.com/group/alt.os.linux.slackware/msg/6cd239fcbd4656d8
Since the first post, I have fixed a couple of bugs and the project
is now using the latest kernel, 2.6.15.3, from -testing. I have been
using and testing it during the last month. The key filesystem component,
unionfs, seems fast and stable. The project uses the unionfs to
create the root filesystem which is a combination of readonly and
read-write elements. The unionfs handled the options I threw at it with
ease. I tested the filesystems composed from a variety of
elements using both loopback files (that is, a filesystem encapsulated
within a file), and actual filesystems (that is, a filesystem on an actual
disc partition). It seems to work very well; thanks in large part to the
unionfs project: http://www.unionfs.org/
If anyone else has tested the project, then I would appreciate your
feedback.
The project's web page is here:
http://www.xmission.com/~ddmayne2/10.2-live/index.html
That web page will be used from now on for posting notices and files
related to the project.
Thanks!
--
Douglas Mayne
Grant
>If anyone else has tested the project, then I would appreciate your
>feedback.
I'm interested, but got distracted while working through it, at
the moment I'm having fun learning awk (gawk).
One thing I'd suggest is publish scripts that allow us to create
the iso without downloading the slackware files we already have.
Saves us time, saves you hosting bandwidth.
Grant.
--
... The computer scientist, who had listened to all of this said,
"Yes, but where do you think the chaos came from?"
Douglas Mayne
> On Sat, 11 Feb 2006 11:53:38 -0700, Douglas Mayne <doug@localhost> wrote:
>
>>If anyone else has tested the project, then I would appreciate your
>>feedback.
>
> I'm interested, but got distracted while working through it, at
> the moment I'm having fun learning awk (gawk).
>
> One thing I'd suggest is publish scripts that allow us to create
> the iso without downloading the slackware files we already have.
>
> Saves us time, saves you hosting bandwidth.
>
> Grant.
>
Here is a tgz archive of just the script components.
http://www.xmission.com/~ddmayne2/10.2-live/v.0.0.2.8/10.2-live/source.tgz
I tried to post the source files for direct browsing at my ISP, but I
couldn't get it to work. I tried various permissions without success
(yet.) However, the tgz is very small, 14236 bytes.
I will post a bootable iso without any loopback included at all.
That way you could use an existing setup as the readonly component. The
size of that download will be about 23M (compressed). That includes
the kernel, all modules, and the initial ramdisk. It will be referenced on
this page:
http://www.xmission.com/~ddmayne2/10.2-live/v.0.0.2.8/
--
Douglas Mayne
Grant
>I have updated my project, "10.2-live" that I announced here:
There's a thread in lkml today: "is there a COW inside the kernel"
(COW: copy on write, search lkml.org for full text)
quote:
- - -
Not directly block-device-based cow, but unionfs is at least a
filesystem-based cow.
- - -
device-mapper snapshots?
Documentation/device-mapper/snapshot.txt
- - -
Say you have a read-only block-device (say a cd-rom) at /dev/hdc. And you have
a small disk partition, /dev/hdb1, that you want to use for your "COW file".
Run:
cow_size=`blockdev --getsize /dev/hdc`
chunk_size=64 # Size of each copied-on-write chunk, in 512 byte sectors
cow_name="my_cow_dev"
echo "0 $cow_size snapshot /dev/hdc /dev/hdb1 p $chunk_size" | \
dmsetup create $cow_name
This will give you a device called /dev/mapper/$cow_name. Presuming /dev/hdc
has a filesystem on it, you can mount /dev/mapper/$cow_name and get a ...
- - -
/quote
May be of interest to those following Douglas' project.
Grant.
--
Living in a land down under / Where women glow and men plunder / Can't you
hear, can't you hear the thunder? / You better run, you better take cover!
--Men At Work
Douglas Mayne
Thanks for the tip. I'll check it out. Device mapper looks to be
getting a lot of attention now: dm-crypt over cryptoloop, lvm, etc. Now,
copy on write, good. All of this should be good for building consistent
syntax among various devices.
I am no expert on unionfs, but it appears they may have a head start over
COW. The job it does is not trivial, but probably the unionfs source
could be integrated using dm.
BTW, one of the next things I am going to add to my project is multiple
sources for the RO component. That way, double-layer DVD's with
their 8.5G capacity could serve as the RO device, with pieces in chunks
which meet the max. size criteria for optical media.
--
Douglas Mayne
Mikhail Zotov
> I have updated my project, "10.2-live" that I announced here:
> That web page will be used from now on for posting notices and files
> related to the project.
Douglas, could you please state clearly the main goal of the project
and how it differs from (many) other Slackware-based live CDs.
Regards,
Mikhail
Douglas Mayne
First off, one of the main goals of my project is to have a lot of fun ;-)
CAUTION: This is a fairly long post. I would like to be able to clearly
and concisely state the main goal of this project, but there isn't a
single goal. The field of what is possible with live CDs is broad and
rapidly changing.
I have written an introduction in the project's README:
http://www.xmission.com/~ddmayne2/10.2-live/v.0.0.2.8/10.2-live/README
I'll admit that file is also a bit long, but _short_ on specifics of
how my project could be used. The bulk of that file deals with the
instructions for using the bootable CD/project. This post will try to
provide some examples of how my project can be used, and hopefully answer
your question by comparing it with other live CDs.
The first thing you may notice about my project, is that there's not
a lot to it. It's simple. My project demonstrates the necessary
elements for making your own live CD. Hell, if I could do it, how
hard could it be? This is because the main components are already in
place; the key components are the boot loader, the Slackware distribution,
the unionfs, and busybox. These components are mature and work (mostly) as
advertised. If the user is so inclined, the user can "do it for
himself," using this as a guide. The same way that I used Slackware
10.0 disc 2 (and other things) as my starting point.
As I worked developing my project, I noticed some interesting working
environments that are possible when using the unionfs as a root
filesystem. These working environments include the rescue
environment (the bootable CD which is available for download) and a fully
functional complete setup of Slackware 10.2. The latter is possible using
your own setup of Slackware 10.2 (out of the box, no changes necessary).
I'll explain more how this could be done below.
You asked me to compare other live CDs. First, the goals of my project
are quite different from the goals of the famous live cd's. Their primary
goal is to allow users to try out a full install of GNU/Linux without
installing anything on the user's hard disk. To make the demonstation as
convincing as possible, they need to include as many components/packages
on the CD/DVD as possible. The secondary goal is to achieve the primary
goal as smoothly as possible, even for users without any technical
expertise. They need to make a good first impression on potential new
GNU/Linux users to entice them to switch OSs. Those are difficult goals,
but the Slax and Knoppix projects achieve them, IMO.
You are probably familiar with the above projects (they're famous), so,
back to my project. My project started as a replacement for Slackware
10.0, disc 2. Slackware 10.2 does not include a disc with similar
functionality to the earlier version. My first attempt to update the
rescue disc resulted in a bootable CD, but requiring a fairly large
initial ramdisk. The immediate effect of this size was for the to have a
hardware requirement of about 256M RAM, that just to run the rescue disc.
I had tried Knoppix and Slax, so I decided to switch from using a large
initial ramdisk and "go live."
Previously (Dec. 2004), I had experimented with running Slackware inside a
loopback file,
http://groups.google.com/group/alt.os.linux.slackware/msg/032f33d74178ee0d
so I knew it would work and that it would be fully functional. I did a
quick and dirty prototype which further verified that it would work.
Grant didn't think my initial code was very good- he rated it with this
:o) mark. I tried to fix that code- accomplishing what the prototype
had done, but in a more general and (somewhat) more user-friendly way.
That is the origin of this project.
This project is designed to mount the root filesystem using the unionfs
so that Slackware's init can simply take over from there. The root
filesystem is combined from a readonly and readwrite components, using the
unionfs. For example, on my bootable CD I have these packages installed on
a loopback file:
http://www.xmission.com/ddmayne2/10.2-live/v.0.0.2.8/10.2-live/packages
This loopback is mounted as the readonly component. Combine this with
an overlaid RW layer, and /* presto */ you have a working rescue
environment.
The RO component can also be set to use a device without a loopback. This
means it can work with a fully setup Slackware distribution as the
readonly layer. Combine that with a RW layer, and /* presto */ a fully
functional system with an immutable layer. This could be used in
various ways. Here are some examples:
1. As a test environment which could be easily "rolled" back to its
previous state. Software can be compiled and installed, tested, and
extracted from the RW layer. This is similar to what Slacktrack does,
but since the changes are encapsulated in the RW layer, it's even simpler
to identify changes.
2. As an alternative to using "trip-wire" on firewalls. If a firewall's
software is stored in the readonly layer, then the only changes to the
system will be in the RW layer, which should include the /var/logs and
any software patches applied. If anything else is present, then that is
an indication that the system may be compromised.
3. As a total desktop replacement. If your personal data (your home
directory, etc) can fit within the size provided by the current
generation of USB flash memory, then your "computer" can go with you.
For example, I have more than one workstation. Setting them up with
Slackware was easy, but keeping them in sync is difficult. Their home
directories are divergent. USB flash may provide the solution. This
would redefine what the user views as "his" computer, shifting the focus
from the machine to the flash drive. The act of plugging in the flash
module will effectively give that computer its identity. Of course, this
assumes the trusted RO layer has been setup, but as I said, setting up
Slackware is easy.
4. YMMV. The above ideas have been tested, but minimally.
My project has shown these modes of operation are possible, and with
little or no speed penalty introduced by using unionfs. My project is
aimed more towards technically savvy users. That seems to align with
the Slackware community in general. When I decided that was my target
audience, that enabled a simplified design that the famous live CDs
could not use. Therefore, my project trades user friendliness and
automatic functionality for more power in the hands of the end user. It
gives more options which enable using hardware in the best
possible or most efficient way. For example, some things are built into
my project from the outset that the famous live CDs have had difficulty
adding on. They have tried to add "save user settings," but that still
remains a difficult task (AFAICT). This was a design feature of this
project from the outset.
As I said, you can use this project combined with your own real setup of
Slackware 10.2. That gives the ability to run as close to "slackware,
proper"- as possible, not someone else's idea or a close facsimile. I'd
classify Slax as a Slackware facsimile. But to be clear, Slax and this
project, are both Slackware derivatives:
http://www.xmission.com/~ddmayne2/10.2-live/index.html#project
The specifics of how this is done:
0. Have Slackware 10.2 setup on you local hard disc. Also, know which
partition it is using as root when booted normally.
1. Download a bootable CD for my project. You can use either the rescue CD
or the minimal CD with no loopback.
2. Boot the CD and provide correct answers to how you intend to use your
hardware. Specify your hard disks partition with the Slackware root as
the readonly component, and not using any loopback encapsulation.
3. Complete boot and you should be up and running, using your full
Slackware 10.2 setup. However, sound will not be functional because
alsa-driver is not installed. I plan to remedy that problem in the near
future.
That's probably a long enough post for newsgroups. I invite
you to test it and see for yourself.
--
Douglas Mayne
Mikhail Zotov
> On Sat, 04 Mar 2006 04:42:58 -0800, Mikhail Zotov wrote:
>
> > Douglas Mayne wrote:
> >> I have updated my project, "10.2-live" that I announced here:
> > ...
> >> That web page will be used from now on for posting notices and files
> >> related to the project.
> >
> > Douglas, could you please state clearly the main goal of the project
> > and how it differs from (many) other Slackware-based live CDs.
> >
> First off, one of the main goals of my project is to have a lot of fun ;-)
A good start, IMHO :-)
> CAUTION: This is a fairly long post.
No problem. :-)
> I would like to be able to clearly
> and concisely state the main goal of this project, but there isn't a
> single goal. The field of what is possible with live CDs is broad and
> rapidly changing.
>
> I have written an introduction in the project's README:
> http://www.xmission.com/~ddmayne2/10.2-live/v.0.0.2.8/10.2-live/README
Yes, I read it before posting the questions.
> The first thing you may notice about my project, is that there's not
> a lot to it. It's simple. My project demonstrates the necessary
> elements for making your own live CD. Hell, if I could do it, how
> hard could it be? This is because the main components are already in
> place; the key components are the boot loader, the Slackware distribution,
> the unionfs, and busybox. These components are mature and work (mostly) as
> advertised. If the user is so inclined, the user can "do it for
> himself," using this as a guide.
I haven't found any build scripts though that can be used, e.g., to
build a similar live CD based of Slackware-current.
> The same way that I used Slackware
> 10.0 disc 2 (and other things) as my starting point.
This was a great disc, IMO.
> You asked me to compare other live CDs. First, the goals of my project
> are quite different from the goals of the famous live cd's.
...
> They need to make a good first impression on potential new
> GNU/Linux users to entice them to switch OSs. Those are difficult goals,
> but the Slax and Knoppix projects achieve them, IMO.
Yes, I have recently found that the latest version of Slax dealing with
a hp pavilion much better than Slackware-current. Perhaps, this is due
to a 2.6 kernel used.
> You are probably familiar with the above projects (they're famous), so,
> back to my project. My project started as a replacement for Slackware
> 10.0, disc 2.
Sounds really interesting to me.
...
> The RO component can also be set to use a device without a loopback. This
> means it can work with a fully setup Slackware distribution as the
> readonly layer. Combine that with a RW layer, and /* presto */ a fully
> functional system with an immutable layer. This could be used in
> various ways. Here are some examples:
>
> 1. As a test environment which could be easily "rolled" back to its
> previous state. Software can be compiled and installed, tested, and
> extracted from the RW layer. This is similar to what Slacktrack does,
> but since the changes are encapsulated in the RW layer, it's even simpler
> to identify changes.
>
> 2. As an alternative to using "trip-wire" on firewalls. If a firewall's
> software is stored in the readonly layer, then the only changes to the
> system will be in the RW layer, which should include the /var/logs and
> any software patches applied. If anything else is present, then that is
> an indication that the system may be compromised.
Do you mean one can install a program not present on the CD to a hard
drive and have it running from there? How will, e.g., /usr/bin be
shared between the RO and RW layers?
> The specifics of how this is done:
>
> 0. Have Slackware 10.2 setup on you local hard disc. Also, know which
> partition it is using as root when booted normally.
...
>
> That's probably a long enough post for newsgroups. I invite
> you to test it and see for yourself.
Blame me but I wasn't sure the project is worth a 150Mb download,
burning a CD, etc. Now, expect another download from the RU domain. ;-)
Thank you for the interesting post!
--
Mikhail