bzt wrote:
Using GPT is not a requirement for EFI, but you would be a fool not to use it anyway.
GPT is mandatory for BOOTBOOT. There's a good reason why I made the legacy implementation
of BOOTBOOT and the Raspberry Pi version GPT-aware. I don't now why are you afraid of GPT.
All mainstream OS supports it, what's more, some demand it (using GPT is the default for
recent Windows versions, as well as in Linux, and in MacOS, supported by BSDs and Solaris
et cetera, et cetera, et cetera).
I'm glad that finally there's only one partitioning scheme that all OS supports, so why
shouldn't your OS support it too?
I said nothing against using GPT, moreover not expressed any fear about using it, what I said,
that you still perfectly can use the MBR scheme if there is reason (you denied it as a possibility,
what's not true). and there might be such a reason, for example, as mentioned a million times over here, it's the only standard option for SD cards - its standard not only requires FAT as a FS, but also - MBR as a partitioning scheme. Also, for a beginner, it could be easier to start with. see, the OP already has some troubles with partitions. starting without ESP may be easier.
bzt wrote:
zaval wrote:
you can create MBR with an ordinary FAT partition and be sure
Nope, you must mark that FAT partition in MBR as 0xEF. The UEFI spec is pretty clear about
this one. Read sections 5.2.1 Legacy Master Boot Record (MBR) and 12.3.2 Partition Discovery.
If your firmware recognizes ESP without a valid 0xEF type, then good for you, but most EFI
machines out there won't (and according to the spec they shouldn't). And if you have a GPT,
then MBR shouldn't be used at all.
No, you shouldn't. Again, for especially gifted - UEFI, by the specification must and does
recognize any FAT volume attached to the system. "recognize" means - lets you do anything
with this volume your OSL might need - read, write etc. it was exactly the point of my suggestion
to the OP - not use ESP at the beginning, to avoid complications, since different tools
noticing an ESP, even on "virtual" disks, may start to behave whimsy - not something you
want to deal with at the beginning of your OS creation. an ordinary FAT volume for such
cases is more than optimal. try it by yourself instead of needlessly arguing - it works as it should.
bzt wrote:
zaval wrote:
your OSL may access your OS boot volume (where your OS resides)
Storing an entire OS on the ESP boot volume is terrible idea. Boot volumes are (as the name suggests)
to store files required for booting. I would recommend having an ESP boot volume with the loader and
an initrd, and a system partition with the rest of the OS files using your OS's native filesystem
(that's what all mainstream OS does btw).
this is all cool, but Boot Volume != System Partition. I specifically clarified in parenthesis,
that Boot Volume in a FW traditional nomenclature is where your OS resides, OS installation target
in other words.
whatever you imply by "initrd", this unixy thing shouldn't reside in the ESP too, with all the honesty,
but this is for normal OSs, that don't tend to put everything in a monolithic piece of it.
bzt wrote:
zaval wrote:
it's more to bzt with his bootboot. the first time user directs the Boot Manager to load your bootboot,
then, at the start, bootboot checks how it was started (by analyzing BootCurrent variable) and if it's
not from its own Load Option, which is the case for the first start, asks a user if they want to install
bootboot to this machine.
Never gonna happen, the philosophy of BOOTBOOT is to boot the OS without
prompting the user for anything. Besides, you can run BOOTBOOT interactively from an EFI shell without making
any changes to your system. Not to mention if it would rely on NVRAM then you couldn't boot it on machines
without one. Right now you can use BOOTBOOT on the simplest qemu configuration too, and I want to keep it that way.
What you describe is a job for an OS installer or a boot manager, not for a boot loader.
whatever. you are free to make it as lame as you wish.
your "philosophy" avoids
prompting the user for some incomprehensible reasons, but puts stupid limitations on the
same user. woohoo!
what you called NVRAM, is a required part of any UEFI implementation and qemu btw, is not
an exception here. I guess, a normal way of working with an emulated environment, would be
doing as close to the real HW as possible, instead of following some crippled configurations,
some dude cluelessly decided are "better" for the user. it's your choice.
what I described is a normal behavior for a UEFI OSL, that is trying to play good, taking into
account it may run in a multi OS machine and having a FW, that provides it a mechanism for reliably
register itself on the system for the user benefit. OS installer may do this - for the OSL. again,
it doesn't change the fact, that it is the normal way, not that lame \efi\boot\bootx64.efi one.
bzt wrote:
zaval wrote:
on this stubborn placement in \efi\boot\bootx64.efi. this is not a normal way
No, it is the simplest and easiest way, no NVRAM required. By default, qemu does not use an NVRAM
storage, you have to add extra parameters on command line to enable it. Using the default OS loader
name saves you from that.
it's the lamest way for sure. another lame loader, that goes to the same disk, will wipe your bootboot
into oblivion. very "simple". for whom? not for the user. again - NVRAM varibales of UEFI are a requirement.
qemu has no defaults what you are talking about - just supply it with a proper OVMF and options and you are well.
it's not qemu business at all, it's OVMF actually and what you supply. if you provide a crippled set, then yeah,
there is no NVRAM. but the same way, you may not provide even the FW at all! what your bootboot will do then?
this is not for a plain arguing. look. this "default", actually - "last resort" option is heavily overused, so
you easily expose your potential users to needless troubles - literally every lame thing overwrites this "resort"
paths. but why you, as a OSL provider do not use UEFI mechanisms? it's plainly unwise. if you want that this is done
by your user OS installer, good, tell this in your documentation and provide the appropriate help.
let's consider this much saner scenario. you make your bootboot. the user creates their .iso for example, and
puts there bootboot, say in \efi\bzt\bootboot. also, they create OS installer, that will create a Load Option
for it. at the first run, their users, run your loader from the Boot Manager "load from file" option, then it starts
their OS. then their users, when doing installation, run their installer, and that, calls UEFI RS SetVariable(),
creating a Load Option for bootboot, creates ESP if needed and copies it over there. this way, your bootboot will
be seen in the Boot Manager menu as an option, it wouldn't get accidently wiped out by some grub or whatever lamery.
but if you think this is "meh" and abusing that "last chance path" is cool, then I have nothing to add here.