Re: Debian GNU/Hurd 2017 released!
Hi, Samuel Thibault wrote: > I rather guess the double-buffering support in grub. But where would that be controllable ? grub-mkimage --help has no options for that. Google does not find me any clue about grub.cfg statements which would promise to do it. Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Thomas Schmitt, on mar. 20 juin 2017 23:01:26 +0200, wrote: > If i only knew what Vladimir meant with "disable double buffering > and try again" to diagnose the menu graphics problem. > Maybe the X extension about double frame buffering: > https://www.x.org/releases/X11R7.7/doc/libXext/dbelib.html I rather guess the double-buffering support in grub. Samuel
Re: Debian GNU/Hurd 2017 released!
Hi, Samuel Thibault wrote: > Files on > https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/ > are now updated accordingly Oh yes. Now it looks much better and should be digestible for partition editors. https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-sid-hurd-i386-NETINST-1.iso boots on my qemu-system-i386 from -hda. No unexpectable miracle cure with menu graphics, though. - If i only knew what Vladimir meant with "disable double buffering and try again" to diagnose the menu graphics problem. Maybe the X extension about double frame buffering: https://www.x.org/releases/X11R7.7/doc/libXext/dbelib.html But i fail to find info how to inquire whether my X can do it and whether qemu's graphics window uses it. (Further i would be reluctant to play with the X server on my real workstation.) I tested with a BIOS equipped real 64 bit machine from USB stick. It shows the GRUB menu just fine. I did not go further, because the box is full of SATA and other witches' brew from around 2010. Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Hello, Thomas Schmitt, on mar. 20 juin 2017 14:32:40 +0200, wrote: > So my proposal to Debian GNU/Hurd is to boldly add option > --protective-msdos-label > to the debian-installer run of xorriso -as mkisofs for hurd. Files on https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/ are now updated accordingly Samuel
Re: Debian GNU/Hurd 2017 released!
Hi, my assembler reading skills are obviously insufficient. It turns out that the bytes in the MBR partition table range are not significant for booting the ISO from qemu -hda. I boldly zeroed them in a copy of the GNU/Hurd ISO and it still boots. (To make sure that it does not boot by El Torito i copied the terminating volume descriptor from block 19 to block 17.) Encouraged by this outcome, i repacked the ISO by these commands: # Obtain GRUB image file from start of original ISO dd if=debian-hurd-2017-i386-NETINST-1.iso bs=2048 count=16 of=grub_embed mount debian-hurd-2017-i386-NETINST-1.iso /mnt/iso # Most options as learned from file /mnt/iso/.disk/mkisofs # but adding option --protective-msdos-label to create a partition table. xorriso -as mkisofs \ -o test.iso \ -J -joliet-long -r \ -V 'Debian 9.0 h-i386 n' \ --embedded-boot grub_embed \ --protective-msdos-label \ -cache-inodes \ -c boot/boot.cat \ -b boot/grub/grub_eltorito \ -no-emul-boot -boot-load-size 4 -boot-info-table -no-pad \ /mnt/iso The resulting test.iso boots as qemu -hda to the same GRUB menu as the original ISO. The partition table is what grub-mkrescue would ask for in case of i386-pc without any efi platform: $ sbin/fdisk -lu test.iso ... Disklabel type: dos ... Device Boot StartEnd Sectors Size Id Type test.iso1 *1 311555 311555 152.1M cd unknown This partition is not mountable because of its start offset 1. But that's how Vladimir wanted it for grub-mkrescue. -- Udate after receiving reply on grub-devel: http://lists.gnu.org/archive/html/grub-devel/2017-06/msg00043.html Vladimir 'phcoder' Serbinenko wrote: > 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. This explains why it looks like somewhat plausible executable code and why i386-pc/boot.img of Debian 8 is in the state it is in. -- So my proposal to Debian GNU/Hurd is to boldly add option --protective-msdos-label to the debian-installer run of xorriso -as mkisofs for hurd. If an empty partition table is desired instead, then at least zeroize the 64 bytes beginning at offset 446 of file "grub_embed" before it gets handed over to xorriso. Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Thomas Schmitt, on mar. 20 juin 2017 11:24:42 +0200, wrote: > Did you already talk to Steve McIntyre about the appearance of amd64 > on your VM ? IIRC I reported the issue, I don't have the reference off-hand. Samuel
Re: Debian GNU/Hurd 2017 released!
Hi, i wrote: > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.0.0-amd64 -netinst.iso > > With OVMF, GRUB2 is in charge and works fine. Samuel Thibault wrote: > That's probably sheer luck. > [ Part 2, Image/PNG 545 KB. ] Wow. That's really unusable. The appearance of Hurd's GRUB menu is ill, but because of the correct graphics every second arrow key one can navigate and trust the result of the key even if it is not visible. Did you already talk to Steve McIntyre about the appearance of amd64 on your VM ? > > -rw-r--r-- 1 root root 512 Mar 23 2015 /usr/lib/grub/i386-pc/boot.img > Note that the script gets executed on Debian GNU/Hurd, not Debian > GNU/Linux. Perhaps for some reason there's a bug in the Hurd version. > ... > Better investigate the Hurd version first before contacting them, > perhaps it's a target-specific issue. It looks as if already the blob boot.img on my amd64 Debian 8 has the problem with the misused partition table byte range. (On GNU/Hurd it could only be better than that.) The first 512 bytes of the 2017 Hurd ISO are the same as in my locally installed file /usr/lib/grub/i386-pc/boot.img . The GRUB targets are the same in both cases: "i386-pc", which i understand is initially the 16 bit aspect of x86 plus BIOS INT services, and maybe later 32 bit code. There are no indications that 64 and 32 bit machines are distinguished at that level. > Coordination between GNU projects? You're dreaming a bit :) rms urges us to do so. Since we don't follow his wish to use Lisp we have to find other ways to please him. :)) Have a nice day :) Thomas
Re: Debian GNU/Hurd 2017 released!
Thomas Schmitt, on mar. 20 juin 2017 09:42:00 +0200, wrote: > But it uses a blob as first part of that file: > > cat "/usr/lib/grub/$platform/boot.img" "$workdir/core.img" > > "$outdir/boot/grub/grub_embed" > > I have one on my Debian 8: > -rw-r--r-- 1 root root 512 Mar 23 2015 /usr/lib/grub/i386-pc/boot.img Note that the script gets executed on Debian GNU/Hurd, not Debian GNU/Linux. Perhaps for some reason there's a bug in the Hurd version. > Now i wonder whether i should ask Debian's GRUB2 maintainers or directly > at grub-devel about the use cases where this would be appropriate. Better investigate the Hurd version first before contacting them, perhaps it's a target-specific issue. > I could declare it a matter of coordination among GNU projects. :)) Coordination between GNU projects? You're dreaming a bit :) Samuel
Re: Debian GNU/Hurd 2017 released!
Hi, i found https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/x86-image which indeed produces a file grub_embed. But it uses a blob as first part of that file: cat "/usr/lib/grub/$platform/boot.img" "$workdir/core.img" > "$outdir/boot/grub/grub_embed" I have one on my Debian 8: -rw-r--r-- 1 root root 512 Mar 23 2015 /usr/lib/grub/i386-pc/boot.img This blob already has the bytes in the partition table which cause the insane numbers in fdisk and other partition table interpreters. Disassembling does not look as if the code would try to hop over the table beginning at 0x1be. I got this command on my cheat sheet: objdump -D -b binary -mi386 -Maddr16,data16 $mbr_file | less but lack true assembler knowledge. Nevertheless i can see that the MBR of grub-mkrescue has a "ret" before the partition table begins and that its jumps go either below 0x1b0 or above 0x1ff. Now i wonder whether i should ask Debian's GRUB2 maintainers or directly at grub-devel about the use cases where this would be appropriate. I could declare it a matter of coordination among GNU projects. :)) Have a nice day :) Thomas
Re: Enable PIE by default in GCC?
James Clarke, on mar. 20 juin 2017 06:18:18 +0100, wrote:
> In all seriousness though, is there anywhere explaining what the issue with
> GDB
> is?
Searching a bit ("gdb pie hurd"...) the mailing lists archive,
https://lists.gnu.org/archive/html/bug-hurd/2016-11/msg00043.html
> I see [1] but that is from a while ago and talking about PIEs themselves
> not working.
Yes, that was fixed.
Samuel
