Re: 26th pass at installing 11-3, fails
Hi,
Gene Heskett wrote:
> > And I did try ext2 for an fs choice. Made no difference, it would not set
> > the bootable flag. Tried both fat16 and fat32 too. Spmething would not
> > allow settiing the bootable flag.
The boot flag is set to a partition's description in the partition table,
not to a filesystem (which is the content of a partition).
Are there particular symptoms by which you notice that the missing boot flag
causes the failure to boot ? (Other than you see it missing, of course.)
If your machine's firmware is EFI:
Did you fight enough with the user interface of the firmware (reachable before
booting attempts) in order to enable the disk for booting ?
There should be some screen or menu with a list of drives from which to
choose.
>...> Z370-AII motherboard
Google ... ASUS PRIME Z370-A II ?
Looks modern. Must be EFI. With a fancy blackish "UEFI BIOS Utility" as
user interface.
(... and japanese premium capacitors on the sound module, as the german web
site of ASUS says about it.)
Earlier:
>...> the installer refuses to set the bootable flag on
>...> that drive, it blinks the remote screen, but when its repainted, its
>...> still off. I went thru the loop, even made a new gpt partition table, but
>...> no joy.
Although GPT has the notion of a "Legacy BIOS bootable" flag, there is
few use for it, as i am not aware of MBR code which would look for it.
EFI will surely not demand it.
So probably the partition editor which works for the installer simply
does not set a boot flag to GPT.
In order to compensate for any usesles deviations caused by my remarks,
let me take out one very improbale theory:
>...> boot files too far into the drive maybe?
That's an old cargo-cult idea. Probably caused by a bug in SYSLINUX which
carried the higher 16 bits of a block address to a subsequent 32-bit
computation with a small number. The 16 high bits were zero if the block
address was small. With a high block address, the bits became non-zero
and revealed the bug in preparation of the subsequent computation.
This is fixed since a decade. But still ISO producers ask xorriso to put
boot images to the lowest possible block addresses in the ISO.
tomas@tuxteam.de wrote:
> Read Thomas Schmitt's post on that. He is most probably one of the most
> knowledgeable people around here.
I have to state that i claim being expert only with the ISO 9660 filesystem
and its boot lures for the various firmwares, and with optical drives, i.e
CD, DVD, or BD burners.
By chance the boot variations for ISOs include those for hard disks.
So i know about the boot flag and its potential for early boot failures.
Have a nice day :)
Thomas
Reply to: