Researching the undocumented feature
You're right the ntldr
command (it is command, not module) is not documented. So it's a great excuse
for some adventures in
code archaeology.
Whenever I find an undocumented feature, first thing to do is check sources.
The source at the Savannah git repo
shows that it was merged into the main line in August 2010.
The source branch seems no more, but you can still see it came into existence
earlier that year, in April 2010. The checkin comment, from "Vladimir 'phcoder' Serbinenko" was
ntldr support. (based on information from nyu but no code from him)
It's based very closely on the chainloader
command, so much so that
the file name in the header comment still hasn't been updated.
Now that we have an exact checkin, and a name, we can check mailing
archives. You can see where the developers had the discussing about
adding this feature a year earlier on the
grub-devel mailing list:
Some relevant excerpts from that thread:
Robert Millan This patch implements a loader for NTLDR boot semantics (which are
the same in BootMGR, hence both are supported)
Robert Millan If we want this feature at all, I think it should be an option in the
chainloader rather than a standalone command. It's almost the same as
the chainloader really, the only difference is that ntldr is load after
PBR by GRUB instead of by PBR itself.
Vladimir Serbinenko I don't think it's of any problem since
ntldr uses this PBR only as superblock to identify the partition. As
such I would rather consider this loading as a special case of passing
$root, just the form of it is a bit weird
Yves Blusseau About the command, i think that it will be simpler for the user if we have
only one command: chainloader (like in grub4dos) that will try to detect the
type of the bootloader. This is only my personal opinion.
Vladimir Serbinenko I don't agree with this. chainloader and ntldr don't share the same
syntax: chainloader expects a bootsector whereas ntldr expects an
ntldr ot bootmgr file. GRUB2 is done to break with bad design
decisions of GRUB1 one of them being "kernel" command. GRUB4DOS
follows GRUB1 on this subject.
Robert Millan Alright. Let's make it a separate command. I think it should still share
code with chainloader.c though (with some ifdefs).
Answering your question
After poring over all that, what do we know about how it can be used?
It's based on chainloader.
It takes a single argument: the file to open.
It avoids the partition boot record: so it can bypass corruption there.
See this post detailing how they tested that.
It's only about 160 lines of code, you can see there's not much else there.
Hope this was useful!
E.G.:
grub-install --boot-directory=/media/USERNAME/Mounted_BootVolume/ --force /dev/sda3
where /dev/sda3 is the "Patch-Core-Onto-Partition" and may be (but doesnt have to be) the same as Mounted_BootVolume.
".../grub" as the trailing-target-dir obviously cannot be changed
taken from manpage: --boot-directory=...
install GRUB images under the directory DIR/grub instead of the boot/grub dir
P.S.: the new custom-dir is implicitly reflected by any boot-up of the grub-shell (i.e. grub.cfg needs no added prefix= lines) AFAIK
Best Answer
It seems that option --core-compress is declared but not implemented. If you use an option unknown to grub-mkrescue and its helpers, then this option gets forwarded to xorriso, which will complain if it does not know the option either:
But you see a GRUB "PROGRAM ERROR", because include/grub/util/install.h has
If you use the option, it gets translated into the number code GRUB_INSTALL_OPTIONS_INSTALL_CORE_COMPRESS. Now GRUB should somewhere have a piece of code which recognizes that number, reads the argument "xz", and registers the user's wish.
It is done with "--compress=xz". install.h has:
and util/grub-install-common.c has:
But for GRUB_INSTALL_OPTIONS_INSTALL_CORE_COMPRESS, there is no such code nowhere.