Although I suspect this is a naive question,
Is it possible to specify a kickstart file upon boot of the liveCD? I am
interested in doing some non-interactive post-boot. Or, should I be using
something like cobbler/koan?
"Don't stand still, if you see me running down the road, 'cause there is
trouble right behind me".
Attached is an up to date revision of my turboLiveInst patch which
incorporates the suggestions made during MarkMC's review.
Mark's executive summary of the feature:
"Reduce installation time by not copying unused data to disk"
"We avoid copying unused data by copying a filesystem image that has
been reduced to the minimal possible size. This minimal image is not
sufficient for a running LiveCD as applications need room to write
more data, but the minimal image is efficiently created just before
copying by applying a pre-calculated set of deltas to the original
large filesystem image."
2nd revision post with performance numbers and decent descritpion:
(first two copy times are typo swapped)
Mark's comments thread:
The anaconda patch applies on top of the selinux bugfix I sent to
anaconda-devel this morning, but there is no overlap.
The main things I'll mention that aren't directly related to the review
- I included a couple typo fixes to the documentation, as well as adding
what seemed to be some appropriate additions.
- I included a slight cleanup of livecd-creator's resize2fsToMinimal.
As discussed in the above thread, since the dumpe2fs code is going into
anaconda for this patch, it seems to make sense to go ahead and include
it in livecd-creator as well to remove the blocksize argument to
resize2fsToMinimal, and have it calculate implicitly instead.
- I had to move the anaconda resize2fs invocation, as now the filesystem
starts out full, and before resize2fs cannot even have mountpoint
directories made in it. Even outside turboLiveInst this is a valid
thing to do.
- renamed the main function from turboLiveInst to genMinInstDelta
- removed option for ignore-deleted, and didn't bother with option for
turboliveinst. The liveinst.sh code gracefully handles the legacy
configuration of no delta file.
- still not yet being a rawhide user, I tested this on an F7 livecd
spin, generated with this git livecd-tools. I used the patch to patch
the installed anaconda. It worked in a test under qemu. (sparse disk
file with du -cms showed that only ~2.2G of data was written).
- I expect, that even just looking at it myself over the next couple
days I'll probably find one or two things to change. Please give me any
feedback about any possible improvements you can think of. If you have
a rawhide livecd spinning enironment handy and want to test it, that
would be greatly appreciated.
in the initramfs /init generated by mayflower-
exec < /dev/console > /dev/console 2>&1
mount -n -t tmpfs -o mode=0755 udev /dev
mknod /dev/console c 5 1
mknod /dev/null c 1 3
Is this a bug that /dev/console is being referenced before it is
created, or is there some obscure magic relating to /dev/console that I
am unaware of?
While I haven't by any means given up pursuit of my devicemapper
implementation of persistence, I wonder-
What do people think about using unionfs for persistence (and perhaps
Copy-On-Write in general) in Fedora LiveCDs?
I was somewhat surprised to discover a while back that ubuntu actually
used devicemapper for their COW long ago (early 2005). But that they
abandoned that in favor of the 'flexibility' of unionfs.
I know that unionfs was ruled out as an option for Fedora, because it
was being kept out of the repos. In fact, before pilgrim/livecd-creator
came into existence, I posted a proof of concept fedora unionfs-based
But a lot has changed in the last 18 months. It seems that unionfs is
in the -mm kernel tree, and between that, fuse-unionfs, and aufs, it
seems pretty likely that some flavor of unionfs will make it into fedora
in the foreseeable future.
Given that, and given the multitude of other projects I could be working
on, makes me wonder how much time I should spend working on devicemapper
persistence, if the vast majority of livecds out there are using
unionfs, and unionfs may become an option for fedora in the near future.
Based on the article:
It worked, a bit slow but It worked, I also mail some typo err on the
relative path for the kqemu called from the ubuntu.bat file need's to be
..\kqemu\.... on line 17. Anyway, since the script is pretty straight
forward and just call the iso, I figure will be possible to replace the
Ubuntu image with the Fedora image.
To my surprise the emulation worked and boot and show the first Fedora
graphic interface to choose how to boot the image, as soon as I select run
from Image, try to boot and get a Kernel Panic error.
Any suggestions on how to get the Fedora 7 LIveCD running from Windows with
THX in advance.
I've noticed a little problem when booting with selinux
enabled: /home/fedora/.bashrc would not be copied/created. When booting
with enforcing=0 all would be fine so I assume this is a selinux
problem. But I've found no entry in /var/log/messages
When I create a new user with adduser the bashrc is there.
Any suggestion how to debug this? I've attached audit.log and messages
if I've overlooked something (booted with selinux=1).
With the actual git version the produced livecds aren't bootable. In vmware it
After this it automatically reboots. Virtualbox or qemu are hanging at this
point. I've not testet a burned iso directly.
With GIT version of Revisor commit
0ad6a3da49ff75fbfcd5802c5b03de51d9d014ac, I got a problem:
Initting progress bar for Configure System
Setting SELinux to: 1
Setting crypted root password
Xorg is installed: True
Traceback (most recent call last):
File "/usr/sbin/revisor", line 293, in <module>
File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 45, in run
File "/usr/lib/python2.5/site-packages/revisor/base.py", line 894, in lift_off
File "/usr/lib/python2.5/site-packages/revisor/base.py", line 1367, in buildLiveMedia
File "/usr/lib/python2.5/site-packages/revisor/lm_optical.py", line 151, in extra_configuration
f = open("%s/etc/inittab" %(instroot,), "rw+")
NameError: global name 'instroot' is not defined
Is this a known problem/bug?
I've been trying to boot the F7 live-cd on a VIA Epia M-6000 (600Mhz
fan-less VIA C3 Eden processor). With the distributed live-cd
(Fedora-7-Live-i686.iso) the machine resets as soon as the kernel starts
(i.e right after the initrd is unpacked).
I built a custom i386 kernel with the VIA drivers and DMA turned off,
which got the kernel to boot. The problem I then have is that when init
should be executed, the system simply hangs and nothing happens. The
last line printed is "Freeing unused kernel memory".
I then built an entire livecd-fedora-minimal system from scratch and
still no joy (same problem where init doesn't run). I then replaced init
by a "hello world" program. If I statically link the hello world program
it happily prints "hello world", but if I dynamically link it it
doesn't. So it looks like /bin/bash (dynamically linked) doesn't run.
At this point I'm at the end of my fedora wisdom. I have previously
successfully booted a custom gentoo 2.6 kernel on this box, and the
ubuntu 6.06.1 system boots as well. I'd rather use fedora, though, and
would appreciate any suggestions either about what to try, or how to get
debug information about what fails when running a dyn linked executable.
NB: I was unsuccessful building the livecd-fedora-minimal system using
the provided kickstart. I had to add the following packages so that
livecd-creator could operate properly in the chrooted environment: nash,
cpio, gzip, findutils, and squashfs-tools.