Bug 1141496

I have similar effect if trying to boot the F21 Alpha/TC5 or Alpha/TC6 release canditates (See the thread https://lists.fedoraproject.org/pipermail/test/2014-September/122716.html I mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1135793).

This is similar problem I am getting an reported in thead https://lists.fedoraproject.org/pipermail/test/2014-September/122917.html.

I downloaded Fedora-Server-netinst-x86_64-21_Alpha.iso on 19th of September and burn it to CD. Booting with this CD resulted the booting stopped when "ISOLINUX" was displayed. I got same results when I used Fedora-Server-DVD-x86_64-21_Alpha.iso.

Installing Fedora-Server-netinst-x86_64-21_Alpha.iso (from the miage) as VM in KVM was OK.

You know what, you're right.

I don't know which is more ridiculous - that we somehow managed to cut a release like this, or that so few people seem to have noticed so far.

Just burned Alpha server x64 netinst to a DVD-R and tried to boot it, it hits SYSLINUX then reboots.

Well, this is a brown paper bag for the ages.

I'm gonna go ahead and say this should probably be a Beta blocker. :)

Alpha criterion "All release-blocking images must boot in their supported configurations.", with sub-note "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size".

Confirmed it also affects the Workstation live.

I can't reproduce this with https://dl.fedoraproject.org/pub/alt/stage/21_Alpha_RC1/Server/x86_64/iso/Fedora-Server-netinst-x86_64-21_Alpha.iso  on a Intel Desktop Board DQ67SK with InsydeH2O firmware "SBM.  03.72.24" built 18-Jun-2012.

In theory that's the same firmware product as your Vaio, though presumably a much newer version.

Correction to my earlier report: as with Jon Ingason, it prints ISOLINUX for me, not SYSLINUX.

So in case Jon and I hijacked Joachim's bug here, I've split the ISOLINUX failure out into https://bugzilla.redhat.com/show_bug.cgi?id=1148087 . If Joachim's really displays "Syslinux ETCD" then it's not the same bug, we don't think. If they do turn out to be the same we can always dupe one off later.

Discussed at 2014-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-03/f21-blocker-review.2014-10-03-15.58.log.txt . So far we believe only Joachim has seen this particular bug - the one Jon and I are seeing seems to be different, and covered in https://bugzilla.redhat.com/show_bug.cgi?id=1148087 . We'd need at least a couple more reproducers to consider any particular 'disc fails to boot' bug as a blocker. For now we're delaying evaluation on this one to try and get some more testing. I'll send out a call for testing today.

Discussed at 2014-10-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-08/f21-blocker-review.2014-10-08-15.58.log.txt . We didn't get around to much testing with TC1, so we agreed to delay again while we *really do some testing this time* with TC2.

Hi, Joachim. If you're able to build a live image, could you try building one with syslinux 6.03 - http://koji.fedoraproject.org/koji/buildinfo?buildID=583538 - both installed on the system used to create the live image, and in the set of packages installed into the live image itself? for me, such a 6.03-based image boots successfully on the system that otherwise fails, and I wonder if it might solve your case as well.

if not, I guess we'll try using 6.03 for the Beta TC3 compose, so you can try with that. thanks!

syslinux-6.03-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/syslinux-6.03-1.fc21

(In reply to Adam Williamson (Red Hat) from comment #11)
> Hi, Joachim. If you're able to build a live image, could you try building
> one with syslinux 6.03 -
> http://koji.fedoraproject.org/koji/buildinfo?buildID=583538 - both installed
> on the system used to create the live image, and in the set of packages
> installed into the live image itself? for me, such a 6.03-based image boots
> successfully on the system that otherwise fails, and I wonder if it might
> solve your case as well.
> 
> if not, I guess we'll try using 6.03 for the Beta TC3 compose, so you can
> try with that. thanks!


Hi Adam, I'm sorry, but I have no good news for you:

The only better thing now is: I see a detailed error message if I try to boot my burned iso:

ISOLINUX 6.03 ETCD, Copyright ...

And then the two lines (this is new!):

Failed to load ldlinux.c32
Boot failed ...

Perhaps this helps!

1. I found a similar issue:

https://bugs.mageia.org/show_bug.cgi?id=12669

2. Describing shortly my Hardware:

a. MSI P35 platinum Motherboard

b. lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 23
Model name:            Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz
Stepping:              7
CPU MHz:               2003.000
CPU max MHz:           2499.0000
CPU min MHz:           2003.0000
BogoMIPS:              5009.88
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              3072K
NUMA node0 CPU(s):     0-3

c. lspci

lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 02)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA Controller [IDE mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA Controller [IDE mode] (rev 02)
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II / PATA Controller (rev b2)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)

3. rpm -qa syslinux*
syslinux-extlinux-nonlinux-6.03-1.fc21.noarch
syslinux-nonlinux-6.03-1.fc21.noarch
syslinux-tftpboot-6.03-1.fc21.noarch
syslinux-perl-6.03-1.fc21.x86_64
syslinux-extlinux-6.03-1.fc21.x86_64
syslinux-devel-6.03-1.fc21.x86_64
syslinux-6.03-1.fc21.x86_64

4. rpm -q mkbootdisk
mkbootdisk-1.5.5-13.fc21.x86_64

Additionally, I want to describe what I'm doing to generate the CD:

1. mkbootdisk --device <BOOTIMAGE> --iso --kernelargs <KERNELARGS> <KERNELVERSION>

2. Burn the iso with wodim

ady2 on IRC suggests your issue may be due to mkbootdisk not supporting newer syslinux releases:

<Ady2> adamw: About https://bugzilla.redhat.com/show_bug.cgi?id=1141496#c15 , mkbootdisk is currently not compatible with (does not support) Syslinux >=5, so he is using an 'unsupported" method.

More:

<Ady2> adamw: basically, mkbootdisk is copying isolinux.bin, but no ldlinux.c32 nor library modules http://www.syslinux.org/wiki/index.php/Library_modules

so it's not really that syslinux/isolinux is 'broken', just that mkbootdisk needs to adjust its behaviour to be compatible with newer syslinux/isolinux.

AFAIK we don't use mkbootdisk for any actual Fedora image generation, so I don't think this needs to block the release.

(In reply to Adam Williamson (Red Hat) from comment #17)
> More:
> 
> <Ady2> adamw: basically, mkbootdisk is copying isolinux.bin, but no
> ldlinux.c32 nor library modules
> http://www.syslinux.org/wiki/index.php/Library_modules
> 
> so it's not really that syslinux/isolinux is 'broken', just that mkbootdisk
> needs to adjust its behaviour to be compatible with newer syslinux/isolinux.
> 
> AFAIK we don't use mkbootdisk for any actual Fedora image generation, so I
> don't think this needs to block the release.

Thanks to the adam and the syslinux team for clarification and information :-) Because mkbootdisk is a bash script I will try to write my own mkbootdisk for the usage together with syslinux.

Sorry for trouble.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

mkbootdisk hasn't been touched except automated rebuilds since we diagnosed this, so I'm pretty sure it's still valid.

Thanks for the report and related info. With patched mkbootdisk the following worked for me on f23:

# mkbootdisk --device ./img.iso --iso `uname -r`

Please let me know or reopen if the problem persists.

(In reply to Jaroslav Škarvada from comment #21)
> Thanks for the report and related info. With patched mkbootdisk the
> following worked for me on f23:
> 
> # mkbootdisk --device ./img.iso --iso `uname -r`
> 
> Please let me know or reopen if the problem persists.

Hi,

I installed mkbootdisk-1.5.5-15 from Koji, built the iso, and it boots perfectly!

Thanks for your efforts.

Kind regards

Joachim Backes

mkbootdisk-1.5.5-15.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-52ba593456

mkbootdisk-1.5.5-15.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update mkbootdisk'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-52ba593456

mkbootdisk-1.5.5-15.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.