Red Hat Bugzilla – Bug 851265
booting a wrong arch results in a black screen
Last modified: 2012-12-06 06:14:37 EST
Created attachment 606634 [details]
wrong arch warning
Description of problem:
By accident I have tried to boot a x86_64 DVD on a i686 machine. After confirming default syslinux option I only saw black screen. I tried several times and assumed this is a problem in Fedora or my graphics card. I also tried "safe graphics mode", nothing helped. Only my colleague saved my time by removing "rhgb quiet" from the boot line. After that I finally saw the warning (see warning.jpg).
So, the problem is that the warning is displayed only when "rhgb quiet" are manually removed from the boot line. In the default state only black screen is displayed. That really doesn't help to inform the user what the problem is.
What component is to blame? Something in syslinux, lorax, kernel itself?
Version-Release number of selected component (if applicable):
Fedora 18 Alpha TC3
always on my hardware
Steps to Reproduce:
1. boot x86_64 image on i686 machine
2. see black screen instead of warning
In our release criteria we say:
" The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to a USB stick with any of the officially supported methods "
This is a corner case, where you try to boot unsupported architecture, so it doesn't directly fall into that criterion. But still I believe we should at least make sure the error message can be read. Proposing as final blocker.
Actually, moving to kernel - perhaps the stub can disable quiet mode before printing the warning.
that string gets printed out using bios int 10h calls. We don't even check for the quiet flag at that point.
My guess is that grub2 isn't setting the video mode ?
(In reply to comment #0)
> By accident I have tried to boot a x86_64 DVD on a i686 machine. After
> confirming default syslinux option I only saw black screen.
So if it isn't a kernel issue it must a syslinux issue? Or did you mean to say grub2?
(In reply to comment #3)
> that string gets printed out using bios int 10h calls.
So if the boot loader starts the kernel while using 'boot loader mode setting' it is expected to have installed a new persistent int 10h handler that can print text messages while in the video mode? Interesting.
> We don't even check for the quiet flag at that point.
Then it is strange that the appearance of the message depends on the quiet flag. Or did it instead actually depend on different boot loader graphics modes?
> My guess is that grub2 isn't setting the video mode ?
In what way and at what level?
(In reply to comment #4)
> So if it isn't a kernel issue it must a syslinux issue? Or did you mean to
> say grub2?
Sorry, I don't really know the difference between those two. I always assumed that the boot menu used on CD/USB is syslinux, and the menu installed on the HDD is grub.
In this case, I'm just referring the the menu used on CD.
> Then it is strange that the appearance of the message depends on the quiet
I have removed two flags - quiet and rhgb. Any of them could have caused it. I can test them separately, but not before Wednesday. Anyone with a i686 machine at hand can probably test it faster.
I also encountered it, when i tried to install to an atom netbook, i totally forgot about 32-bit existence... I eventually tried 'rhgb quiet' and i was able to see my obvious mistake. :-)
While it would be nice for the warning to be visible by default, i do not think this should block release. (A NTH maybe).
Discussed at 2012-12-05 blocker review meeting - http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-05/f18final-blocker-review-2.2012-12-05-17.01.log.txt . Agreed this is annoying but serious enough to block release. It is accepted as NTH if the fix is not too invasive.
(Between F16 and F17, grub2 starting doing modesetting; between F17 and F18, theming was added).
"but serious enough" -> "but not serious enough"
Adjusting whiteboard, I guess it was a mistake.
I have tested this with F18 Beta images and I see the error messages just fine now. Marking as fixed.