Bug#776414: Blurry EFI splash
Package: debian-cd When an official Debian disc image is loaded on a system with EFI, the bootloader is displayed at at size of 800x600, larger than that used on BIOS systems (640x480). The disc images include a bootloader splash image (found in the syslinux directory) which has dimensions of 640x480 however, which is displayed sharp and clear on BIOS systems, but on EFI systems, this splash image is stretched up to 800x600 making it blurry. Please either swap the 640x480 image with an 800x600 one (presuming syslinux will scale it down correctly), or include an additional 800x600 sized one for the grub (EFI) bootloader to use. I have attached a copy of an updated/alternative 'Lines' theme svg, which I also sent to the debian-cd team recently for consideration. This uses the latest 'Lines' theme assets (I noticed tiny differences in the logo compared to the current png that is available in the debian-cd_info archive available on the mirrors), and I made an attempt to clean up the 'GNU/Linux' text (which someone other than the theme author has added on top and imo looked messy). CC-ing the debian-installer team, since the debian-cd_info archive is held under the installer directories on the mirrors.
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
Hi, i just realize that the xorriso run in http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/x86.cfg does not produce an isohybrid image. Therefore one currently cannot simply omit the "isohybrid" run in geniso_hybrid_plus_firmware_partition. Option -isohybrid-mbr is a precondition for -isohybrid-gpt-basdat which marks the EFI boot image in MBR and GPT. It needs the disk path to the file isohdpfx.bin in the local SYSLINUX installation (from where file isolinux.bin stems). debian-cd for debian-7*-amd64.iso does: -isohybrid-mbr syslinux/usr/lib/syslinux/isohdpfx.bin (Don't ask me where its pwd is at that moment.) --- So the small improvement without GPT becomes more attractive: -- Add an argument to util/geniso_hybrid_plus_firmware_partition + efi_fat="$2" and in the case [ "$(GRUB_EFI)" = y ] hand it down from build/config/x86.cfg : if [ "$(GRUB_EFI)" = y ]; then \ xorriso -as mkisofs ... ; \ +geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO) \ $(TEMP_CD_TREE)/boot/grub/efi.img ; \ else \ xorriso -as mkisofs ... ; \ +geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO) "" ; \ fi - geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO) (Why those backslashes and semicolons in config/x86.cfg, btw ?) -- If "$efi_fat" is not empty, (m)copy the directories and files from "$efi_fat" to "$firmware_volume_name" after that one was created by mkfs.msdos. (mtools expert wanted.) -- In the fdisk run at the end of util/geniso_hybrid_plus_firmware_partition - # Pedantically, set partition type to 1: FAT 16 + # Set partition type to 0xef: FAT for EFI echo t echo 2 - echo 1 + echo 239 --- Now, who wants to set up a debian-installer, make the proposed code changes, and produce a mini.iso which i can inspect ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/25222543353042887...@scdbackup.webframe.org
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
Hi, > xorriso -as mkisofs -r -J -b isolinux.bin -c boot.cat \ > -no-emul-boot -boot-load-size 4 -boot-info-table \ > -eltorito-alt-boot \ > --efi-boot boot/grub/efi.img -no-emul-boot \ > -o $(TEMP_MINIISO) $(TEMP_CD_TREE); \ I did not guess too bad with my repacking experiment. But this does not explain how the empty FAT partition got to the end of mini.iso I see in http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/x86.cfg#n347 geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO) So obviously the appended partition was not intended for EFI but for additional firmware. Now if mini.iso gets GPT, then http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/geniso_hybrid_plus_firmware_partition should add its partition to GPT too. At its end, it uses fdisk to manipulate the MBR partition table. Number 2 would have to become 3 then, because slot 2 is already occupied by /boot/grub/efi.img. I guess that gdisk can do similar for GPT. Problem is that the GPT backup block needs to be moved after the end of the partition data which was appended in line 37: cat "$firmware_volume_file" >> "$iso" I dimly remember that gdisk has a menu item for moving the backup GPT and/or for re-creating the backup GPT. The backup GPT would actually have to be re-located whenever the ISO image gets copied onto a disk device. It might be that gdisk or other partition editors go on strike when they see the nested partitions. In this case, we might need to write MBR and GPT slots on byte level. (A re-write to geniso_hybrid_plus_firmware_partition.c would be a good idea then. Byte manipulation in shell is cumbersome.) It is a bad idea to apply the SYSLINUX program "isohybrid" to an ISO which was equipped with advanced isohybrid by xorriso. So one should delete line 26: isohybrid -h "$heads" -s "$sectors" "$iso" > I guess -e is short for --efi-boot? --efi-boot XYZ does a bit more: -eltorito-alt-boot -e XYX -no-emul-boot -eltorito-alt-boot Since i propose to apply -isohybrid-gpt-basdat, one would have to switch to -e . E.g.: --eltorito-alt-boot \ ---efi-boot boot/grub/efi.img -no-emul-boot \ +-eltorito-alt-boot \ +-e boot/grub/efi.img \ +-no-emul-boot -isohybrid-gpt-basdat \ -e is quite like -b, including the inappropriate default to mark the boot image in El Torito as emulated floppy disk. Therefore option -no-emul-boot must be given. > I don't suppose I can tempt you into sending a patch against the above > git repo, can I? ;-) Seems we are not done with development yet. There is the problem that i cannot easily test because i have no EFI and not even a contemporary Debian. If an authorized developer can set up a suitable environment for production of mini.iso, i will help to adapt the scripts. We will have to make decisions. E.g. whether to keep a BIOS-only version of mini.iso and thus cannot hardcode the partition number in geniso_hybrid_plus_firmware_partition. Some experience with gdisk would be helpful. (I guess my Debian 6 test system can give me hints.) - Alternatively one could really copy the directories and boot program from /boot/grub/efi.img into the appended partition and give it the type 0xef. Having no GPT would avoid problems with the appended partition. But it might be that some EFI implementations will not recognize the MBR partition and insist in GPT. Only tests can tell. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/661054846588...@scdbackup.webframe.org
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
On Tue, 2015-01-27 at 15:57 +0100, Thomas Schmitt wrote: [...] Thanks for all the excellent information, I still have fully absorbed it all... > Regrettably there is no file /.disk/mkisofs in the ISO which > tells the used xorriso -as mkisofs options. > I guess that /boot/grub/efi.img got marked by an option like The code is at: http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/x86.cfg#n335 and has: xorriso -as mkisofs -r -J -b isolinux.bin -c boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -eltorito-alt-boot \ --efi-boot boot/grub/efi.img -no-emul-boot \ -o $(TEMP_MINIISO) $(TEMP_CD_TREE); \ > -e boot/grub/efi.img I guess -e is short for --efi-boot? > To mark this file in MBR and GPT, one may add option > > -isohybrid-gpt-basdat > > directly after -e and its argument. I don't suppose I can tempt you into sending a patch against the above git repo, can I? ;-) Ian. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422371143.25294.40.ca...@debian.org
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
Hi, Jack Truong wrote: > I have copied the contents of efi.img to the FAT partition and it does boot > on my EFI firmware now. Thank you! So your EFI indeed hopped on that partition. Possibly only because it sees no other indication where to start the boot process. I now wonder whether the MBR partition 2 is actually intended as EFI System Partition. The partition type 0x01 generally indicates a FAT12 filesystem. An EFI partition should have type 0xef. Regrettably there is no file /.disk/mkisofs in the ISO which tells the used xorriso -as mkisofs options. I guess that /boot/grub/efi.img got marked by an option like -e boot/grub/efi.img To mark this file in MBR and GPT, one may add option -isohybrid-gpt-basdat directly after -e and its argument. I tested by extracting the MBR and partition 2 from mini.iso, mounting it, and repacking a new mini_with_gpt.iso by: $ dd if=mini.iso bs=512 count=1 of=mini_template.mbr $ dd if=mini.iso bs=512 skip=45056 count=12288 of=mini_partition2.img $ mount -o loop mini.iso /mnt/iso $ xorriso -as mkisofs -R \ -o mini_with_gpt.iso \ -isohybrid-mbr mini_template.mbr \ -c '/boot.cat' \ -b '/isolinux.bin' \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -eltorito-alt-boot \ -e '/boot/grub/efi.img' \ -isohybrid-gpt-basdat -no-emul-boot \ -append_partition 3 0x01 mini_partition2.img \ /mnt/iso This yields: Volume id: 'ISOIMAGE' El Torito catalog : 45 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 4 46 El Torito boot img : 2 UEFI y none 0x 0x00832 66 El Torito img path : 1 /isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img System area options: 0x0102 System area summary: MBR isohybrid cyl-align-on GPT ISO image size/512 : 45056 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x00045056 MBR partition : 2 0x00 0xef 264 832 MBR partition : 3 0x00 0x014505612288 MBR partition path : 2 /boot/grub/efi.img GPT: N Info GPT disk GUID : 61bf3bd0595c364488002bde6f8fecfb GPT entry array: 2 248 overlapping GPT lba range : 64 44992 45055 GPT partition name : 1 490053004f00480079006200720069006400 GPT partname local : 1 ISOHybrid GPT partition GUID : 1 61bf3bd0595c364488022bde6f8fecfb GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 0 44992 GPT partition name : 2 490053004f004800790062007200690064003100 GPT partname local : 2 ISOHybrid1 GPT partition GUID : 2 61bf3bd0595c364488032bde6f8fecfb GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x1001 GPT start and size : 2 264 832 GPT partition path : 2 /boot/grub/efi.img Now the empty FAT12 filesystem is in MBR partition 3. It is unclear whether it is usiable on a system that knows about GPT. (Maybe i should enhance -append_partition so that it publishes the partition in GPT too.) Of course, if the empty 6 MB partition is undesired in a 22.5 MB ISO, then one can omit option -append_partition 3 0x01 mini_partition2.img \ from above xorriso run. If one wants to eradicate GPT and only keep MBR: $ cp mini_with_gpt.iso mini_with_mbr_efi.iso $ dd if=/dev/zero bs=512 count=1 seek=1 conv=notrunc of=mini_with_mbr_efi.iso $ dd if=/dev/zero bs=512 count=1 seek=45055 conv=notrunc of=mini_with_mbr_efi.iso (The backup GPT header is the last 512 block of the ISO filesystem range. Probably the appended partition data prevent it from being recognized at all.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/29399543329384549...@scdbackup.webframe.org
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
Hi all, The ISO in question was in fact the same one mentioned (http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20150107/images/netboot/mini.iso). I have copied the contents of efi.img to the FAT partition and it does boot on my EFI firmware now. Thank you! On 01/27/2015 04:47 AM, Thomas Schmitt wrote: Hi, Summary: There are two EFI System Partitions in mini.iso. The one for booting from USB stick or qemu -hdb is indeed empty. One could try whether it helps to copy the files from the FAT image /boot/grub/efi.img in the ISO to MBR partition 2: - Put mini.iso onto a USB stick /dev/sdb or other hard disk device dd if=mini.iso of=/dev/sdb - Mount the ISO image mount -o loop mini.iso /mnt/iso - Mount the FAT filesystem inside /mnt/iso/boot/grub/efi.img mount -o loop /mnt/iso/boot/grub/efi.img /mnt/fat_iso - Mount the FAT filesystem in MBR partition 2 of the USB stick mount /dev/sdb2 /mnt/fat - Copy from efi.img into partition 2 of the USB stick: cp -a /mnt/fat_iso/* /mnt/fat - Check for sucessful copy: find /mnt/fat should yield /mnt/fat /mnt/fat/efi /mnt/fat/efi/boot /mnt/fat/efi/boot/bootx64.efi - Unmount what you mounted: umount /mnt/fat_iso /mnt/fat /mnt/iso - Try whether the stick boots via EFI. --- Details: Cyril Brulebois wrote: I don't know much about EFI Partition etc. therefore I'm not sure how they're related to an ISO9660 image. :/ mini.iso and debian-7*-amd64-netinst.iso differ in this aspect. In Debian amd64 netinst, the EFI System Partition is a data file inside the ISO filesystem which contains a FAT filesystem image. In this FAT image there are the files which EFI will use for booting. Debian has GRUB2 boot loader equipment in there. The block address and size of the EFI partition is published by an entry in the El Torito boot catalog, by a partition table entry in the MBR, by a partition table entry in GPT, and by a (probably useless) entry in Apple Partition Map. Inspecting mini.iso http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20150107/images/netboot/mini.iso by xorriso-1.3.8 yields: Volume id: 'ISOIMAGE' El Torito catalog : 59 1 El Torito cat path : /boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 48959 El Torito boot img : 2 UEFI y none 0x 0x008329205 El Torito img path : 1 /isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img System area options: 0x0302 System area summary: MBR isohybrid cyl-align-all ISO image size/512 : 44332 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x17045056 MBR partition : 2 0x00 0x014505612288 So we have no GPT and no (probably useless) APM here. There are two EFI partitions exposed. One is the data file /boot/grub/efi.img of the ISO filesystem pointed to by the El Torito boot catalog. The other is an appended blob, marked by MBR partition 2. (The partition type 0x01 is questionable.) One can extract them by: mount -o loop mini.iso /mnt/iso cp /mnt/iso/boot/grub/efi.img eltorito_efi.img dd if=mini.iso bs=512 skip=45056 count=12288 of=mbr_efi.img Both files differ heavily in size -r--r--r-- 1 thomas thomas 425984 2015-01-27 09:59 eltorito_efi.img -rw-r--r-- 1 thomas thomas 6291456 2015-01-27 10:00 mbr_efi.img Inspecting both: $ mount -o loop eltorito_efi.img /mnt/fat $ find /mnt/fat /mnt/fat /mnt/fat/efi /mnt/fat/efi/boot /mnt/fat/efi/boot/bootx64.efi $ umount /mnt/fat $ mount -o loop mbr_efi.img /mnt/fat $ find /mnt/fat /mnt/fat $ So the El Torito advertised partition contains files, whereas the MBR advertised partition has an empty filesystem. Probably mini.iso will boot via EFI from CD/DVD/BD resp. qemu -cdrom, but not from USB stick resp. qemu -hdb. The presence of an isohybrid MBR will allow booting via BIOS emulation. --- For comparison the boot anatomy of a amd64 netinst ISO: $ xorriso-1.3.8 -indev debian-7.7.0-amd64-netinst.iso \ -report_el_torito plain -report_system_area plain ... Volume id: 'Debian 7.7.0 amd64 1' El Torito catalog : 847 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 4 848 El Torito boot img : 2 UEFI y none 0x 0x00896 860 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
Hi, Summary: There are two EFI System Partitions in mini.iso. The one for booting from USB stick or qemu -hdb is indeed empty. One could try whether it helps to copy the files from the FAT image /boot/grub/efi.img in the ISO to MBR partition 2: - Put mini.iso onto a USB stick /dev/sdb or other hard disk device dd if=mini.iso of=/dev/sdb - Mount the ISO image mount -o loop mini.iso /mnt/iso - Mount the FAT filesystem inside /mnt/iso/boot/grub/efi.img mount -o loop /mnt/iso/boot/grub/efi.img /mnt/fat_iso - Mount the FAT filesystem in MBR partition 2 of the USB stick mount /dev/sdb2 /mnt/fat - Copy from efi.img into partition 2 of the USB stick: cp -a /mnt/fat_iso/* /mnt/fat - Check for sucessful copy: find /mnt/fat should yield /mnt/fat /mnt/fat/efi /mnt/fat/efi/boot /mnt/fat/efi/boot/bootx64.efi - Unmount what you mounted: umount /mnt/fat_iso /mnt/fat /mnt/iso - Try whether the stick boots via EFI. --- Details: Cyril Brulebois wrote: > I don't know much about EFI Partition etc. therefore I'm not > sure how they're related to an ISO9660 image. :/ mini.iso and debian-7*-amd64-netinst.iso differ in this aspect. In Debian amd64 netinst, the EFI System Partition is a data file inside the ISO filesystem which contains a FAT filesystem image. In this FAT image there are the files which EFI will use for booting. Debian has GRUB2 boot loader equipment in there. The block address and size of the EFI partition is published by an entry in the El Torito boot catalog, by a partition table entry in the MBR, by a partition table entry in GPT, and by a (probably useless) entry in Apple Partition Map. Inspecting mini.iso http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20150107/images/netboot/mini.iso by xorriso-1.3.8 yields: Volume id: 'ISOIMAGE' El Torito catalog : 59 1 El Torito cat path : /boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x 0x00 48959 El Torito boot img : 2 UEFI y none 0x 0x008329205 El Torito img path : 1 /isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /boot/grub/efi.img System area options: 0x0302 System area summary: MBR isohybrid cyl-align-all ISO image size/512 : 44332 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x17045056 MBR partition : 2 0x00 0x014505612288 So we have no GPT and no (probably useless) APM here. There are two EFI partitions exposed. One is the data file /boot/grub/efi.img of the ISO filesystem pointed to by the El Torito boot catalog. The other is an appended blob, marked by MBR partition 2. (The partition type 0x01 is questionable.) One can extract them by: mount -o loop mini.iso /mnt/iso cp /mnt/iso/boot/grub/efi.img eltorito_efi.img dd if=mini.iso bs=512 skip=45056 count=12288 of=mbr_efi.img Both files differ heavily in size -r--r--r-- 1 thomas thomas 425984 2015-01-27 09:59 eltorito_efi.img -rw-r--r-- 1 thomas thomas 6291456 2015-01-27 10:00 mbr_efi.img Inspecting both: $ mount -o loop eltorito_efi.img /mnt/fat $ find /mnt/fat /mnt/fat /mnt/fat/efi /mnt/fat/efi/boot /mnt/fat/efi/boot/bootx64.efi $ umount /mnt/fat $ mount -o loop mbr_efi.img /mnt/fat $ find /mnt/fat /mnt/fat $ So the El Torito advertised partition contains files, whereas the MBR advertised partition has an empty filesystem. Probably mini.iso will boot via EFI from CD/DVD/BD resp. qemu -cdrom, but not from USB stick resp. qemu -hdb. The presence of an isohybrid MBR will allow booting via BIOS emulation. --- For comparison the boot anatomy of a amd64 netinst ISO: $ xorriso-1.3.8 -indev debian-7.7.0-amd64-netinst.iso \ -report_el_torito plain -report_system_area plain ... Volume id: 'Debian 7.7.0 amd64 1' El Torito catalog : 847 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 4 848 El Torito boot img : 2 UEFI y none 0x 0x00896 860 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 System area options: 0x0102 System area summary: MBR isohybrid cyl-align-on GPT APM ISO image size/512 : 454656 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
On Tue, 2015-01-27 at 09:15 +0100, Cyril Brulebois wrote: > I've just grabbed mini.iso in both (respectively used for Beta 2 and RC > 1), and both seem to have efi bits inside (at least according to a loop > mount). Not speaking of boot.efi but -- there was no useful grub.cfg on the x86 mini.iso until the 20150107 release (see #762618). So 20150107 is certainly necessary for a useful EFI boot from mini.iso and everything was present and correct when I was looking at #762618. It's possible I suppose that the lack of grub.cfg might look a bit like a lack of boot.efi under some circumstances. > I don't know much about EFI Partition etc. therefore I'm not > sure how they're related to an ISO9660 image. :/ (Feel free to skip this bit if you don't care about the details!) The EFI System Partition (ESP) is on the ISO as /boot/grub/efi.img, which is a file with a suitable FAT partition for EFI to read (it's also referenced by various ISO headers, el-torito/*mumble* etc). AFAICT the beta release (20141002) had everything needed apart from the grub.cfg: $ wget http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20141002/images/netboot/mini.iso $ isoinfo -i mini.iso -RJ -x /boot/grub/efi.img > efi.img $ mdir -i efi.img ::efi/boot Volume in drive : has no label Volume Serial Number is FF65-0EDB Directory for ::/efi/boot . 2014-09-27 0:08 ..2014-09-27 0:08 bootx64 efi392192 2014-09-27 0:08 3 files 392 192 bytes 10 240 bytes free $ The remainder of the grub bits are then on the ISO (outside the ESP) in /boot/grub/..., except as noted, that the grub.cfg in 20141002 was empty. $ isoinfo -i mini.iso -fRJ | grep /boot/grub /boot/grub /boot/grub/efi.img /boot/grub/font.pf2 /boot/grub/grub.cfg /boot/grub/x86_64-efi /boot/grub/x86_64-efi/acpi.mod [...lots more...] > It'd be nice to start by telling us the full URL to the mini.iso you > downloaded. Yes, please. Ian. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422348131.29309.13.ca...@debian.org
Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader
Hi Jack, and thanks for your report. Jack Truong (2015-01-26): > Package: cdimage.debian.org > > Apologies if this is the wrong package. This might be, but don't worry, we'll sort it out. > I'm using the jessie rc1 amd64 mini.iso and the EFI partition doesn't seem > to have anything in it. It should have efi/boot/boot.efi for EFI > firmware to load properly. It also doesn't seem to exist in the i386 image > either. mini.iso is produced during the build of the debian-installer package, and later installed on mirrors in e.g.: http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20141002/images/netboot/ http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20150107/images/netboot/ I've just grabbed mini.iso in both (respectively used for Beta 2 and RC 1), and both seem to have efi bits inside (at least according to a loop mount). I don't know much about EFI Partition etc. therefore I'm not sure how they're related to an ISO9660 image. :/ It'd be nice to start by telling us the full URL to the mini.iso you downloaded. Mraw, KiBi. signature.asc Description: Digital signature
