11:25 p.m.
I am using a F9 host to build a F7 liveCD -- the School Server image
-- and I am finding that livecd-creator never manages to unmount the
temporary partition, and the resulting image fails to boot (tested
with qemu and on real hw).
When livecd-creator tries to unmount the CD, two processes are still
running - httpd, and a custom network daemon written in python. lsof
shows them as the only processes keeping files open. Once I kill those
processes, I can unmount cleanly.
Is this expected? Are any incompatibilities with F7 known? Should
livecd-creator try to run all the relevant init scripts with stop, and
perhaps run lsof to see if any programs need to be killed or
kill-9'ed?
The boot failures (fails to load the kernel modules, and kills init)
probably have to do with the image being incomplete.
This is the kickstart file I am using...
http://dev.laptop.org/git?p=projects/xs-livecd;a=blob;f=kickstarts/livecd...
cheers,
martin
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
1:21 a.m.
On Sat, Jul 26, 2008 at 4:25 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
I am using a F9 host to build a F7 liveCD -- the School Server image
-- and I am finding that livecd-creator never manages to unmount the
temporary partition, and the resulting image fails to boot (tested
with qemu and on real hw).
With a bit more work into it, I can resolve the unmounting issue by
stopping the daemons late in %post, however, the boot failures
continue.
They look like this:
Loading vmlinuz0...
Loading initrd0.img...
Ready.
Uncompressing Linux... Ok, booting the kernel.
PCI: PIIX3L Enabling Passive Release on 0000"00:01.0
Red Hat nash version 6.0.9 starting
insmod: error inserting '/lib/ehci-hcd.ko' : -1 File exists
insmod: error inserting '/lib/uhci-hcd.ko' : -1 File exists
insmod: error inserting '/lib/ohci-hcd.ko' : -1 File exists
stabilized: stat /proc/bus/usb/devices: No such file or directory
... and eventually ...
Kernel panic - non syncing: Attempted to kill init!
Any hints as to what to try next, doco or source to read?
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
10:25 p.m.
On Sat, Jul 26, 2008 at 6:21 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
Any hints as to what to try next, doco or source to read?
After a bit more investigation. the livecd-tools package in F9
(017.1-1.fc9) can only build F9 correctly, and the problem boils down
to incorrect placement of the .ko files in the initrd. Here is how to
repro with F9 vs F7. In my testing, F8 shows the same problems.
1 - Take the fedora-minimal.ks file and replace "rawhide" with
'fedora-9', 'fedora-7' - as follows:
--8<----8<----8<--
lang en_US.UTF-8
keyboard us
timezone US/Eastern
auth --useshadow --enablemd5
selinux --disabled
firewall --disabled
part / --size 1024
repo --name=released
--mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=$basearch
%packages
@core
bash
kernel
passwd
policycoreutils
chkconfig
authconfig
rootfiles
%end
--8<----8<----8<--
2 - Build one minimal Liveimage for each. The image should boot to a
login prompt - though it will not allow logins as no root pw has been
set.
3 - Boot the images with qemu -m 512 --cdrom <path-to-iso> -- the F7
iso will panic
4 - mount -o loop both ISOs, in my case in /tmp/f7 /tmp/f9 and extract
the initrd in each
5 - find initrd-7 initrd-9 -type f -name '*.ko'
initrd-7/lib/mbcache.ko
initrd-7/lib/sr_mod.ko
initrd-7/lib/msdos.ko
initrd-7/lib/ext3.ko
initrd-7/lib/ehci-hcd.ko
initrd-7/lib/uhci-hcd.ko
initrd-7/lib/pata_pcmcia.ko
initrd-7/lib/mmc_block.ko
initrd-7/lib/jbd.ko
(...snipped...)
initrd-9/lib/modules/2.6.25-14.fc9.i686/pata_jmicron.ko
initrd-9/lib/modules/2.6.25-14.fc9.i686/ata_generic.ko
initrd-9/lib/modules/2.6.25-14.fc9.i686/pata_qdi.ko
initrd-9/lib/modules/2.6.25-14.fc9.i686/sata_vsc.ko
initrd-9/lib/modules/2.6.25-14.fc9.i686/sata_sil24.ko
initrd-9/lib/modules/2.6.25-14.fc9.i686/pata_hpt366.ko
Additionally, I have a F7 liveCD built elsewhere (with an earlier,
patched version of livecd-tools) that boots successfully - the initrd
of that liveCD looks like
find initrd-7-good -type f -name '*.ko' | head
initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_jmicron.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/ata_generic.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_qdi.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/sata_vsc.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/sata_sil24.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_hpt366.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/mbcache.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/sata_sx4.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/pata_serverworks.ko
initrd-7-good/lib/modules/2.6.23.1-21.fc7/sr_mod.ko
I am not sure why this is happening, but I keep working on this.
regards,
martin
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
12:10 a.m.
On Sun, Jul 27, 2008 at 3:25 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
After a bit more investigation. the livecd-tools package in F9
(017.1-1.fc9) can only build F9 correctly, and the problem boils down
to incorrect placement of the .ko files in the initrd. Here is how to
repro with F9 vs F7. In my testing, F8 shows the same problems.
I tracked this down to the switch from mayflower to mkinitrd, which
lead me to commit
11dbd0bb5ba4b845e80109e990e4e780ca402218 where mayflower gets
installed and called during %post.
So I updated my ks file as below. This still fails to build a bootable
F8 or F7, both drop to an emergency shell after failing to find root
(see below for more details). I am using git's master for these
builds.
Current kickstart file
--8<----8<----8<--
lang en_US.UTF-8
keyboard us
timezone US/Eastern
auth --useshadow --enablemd5
selinux --disabled
firewall --disabled
part / --size 1024
repo --name=released
--mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=$basearch
%packages
@core
bash
kernel
passwd
policycoreutils
chkconfig
authconfig
rootfiles
# for live initrd
livecd-tools
# livecd bits to set up the livecd and be able to install
anaconda
#isomd5sum
%end
%post
# make the initrd we care about
rm -f /boot/initrd*.img
cp /etc/sysconfig/mkinitrd /etc/mayflower.conf
ver=`ls /boot/vmlinuz* |head -n 1 |sed -e 's;/boot/vmlinuz-;;'`
/usr/lib/livecd-creator/mayflower -f /boot/initrd-$ver.img $ver
rm -f /etc/mayflower.conf
%end
%post --nochroot
# move the initrd we created to be the booted one
mv $INSTALL_ROOT/boot/initrd-*.img $LIVE_ROOT/isolinux/initrd0.img
%end
--8<----8<----8<--
With this ks file, the initrd is now built correctly. But during boot
with F8 I see all sorts of odd errors:
WARNING: Bogus /etc/fstab file - cannot have /dev/root as the device for /
...
starting udevd
creating devices
waiting for system to settle
...
SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem
SQUASHFS error: Please update your kernel
mount: wrong fstype ...
Once on the shell, the dmesg output looks normal except for the
Squashfs errors, and ls /dev/ does not contain anything that looks
like a usable block device. Trying to mount /dev/loop0 gives me the
same squashfs error as before.
hmmmm? hints?
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
10:06 a.m.
On Sun, 2008-07-27 at 17:10 +1200, Martin Langhoff wrote:
On Sun, Jul 27, 2008 at 3:25 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
> After a bit more investigation. the livecd-tools package in F9
> (017.1-1.fc9) can only build F9 correctly, and the problem boils down
> to incorrect placement of the .ko files in the initrd. Here is how to
> repro with F9 vs F7. In my testing, F8 shows the same problems.
I tracked this down to the switch from mayflower to mkinitrd, which
lead me to commit
11dbd0bb5ba4b845e80109e990e4e780ca402218 where mayflower gets
installed and called during %post.
Yes, if you are building for newer than Fedora 9's mkinitrd, then you
have to do the initrd build by hand as you've done. This is because
this had no place being in livecd-creator to begin with really. I
updated the stock configs and put blinking warnings in the commit log
for that reason :-)
WARNING: Bogus /etc/fstab file - cannot have /dev/root as the device
for /
This is a warning that I should just kill. In fact, done :-)
...
starting udevd
creating devices
waiting for system to settle
...
SQUASHFS error: Major/Minor mismatch, trying to mount newer 3.1 filesystem
SQUASHFS error: Please update your kernel
mount: wrong fstype ...
squashfs is (still) notorious about changing things, unfortunately --
although I'd think that the current F7 update kernel would have a new
enough squashfs in the kernel for the squashfs-tools.
Unfortunately, the only real way to be able to handle this is
1) Install an older version of squashfs-tools on your build host
2) Build your image without compression (--skip-compression)
3) Have a kernel with a newer squashfs kernel module
Jeremy
9:08 a.m.
Martin Langhoff <martin.langhoff <at> gmail.com> writes:
I am using a F9 host to build a F7 liveCD -- the School Server image
How about not running the school server on an OS which gets no more upgrades,
not even critical security upgrades??? Fedora 7 is no longer supported, so of
course there will be no efforts made to make modern live CD tools work with it.
Kevin Kofler
10:01 a.m.
On Sat, 2008-07-26 at 16:25 +1200, Martin Langhoff wrote:
When livecd-creator tries to unmount the CD, two processes are still
running - httpd, and a custom network daemon written in python. lsof
shows them as the only processes keeping files open. Once I kill those
processes, I can unmount cleanly.
Is this expected?
If you start a process in your %post, then you need to clean up after
yourself at the end of %post
Are any incompatibilities with F7 known? Should
livecd-creator try to run all the relevant init scripts with stop, and
perhaps run lsof to see if any programs need to be killed or
kill-9'ed?
How do you know what's relevant? Packaging policy states (for reasons
including this one) that services shouldn't be started in the %post of a
package install. Which means that it's something you're starting
yourself. Which means you need to kill it off also.
The boot failures (fails to load the kernel modules, and kills init)
probably have to do with the image being incomplete.
Will leave this as a reply for some of your later mails...
Jeremy
2:30 p.m.
On Tue, Jul 29, 2008 at 3:01 AM, Jeremy Katz <katzj(a)redhat.com> wrote:
On Sat, 2008-07-26 at 16:25 +1200, Martin Langhoff wrote:
> When livecd-creator tries to unmount the CD, two processes are still
> running - httpd, and a custom network daemon written in python. lsof
> shows them as the only processes keeping files open. Once I kill those
> processes, I can unmount cleanly.
>
> Is this expected?
If you start a process in your %post, then you need to clean up after
yourself at the end of %post
The custom network daemon I am ready to take blame for, but what is
intriguing is that httpd - from the standard httpd rpm - starts and is
left running. Perhaps I'm doing something wrong.
> Are any incompatibilities with F7 known? Should
> livecd-creator try to run all the relevant init scripts with stop, and
> perhaps run lsof to see if any programs need to be killed or
> kill-9'ed?
How do you know what's relevant? Packaging policy states (for reasons
including this one) that services shouldn't be started in the %post of a
package install. Which means that it's something you're starting
yourself. Which means you need to kill it off also.
Hmmm. httpd might be buggy in that regard. We are also installing
mod_perl, mod_python and mod_php, any of those might be trying to
(incorrectly) reload httpd.
> The boot failures (fails to load the kernel modules, and kills
init)
> probably have to do with the image being incomplete.
Will leave this as a reply for some of your later mails...
- thanks!
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
5758
days inactive
5760
days old
7 comments
3 participants
participants (3)
-
Jeremy Katz -
Kevin Kofler -
Martin Langhoff