-------- Original Message -------- Subject: Re: Debian installation issues UTC Time: June 10, 2017 7:16 AM From: scdbac...@gmx.net
Hi, by mistake Fungi4All and i exchanged a few mails in private. I put this back to the list (although it could deserve a new topic). He showed me a xorriso report of a MS-Windows "ISO" (which we now know is actually an UDF filesystem), and i stated the same as with my reply here to Dan Ritter: All by mistake of hitting reply instead of reply-all. It seems as Thomas includes a header reply-to: Thom... which is passed on by the list while others don't and the reply goes to list. I would have to act against the specs. To boot from hard disk or USB stick, there must be a Master Boot Record. In linux alone the MBR is unnecessary and boot info can be stored in each partition and be handled by grub or lilo. Correct? If an MBR exists grub can have an entry within it including the MS instructions as an option. BIOS loads the 512 bytes of this first block of the disk and executes them as 16 bit x86 program. This program then has to do what is necessary to start the boot loader and later the operating system. So this is always found in 0-512b and can not be relocated otherwise it will not be and can not be found. Playing around with gparted one finds that the order of logical and extended partitions in terms of labels as sda1...sdan is not related to the sequence of the drive's sector. 3 can be in front of 1 and 6 be before 4 .. etc. EFI only looks at the partition table. There are two kinds of table in use: MBR based or GPT. In case of a MBR partition table, EFI looks for a partition with type 0xef. If the MBR partition table only contains only one partition starting at block 1, there might be a GUID Partition Table where EFI looks for a partition with type GUID Ok, GPT is a hole in knowledge base. Thanks for the heads up. C12A7328-F81F-11D2-BA4B-00A0C93EC93B. In the EFI partition there must be a FAT filesystem which contains EFI boot programs like /EFI/BOOT/BOOTX64.EFI for amd64 /EFI/BOOT/BOOTIA32.EFI for i386 /EFI/BOOT/BOOTAA64.EFI for arm64 The EFI System Partition is in the MS-Windows image. But it is not advertised by a partition table. Only by El Torito, which is to be interpreted only if presented on CD, DVD, or BD media. > Are you saying that the boot part of what I send you is pretty much the > same as that of win10ent you downloaded? [...] that image is for a > version of the system 3 generations back, [...] The boot equipment is the same. El Torito for BIOS and EFI. No MBR. This is on their installation disks, when you install MSw it utilizes the MBR So making images or transferring the image of the installation disk is different than cloning a win installation, correct? Still this does not explain to me what specifically does Rufus do that I couldn't replicate in linux. Same iso, same medium, will not boot up, you do it with rufus (which asks what type of image are you burning in the cd/usb) and it boots up first try. > > The size 1 of the EFI System Partition says that it might extend > > up to the end of the image or storage device. > So whether it is on a 4gb medium or 256gb medium it wouldn't matter as > it can not read that far. El Torito can store only block counts up to 65535 which means 32 MiB minus 1 block. If the EFI partition is larger, then UEFI specs prescribe to set the size field to 0 or 1, which both mean that it might reach up to the end of the medium. The FAT filesystem inside the EFI partition has its own size fields. So a reader of the FAT filesystem will not be lured into reading blocks which do not belong to the FAT filesystem. In the case of Win10_1607_English_x64.iso there is really no need to announce 0 or 1. The FAT filesystem is far smaller than 32 MB. > > There seems to be not more than a single file in the ISO. > > So possibly all the show happens inside the FAT filesystem of the > > EFI System Partition. > I suppose the installer and data is all compressed in one file At least in case of Win10_1607_English_x64.iso my suspicion was wrong. The show happens in the UDF filesystem. The EFI partition is too small to contain much brain. You would think that it would even make financial/economic sense, if they all got together and agreed on one basic system for all, a simpler universal bios chip and chipware, and all it would look for a pt and boot info in each partition independently instead of each installation trying to conquer control for the disk entirely and manage the rest. That would be a non-hierarchical system allowed by the hardware. Here we have one system striving to be alone, and the rest of the systems accepting cohabitation but wanting to be in charge of when and how others will boot. Either linux starting msW or msW preventing others from starting. Have a nice day :) Thomas You too, more and more to study
