Bug 209284
| Summary: | ksdevice=bootif option broken | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Terje Rosten <terjeros> |
| Component: | anaconda | Assignee: | David Cantrell <dcantrell> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 5.0 | CC: | atodorov, ddomingo, djuran, drussell, justin, k.georgiou, tao, tscherf |
| Target Milestone: | --- | Keywords: | OtherQA, Regression |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2007-0644 | Doc Type: | Bug Fix |
| Doc Text: |
When booting Anaconda with PXE using the parameter ksdevice=bootif, you will still be prompted for the ethernet interface to use during installation. If only one ethernet device is plugged in, use the parameter ksdevice=link instead.
Alternatively, you can also specify the interface manually.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-11-07 17:18:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 197865, 227613 | ||
| Attachments: | |||
|
Description
Terje Rosten
2006-10-04 10:56:12 UTC
More info: o works in RHEL 4 Update 4, here eth1 is picked up by ksdevice=bootif, kickstart file has: network --device=eth0 ... o does not work in RHEL 3 Update 8. o ksdevice=link works in RHEL 3 Update 8, kickstart file has: network --device=eth0 ... o ksdevice=link don't work in RHEL 5 Beta 1 when network section in kickstart file has --device=eth0 while link device during install is eth1. Seems like when the installler get --device=eth0 from kickstart file it try to set it up eth0 *during* install, but eth1 already has that IP address and routes etc becomes confused. Setting flags... This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. As far as I can see this is fixed. Please re-test with Beta2 > As far as I can see this is fixed. Please re-test with Beta2 Still not working, hardware is SunFire V20z with two onboard broadcom nics and a extra Intel nic (PCI). The pxeboot is from first Broadcom nic with MAC: 0:9:3d:13:50:d6. Logging from console: PXELINUX 3.31 0x4518b206 Copyright (C) 1994-2005 H. Peter Anvin UNDI data segment at: 00090590 UNDI data segment size: 4CA0 UNDI code segment size: 4CFC UNDI code segment size: 4CFC PXE entry point found (we hope) ootdata ok (command line is initrd=initrd.img-rhas5.0b2-x86_64 ksdevice=bootif noipv6 network ks=http://webserver/ks/ console=tty0 console=ttyS0,9600n8 root=/dev/ram0 ide0=noprobe ide1=noprobe BOOT_IMAGE=vmlinuz-rhas5.0b2-x86_64 BOOTIF=01-00-09-3d-13-50-d6 ) Linux version 2.6.18-1.2747.el5 (brewbuilder.redhat.com) (gcc ve rsion 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Thu Nov 9 18:52:11 EST 2006 BIOS-provided physical RAM map:4.................................. BIOS-e820: 0000000000000000 - 0000000000099c00 (usable)........................ BIOS-e820: 0000000000099c00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007ff70000 (usable) BIOS-e820: 000000007ff70000 - 000000007ff77000 (ACPI data) BIOS-e820: 000000007ff77000 - 000000007ff80000 (ACPI NVS) BIOS-e820: 000000007ff80000 - 0000000080000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) DMI present. SRAT: PXM 0 -> APIC 0 -> Node 0 SRAT: PXM 1 -> APIC 1 -> Node 1 SRAT: Node 0 PXM 0 0-a0000 SRAT: Node 0 PXM 0 0-40000000 SRAT: Node 1 PXM 1 40000000-80000000 Bootmem setup node 0 0000000000000000-0000000040000000 Bootmem setup node 1 0000000040000000-000000007ff70000 ACPI: PM-Timer IO Port: 0x8008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:5 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfd000000] gsi_base[24]) IOAPIC[1]: apic_id 3, version 17, address 0xfd000000, GSI 24-27 ACPI: IOAPIC (id[0x04] address[0xfd001000] gsi_base[28]) IOAPIC[2]: apic_id 4, version 17, address 0xfd001000, GSI 28-31 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) Setting APIC routing to physical flat ACPI: HPET id: 0x102282a0 base: 0xfed00000 Using ACPI (MADT) for SMP configuration information Nosave address range: 0000000000099000 - 000000000009a000 Nosave address range: 000000000009a000 - 00000000000a0000 Nosave address range: 00000000000a0000 - 00000000000d2000 Nosave address range: 00000000000d2000 - 0000000000100000 Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000) SMP: Allowing 2 CPUs, 0 hotplug CPUs Built 2 zonelists. Total pages: 515540 Kernel command line: initrd=initrd.img-rhas5.0b2-x86_64 ksdevice=bootif noipv6 ne twork ks=http://webserver/ks/ console=tty0 console=ttyS0,9600n8 root=/ dev/ram0 ide0=noprobe ide1=noprobe BOOT_IMAGE=vmlinuz-rhas5.0b2-x86_64 BOOTIF=01-00-09-3d-13-50-d6 ide_setup: ide0=noprobe ide_setup: ide1=noprobe Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) start_kernel(): bug: interrupts were enabled early Console: colour VGA+ 80x25 [snip] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled ÿÿserial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ÁÁéÁéÑÑåMÁÑ%½=ÁáÍá¡¥ÉÅõÑ¥¥ÍÅÙÕÕÁ5)ÿRAMDISK driver initialized: 16 R AM disks of 16384K size 4096 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Welcome to Red Hat Enterprise Linux Server +---------------------+ Networking Device +----------------------+ | | | You have multiple network devices on this system. Which | | would you like to install through? | | | | eth0 - Intel Corporation 82557/8/9 [Ethernet Pro 100] | | eth1 - Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet | | eth2 - Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet | | | | +----+ +------+ | | | OK | | Back | | | +----+ +------+ | | | | | +----------------------------------------------------------------+ <Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next screen I just checked and this bug is still present in the RHEL-5 nightly trees, today's tree being the one I checked. Will investigate this problem for RHEL 5.1. Setting flag. This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP. We need something in the release notes for this. Setting flag. An update... The code for ksdevice=bootif in both RHEL-4 and RHEL-5 require the user to provide the BOOTIF= parameter specifying the MAC address of the interface to use. Loader has no code to determine the boot interface used for PXE. The ksdevice=link parameter instructs loader to find the first network interface with an active link. So, to use ksdevice=bootif, you must also pass BOOTIF with the MAC address of the interface to use: ksdevice=bootif BOOTIF=xx:xx:xx:xx:xx:xx The capitalization of the the arguments is important, BOOTIF must be written in upper case. > So, to use ksdevice=bootif, you must also pass BOOTIF with the MAC address of > the interface to use: > > ksdevice=bootif BOOTIF=xx:xx:xx:xx:xx:xx No! This is not the case, it's *pxelinux* job to add the BOOTIF parameter, and it do nicely, see the log in comment #6: command line is initrd=initrd.img-rhas5.0b2-x86_64 ksdevice=bootif noipv6 network ks=http://webserver/ks/ console=tty0 console=ttyS0,9600n8 root=/dev/ram0 ide0=noprobe ide1=noprobe BOOT_IMAGE=vmlinuz-rhas5.0b2-x86_64 BOOTIF=01-00-09-3d-13-50-d6 Right, my mistake. Was unclear in my description. OK, so digging back through the RHEL-4 code and comparing it to the RHEL-5 code, it looks like this is what happened: The sanitizeMacAddr() function in libisys would automatically convert every third character in the MAC address in BOOTIF to a colon so it could be used directly as a MAC address later. That's not present in the RHEL-5 code. Sorry for all the confusion from me. Was trying to fully understand what was happening and the one line that handled the transposition of - to : in RHEL-4 was hiding well. Patching RHEL-5 anaconda. Will post patch shortly. Created attachment 149648 [details]
patch to loader in RHEL-5 to handle BOOTIF args correctly
Patch for loader in RHEL-5's anaconda. The argument handed to us in the
BOOTIF= parameter is taken as is. This patch converts the hyphens to colons.
Very trivial.
If you'd like an initrd.img to test this patch with, let me know and I can
prepare one for you for the RHEL-5 GOLD tree.
> If you'd like an initrd.img to test this patch with, let me know and I can
> prepare one for you for the RHEL-5 GOLD tree.
Yeah, that would be great!
Created attachment 149701 [details]
Updated anaconda SRPM for RHEL-5-Client
Updated anaconda source RPM with the loader patch. This is for the RHEL-5
Client platform.
Created attachment 149702 [details]
Updated anaconda SRPM for RHEL-5-Server
Updated anaconda source RPM with loader patch. This is for the RHEL-5 Server
platform.
Created attachment 149703 [details]
New netboot initrd.img for i386 on RHEL-5 Client
New netboot initrd.img for i386 on RHEL-5 Client.
Created attachment 149704 [details]
New netboot initrd.img for x86_64 on RHEL-5 Client
New netboot initrd.img for x86_64 on RHEL-5 Client
Created attachment 149705 [details]
New netboot initrd.img for i386 on RHEL-5 Server
Created attachment 149706 [details]
New netboot initrd.img for ia64 on RHEL-5 Server
Created attachment 149707 [details]
New netboot ramdisk.image.gz for ppc on RHEL-5 Server
Created attachment 149708 [details]
New netboot initrd.img for s390x on RHEL-5 Server
Created attachment 149709 [details]
New netboot initrd.img for x86_64 on RHEL-5 Server
I've generated new netboot images for all RHEL-5 platforms. Please select the appropriate netboot image and test it out. *** Bug 229627 has been marked as a duplicate of this bug. *** > New netboot initrd.img for x86_64 on RHEL-5 Server
It works. Thanks!
I filed bug 229627, which was for Fedora Core 6, rather than RHEL. Since it's a different distribution, effectively, this seems like it would not be a direct duplicate of this bug. I see this bug includes numerous initrd images for RHEL5. Are these usable with FC6? Will this bug be addressed in FC7? Confused, but thanks, Justin (In reply to comment #35) > I filed bug 229627, which was for Fedora Core 6, rather than RHEL. Since it's a > different distribution, effectively, this seems like it would not be a direct > duplicate of this bug. I see this bug includes numerous initrd images for > RHEL5. Are these usable with FC6? Will this bug be addressed in FC7? > > Confused, but thanks, > Justin The RHEL5 initrd images will not work with FC-6. I'm not making an update image for FC-6. The fixes for this problem are present in rawhide, so the fix will be included in F7. Sorry if it's confusing, but the bugs are dupes from an engineering standpoint. -David An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0644.html Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. |