Re: Debian installation issues
Hi,
> In linux alone the MBR is unnecessary and boot info can be stored in
> each partition and be handled by grub or lilo. Correct?
Not really. A hard-disk-like device that is bootable via BIOS or EFI
must have an MBR. For BIOS because of the x86 prgram. For EFI because
of the need for a partition table. Either MBR partitions or GPT.
Bootloaders like GRUB install their own MBR programs and/or prepare an
EFI System Partition. This happens when you install the boot loader.
As mentioned previously, there is also the boot flag convention, which
is _not_ followed by GRUB and SYSLINUX. This convention expects a program
in the MBR which looks for the boot flag in the MBR partition table.
Then it loads the first block of the partition which has the boot flag
and executes the loaded bytes as x86 program. Aka "chainloading".
> So this is always found in 0-512b and can not be relocated otherwise it
> will not be and can not be found.
Yes. The starting points for BIOS and EFI are in the first 512 bytes.
The minimum requirement for an MBR is that byte 510 must have value 0x55
and byte 511 must have value 0xaa.
But BIOS expects some mindful program bytes for the CPU. EFI expects
at least one partition in the MBR partition table. So there must be some
more beef which depends on the programmer's discretion and skills.
> 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.
I guess Linux attributes the partition numbers according to the item
numbers in the partition table. "sda1" is not a property of the partition,
but rather a name handed out by the kernel.
The partition table formats do not enforce that partition items are
sorted by start address and do not overlap.
> Ok, GPT is a hole in knowledge base. Thanks for the heads up.
To be clear: Most Linux installation ISOs let EFI boot from an MBR
partition of type 0xef when presented on USB stick. Even if they
contain a GPT, it is invalid and the partition with the EFI FAT filesystem
is not marked by the proper type GUID. (Yada yada ...)
If you want to see an ISO with effective GPT then install packages
grub-pc, grub-efi-ia32-bin, grub-efi-amd64-bin, and run
grub-mkrescue -o test.iso /usr/bin/grub-mkrescue
(It wants a file as payload. So it gets the job to pack up itself.)
The resulting file test.iso is equipped with MBR, a single MBR partition
of type 0xee, and a valid GUID Partition Table.
Partition editor gdisk should be happy with it if it does not take
offense of the Apple Partition Map that is present, too.
> > El Torito for BIOS and EFI. No MBR.
> This is on their installation disks, when you install MSw it utilizes the
> MBR
Somewhere in the UDF filesystem must be the bytes which it installs as
MBR boot program and/or the bytes which it installs as EFI System
Partition.
> So making images or transferring the image of the installation disk is
> different than cloning a win installation, correct?
I have problems with the MS-Windows specific terms.
So i cannot answer this.
The image is not prepared to be put plainly on an USB stick and to then boot
like a contemporary Debian ISO is.
> Still this does not explain
> to me what specifically does Rufus do that I couldn't replicate in linux.
I guess it unpacks the UDF filesystem to a partition on the USB stick
and installs the necessary MBR plus boot loader software.
You could completely erase a stick by doing
dd if=/dev/zero of=/dev/sdX
until it reports i/o error. sdX would be the address of your USB stick.
Then let Rufus bring the MS-Windows ISO onto the stick. Afterwards unplug,
replug, and examine the freshly emerged partitioning of the stick.
Mount the partitions and inspect the content of their filesystems.
Compare with the content of the UDF filesystem in the "ISO".
> 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,
Intel rather went the virtual way and defined the EFI operating system,
which is to be implemented by mainboard producers. The chips are supposed
to not matter, as long as the EFI implementation obeys the specs.
Obedience is limited. Some EFIs are too forgiving, others impose extra
demands like the need for some other partition with boot flag if EFI shall
boot from a MBR partition of type 0xef.
Have a nice day :)
Thomas
Reply to: