Two problems I'm having with kadischi.
First, the system never starts in runlevel 5, always 3. Somewhere
during the ISO creation process I get "cannot determine current
runlevel" which may be related.
Second, is there any way to create a non-root user? I don't want people
using the root account to log into the system.
I'm using the live CDs for teaching a Linux desktop class. So far, I've
been able to hack around, create the user after boot time and kick the
init level to 5, but that takes a few minutes times 10 machines or so I
have to do this on.
Mark Komarinski mark_komarinski(a)hms.harvard.edu
Sr. Research Systems Architect http://ritg.med.harvard.edu
Research IT Group
Harvard Medical School
Over the past week or so, I've become familiar with the Kadischi portion
of Kadischi (as opposed to anaconda) and put together squashfs support.
Unfortunately, I've been depending on cvs diff to generate a patch and
the cvs server is down right now. Does anyone have a pristine tree I
can diff against? If not, I'll tar up my tree later tonight and stick
them somewhere for others to look at.
The drawback of that is I had to make a few unrelated changes because
I'm creating a minimal install and certain pieces of kadischi make
assumptions of what software is installed in the image.
>anaconda_args are passed from kadischi.py.
>If it is empty, it is set to None.
Maybe this should be, but in my case I had the log statement clearly saying that anaconda_args is an  (empty array, tuple or sth. like that)
Don't ask me why, i added check against  as well ans maybe as you could have seen and now the installation asked me for iptables configuration and services to be started.
Just at this moment I had to leave the office to get my train home.
You will hear from me soon.
--- Jane Dogalt <jdogalt(a)yahoo.com> wrote:
> Actually it's called "Xorg -configure". That will generate an xorg.conf file
Actually this looks fairly interesting (because I went as far as googling, but
not quite as far as just reading knoppix scripts, which is obviously an
integral part of the final solution). I was googling to see whatever happened
to the read-edid program I used, and while it appears to be less than fully
maintained and robust, this appears to be the successor-
(note, despite the nongnu domain name, the tool in question advertises gpl-v2)
> that matches your vga (and sometimes monitor I think) hardware. Then you do
> some sed or python or perl to tune things like the user preferred resolution.
> I was using this feature immediately after it was released in XFree86 several
> years ago in a mandrake-8.0 livecd. Though my appliance only required
> so I didn't have to worry too much about how successfully the monitor probing
> (edid stuff) worked.
> Then if you want to, you can do some more scripting to replace nv with nvidia
> etc (assuming you've agreed to all their terms, etc...)
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
is there any change with rootpath of anaconda-18.104.22.168-1 ?
# anaconda --rootpath=/tmp/livecd-build_no4/system --m=nfs://bordeaux
anaconda: error: --rootpath option does not take a value
As I've seen that this one is new, it maybe could have a bug.
non zero (256) exit code.
This comes from chroot exiting with 32512 because /usr/sbin/authconfig
could not be found (in the chroot)
Unfortunately the scrips clean out the build tree, so I could not check
this out yet. (I will uncomment the cleaning and try again.
I am following the list and wanted to try kadischi yesterday.
After creating the repo the installation went fine, it printed:
anaconda has finished the job
and now python is consuming 100% CPU, but I can't find any information
what it is doing.
Have I missed something important?
A few seem to be interested in getting Kadischi-like stuff fused with
What we are looking from my point of view is this:
Just enabling a checkbox for building a LiveCD, which would require an
existing Ext2/3 partition to write to.
In this LiveCD payload must include Anaconda which can also from the CD
install to the HDD.
This makes little sense in my opinion, since rootpath doesn't do HDD
e.g. to even allow partitioning of a drive, to get a LiveCD written.
Can someone describe some ideas they may have for doing this?
Is there some clarity we can establish here?
I've tried to create a 32bit LiveCd with a 32-bit repository on an
x86_64 system a couple times and run into an error. After the isolinux
prompt I get this:
Uncompressing Linux... Ok, booting the kernel.
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
Kernel panic - not syncing: VFS: Unable to mount root fs on
This is under vmware which works for running 32bit images created on a
32bit system. I haven't burned one of these disks to a CD yet. The
first two lines are normal in that environment (running a LiveCD image
generated on a 32bit box brings up those two lines.) But the next line
is a sign that something is really not happy.
I suspect that something in the 64 bit environment is being copied from
the builder's hard drive to the LiveCd instead of coming from the 32bit
packages in my repository.
Is anyone else attempting to create 32bit ISOs on x86_64? Success or
failure reports would help me zero in on the problems.
A pair of patches to cleanup selinux disabling and adding squashfs
modules to the initrd. These are based on an irc conversation with
* kadischi.py: Install squashfs and loop modules insto the initrd only
if we are building a squashfs image. This is passed via a KMODULES
environment variable to livecd-mkinitrd.sh
* livecd-mkinitrd.sh: Modify the module searching to use values passed
* install-boot.sh: Remove the selinux=0 kernel parameter as we want a
more generic and finer grained option for the future.
* 04auth.sh: Use sed within the chroot to change the value of SELINUX=
in /etc/selinux/config to 'disabled' When we have a filesystem that
supports extended atributes, we can modify this behaviour by setting
SELINUXSTATE to enforcing, permissive, etc. A similar method can be
used to configure SELINUXTYPE (strict/targeted/mls) at that time as
* 05fsclean.sh: Add .autorelabel to the list of files to remove. We
can't relabel a read-only filesystem.