Bug 802042

 regret to confirm that proper F17 netboot with proper kernel, initrd and
squashfs from test/17-Alpha fail the same way on x86_64 machine with CentOS 6
in LVM in DOS partition table already installed. The problem seems to be
related to search for upgradable systems.

Unfortunately, on an empty disk, the x86_64 kernel fails with something like:

swapper/0 Not tainted 3.3.0-0.rc3.git7.2.fc17.x86_64

And with i386 it fails later when choosing network interfaces. The bad thing is
that the installer lets me choose the wired ethernet device and then lets me
choose from wireless networks (it scans them instead of just ignoring
wireless at all).

Somewhere on the way I also got HDIO_GET_IDENTITY failed (when using USB-to-IDE
cable to install on a USB disk). But I only have handwritten notes, so I don't
know the exact circumstances.

*** Bug 802041 has been marked as a duplicate of this bug. ***

This is what I'm using for pxelinux configuration:

LABEL fedora-test/17-Alpha-i386
    MENU LABEL Fedora test/17-Alpha Install i386
    KERNEL http://ftp.linux.cz/pub/linux/fedora/linux/releases/test/17-Alpha/Fedora/i386/os/images/pxeboot/vmlinuz
    APPEND root=live:http://ftp.linux.cz/pub/linux/fedora/linux/releases/test/17-Alpha/Fedora/i386/os/LiveOS/squashfs.img initrd=http://ftp.linux.cz/pub/linux/fedora/linux/releases/test/17-Alpha/Fedora/i386/os/images/pxeboot/initrd.img
LABEL fedora-test/17-Alpha-x86_64
    MENU LABEL Fedora test/17-Alpha Install x86_64
    KERNEL http://ftp.linux.cz/pub/linux/fedora/linux/releases/test/17-Alpha/Fedora/x86_64/os/images/pxeboot/vmlinuz
    APPEND root=live:http://ftp.linux.cz/pub/linux/fedora/linux/releases/test/17-Alpha/Fedora/x86_64/os/LiveOS/squashfs.img initrd=http://ftp.linux.cz/pub/linux/fedora/linux/releases/test/17-Alpha/Fedora/x86_64/os/images/pxeboot/initrd.img

By the way, who thinks LiveOS/squashfs.img is a good name for the installer image?

Moving to lorax, as it creates these structures.

These structures are all working:

LABEL Fedora with NFS exported ISO
      kernel release-export/vmlinuz
      append initrd=release-export/initrd.img inst.repo=nfs:10.0.1.16:/var/exports/fedora/install/F17-x86_64

LABEL Fedora with NFS Repo and http Kickstart
      kernel release-export/vmlinuz
      append initrd=release-export/initrd.img inst.ks=http://10.0.1.16:/cobbler/aux/ks-basic.cfg repo=nfs:10.0.1.16:/var/exports/fedora/install/\
F17-x86_64

LABEL Fedora Basic Netinstall, Using fp.o repo
      kernel release-export/vmlinuz
      append initrd=release-export/initrd.img root=live:http://10.0.1.16/cobbler/aux/squashfs.img

LABEL Fedora VNC attended Install 
      kernel release-export/vmlinuz
      append initrd=release-export/initrd.img root=live:http://10.0.1.16/cobbler/aux/squashfs.img inst.vnc inst.vncconnect=10.0.1.100:5500 inst.\
ks=http://10.0.1.16:/var/exports/fedora/ks/ks-autopart.cfg


As this bug appears to be on the options build into the release media, not the product itself, I will add that root=live:nfs:server:/path works now on TC2 and ks=nfs:server:/path does not appear to be functioning. Please advise if this is a non issue or a seperate issue.


I'm tracking this for inclusion in the release notes, and it would be nice to have some clarification. If anaconda needs the root image, I don't see the 'fix' for this bug other than to advise users to provide it.

(In reply to comment #4)
> By the way, who thinks LiveOS/squashfs.img is a good name for the installer
> image?

dracut requires that path/name, so that's what we're using. When dracut can take arbitrary path/names for the runtime image, we'll go back to using images/install.img.

(In reply to comment #6)

> As this bug appears to be on the options build into the release media, not
> the product itself, I will add that root=live:nfs:server:/path works now on
> TC2 and ks=nfs:server:/path does not appear to be functioning. Please advise
> if this is a non issue or a seperate issue.

ks=nfs:server:/path should work; file a bug if it doesn't.

> I'm tracking this for inclusion in the release notes, and it would be nice
> to have some clarification. If anaconda needs the root image, I don't see
> the 'fix' for this bug other than to advise users to provide it.

Yes, unless there is installer media in the CDROM drive, one of root=XXX, repo=XXX, or stage2=XXX is required. This is roughly the same behavior as in Fedora 14 and earlier.

We're updating the documentation for anaconda's boot options for Fedora 17. A draft can be found here:

  http://wwoods.fedorapeople.org/doc/boot-options.html

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.