Re: Debian installation issues
-------- Original Message --------
Subject: Re: Debian installation issues
UTC Time: June 10, 2017 7:16 AM
From: scdbackup@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
Reply to: