Re: A thread on grub-bug could need attention
Hi, about two hours ago i sent an answer to Date: Thu, 1 Feb 2018 22:56:26 +0100 From: Michel Bouissou Subject: Re: A thread on grub-bug could need attention with own Date: Fri, 02 Feb 2018 09:15:42 +0100 Message-Id: <28716785462546254...@scdbackup.webframe.org> It did not show up in the mailing list yet. Neither in my mailbox nor at http://lists.gnu.org/archive/html/grub-devel/2018-02/threads.html This is an attempt to resend it. I again Cc: Michel Bouissou because i don't know whether the problem is with my mail provider. - Hi, i wrote: > > zeroize 512-byte block 1 of the > > Debian Live ISO and then try to boot it from USB stick Michel Bouissou wrote: > I made it (with latest debian-gnome 9.3 live),i Now we have no surplus GPT any more. The EFI system partition is only marked by the MBR partition 2 (and by the El Torito catalog which should be ignored when found on USB stick). > and tested it OK on *another* machine. > But on the machine where the problem is, it does *NOT* boot. Normally i would now again exclude the theory that the partitions inside the ISO are to blame. (We still have to explain why the GRUB installations on hard-disk-like partitioned USB sticks failed too.) > It does display the key brand/model (instead of "Windows boot manager") But this slight change in firmware behavior could be significant. Under the theory that it's the partition layout and not the EFI partition image content or its way to hop on the ISO, there remains the nested partition situation as main suspect: $ /sbin/fdisk -l debian-live-9.3.0-amd64-xfce.iso ... DeviceBoot Start End Sectors Size Id Type debian-live-9.3.0-amd64-xfce.iso1 *0 3803903 3803904 1.8G 0 Empty debian-live-9.3.0-amd64-xfce.iso2 15482379 832 416K ef EFI The block range of partition 2 is inside partition 1. Normally the type 0 ("Empty") of partition 1 is enough to let firmwares tolerate this. Partition 1 is not needed for the boot process. It just protects the ISO from partition editors and provides a mountable partition to operating systems. So the next experiment would be to remove it, i.e. zeroize its slot in the MBR. One can do it in the ISO file img=debian-live-9.3.0-amd64-xfce.iso or directly on the USB stick where it was copied img=/dev/sdc Either by: /sbin/fdisk "$img" <<+ d 1 w + Or by: dd if=/dev/zero bs=1 seek=446 count=16 conv=notrunc of="$img" The result should then be $ /sbin/fdisk -l "$img" ... DeviceBoot Start End Sectors Size Id Type debian-live-9.3.0-amd64-xfce.iso2 15482379 832 416K ef EFI Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, i wrote: > > zeroize 512-byte block 1 of the > > Debian Live ISO and then try to boot it from USB stick Michel Bouissou wrote: > I made it (with latest debian-gnome 9.3 live),i Now we have no surplus GPT any more. The EFI system partition is only marked by the MBR partition 2 (and by the El Torito catalog which should be ignored when found on USB stick). > and tested it OK on *another* machine. > But on the machine where the problem is, it does *NOT* boot. Normally i would now again exclude the theory that the partitions inside the ISO are to blame. (We still have to explain why the GRUB installations on hard-disk-like partitioned USB sticks failed too.) > It does display the key brand/model (instead of "Windows boot manager") But this slight change in firmware behavior could be significant. Under the theory that it's the partition layout and not the EFI partition image content or its way to hop on the ISO, there remains the nested partition situation as main suspect: $ /sbin/fdisk -l debian-live-9.3.0-amd64-xfce.iso ... DeviceBoot Start End Sectors Size Id Type debian-live-9.3.0-amd64-xfce.iso1 *0 3803903 3803904 1.8G 0 Empty debian-live-9.3.0-amd64-xfce.iso2 15482379 832 416K ef EFI The block range of partition 2 is inside partition 1. Normally the type 0 ("Empty") of partition 1 is enough to let firmwares tolerate this. Partition 1 is not needed for the boot process. It just protects the ISO from partition editors and provides a mountable partition to operating systems. So the next experiment would be to remove it, i.e. zeroize its slot in the MBR. One can do it in the ISO file img=debian-live-9.3.0-amd64-xfce.iso or directly on the USB stick where it was copied img=/dev/sdc Either by: /sbin/fdisk "$img" <<+ d 1 w + Or by: dd if=/dev/zero bs=1 seek=446 count=16 conv=notrunc of="$img" The result should then be $ /sbin/fdisk -l "$img" ... DeviceBoot Start End Sectors Size Id Type debian-live-9.3.0-amd64-xfce.iso2 15482379 832 416K ef EFI Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Michel Bouissou wrote: > So I'm afraid we'll have to wait for season 2 by early march to see the > continuation of the story ;-) A classical cliff hanger. :)) > Kind regards and thanks again for all your help and suggestions. Thanks to you for being a very endurant bug reporter. And thanks to your son for letting his dad play with the computer. Mine would have met more resistence. --- (I only got one copy of this mail. Probably the Cc: for me. The list seems not to work for me as receiver or for the archive http://lists.gnu.org/archive/html/grub-devel/2018-02/threads.html Michel obviously got my mail from 09:15:42 +0100. ) Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi Thomas, Le 02/02/2018 à 09:15, Thomas Schmitt a écrit : > So the next experiment would be to remove it, i.e. zeroize its slot in > the MBR. Well, my son left this morning for the week-end with the machine, and I will fly to India myself before I get a chance to do any further testing. So I'm afraid we'll have to wait for season 2 by early march to see the continuation of the story ;-) Kind regards and thanks again for all your help and suggestions. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Le 01/02/2018 à 01:02, Thomas Schmitt a écrit : > Michel - on his way to India - could zeroize 512-byte block 1 of the > Debian Live ISO and then try to boot it from USB stick > > dd if=/dev/zero conv=notrunc bs=512 seek=1 count=1 of=...image.or.stick... > > where "...image.or.stick..." mabe either something like debian-live-*.iso > or /dev/sdc. > This would further deface the GPT and possibly de-confuse the firmware. I made it (with latest debian-gnome 9.3 live), and tested it OK on *another* machine. But on the machine where the problem is, it does *NOT* boot. It does display the key brand/model (instead of "Windows boot manager") but when selecting it, the punishment is as usual : black screen with cursor, game over. No grub message or output of any kind. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Michel Bouissou wrote: > I'm happy to report that the USB stick I made today with > grub-mkrescue-sed.sh does boot alright on tested machines. So GRUB itself is ok with the machine. GPT and MBR partitions alike. > The HP tested machine has, AFAIK, no CSM "legacy" boot mode at all and I > believe it doesn't boot anything but UEFI. It booted the tails ISO which has no EFI boot equipment but only an ISOLINUX El Torito boot image for BIOS and an ISOLINUX isohybrid MBR with machine code which BIOS will execute when presented on USB stick. The machine's firmware probably falls back to legacy mode when detecting BIOS stuff but no EFI partition. - What only do our users at the distro ISO projects miss which grub-mkrescue does right ? Is it simply the invalid GPT which Matthew J. Garrett introduced to get some of his test machines booting ? (Or did he introduce the MBR partition without noticing that this invalidates GPT ?) See "Anatomy of a Fedora 17 ISO image" https://mjg59.dreamwidth.org/11285.html preceeded by "Further adventures in EFI booting" https://mjg59.dreamwidth.org/4957.html The EFI images, which he and nearly all others use, are made with GRUB2. grub-mkrescue does a similar stunt about x86 machine code without side effects and the Block0 of an Apple Partition Map. But it does not combine a non-protective MBR with GPT. Michel - on his way to India - could zeroize 512-byte block 1 of the Debian Live ISO and then try to boot it from USB stick dd if=/dev/zero conv=notrunc bs=512 seek=1 count=1 of=...image.or.stick... where "...image.or.stick..." mabe either something like debian-live-*.iso or /dev/sdc. This would further deface the GPT and possibly de-confuse the firmware. Michel, i will try to remember to remind you, when you are back. :)) - The partition tables of modified and vanilla grub-mkrescue ISOs: This is the modified one from grub-mkrescue-sed.sh : > root@zafu:/# xorriso -indev stdio:/dev/sdb -report_el_torito plain > -report_system_area plain > ... > El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA > El Torito boot img : 1 BIOS y none 0x 0x00 41487 > El Torito boot img : 2 UEFI y none 0x 0x00 57607154 > El Torito img path : 1 /boot/grub/i386-pc/eltorito.img > El Torito img opts : 1 boot-info-table grub2-boot-info We see that it's with EFI equipment. (LBA counts blocks of 2048 bytes. Ldsiz counts blocks of 512 bytes. Blame IBM and Phoenix, not me.) > MBR partition table: N Status TypeStart Blocks > MBR partition : 1 0x80 0x00 6428552 > MBR partition : 2 0x00 0xef28616 5760 (Here all block numbers are counted with 512 bytes per block.) By the options manipulation of grub-mkrescue-sed.sh the EFI partition image was appended after the mountable ISO 9660 partition. Other than with vanilla grub-mkrescue both partitions are marked in the MBR partition table. Partition 1 has the Boot/Active flag set, because some firmwares ignore media which do not have it on any partition. Partition 2 is the EFI partition. The same bytes as the El Torito UEFI boot image. (7154 * 2048 / 512 = 28616) Vanilla grub-mkrescue would rather look like: El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 44047 El Torito boot img : 2 UEFI y none 0x 0x00 5760 85 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table grub2-boot-info El Torito img path : 2 /efi.img ... MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee134779 GPT: N Info GPT disk GUID : 04a5adf35d1adb4382bf8300bebe08a1 GPT entry array: 20 176 separated GPT lba range : 64 34734 34779 GPT partition name : 1 4700610070003000 GPT partname local : 1 Gap0 ... GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00 GPT partname local : 2 EFI boot partition GPT partition GUID : 2 04a5adf35d1adb4382bd8300bebe08a1 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x1001 GPT start and size : 2 340 5760 GPT partition path : 2 /efi.img ... GPT start and size : 4 34132 600 plus maybe APM: N Info APM block size : 2048 ... Other than with the mbr_only version, the EFI partition is a data file inside the ISO 9660 filesystem: /efi.img 247 lines of explanation of the report format are available with xorriso -report_system_area help -report_el_torito help | less Have a nice day
Re: A thread on grub-bug could need attention
Hi, Le 31/01/2018 à 22:37, Thomas Schmitt a écrit : > > In this case a run with grub-mkrescue-sed.sh will not make much sense. > First one will have to configure GRUB to enable at least one of the EFI > variants. I dimly remember that the machine was 64 bit, i.e. should run > bootx64.efi. I'm happy to report that the USB stick I made today with grub-mkrescue-sed.sh does boot alright on tested machines. As a side note, the machine on wich I made it is a Manjaro that boots in UEFI 64 mode, so for sure it's grub is UEFI-capable. The HP tested machine has, AFAIK, no CSM "legacy" boot mode at all and I believe it doesn't boot anything but UEFI. That said, I don't have the machine on which I made the stick at hand and I made the ISO image in a tmpfs, so... But directly analyzing the USB stick I made, on another (Arch) machine now gives : root@zafu:/# xorriso -indev stdio:/dev/sdb -report_el_torito plain -report_system_area plain xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 632 nodes read in 1 seconds libisofs: WARNING : Found hidden El-Torito image. Its size could not be figured out, so image modify or boot image patching may lead to bad results. xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev 'stdio:/dev/sdb' Media current: stdio file, overwriteable Media status : is written , is appendable Boot record : El Torito , MBR grub2-mbr cyl-align-off Media summary: 1 session, 8594 data blocks, 16.8m data, 14.8g free Volume id: 'ISOIMAGE' El Torito catalog : 141 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 41487 El Torito boot img : 2 UEFI y none 0x 0x00 57607154 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table grub2-boot-info El Torito img blks : 2 1440 System area options: 0x4a00 System area summary: MBR grub2-mbr cyl-align-off ISO image size/512 : 34376 Partition offset : 16 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x00 6428552 MBR partition : 2 0x00 0xef28616 5760 Hope this helps (although I don't get much out of this myself ;-) ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, it comes to me that possibly Michel's grub-mkrescue run was BIOS-only. So Michel, take much care to come back in good shape. We have experiments to do. :)) --- At least on Debian the boot equipment prepared by grub-mkrescue depends on which grub-* Debian packages are installed. "grub-pc" enables BIOS equipment. In the case of an USB stick, it's the MBR x86 boot code which comes into effect. It knows the block address of the El Torito boot image. So i assume it loads and executes that binary. "grub-efi-amd64" causes grub-mkrescue to prepare an EFI System Partition with binary /efi/boot/bootx64.efi . "grub-efi-ia32" causes an EFI System Partition with binary /efi/boot/bootia32.efi . All three can be combined. So after a vanilla run with grub-mkrescue, it is essential to inspect the partition tables and El Torito boot equipment by xorriso -indev output.iso \ -report_el_torito plain -report_system_area plain If no lines like GPT disk GUID : 04a5adf35d1adb4382bf8300bebe08a1 ... GPT start and size : 4 34132 600 are reported, then the ISO has no EFI System Partition. In this case a run with grub-mkrescue-sed.sh will not make much sense. First one will have to configure GRUB to enable at least one of the EFI variants. I dimly remember that the machine was 64 bit, i.e. should run bootx64.efi. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
On Wed, Jan 31, 2018 at 10:38:03AM +0100, Michel Bouissou wrote: > Hello, > > Le 30/01/2018 ?? 20:15, Thomas Schmitt a ??crit??: > > It also does not work when booting the ISO images which shall install > > the systems. > > E.g. debian-9.3.0-amd64-netinst.iso : > Yes. AFAIR I had tested all the latest (in december) standard > installation media for at least : > - Manjaro Cinnamon x64 (created either with dd or unetbootin) > - Mint Cinnamon x64 (created either with dd or unetbootin) > - Ubuntu 17.10 > - Debian live > - Parted Magic (created with dd) > (and maybe a few more, see my first mails...) > > - Manjaro Cinnamon after it being "normally" installed on a USB key > instead of an HD on another machine - and tested working. > > None of them booted, all showed the same behaviour : > - The machine's UEFI BIOS displays the USB Key as ?? Windows bootloader ?? > (and the true on-HD Windows bootloader bears the same label) > - Selecting is causes the screen to go black with a cursor on the top > left and nothing else ever happens. > > Now what works : > - rEFInd USB key (made with dd) > - Knoppix USB key (made with dd from DVD image) > - Tails USB key (both made with dd or from the Tails installer) > - Manjaro install key created with unetbootin THEN manually doctored to > remove grub and install syslinux instead. > > - Plus the grub test keys you asked me to create and test in your > previous mails. > > Interestingly, for "working" keys, the machines UEFI?? displays the USB > key brand / model instead of ?? Windows bootloader ?? Could you check partitioning type used on each of above mentioned devices? Is it MBR or GPT? Please remember that GPT have to be always protected by something called "protective MBR". So, you will see MBR everywhere but in case of GPT it should contain one entry with 0xee (GPT) type. > Even more interesting, keys that do NOT work do not work either when > chained to from rEFInd (inserting both keys, booting on rEFInd then > chaining to the other key), with the same symptoms - where keys that > work, also work when performing the same test. > > As I side note I'm currently packing for a trip to India and will be > unable to perform any further tests from next week to the end of > february (and will have very little time left for doing so before leaving) > > Have a nice day :) Have a nice vacation! Drop us a line when you are back. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Michel Bouissou wrote: > I would assume that I need to create a "minimal" directory with a > "dummy" file inside like previously ? Yes. The experiment can well wait until you are back from travel. > However, I don't have any "grub-mkrescue-sed.sh" file Get it from https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh It belongs to the upstream sources of xorriso, where i am developer. The GNU xorriso tarball has it as demo in its ./frontend directory. You can trust its good intentions as much as the ones of xorriso. File operations only affect the grub-mkrescue temporary directory and the /tmp directory. Files get moved, not deleted. (The practical consequences of running it are subject to the usual risk of bugs, i fear.) It works with xorriso-1.4.4 or newer. Best with current release 1.4.8. If your installed xorriso tells an older revision when run without any arguments, then consider to get xorriso and grub-mkrescue-sed.sh by the tarball at https://www.gnu.org/software/xorriso/#download This xorriso needs no installation but only a place where to unpack and compile tar xzf xorriso-1.4.8.tar.gz cd xorriso-1.4.8 ./configure && make If you run its fellow ./frontend/grub-mkrescue-sed.sh then it will make use of the compiled binary ./xorriso/xorriso. Existing installed xorriso and its libraries will not be affected. Lengthy motivation: The purpose of grub-mkrescue-sed.sh is to modify the xorriso run underneath grub-mkrescue to get other partition layouts. The native layout as defined by Vladimir Serbinenko and implemented by me obviously works fine. Its main disadvantage is that it shows at least two not mountable GPT partitions (e.g. /dev/sdc1 and /dev/sdc4). The ISO 9660 filesystem can only be mounted by the base device /dev/sdc. GPT has the further disadvantage that it prescribes to have a backup partition table at the end of the storage device. But when bootable ISOs are made, it is not yet known how large the device will be. And even if so, one would have to pad up the image to write that backup GPT. So any ISO copied onto USB stick has its backup GPT at the wrong place and any remnant backup GPT at the correct position would be in conflict with the main GPT at image start. The MBR partition table doesn't refer to the device end. UEFI specifies that a MBR partition of type 0xEF shall be regarded as EFI System Partition. By some extra measures, the default mode of grub-mkrescue-sed.sh achieves that all partitions are mountable and that no nested partitions emerge. This partition table is fully acceptable to MBR partition editors like fdisk which can then be used to add partitions and so give the rest of the USB stick a life. Because of the 64 block gap before partition 1, it is even possible to install a new boot loader and use the ISO as read-only data partition rather than as home of the operating system. The same measures can help to make GPT with mountable ISO partition (see description of "gpt_appended" in the script). But the problem of misplaced backup GPT cannot be solved at the time when the ISO gets produced. Most modes avoid HFS+ partition and Apple Partition Map. Partition editors and operating systems do not expect APM to be combined with MBR or GPT by some hot x86 machine code stunt and an unusual APM block size. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Le 31/01/2018 à 13:20, Thomas Schmitt a écrit : > This run too ? > > grub-mkrescue -o output.iso minimal \ > --xorriso=...path.../grub-mkrescue-sed.sh \ > -partition_offset 16 > I would assume that I need to create a "minimal" directory with a "dummy" file inside like previously ? However, I don't have any "grub-mkrescue-sed.sh" file on the system on which I would try to build the USB key... [root@tiru ~]# pacman -Ql grub | grep rescue grub /usr/bin/grub-mkrescue grub /usr/share/man/man1/grub-mkrescue.1.gz Kind regards. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, i wrote: > > It also does not work when booting the ISO images which shall install > > the systems. Michel Bouissou wrote: > Yes. AFAIR I had tested all the latest (in december) standard > installation media for at least : > [...] > - Debian live debian-live-9.3.0-amd64-xfce.iso looks much like the Debian netinst ISO. Strings from end of /mnt/fat/efi/boot/bootx64.efi : - search --file --set=root /.disk/info set prefix=($root)/boot/grub source $prefix/x86_64-efi/grub.cfg (memdisk)/boot/grub - /mnt/iso/boot/grub/x86_64-efi/grub.cfg : - insmod part_acorn insmod part_amiga insmod part_apple insmod part_bsd insmod part_dfly insmod part_dvh insmod part_gpt insmod part_msdos insmod part_plan insmod part_sun insmod part_sunpc source /boot/grub/grub.cfg - /mnt/iso/boot/grub/grub.cfg : - if loadfont $prefix/font.pf2 ; then set gfxmode=800x600 insmod efi_gop insmod efi_uga insmod video_bochs insmod video_cirrus insmod gfxterm insmod png terminal_output gfxterm fi if background_image /isolinux/splash.png; then set color_normal=light-gray/black set color_highlight=white/black else set menu_color_normal=cyan/blue set menu_color_highlight=white/blue fi insmod play play 960 440 1 0 4 440 1 if [ ${iso_path} ] ; then set loopback="findiso=${iso_path}" fi menuentry "Debian GNU/Linux Live (kernel 4.9.0-4-amd64)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } submenu "Debian Live with Localisation Support" { menuentry "Albanian (sq)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=sq_AL.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Amharic (am)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=am_ET "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Arabic (ar)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=ar_EG.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Asturian (ast)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=ast_ES.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Basque (eu)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=eu_ES.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Belarusian (be)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=be_BY.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Bangla (bn)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=bn_BD "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Bosnian (bs)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=bs_BA.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Bulgarian (bg)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=bg_BG.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Tibetan (bo)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=bo_IN "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "C (C)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=C "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Catalan (ca)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=ca_ES.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Chinese (Simplified) (zh_CN)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=zh_CN.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Chinese (Traditional) (zh_TW)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=zh_TW.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Croatian (hr)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=hr_HR.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Czech (cs)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=cs_CZ.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Danish (da)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=da_DK.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Dutch (nl)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=nl_NL.UTF-8 "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "Dzongkha (dz)" { linux /live/vmlinuz-4.9.0-4-amd64 boot=live components locales=dz_BT "${loopback}" initrd /live/initrd.img-4.9.0-4-amd64 } menuentry "English (en)" { linux /live/vmlinuz
Re: A thread on grub-bug could need attention
Hello, Le 30/01/2018 à 20:15, Thomas Schmitt a écrit : > It also does not work when booting the ISO images which shall install > the systems. > E.g. debian-9.3.0-amd64-netinst.iso : Yes. AFAIR I had tested all the latest (in december) standard installation media for at least : - Manjaro Cinnamon x64 (created either with dd or unetbootin) - Mint Cinnamon x64 (created either with dd or unetbootin) - Ubuntu 17.10 - Debian live - Parted Magic (created with dd) (and maybe a few more, see my first mails...) - Manjaro Cinnamon after it being "normally" installed on a USB key instead of an HD on another machine - and tested working. None of them booted, all showed the same behaviour : - The machine's UEFI BIOS displays the USB Key as « Windows bootloader » (and the true on-HD Windows bootloader bears the same label) - Selecting is causes the screen to go black with a cursor on the top left and nothing else ever happens. Now what works : - rEFInd USB key (made with dd) - Knoppix USB key (made with dd from DVD image) - Tails USB key (both made with dd or from the Tails installer) - Manjaro install key created with unetbootin THEN manually doctored to remove grub and install syslinux instead. - Plus the grub test keys you asked me to create and test in your previous mails. Interestingly, for "working" keys, the machines UEFI displays the USB key brand / model instead of « Windows bootloader » Even more interesting, keys that do NOT work do not work either when chained to from rEFInd (inserting both keys, booting on rEFInd then chaining to the other key), with the same symptoms - where keys that work, also work when performing the same test. As I side note I'm currently packing for a trip to India and will be unable to perform any further tests from next week to the end of february (and will have very little time left for doing so before leaving) Have a nice day :) ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Daniel Kiper wrote: > IIRC you see blank screen after installing some distros. Right? It also does not work when booting the ISO images which shall install the systems. E.g. debian-9.3.0-amd64-netinst.iso : mount debian-9.3.0-amd64-netinst.iso /mnt/iso mount /mnt/iso/boot/grub/efi.img /mnt/fat At the end of the binary /mnt/fat/efi/boot/bootx64.efi, "strings" sees: search --file --set=root /.disk/info set prefix=($root)/boot/grub source $prefix/x86_64-efi/grub.cfg (memdisk)/boot/grub The search leads to the ISO 9660 filesystem. /mnt/iso/boot/grub/x86_64-efi/grub.cfg has insmod part_acorn insmod part_amiga insmod part_apple insmod part_bsd insmod part_dfly insmod part_dvh insmod part_gpt insmod part_msdos insmod part_plan insmod part_sun insmod part_sunpc source /boot/grub/grub.cfg /mnt/iso/boot/grub/grub.cfg has if loadfont $prefix/font.pf2 ; then set gfxmode=800x600 insmod efi_gop insmod efi_uga insmod video_bochs insmod video_cirrus insmod gfxterm insmod png terminal_output gfxterm fi if background_image /isolinux/splash.png; then set color_normal=light-gray/black set color_highlight=white/black else set menu_color_normal=cyan/blue set menu_color_highlight=white/blue fi insmod play play 960 440 1 0 4 440 1 set theme=/boot/grub/theme/1 menuentry --hotkey=g 'Graphical install' { set background_color=black linux/install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux/install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/initrd.gz } submenu --hotkey=a 'Advanced options ...' { set menu_color_normal=cyan/blue set menu_color_highlight=white/blue set theme=/boot/grub/theme/1-1 menuentry '... Graphical expert install' { set background_color=black linux/install.amd/vmlinuz priority=low vga=788 --- initrd /install.amd/gtk/initrd.gz } menuentry '... Graphical rescue mode' { set background_color=black linux/install.amd/vmlinuz vga=788 rescue/enable=true --- quiet initrd /install.amd/gtk/initrd.gz } menuentry '... Graphical automated install' { set background_color=black linux/install.amd/vmlinuz auto=true priority=critical vga=788 --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=x '... Expert install' { set background_color=black linux/install.amd/vmlinuz priority=low vga=788 --- initrd /install.amd/initrd.gz } menuentry --hotkey=r '... Rescue mode' { set background_color=black linux/install.amd/vmlinuz vga=788 rescue/enable=true --- quiet initrd /install.amd/initrd.gz } menuentry --hotkey=a '... Automated install' { set background_color=black linux/install.amd/vmlinuz auto=true priority=critical vga=788 --- quiet initrd /install.amd/initrd.gz } submenu --hotkey=s '... Speech-enabled advanced options ...' { set menu_color_normal=cyan/blue set menu_color_highlight=white/blue set theme=/boot/grub/theme/1-1-1 menuentry --hotkey=x '... Expert speech install' { set background_color=black linux/install.amd/vmlinuz priority=low vga=788 speakup.synth=soft --- initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=r '... Rescue speech mode' { set background_color=black linux/install.amd/vmlinuz vga=788 rescue/enable=true speakup.synth=soft --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=a '... Automated speech install' { set background_color=black linux/install.amd/vmlinuz auto=true priority=critical vga=788 speakup.synth=soft --- quiet initrd /install.amd/gtk/initrd.gz } } } menuentry --hotkey=s 'Install with speech synthesis' { set background_color=black linux/install.amd/vmlinuz vga=788 speakup.synth=soft --- quiet initrd /install.amd/gtk/initrd.gz } Well, my MBR versus GPT theory fades away by Daniel Kiper's above question. The next step would have been to build a grub-mkrescue image with a partition layout like Knoppix 8.1. You'd take script xorriso-1.4.8/frontend/grub-mkrescue-sed.sh from a GNU xorriso source installation or from https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh and use it as "xorriso" for the grub-mkrescue run. It re-arranges the options for the xorriso run to achieve other partition layouts and/or positions
Re: A thread on grub-bug could need attention
On Mon, Jan 29, 2018 at 07:20:25PM +0100, Michel Bouissou wrote: > Hi again, > > Le 29/01/2018 ?? 16:29, Michel Bouissou a ??crit??: > > I created the USB stick per your instructions. I will try to give it a > > shot tonight on my son's machine. > > I tested the USB stick on my son's machine, and I do get a grub prompt. > > >From there, if I type "help", I get a list of grub shell commands. > > And if I type "reboot", the machine reboots. > > So tha'ts a progress. Great! > Thanks for the suggestion. You are welcome! IIRC you see blank screen after installing some distros. Right? Could you send me grub.cfg/grub2.cfg generated by the installer? It should be somewhere in /boot/grub or /boot/grub2 or even on EFI System Partition. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Le 30/01/2018 à 17:33, Thomas Schmitt a écrit : >> I will try to test it tonight on the affected machine and let you know. > I am curious what will happen. It boots into grub properly. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, I wrote: > > Does this mean that the decisive trick is to use GPT with EFI partition > > instead of a MBR partition of type 0xEF ? Michel Bouissou wrote: > So might this machine boot only from GPT disks ? Well, then it would'tn > boot a Knoppix ISO image stick. But it does... Yes, i proposed to Klaus Knopper to deviate from Matthew J. Garrett's layout which is used by Fedora, Debian, and others. So Knoppix 8.1 has the EFI partition appended outside the ISO 9660 filesystem range, with a neat MBR partition table without nested partitions. No GPT gets written, because it would be invalid. Nevertheless, Knoppix uses SYSLINUX which could be less dependent on a neat GPT than GRUB2 could be ... theoretically guessing ... > I have installed a Manjaro with grub onto a blank USB stick, in EFI > mode, and it would boot perfectly on other machines, but not on affected > machine. It would be interesting to compare the particular actions of the installation with the procedure proposed by Daniel Kiper which works. > I could boot no > standard Linux USB install stick made from an ISO image on this machine, > besides Knoppix or Tails. Oh. I forgot your success with Tails. My mailbox says i inspected 3.3 and that it was BIOS-only with ISOLINUX as bootloader. Just to be sure: http://dl.amnesia.boum.org/tails/stable/tails-amd64-3.5/tails-amd64-3.5.iso No EFI partition at all. And no GRUB. This corresponds to the "mac" ISOs of Debian, which are BIOS-only because some MacIntoshs are said to take offense on the EFI equipment. E.g. this 293 MB image: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-mac-9.3.0-amd64-netinst.iso > > grub-mkrescue -o output.iso ./minimal > I will try to test it tonight on the affected machine and let you know. I am curious what will happen. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi there, Le 29/01/2018 à 19:53, Thomas Schmitt a écrit : > > Does this mean that the decisive trick is to use GPT with EFI partition > instead of a MBR partition of type 0xEF ? > > Or is there something missing in the FAT filesystem images of e.g. > Debian installation ISOs like > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.3.0-amd64-netinst.iso > > ? It's probably not related to any specific images, as I could boot no standard Linux USB install stick made from an ISO image on this machine, besides Knoppix or Tails. I have installed a Manjaro with grub onto a blank USB stick, in EFI mode, and it would boot perfectly on other machines, but not on affected machine. But AFAIR the USB partition table was DOS, not GPT. So might this machine boot only from GPT disks ? Well, then it would'tn boot a Knoppix ISO image stick. But it does... > Michel: Does a simple ISO "output.iso" work, when made by > > mkdir ./minimal > echo dummy >./minimal/dummy > grub-mkrescue -o output.iso ./minimal > > and then copied onto the plain USB stick device (e.g. /dev/sdc) ? > grub-mkrescue produces valid GPT in ISO 9660. > I've produced an USB stick per your instructions above and tested it OK on another machine. I will try to test it tonight on the affected machine and let you know. Thanks for your help. Kind regards. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi, Daniel Kiper wrote: > > 2) Create EFI System Partition (code EF00) using gdisk. 256.0 MiB will > > suffice. > > 3) Format EFI System Partition > > # mkdosfs /dev/sdb1 > > > >4) Create GRUB2 EFI bootable image > > # mount /dev/sdb1 /mnt > > # mkdir /mnt/efi/boot > > # grub-mkstandalone -O x86_64-efi -o /mnt/efi/boot/bootx64.efi Michel Bouissou wrote: > I tested the USB stick on my son's machine, and I do get a grub prompt. Does this mean that the decisive trick is to use GPT with EFI partition instead of a MBR partition of type 0xEF ? Or is there something missing in the FAT filesystem images of e.g. Debian installation ISOs like https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.3.0-amd64-netinst.iso ? Michel: Does a simple ISO "output.iso" work, when made by mkdir ./minimal echo dummy >./minimal/dummy grub-mkrescue -o output.iso ./minimal and then copied onto the plain USB stick device (e.g. /dev/sdc) ? grub-mkrescue produces valid GPT in ISO 9660. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hi again, Le 29/01/2018 à 16:29, Michel Bouissou a écrit : > I created the USB stick per your instructions. I will try to give it a > shot tonight on my son's machine. I tested the USB stick on my son's machine, and I do get a grub prompt. From there, if I type "help", I get a list of grub shell commands. And if I type "reboot", the machine reboots. So tha'ts a progress. Thanks for the suggestion. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hello, Le 29/01/2018 à 13:49, Daniel Kiper a écrit : > OK, I have looked through the email exchange. I have not seen any info > about the UEFI/firmware update. Have you done that? If you have not > please do. I have installed the latest HP UEFI/firmware from HP on this machine the day I got it (last december) Version is 01.11 (Machine came with 01.09 AFAIR) > If it does not help please create bootable USB stick in > following way. I created the USB stick per your instructions. I will try to give it a shot tonight on my son's machine. For your reference, the machine from which I created the stick is a Manjaro and grub package version is 2.02.0-4. After the grub-mkstandalone phase, the /mnt/efi/boot contains : -rwxr-xr-x 1 root root 12068352 29 janv. 16:19 bootx64.efi Thanks for your help. Kind regards. -- ॐ Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
On Mon, Jan 08, 2018 at 01:48:42PM +0100, Daniel Kiper wrote: > On Wed, Dec 20, 2017 at 12:35:20PM +0100, Thomas Schmitt wrote: > > Hi, > > > > i am unhappy about the state of the thread > > > > http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00010.html > > "HP ProBook x360 11 G1 EE incompatible with grub" > > > > which is about an EFI implementation which SYSLINUX for EFI can operate > > from USB stick whereas GRUB from USB stick ends up with black screen. > > > > An allergy of the firmware towards ISO 9660 hybrid images on USB stick > > can surely be ruled out by > > http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00022.html > > (The only known production ISO with SYSLINUX for EFI does work) > > http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00024.html > > (A normal distro installation works after replacing GRUB by SYSLINUX) > > > > The bug reporter, Michel Bouissou, seems well apt enough to do experiments. > > But i am not apt enough to propose any beyond ISO 9660. > > Could people from this list please give Michel some hints about how to > > retrieve more information about the problem between GRUB and this > > peculiar EFI ? > > Thank you for a notice. Sorry for late reply. I am just back after a bit > longer vacation. Now I am recovering and trying to get at speed. I will > take closer look at the thread next week. OK, I have looked through the email exchange. I have not seen any info about the UEFI/firmware update. Have you done that? If you have not please do. If it does not help please create bootable USB stick in following way. I assume that USB stick is /dev/sdb device. If not please change device path below accordingly. Additionally, if you use Debian, IIRC you do, please install at least following extra packages: dosfstools, gdisk, grub-common and grub-efi-amd64-bin. I assume that other distros has similar ones. 1) Zap GPT and MBR - DANGEROUS - it removes all GPT and MBR partitions # sgdisk -Z /dev/sdb 2) Create EFI System Partition (code EF00) using gdisk. 256.0 MiB will suffice. 3) Format EFI System Partition # mkdosfs /dev/sdb1 4) Create GRUB2 EFI bootable image # mount /dev/sdb1 /mnt # mkdir /mnt/efi/boot # grub-mkstandalone -O x86_64-efi -o /mnt/efi/boot/bootx64.efi # umount /dev/sdb1 Reboot HP machine from this USB stick. You should see normal GRUB2 prompt. If it does not happen then I will think about next steps. If you have any questions please drop me a line. Additionally, I will be at FOSDEM this weekend. So, if you wish and you will be there then you can bring the machine and I can take a look. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
Hello, Le 08/01/2018 à 13:48, Daniel Kiper a écrit : > On Wed, Dec 20, 2017 at 12:35:20PM +0100, Thomas Schmitt wrote: >> Hi, >> >> i am unhappy about the state of the thread >> >> http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00010.html >> "HP ProBook x360 11 G1 EE incompatible with grub" >> >> which is about an EFI implementation which SYSLINUX for EFI can operate >> from USB stick whereas GRUB from USB stick ends up with black screen. >> >> An allergy of the firmware towards ISO 9660 hybrid images on USB stick >> can surely be ruled out by And I believe it has been. I have made a complete Linux install on an USB stick of the latest Manjaro, so the stick is « setup like a hard disk ». It will boot on other UEFI machines but will not boot on the ProBook x360 11 G1 EE. >> The bug reporter, Michel Bouissou, seems well apt enough to do experiments. >> But i am not apt enough to propose any beyond ISO 9660. >> Could people from this list please give Michel some hints about how to >> retrieve more information about the problem between GRUB and this >> peculiar EFI ? As a side note, this is my son's student machine, he needs it daily in college and also often needs it at home, so I don't have it available all day and I cannot do experiments that would break the installed Windows (alas). I have also been on travel between XMas and january 1st, my son at another place with his machine, and I will be in travel again all february. So I volunteer to perform all necessary tests to understand this issue better, however for the reasons above it may take some time before I can both have the machine at hand and time to work on the issue. But I will try my best to perform all proposed tests - and already did quite a number of them... So far my understanding of the issue is : as soon as the computer loads grub, it freezes, independantly of the distro, used, whether be it from an ISO image or a "normally" installed distro, and whether grub was directly loaded from UEFI, or chained from rEFINd. rEFInd works, Syslinux loads and boots ; grub hangs. Best regards. ॐ -- Michel Bouissou OpenPGP ID 0xEB04D09C ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: A thread on grub-bug could need attention
On Wed, Dec 20, 2017 at 12:35:20PM +0100, Thomas Schmitt wrote: > Hi, > > i am unhappy about the state of the thread > > http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00010.html > "HP ProBook x360 11 G1 EE incompatible with grub" > > which is about an EFI implementation which SYSLINUX for EFI can operate > from USB stick whereas GRUB from USB stick ends up with black screen. > > An allergy of the firmware towards ISO 9660 hybrid images on USB stick > can surely be ruled out by > http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00022.html > (The only known production ISO with SYSLINUX for EFI does work) > http://lists.gnu.org/archive/html/bug-grub/2017-12/msg00024.html > (A normal distro installation works after replacing GRUB by SYSLINUX) > > The bug reporter, Michel Bouissou, seems well apt enough to do experiments. > But i am not apt enough to propose any beyond ISO 9660. > Could people from this list please give Michel some hints about how to > retrieve more information about the problem between GRUB and this > peculiar EFI ? Thank you for a notice. Sorry for late reply. I am just back after a bit longer vacation. Now I am recovering and trying to get at speed. I will take closer look at the thread next week. Thanks, Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel