Finally, there is A livecd based on the Fedora Core 5 Test 3 available
Thanks to JonFautley.
About the Live CD
The liveCD is gnome-based only.
Language & Keyboard settings : french (fr)
ISO size: 694.2 MB
License: same as Fedora Core 5 Test 3
why french? because i had already an iso for a French project and to
promote FC5 as well.
Ill replace the iso during the weekend by an ENGLISH version.
username = root
password = fedora
If your favorite packages are not in the livecd or it does not support
your language, you can still create your own Fedora Core 5 Test 3 live
cd with Kadischi.
Support for writing a release note during the enhancement of this
livecd is welcome. ;)
Chitlesh, the patch is attached.
Try this instead. I've tested it here and it works fine.
I also do have working Xen CDs. So do not forget to post the output
from a previous mail.
I've got Xen kernels booting from our LiveCD medias, and I'll attach the
There are a few things I'd like to go over though, if anyone has any
The main concerns I have are:
1) The dom0_mem= allocated values.
2) The ramdisk_size= values specified at 10000
3) The naming convention for the labels.
Chitlesh stated the other day he recieved "no space left on device" errors
and I would assume that is because of the tiny ramidsk_size allocated.
Chitlesh, what was the memory specs in the machine you were using when
Also, with the dom0_mem= values, 65536 (64MB) is surely too small.
However, we can't expect anyone running a LiveCD to have gigabytes of
RAM tucked into thier
machines. Likewise you can't expect to run Xen for any real purpose
without enough RAM either.
If we could get some opinions on this, that would be great.
As it stands, the patch works great for non-Xen and Xen kernels and will
decide what to
do considering what kernel was in fact installed. Perhaps a few others
can test this and
send some feedback that would be good.
If you've been using Kadishci under Fedora Core 4 and under Fedora Core
you will notice Kadischi's post_install_script 01umountproc.sh fails
under Fedora Core 5 tests.
I do not know if this has to do with Anaconda neccessarily as being a
bug, or something that has simply changed.
If we could get some info on why the rootdir/proc isn't mounted any
longer, we could probably move
towards replacing 01umountproc.sh with 01prelink.sh and in prelink,
maybe just check if rootdir/proc is mounted
and unmount it if so, this would allow for prelinking the system root
before writing to a CD and
unmount rootdir/proc if neccessary, but not fail if not. Perhaps we
could put this on the Schedule
so it can be done sooner than later, without breaking anything between
FC4/5 when Fedora Core 5 is in fact released.
Chitlesh, I am also curious about the organization of the
I'm not so positive all users of Kadischi would want autologin features
with blank passwords.
Could you verify that this is for a Fedora provided Live media rather
than something that should be put in Kadischi
in general, and if so split the Schedule to reflect that, it will be
less confusing for those interested in
what is to be done. If these _are_ in fact features that should be in
Kadischi, then just notify the list so
Is anyone aware of/if busybox-anaconda when job control option for ash
off? I see in even the Fedora Core 4 latest busybox-anaconda that this
option is not set.
I'm curious if anyone on the list knows if or when this was disabled.
I am pretty sure it is the culprit of the problem I am running into as
Xen kernels are installed and the initrd is created fine, along with
doing everything neccessary
in install-boot.sh.. upon bootstrapping the CD using the Xen kernel
halting occurs as soon as
ash, busybox.anaconda's builtin feature is invoked.
Jeremy could possibly provide some information on this issue.
The message I am getting is: /bin/sh: could not access tty: job control
Other than that, invoking /linuxrc by hand continues the process though
this problem needs to be investigated, of course we cannot invoke
linuxrc by hand.
I'd like to ask:
Please add the files
codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
from the /usr/share/aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
1) Are the above steps useful/no good?
configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:44: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT
configure.ac:45: error: possibly undefined macro: AC_PROG_INTLTOOL
2) Does those errors occur at your end?
I'm sitting here and have read over the small document in the syslinux
for using multiboot standard kernels. It entails simply using the
mboot.c32 as a kernel
and loading the rest as appropriate.
Since the kernel Xen packages have been going through a naming scheme
(kernel-xen-(hypervisor|guest) and kernel-xen(0|U))
the current functions.py is incorrect and will be changed once again.
The relevant kernel changelog entries for this convention are:
- Rename kernel-xen-(hypervisor|guest) to kernel-xen(0|U) for consistency
with upstream and to make kernel subtype suffixes match the subpackage
Dated March 6th, 2006.
I am asking for your opinions however on the use of the Xen kernels with
There are two ways I see this happenning, let me explain.
1) In functions.py, if we resolve the kernel to be a xen0 kernel, set
kernel_is_xen to True
within the existing get_kernel_version() function. Likewise in
kadischi.py pass the value of kernel_is_xen to
install-boot.sh as a 4th argument(There are three now, sysdir, csysdir,
While in install-boot.sh we could simply evaluate kernel_is_xen for True
and set isolinux.cfg appropriately while also copying the neccessary
files from the syslinux
tree, to $csysdir/boot/isolinux.
This requires changing 3 documents within the kadischi module.
(functions.py, kadischi.py and install-boot.sh)
2) In install-boot.sh simply grep, awk or otherwise parse the $kernel
for a "xen0" string
since the kernel version will have already been established and of
course add the extra
block for writing isolinux.cfg (bash if - else).
This requires modifying one document in the Kadischi module.
I'll also be re-updating functions.py tonight, I certainly didn't check
the naming scheme
since I had modified functions.py to resolve kernel-xen-hypervisor
kernels correctly, since March 6th.
These are the two methods I see as plausible and I am liking option #2
as it requires
the least number of modifications.
CVS updates were committed for the documented bugs #169812 and #178623
if you are subscribed to the fedora-cvs-commits list you will recieve
the full manifesto.
For those not subscribed the changes have been committed, please update
if you are working with Kadischi from CVS.