Bug 810005 - network installs fail due to incorrect parsing of command line parameters
network installs fail due to incorrect parsing of command line parameters
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
Unspecified Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F17Beta/F17BetaBlocker
  Show dependency treegraph
 
Reported: 2012-04-04 17:00 EDT by Tim Flink
Modified: 2012-05-03 12:08 EDT (History)
15 users (show)

See Also:
Fixed In Version: anaconda-17.20-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-11 13:22:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Flink 2012-04-04 17:00:37 EDT
I attempted to do a pxe install with F17 beta RC3 using the following command line:
initrd=/images/F17b-rc3/initrd.img console=ttyS0,38400 console=tty0 repo=http://192.168.0.5/cblr/ks_mirror/f17b-rc3-x86_64/ rd.debug ks=http://192.168.0.5/cblr/svc/op/ks/profile/f17b-rc3 BOOT_IMAGE=/images/F17b-rc3/vmlinuz

I end up seeing:
    [ 9.203018] udevd[264]: renamed network interface eth0 to em1
    [ 9.333161] ADDRCONF(NETDEV_UP): em1: link is not ready
    [ 13.161863] tg3 0000:3f:00.0: em1: Link is up at 1000 Mbps, full duplex
    [ 13.162062] tg3 0000:3f:00.0: em1: Flow control is off for TX and off for RX
    [ 13.203335] ADDRCONF(NETDEV_CHANGE): em1: link becomes ready
    [ 21.103726] dracut: anaconda fetching kickstart from http://192.168.0.5/cblr/svc/op/ks/profile/f17b-rc3
    [ 21.684878] dracut: anaconda fetching installer from http
    [ 21.704212] dracut Warning: can't find installer mainimage path in .treeinfo
    [ 22.262295] dracut: anaconda fetching installer from http
    [ 43.062147] dracut Warning: Unable to process initqueue
    [ 43.078239] dracut Warning: /dev/root does not exist
    [ 43.093263] dracut Warning: /dev/root does not exist

before the boot fails and I end up at the dracut shell.

According to wwoods, the repo= parameter is not being parsed correctly and any network install without live= or stage2= will fail to boot when it can't find the files it needs to continue booting
Comment 1 Tim Flink 2012-04-04 17:10:55 EDT
It appears possible to workaround this bug by adding:
root=live:http://path/to/repo/LiveOS/squashfs.img

If that is added in addition to repo=http://repo, the installer boots correctly with pxe
Comment 2 Kamil Páral 2012-04-05 03:42:39 EDT
repo=nfsiso is also broken:
https://bugzilla.redhat.com/show_bug.cgi?id=806708#c16
Comment 3 Kamil Páral 2012-04-05 03:50:23 EDT
(In reply to comment #2)
> repo=nfsiso is also broken:
> https://bugzilla.redhat.com/show_bug.cgi?id=806708#c16

If I add root=live:nfs it seems to work correctly. So this is available as a workaround.
Comment 4 Will Woods 2012-04-05 12:26:27 EDT
repo={http*,ftp,nfs*} are all broken, because this line:
  splitsep ":" "$root" prefix repo
should set repo to "anaconda-net:http://host/path/to/repo", but instead it's "http" due to a bug in dracut.

We added a workaround in anaconda (commit 844c0c1) and I'm sending a fix upstream.
Comment 5 Adam Williamson 2012-04-05 15:40:27 EDT
*** Bug 810136 has been marked as a duplicate of this bug. ***
Comment 6 Adam Williamson 2012-04-05 15:44:16 EDT
So this is also causing preupgrade fail - #810136.

We could also use the root= workaround for this bug, like so:

root=live:UUID=(sameuuidastheothers) rd.live.dir=upgrade

except when you do that, you hit a further bug where dracut mounts the target system's /boot at /run/initramfs/live and then anaconda tries to mount it at /mnt/sysimage/boot , and things fall over.

So the workaround which actually works is to pass:

root=live:http://path/to/squashfs.img (it's in LiveOS/ on the mirrors)

I have tested that just adding this, pointing to a repo with a new enough anaconda build, makes preupgrade succeed. However, it does require network access to work, and it's not at all obvious. You could only possibly 'figure it out' by reading the docs (we would, of course, put this in CommonBugs).

It's not realistically possible to workaround this in preupgrade; it will need fixing on anaconda side.

So, we can either ship and document the workaround, or we can slip for this.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 Adam Williamson 2012-04-05 15:45:17 EDT
Nominating as Beta blocker again since we now know it breaks preupgrade.
Comment 8 Tim Flink 2012-04-05 19:26:26 EDT
I just did a successful preupgrade after replacing the stage2=... arg with:
root=live:DEVICE rd.live.dir=upgrade rd.live.ram

where DEVICE is the same UUID=<diskuuid> used elsewhere in the preupgrade args
Comment 9 Adam Williamson 2012-04-06 00:20:20 EDT
Discussed at 2012-04-05 go/no-go (http://meetbot.fedoraproject.org/fedora-meeting-1/2012-04-05/gono-go_continuation_f17_beta_rc3_part_two_or_three.2012-04-05-15.00.html ). We agreed that this bug constitutes a blocker as it breaks preupgrade, without a workaround that is sufficient enough to be considered acceptable. Criterion is "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria".



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Fedora Update System 2012-04-06 09:58:25 EDT
anaconda-17.19-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.19-1.fc17
Comment 11 Tim Flink 2012-04-06 13:08:04 EDT
I just did a PXE boot with an image built using anaconda-17.19-1 and everything booted without issue
Comment 12 Fedora Update System 2012-04-06 19:22:39 EDT
Package anaconda-17.19-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-17.19-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-5447/anaconda-17.19-1.fc17
then log in and leave karma (feedback).
Comment 13 Fedora Update System 2012-04-10 00:14:19 EDT
anaconda-17.20-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.20-1.fc17
Comment 14 Kamil Páral 2012-04-10 05:29:06 EDT
repo=nfsiso works in Beta RC4
Comment 15 Orion Poplawski 2012-04-10 11:46:40 EDT
cobbler pxe boot install retrieves the squashfs.img fine for me with RC4.
Comment 16 Fedora Update System 2012-04-11 13:22:13 EDT
anaconda-17.20-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Patrick C. F. Ernzer 2012-04-18 16:59:45 EDT
confirm, for plain installs, inst.repo=... works
for kickstart I also need inst.repo=... but I presume that's OK, at least for me it is.

(for others reading this, I used inst.repo=... instead of repo=... because an error output earlier told me the latter was deprecated)
Comment 18 Kamil Páral 2012-04-19 04:54:16 EDT
(In reply to comment #17)
> for kickstart I also need inst.repo=...

I don't think we want to change kickstart syntax. Will?
Comment 19 Orion Poplawski 2012-04-19 10:33:22 EDT
pxe kickstart install works fine for me without any extra boot args.
Comment 20 Patrick C. F. Ernzer 2012-04-23 10:06:38 EDT
(In reply to comment #19)
> pxe kickstart install works fine for me without any extra boot args.

Hmm, if it works fine for you we can presume some typo in my test. I do wonder what it might have been though. Below is my current PXE entry (the one which started working after addition of install.repo=... )

label F17-x86_64-ks
  MENU LABEL Fedora 17 x86_64 kickstart
  TEXT HELP
This will WIPE all your DISKS
  ENDTEXT
  IPAPPEND 2
  kernel images/F17-Beta-x86_64/vmlinuz
  append initrd=images/F17-Beta-x86_64/initrd.img inst.repo=ftp://hp-microserver.internal.pcfe.net/pub/redhat/Fedora/linux/releases/test/17-Beta/Fedora/x86_64/os ks=ftp://hp-microserver.internal.pcfe.net/pub/kickstart/F17-beta-x86_64-ks.cfg ksdevice=bootif


Orion, can you post yours for comparison?
Comment 21 Kamil Páral 2012-04-23 10:21:52 EDT
I think there is some misunderstanding. Patrick, I supposed you were saying you needed to modify kickstart contents. Using "inst.repo=" and "ks=" on boot cmdline is fine, that's expected.
Comment 22 Orion Poplawski 2012-04-23 10:59:24 EDT
append initrd=/images/fedora-16-x86_64/initrd.img ksdevice=bootif lang=  kssendmac text  ks=http://10.10.10.1/cblr/svc/op/ks/system/hammer

No need for inst.repo=, the url line is in the kickstart file.
Comment 23 Patrick C. F. Ernzer 2012-05-03 11:31:22 EDT
Orion, even when you drop 'text' from your kernel line? If yes, then PEBKAC on my side.
Comment 24 Orion Poplawski 2012-05-03 12:08:30 EDT
Yes, even without text.

Note You need to log in before you can comment on or make changes to this bug.