вт, 20 июн. 2017 г., 13:02 Thomas Schmitt <scdbac...@gmx.net>: > Hi, > > i am discussing with Samuel Thibault two riddling issues of the new > Debian GNU/Hurd ISOs, e.g. this one of about 160 MB: > > > http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/debian-hurd-2017-i386-NETINST-1.iso > > Those ISOs are among the very few which use GRUB for booting via BIOS. > So i think the problems are worth to be discussed here. > I assume that Debian maintainers of GRUB are around, too. > > My discussion with Samuel begins at: > https://lists.debian.org/debian-hurd/2017/06/msg00019.html > > ---------------------------------------------------------------------- > Issue 1: > > There is an MBR with probably x86 code after byte 446 where normally > the partition table is located. This yields of course weird results with > partition editors and would expose the code for being damaged by editors. > > The MBR is a 1:1 copy of what my Debian 8 amd64 has as > /usr/lib/grub/i386-pc/boot.img > > It gets appended a grub-mkimage result in line 53 of > > https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/x86-image > > The concatenated result is then submitted to xorrisofs by option -G without > any options to write a partition table. > > Questions: > > - Is the state of i386-pc/boot.img intentional ? > If yes: > - With what use case is it useful to have an MBR with garbled partition > table ? > - Are the bytes 446 to 509 indeed intended to be executed as x86 code ? > Those are only for floppies with old BIOS. If your image is over 2.88 MiB and thus never useful on floppies, it's safe to overwrite.
> If yes: > - Are there other MBR templates which do not have code in bytes 446 to > 509 but would nevertheless be suitable for getting appended a result > from grub-mkimage ? > If no: > - What might have went wrong with the production of i386-pc/boot.img ? > > > ---------------------------------------------------------------------- > Issue 2: > > The GRUB menu of the ISOs when started on Debian 8 amd64 by > > qemu-system-i386 -enable-kvm -m 1024 -hda > debian-hurd-2017-i386-NETINST-1.iso > > appears with wrong color, pushed up by about 30 percent of image size, > and rolled over horizontally by about 45 percent. Same effect with qemu > option -cdrom rather than -hda. > > I can post an image if this cannot be reproduced easily. > > The first arrow key press repairs the graphics, but the second arrow key > press brings it back into wrong state. So every second menu choice is > visible and every other item has to be chosen blindly. > (A nice trick is to navigate to the last item and to press arrow once > in vain. When moving up, the previously bad screens become good and the > good ones go bad.) > > > The problem with qemu + SeaBIOS seems well reproducible. > But only some versions of OVMF seem not to work well with the GRUB software > of the Debian 9.0.0 amd64 netinst ISO. > Samuel posted a PNG of a garbled menu which he gets from his local OVMF, > which the debian-hurd mailing list seems to have rejected. It's not to see > in the archives, i fear. > My local OVMF shows the menu ok. > > Questions: > - Is it known that GRUB graphics and SeaBIOS or OVMF do not go well > together ? > Never had such problems but it sounds like a problem with doublebuffering. Can you disable double buffering and try again > - Any ideas how to give the GNU/Hurd ISO a flawlessly working menu > on SeaBIOS ? (VMs are the main installation target of GNU/Hurd.) > > > ---------------------------------------------------------------------- > > Have a nice day :) > > Thomas > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
