Re: UEFI PC?
Peter Wiehe writes: > Hello, > I'm new to Hurd and this mailing list. > > Is Debian GNU/Hurd able to be installed on an UEFI PC? Are you certain that you want to install the Hurd on bare hardware? The Hurd is not as stable as GNU/Linux. Most Hurd developers run the Hurd in qemu. This is probably the easiest way to run the Hurd. That being said, I would guess that the Hurd does not have UEFI support...but I do not know for certain. I do know of one Hurd developer who managed to install Debian GNU/Hurd on a Thinkpad T60. Those old Thinkpads are pretty awesome. I'm using a T400, and it was only $50 on ebay. Also, as far as I know, you have to use the proprietary BIOS to boot the Hurd. Coreboot or libreboot currently do not support booting the Hurd. That being said, you can probably still boot the Hurd in newer laptops...You can normally boot a UEFI laptop in BIOS compatibility mode. I hope that helps! > > (I searched the archives for UEFI but only found this thread: > https://lists.debian.org/debian-hurd/2016/05/msg00033.html > ...which doesn't answer the question.) > > Greetings > Peter > -- Joshua Branson Sent from Emacs and Gnus
Re: UEFI PC?
Peter Wiehe, le sam. 16 nov. 2019 16:41:06 +0100, a ecrit: > Is Debian GNU/Hurd able to be installed on an UEFI PC? Actually there is no technical reason why it shouldn't work: it's grub which has to care about BIOS vs UEFI. That being said, it seems that the hurd-i386 variant of the Debian installation CDs can't be booted on UEFI. I don't know why, it's using grub, like the i386 variant. So technically that should be possible with a few fixes, but nobody did the fixes yet, so without tinkering you will not get it to work this way, and you have to configure your BIOS to boot in legacy mode. Samuel
Re: UEFI PC?
Hi, Samuel Thibault wrote: > Actually there is no technical reason why it shouldn't work: it's grub > which has to care about BIOS vs UEFI. > > That being said, it seems that the hurd-i386 variant of the Debian > installation CDs can't be booted on UEFI. I don't know why, it's using > grub, like the i386 variant. The immediate cause is the lack of an El Torito boot image for UEFI and of an EFI System Partition. (Looking at debian-sid-hurd-i386-NETINST-1.iso, 2017 06 20 12 43 44 00.) On an amd64 system i can get UEFI equipment in a grub-mkrescue ISO by installing binary packages grub-efi-amd64-bin and/or grub-efi-ia32-bin. This can be further combined with grub-pc-bin for PC-BIOS. Then i run grub-mkrescue with a dummy payload directory instead of a directory tree with operating system files: mkdir minimal grub-mkrescue -o output.iso minimal The result should then have EFI System Partition and El Torito image in personal union, containing start programs for i386 and/or amd64. Further there should be bootable MBR code and El Torito image for PC-BIOS. Partition table is GPT. Have a look at Guix ISOs which get built by grub-mkrescue. (There is also HFS+/APM stuff for antique x86 Macs.) The Volume Id of the Hurd ISO from june 2017 looks like debian-cd Volume Id: Debian sid h-i386 n But it has GRUB equipment for PC-BIOS rather than the usual ISOLINUX. Well, debian-cd is flexible. If it's that what you are using, let's talk to Steve McIntyre when he is done with converting Jigdo to SHA256. Whatever, it will be not a big obstacle to develop a xorriso run if you have all GRUB equipment ready for EFI. It may also be a good opportunity to switch to grub-mkrescue for ISO generation (and my wrapper script for making MBR partitions rather than GPT). -- I cannot say whether there is nothing which the Mach kernel would want from the firmware. Maybe ask Steve McIntyre whether he had to wait for special Linux precautions before being able to boot amd64 via EFI (long ago). Have a nice day :) Thomas Running with C source
Re: UEFI PC?
Thomas Schmitt, le dim. 17 nov. 2019 16:39:28 +0100, a ecrit: > Samuel Thibault wrote: > > That being said, it seems that the hurd-i386 variant of the Debian > > installation CDs can't be booted on UEFI. I don't know why, it's using > > grub, like the i386 variant. > > The immediate cause is the lack of an El Torito boot image for UEFI and of > an EFI System Partition. Ok, so the build scripts definitely are different, but I don't see any reason why. Mmm, actually I had tested with the amd64 debian iso image, not the i386. The i386 http://cdimage.debian.org/cdimage/release/10.2.0/i386/iso-cd/debian-10.2.0-i386-netinst.iso has the same issue, so that must be just a small thing in the debian-cd package which builds images differently on amd64 and i386. Samuel
Re: UEFI PC?
Hi, Samuel Thibault wrote: > Mmm, actually I had tested with the amd64 debian iso image , not the > i386. The i386 http://cdimage.debian.org/cdimage/release/10.2.0/i386/iso-cd/debian-10.2.0-i386-netinst.iso > has the same issue, Aren't amd64 and i386 GNU/Linux systems ? Those have ISOLINUX equipment for PC-BIOS and GRUB for EFI. CD and USB stick. Don't we talk about ISOs like https://cdimage.debian.org/cdimage/ports/current-hurd-i386/iso-cd/debian-hurd-2019-i386-NETINST-1.iso It has a GRUB El Torito image for CD via PC-BIOS. No recognizable MBR code for booting via PC-BIOS from USB stick. Can it be that hurd-i386 is prepared by https://sources.debian.org/src/debian-cd/3.1.27/tools/boot/bullseye/boot-hurd-common whereas i386 and amd64 are prepared by https://sources.debian.org/src/debian-cd/3.1.27/tools/boot/bullseye/boot-x86 ? Both tinker with xorrisofs boot options. boot-x86 is much more elaborate than boot-hurd-common. In both it seems that ISOLINUX and GRUB binaries are already prepared. Dunno where this is done. The hurd script shows no traces of xorrisofs options for EFI, which would be --efi-boot or -e. No option --grub2-mbr is to see for booting via PC-BIOS from USB stick. As said, it uses GRUB for PC-BIOS, whereas i386/amd64 use ISOLINUX. (In case you plan to join boot-x86 with EFI: I have a change proposal pending for i386 and amd64 images. Motivated in detail at: https://lists.debian.org/debian-cd/2019/07/msg7.html It would be worth to adopt it if you copy all the boot-x86 stuff. I should prod Steve again. His excuse about the old xorriso version is gone meanwhile. The i386 ISO has Preparer Id : XORRISO-1.5.0 2018.09.15.133001, ... ) --- xorriso offers commands for inspection of boot equipment. E.g. xorriso -indev debian-hurd-2019-i386-NETINST-1.iso \ -report_system_area plain \ -report_el_torito plain yields ... Volume id: 'Debian 2019 h-i386 n' System area options: 0x0201 System area summary: MBR protective-msdos-label cyl-align-off ISO image size/512 : 457764 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0xcd1 457763 El Torito catalog : 804 1 El Torito cat path : /boot/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 4 53448 El Torito img path : 1 /boot/grub/grub_eltorito El Torito img opts : 1 boot-info-table With i386 GNU/Linux: Volume id: 'Debian 10.2.0 i386 n' System area options: 0x0102 System area summary: MBR isohybrid cyl-align-on GPT APM ISO image size/512 : 872448 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x000 872448 MBR partition : 2 0x00 0xef 3856 4416 MBR partition path : 2 /boot/grub/efi.img ... ... invalid GPT and useless APM ... ... El Torito catalog : 963 1 El Torito cat path : /isolinux/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 42068 El Torito boot img : 2 UEFI y none 0x 0x00 4416 964 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img With Guix (made by grub-mkrescue): Volume id: 'GUIXSD_IMAGE' System area options: 0x4201 System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM ISO image size/512 : 2109436 Partition offset : 0 MBR heads per cyl : 65 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee1 2109435 GPT: N Info GPT disk GUID : 38bec621914e604ea91884e71f367b5c GPT entry array: 20 176 separated GPT lba range : 64 2109390 2109435 GPT partition name : 1 4700610070003000 GPT partname local : 1 Gap0 GPT partition GUID : 1 38bec621914e604ea91984e71f367b5c GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 64 34424 GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00 GPT partname local : 2 EFI boot partition GPT partition GUID : 2 38bec621914e604ea91a84e71f367b5c GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x1001 GPT start and size : 2 34488 2880 GPT partition path : 2 /efi.img GPT
Re: UEFI PC?
Thomas Schmitt, le dim. 17 nov. 2019 18:35:34 +0100, a ecrit: > Samuel Thibault wrote: > > Mmm, actually I had tested with the amd64 debian iso image , not the > > i386. The i386 > http://cdimage.debian.org/cdimage/release/10.2.0/i386/iso-cd/debian-10.2.0-i386-netinst.iso > > has the same issue, > > Aren't amd64 and i386 GNU/Linux systems ? They are > Those have ISOLINUX equipment for PC-BIOS and GRUB for EFI. CD and USB stick. Yes, but they use grub for EFI booting. > Don't we talk about ISOs like > > https://cdimage.debian.org/cdimage/ports/current-hurd-i386/iso-cd/debian-hurd-2019-i386-NETINST-1.iso Depends what exactly we are talking about. The original request is for such image, yes, but apparently scripts building it don't have EFI enabled indeed, I'm having a look. Samuel
Re: UEFI PC?
Thomas Schmitt, le dim. 17 nov. 2019 18:35:34 +0100, a ecrit: > Can it be that hurd-i386 is prepared by > > https://sources.debian.org/src/debian-cd/3.1.27/tools/boot/bullseye/boot-hurd-common It is. I have now pushed EFI code there. I have regenerated http://people.debian.org/~sthibault/hurd-i386/installer/cdimages/daily/debian-sid-hurd-i386-NETINST-1.iso > xorriso -indev debian-hurd-2019-i386-NETINST-1.iso \ > -report_system_area plain \ > -report_el_torito plain now yields Volume id: 'Debian sid h-i386 n' System area options: 0x0201 System area summary: MBR protective-msdos-label cyl-align-off ISO image size/512 : 366800 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0xcd1 366799 El Torito catalog : 703 1 El Torito cat path : /boot/boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 4 36581 El Torito boot img : 2 UEFI y none 0x 0x00608 53849 El Torito img path : 1 /boot/grub/grub_eltorito El Torito img opts : 1 boot-info-table El Torito img path : 2 /boot/grub/efi.img So there is efi stuff in there, and efi.img does contain bootia32.efi, but kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's a grub-ia32 issue (since I can't boot a linux-i386 image either), do you have an idea at this point? Samuel
Re: UEFI PC?
Samuel Thibault, le dim. 17 nov. 2019 18:58:08 +0100, a ecrit: > Thomas Schmitt, le dim. 17 nov. 2019 18:35:34 +0100, a ecrit: > > Can it be that hurd-i386 is prepared by > > > > https://sources.debian.org/src/debian-cd/3.1.27/tools/boot/bullseye/boot-hurd-common > > It is. I have now pushed EFI code there. Ah, no, the push didn't work, you can read it from https://salsa.debian.org/sthibault/debian-cd/blob/master/tools/boot/bullseye/boot-hurd-common Samuel
Re: UEFI PC?
Samuel Thibault, le dim. 17 nov. 2019 18:58:08 +0100, a ecrit: > kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd > > doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's > a grub-ia32 issue (since I can't boot a linux-i386 image either), Mmm, OVMF.fd is a 64bit firmware, perhaps it doesn't support loading 32bit binaries? Samuel
Re: UEFI PC?
Samuel Thibault, le dim. 17 nov. 2019 19:08:20 +0100, a ecrit: > Samuel Thibault, le dim. 17 nov. 2019 18:58:08 +0100, a ecrit: > > kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd > > > > doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's > > a grub-ia32 issue (since I can't boot a linux-i386 image either), > > Mmm, OVMF.fd is a 64bit firmware, perhaps it doesn't support loading > 32bit binaries? My laptop doesn't seem to be able to boot it in EFI mode either. But legacy mode boots fine. Samuel
Processing of gnumach_1.8+git20191117-1_source.changes
gnumach_1.8+git20191117-1_source.changes uploaded successfully to localhost along with the files: gnumach_1.8+git20191117-1.dsc gnumach_1.8+git20191117.orig.tar.xz gnumach_1.8+git20191117-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
gnumach_1.8+git20191117-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Nov 2019 18:33:09 + Source: gnumach Binary: gnumach-common gnumach-dev gnumach-image-1-486 gnumach-image-1.8-486 gnumach-image-1.8-486-dbg kernel-image-1.8-486-di Built-For-Profiles: noudeb noprof noxen Architecture: source Version: 2:1.8+git20191117-1 Distribution: unstable Urgency: medium Maintainer: GNU Hurd Maintainers Changed-By: Samuel Thibault Description: gnumach-common - GNU version of the Mach microkernel, common files. gnumach-dev - GNU version of the Mach microkernel gnumach-image-1-486 - GNU version of the Mach microkernel gnumach-image-1.8-486 - GNU version of the Mach microkernel gnumach-image-1.8-486-dbg - GNU version of the Mach microkernel for debugging kernel-image-1.8-486-di - GNU version of the Mach microkernel for the Debian installer (udeb) Changes: gnumach (2:1.8+git20191117-1) unstable; urgency=medium . * New upstream snapshot. - git-xen-fix, git-spl-squash, git-picmask, git-interrupt-spl7, git-intpri, git-disable-irq: Merged. * patches/70_dde.patch: Update debugging prints. Checksums-Sha1: bb24e84869c0c79fc732f1d73e60117f5301ba61 3074 gnumach_1.8+git20191117-1.dsc 6cd5f7c7853ecc6219ea2cb3a46812e23f16679a 2792344 gnumach_1.8+git20191117.orig.tar.xz 6ba812b480518b0a15cec0a35f6245ca74d3f457 30684 gnumach_1.8+git20191117-1.debian.tar.xz Checksums-Sha256: 812edd8a0897b13a8bd3590630bb1a7dcd7ea0cb4acda5606adc5d2acb623e93 3074 gnumach_1.8+git20191117-1.dsc e28bd735248155ce4010c1eb8f84d49e38d088605a47cbe31b0c7458ba8a 2792344 gnumach_1.8+git20191117.orig.tar.xz dc60ed9433dfb4505fb62d15730479ba8014d8b60192de447a13e2b1f4fdeccc 30684 gnumach_1.8+git20191117-1.debian.tar.xz Files: da20fddb38b417978fa24b70e7e12319 3074 kernel optional gnumach_1.8+git20191117-1.dsc 39e5b987a8645a96db4b8d25c7e26655 2792344 kernel optional gnumach_1.8+git20191117.orig.tar.xz 22ef7ccec8039658e16bb2b3bf3b0170 30684 kernel optional gnumach_1.8+git20191117-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE5h27FdQXK97JfpLZ21UOifD6VPMFAl3RlIIACgkQ21UOifD6 VPOQdQ//WCu4E0jLQ9LxqlVugfsrHwAnMnGuwG+MSWsGcq0eOJe1y7Bdj3x+pV/h DYSiNV5yN5sHmRsO4LuHTlml0aL0tkfENqolf3g2tHBDJUXiyB3LS2eZrJXO7h1s 4NF2274e3yaDwjYnSP4CyU1CmY9TUmfynMz5JNOpXKhgNax/sv5NIU3115YO3qpz HmMXlWIyjLcJb1wCeCgvsQZcfCi/149Ir1uJbxdYW3k/uBvy0048GsziR/uUuToD wYaZmXiueJUeDvBvBe6DK7ogH8NUb7VBDOOy3PG7PGadmQqXSYk9EgAgkaIWO/0R UIdGwHNFf0QVqAAXtHyO845Ze9YCjYCDYq/7OW728HEbsnMH1BiHVAVcwhPsQj+H h4H1lS4mFF7zToX4GIUgHxDylkbfhP0H1aljF9XcPG0K4rJ09k9ED7cKcVk1UZGC lKnXXauLxrLmnnoEg7nzc0M7QGxyelUTy7SSFbaAhH2f5cibv06jDSfWYkj/JgXt drsO3YQuqd8wz+pyajqg1IUhgxGERhlblDnnUAQu56adjZdHgTkQZOl9Wdz2n2py hyhHihU0E5rgh+mYdE/do+2gFmVpyzPpIK9f+y/iWXSGK36QmHr9xOmaYJvbIRzb vyD+h6tONquPw4YdXRQe095mLWHXDUDCqK7jlsuxQ2yEGhgnRk4= =F4v5 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Re: UEFI PC?
Hi, Samuel Thibault wrote: > kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd > doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's > a grub-ia32 issue (since I can't boot a linux-i386 image either) Indeed, this gives a "UEFI Interactive Shell" prompt and no Debian menu qemu-system-x86_64 -enable-kvm -m 512 \ -cdrom debian-10.2.0-i386-netinst.iso \ -bios /usr/share/ovmf/OVMF.fd But it boots to a GRUB/Debian menu with qemu-system-i386 ... > http://people.debian.org/~sthibault/hurd-i386/installer/cdimages/daily/debian-sid-hurd-i386-NETINST-1.iso (Find the surplus "s" in this URL.) qemu-system-i386 ... debian-sid-hurd-i386-NETINST-1.iso ... does not boot, i fear. The most obvious difference is in the two EFI System Partitions: $ cd /mnt/fat_hurd $ find . . ./efi ./efi/boot ./efi/boot/bootia32.efi $ cd /mnt/fat_i386 $ find . . ./efi ./efi/boot ./efi/boot/bootia32.efi ./efi/boot/grubia32.efi ./efi/debian ./efi/debian/grub.cfg bootia32.efi in hurd has 278,528 bytes. In i386 it's 1,065,120 for bootia32.efi, which says "Microsoft" 53 times, and 1,156,464 for grubia32.efi. The file grub.cfg contains only the instruction to use the grub.cfg in the ISO filesystem: search --file --set=root /.disk/info set prefix=($root)/boot/grub source $prefix/i386-efi/grub.cfg (In the hurd ISO, the EFI image is not marked in the partition table. Thus according to specs no booting from USB stick. But OVMF would boot by -hda nevertheless if it would work by -cdrom.) Have a nice day :) Thomas
Re: UEFI PC?
Thomas Schmitt, le dim. 17 nov. 2019 20:42:37 +0100, a ecrit: > The most obvious difference is in the two EFI System Partitions: > > $ cd /mnt/fat_hurd > $ find . > . > ./efi > ./efi/boot > ./efi/boot/bootia32.efi > > $ cd /mnt/fat_i386 > $ find . > . > ./efi > ./efi/boot > ./efi/boot/bootia32.efi > ./efi/boot/grubia32.efi > ./efi/debian > ./efi/debian/grub.cfg Yes, but that should only be needed for signed EFI booting (at least that's what the code comments say). > bootia32.efi in hurd has 278,528 bytes. > In i386 it's 1,065,120 for bootia32.efi, which says "Microsoft" 53 times, Yes, that's the signed shim. But we should be able to boot in EFI mode without a signature. > The file grub.cfg contains only the instruction to use the grub.cfg in > the ISO filesystem: > search --file --set=root /.disk/info > set prefix=($root)/boot/grub > source $prefix/i386-efi/grub.cfg Yes, that is expected, to make the scripts simpler. Samuel
Re: UEFI PC?
Samuel Thibault, le dim. 17 nov. 2019 19:08:20 +0100, a ecrit: > Samuel Thibault, le dim. 17 nov. 2019 18:58:08 +0100, a ecrit: > > kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd > > > > doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's > > a grub-ia32 issue (since I can't boot a linux-i386 image either), > > Mmm, OVMF.fd is a 64bit firmware, perhaps it doesn't support loading > 32bit binaries? Indeed, a 32bit version of OVMF is needed. I could grab one, and grub boots fine. gnumach however doesn't. I guess that could be because in EFI mode it won't find a BIOS-e820 table, so that's still a TODO, but apparently at least the debian-installer boot part is now supported. Samuel
Re: UEFI PC?
Hi, Samuel Thibault wrote: > Indeed, a 32bit version of OVMF is needed. I could grab one, This explains why i could not repeat my success with qemu-system-i386. (Now i wonder what i did to fall victim to that illusion.) > grub boots fine. gnumach however doesn't. Good luck with the rest of the journey. :)) Have a nice day :) Thomas
Re: UEFI PC?
Samuel Thibault, le dim. 17 nov. 2019 21:31:50 +0100, a ecrit: > Samuel Thibault, le dim. 17 nov. 2019 19:08:20 +0100, a ecrit: > > Samuel Thibault, le dim. 17 nov. 2019 18:58:08 +0100, a ecrit: > > > kvm -cdrom debian-sid-hurd-i386-NETINST-1.iso -bios OVMF.fd > > > > > > doesn't manage to boot it. Perhaps that's a kvm issue, or perhaps that's > > > a grub-ia32 issue (since I can't boot a linux-i386 image either), > > > > Mmm, OVMF.fd is a 64bit firmware, perhaps it doesn't support loading > > 32bit binaries? > > Indeed, a 32bit version of OVMF is needed. I could grab one, (FTR, from https://www.kraxel.org/repos/jenkins/edk2/ , https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-ia32-0-20191016.1286.gc9af866cdd.noarch.rpm , the usr/share/edk2.git/ovmf-ia32/OVMF-pure-efi.fd file) Samuel
Re: UEFI PC?
Thomas Schmitt wrote: > >On an amd64 system i can get UEFI equipment in a grub-mkrescue ISO >by installing binary packages grub-efi-amd64-bin and/or grub-efi-ia32-bin. >This can be further combined with grub-pc-bin for PC-BIOS. >Then i run grub-mkrescue with a dummy payload directory instead of a >directory tree with operating system files: > > mkdir minimal > grub-mkrescue -o output.iso minimal > >The result should then have EFI System Partition and El Torito image in >personal union, containing start programs for i386 and/or amd64. >Further there should be bootable MBR code and El Torito image for PC-BIOS. >Partition table is GPT. Have a look at Guix ISOs which get built by >grub-mkrescue. (There is also HFS+/APM stuff for antique x86 Macs.) > >The Volume Id of the Hurd ISO from june 2017 looks like debian-cd > Volume Id: Debian sid h-i386 n >But it has GRUB equipment for PC-BIOS rather than the usual ISOLINUX. >Well, debian-cd is flexible. >If it's that what you are using, let's talk to Steve McIntyre when he is >done with converting Jigdo to SHA256. > >Whatever, it will be not a big obstacle to develop a xorriso run if >you have all GRUB equipment ready for EFI. It may also be a good >opportunity to switch to grub-mkrescue for ISO generation (and my wrapper >script for making MBR partitions rather than GPT). > >-- > >I cannot say whether there is nothing which the Mach kernel would want from >the firmware. Maybe ask Steve McIntyre whether he had to wait for special >Linux precautions before being able to boot amd64 via EFI (long ago). There's a few pieces to think about here, from reading the thread: 1. adding UEFI support in debian-cd for the hurd-i386 CD build. That's easy 2. If you're going to test-boot that in a qemu VM, you'll need a 32-bit OVMF build to test it too. Thet 64-bit OVMF in the archive will only boot a 64-bit kernel. I have a 32-bit binary build I use myself for local testing in git at https://git.einval.com/cgi-bin/gitweb.cgi?p=efitest.git in case that helps 3. Finally (the elephant in the room) - booting via UEFI is not the same as BIOS boot. The entry points are different (for a start), and there are quite a lot og kernel changes needed to support UEFI initialisation etc. I've not heard anything about people working on this for Hurd at all. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: UEFI PC?
Steve McIntyre, le dim. 17 nov. 2019 20:36:13 +, a ecrit: > 1. adding UEFI support in debian-cd for the hurd-i386 CD > build. That's easy Yes, that's now on https://salsa.debian.org/images-team/debian-cd/merge_requests/5 > 3. Finally (the elephant in the room) - booting via UEFI is not the > same as BIOS boot. gnumach uses multiboot, so it should be quite similar actually. > to support UEFI initialisation etc. What I can think of is memory layout initialization and PCI BIOS support, do you think of anything else? Samuel
Re: UEFI PC?
Am 17. November 2019 22:14:05 MEZ schrieb Samuel Thibault : >Steve McIntyre, le dim. 17 nov. 2019 20:36:13 +, a ecrit: >> to support UEFI initialisation etc. > >What I can think of is memory layout initialization and PCI BIOS >support, do you think of anything else? > I don't know if this belongs here, but speaking about UEFI init: Afaik there' s a watchdog timer which needs to be turned off shortly after startup or else your shiny OS will reboot after some seconds. I don't know if this is relevant for grub boot. Peter
Re: UEFI PC?
On Sun, Nov 17, 2019 at 10:14:05PM +0100, Samuel Thibault wrote: >Steve McIntyre, le dim. 17 nov. 2019 20:36:13 +, a ecrit: >> 1. adding UEFI support in debian-cd for the hurd-i386 CD >> build. That's easy > >Yes, that's now on >https://salsa.debian.org/images-team/debian-cd/merge_requests/5 > >> 3. Finally (the elephant in the room) - booting via UEFI is not the >> same as BIOS boot. > >gnumach uses multiboot, so it should be quite similar actually. > >> to support UEFI initialisation etc. > >What I can think of is memory layout initialization and PCI BIOS >support, do you think of anything else? I'm not the expert here, but off the top of my head you'll also need to deal with UEFI boot-time and/or runtime services, and you'll probably need to make your initial boot binary be a PE UEFI executable. I'm sure there's probably more - I'd look at the Linux UEFI boot path. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: UEFI PC?
Am 17. November 2019 23:09:18 MEZ schrieb Steve McIntyre : >you'll >probably need to make your initial boot binary be a PE UEFI >executable. No, afaik that's not neccessary if you boot from an intermediate bootloader like grub. Peter
