30 replies to this topic

[Wonko the Sane]

@gerolf

Please note how the proposed "more normal" way is not exactly the "normal hybrid" way.

Quick sum up:

1) UMBR code in unused space of the MBR chainloading a hardcoded extent (corresponding to grldr or grldr.mbr)
2) "normal Hybrid", normal MBR code in the unused space of the MBR chainloading the bootsector of a partition address written to the MBR partiton table
3) proposed Hybrid, special MBR code in unused space of the MBR chainloading the bootsector of a partition address written also in the unused space of the MBR (pointing to the already existing FAT32 ESP partition)

 

Or, if you prefer:

#1 leaves the protective MBR partition table untouched BUT chainloads a hard coded extent
#2 chainloads the already existing FAT32 ESP partition bootsector BUT adds to the protective MBR partition table a non-standard entry 
#3 leaves the protective MBR partition table untouched AND chainloads the already existing FAT32 ESP partition bootsector

 

The "more normal" refers to the booting sequence:

Normal BIOS booting sequence:

BIOS->MBR code->Active partition in MBR partition table->bootsector code->whatever loader the bootsector code invokes

 

To be compared with:

 

UMBR BIOS booting sequence:

BIOS->UMBR code in the MBR->grldr or glrdr.mbr in a fixed position on disk

 

"normal" Hybrid BIOS booting sequence:

BIOS-> MBR code->partition address added to the protective MBR partitoin table (ugly/non-standard) ->bootsector code->whatever loader the bootsector code invokes

 

Proposed BIOS booting sequence:
BIOS-> MBR code->partition address within MBR code->bootsector code->whatever loader the bootsector code invokes

 

Wonko

[alacran]

@ gerolf

 

I think DiskGenius Free could be more useful than Minitool Partition Wizard, I prefer the portable version, it runs very fine from a WinPE too.

 

If booting from a PE located into a USB device, usually it can deal easily with the EFI and reserved partitions on the internal disk, (never tested it in the particular case of this topic), also it is able to access EXT2/3/4 Linux partitions and let you copy/paste small files from/to a Win partition, this makes easy to copy a file to be edited, and copy back the new modified version (notepad++ Portable version recommended) to EXT2/3/4 partitions if required.

 

alacran

[Gerolf]

Okay. Yes, Alacran, the preinstallation environment should boot faster than the full desktop environment, and if the required binaries to boot to notepad and open the configuration files on the EFI partition are already present on the system, then correspondent entries should of course be added to the boot menus (and this is not limited to legacy Grub4DOS). I never used the preinstallation environment; I understand I still would have to download it. In my thinking it gets a new section number. Here I see the question how to edit configuration files more in general, as one that must be answered for every operating system I'm currently testing, and not as a problem I couldn't solve at all.

 

Concerning section 9, Wonko said in his previous post:

Proposed BIOS booting sequence:

BIOS-> MBR code->partition address within MBR code->bootsector code->whatever loader the bootsector code invokes

 

I understand this is the intended behavior of your mbrfat32GPT program, Wonko. Your post covered precisely the field of my wondering: Why do you somehow seem to "not like" Chenall's UMBR solution, to not be quite content with it? Now my impression is you missed the step I took at the beginning of my previous post, which was to test an option explicitly mentioned in the syntax help but seemed to be untested yet, namely to provide a partition instead of a file as argument. When I say "umbr (hd0,0)+1" and am answered "(hd0,0)+1 success:[66a5]", then umbr does not know that I'm about to install grldr.mbr and grldr. Instead, as you said, it addresses and executes the partition boot sector code. Just like, not in contrast to, your program, which surely has quality of its own, and deserves further development and a dedicated thread. I feel it means something precious to you. I just cannot appreciate this and help you tweak remaining details because of my close-to-zero experience with assembly language.

 

So I think you’re mistaken when you reduce UMBR to this behavior:

 

UMBR BIOS booting sequence:

BIOS->UMBR code in the MBR->grldr or glrdr.mbr in a fixed position on disk

 

I feel misunderstood. And I want to be allowed to seriously answer to objections and to resolve misunderstandings without immediately being torn out of context and taken to the dumpster. This thread wasn't "started by Gerolf", as is falsely stated on top. Instead, my postings were moved here without my approval, and I find myself, on a platform highly frequented by international IT professionals, under my real name, presented as the guy who doesn't know counting starts with number one. I'm not even given edit permission for my own posts to correct the now misleading references. So I also feel disrespected.

 

Though I think our communication has been productive so far, now I'm tempted to stop contributing. I do my very best to not be confusing when writing about new things of complexity. To get a dual-mode machine running, with the help of "Grub4EFI", but interwoven with legacy code, is mind-opening for me. I was in a state of flow, I had energy. Now part of my reporting is moved without any trace, and some of the older posts I mentioned got a different number. Now I'm "promoting disorder". Please move this back. The next thing I wanted to write about is how to edit the customized configuration files for the involved boot managers with the help of Kolibri for UEFI, which may work with "Grub2EFI" but fail with "Grub4EFI", whereas Grub4DOS will happily boot legacy Kolibry. Will my menu.lst just need a little tweak I wasn't aware of, or is it an issue with either "Grub4EFI" or Kolibri?

 

I need a test machine to be more precise and help "Grub4EFI" get out of beta state. There are more such issues to come. How does “this thing” behave on internal disk? It's not that the "Grub4EFI" thread, at the beginning, had always been more to the point or covered the full spectrum opened by its title when revolving about booting from external disk and into RAM. I feel that Zammibro, who was told that "it is not intended for novice users", had a reason when asking, on page 12 of the thread that I was now removed from: "how to add this thing to a Windows PC?"

 

It's not that I was being boring. In one post, titled as section 9 of my reporting about the setup of a test machine for "Grub4EFI", I gave the summary of a solution that took three months and three pages to be found. Then it took me two more posts to improve it a little. I did not intend to extend this section too much. It was the other way round, I wanted to help novice readers set up a dual-mode test machine so that they can provide more meaningful context information when their switching from BIOS to UEFI fails, unlike in the case of the frequent-reader-turned-new-member who had to be told to read and follow the manual; a homework which by the hour seemingly isn't accomplished yet.

[Wonko the Sane]

@gerolf

I have nothing against UMBR, of course.

 

I was trying (clearly failing at it) to make clear that the "proposed Hybrid" and the "UMBR chainloading the bootsector of the ESP partition" are essentially the same approach.

 

Using this (or that) code in the MBR, the UMBR, the modified makebootfat one or another leads to the same result (chainloading the bootsector of the ESP FAT32 partitoin).

 

For Windows users it may be simpler (IF it works, or if it still works) to use the /NT52 bootsector to load grldr (as opposed to installing via Linux and bootlace.com), but of course there are other ways.

 

Otherwise (and it has to be seen if it still works on newer Windows), I had at the time made a small batch to install both the modified makebootfat MBR (which can be replaced by the UMBR installed to point to the ESP partition) and the grub4dos "original" FAT32 MBR.

 

The batch uses the usual simple tools (dumphex,. dsfi, dsfo, hexalter), but it should be possible, now that we have grub4dos batches working quite well, to "port" the whole stuff to a .g4b batch, making the whole stuff depending only on grub4dos, should there be any interest.

 

I am attaching the thingy.

 

 

Wonko

 

 

Attached Files

•  mkgrldrGPT_01.zip   10.15KB   183 downloads

[Gerolf]

Microsoft already has something against your thingy, warning me not to open these archives (again) due to included "malware" that will "damage" my computer.

[Wonko the Sane]

Microsoft already has something against your thingy, warning me not to open these archives (again) due to included "malware" that will "damage" my computer.

Sure, half to 3/4 of files that are not password protected are giving nowadays false alarms, if it is not Microsoft, it is Firefox, recent example:

http://reboot.pro/in...c=18588&page=18

.

I resist the idea of password protecting these as - in order to protect the innocents - these crappy heuristic false positives, actually protect the innocents.

 

I mean, this kind of tools/scripts/etc. should only be used by people that know what they are about as in the hands of kids or of less experienced user they are capable of making a system unbootable.

 

Wonko