61 replies to this topic

[wimb]

Something like that but:

 

in set_true.lst it is MBR Write True instead of False

 

menu.lst is not ok yet .... 

[DapperDeer]

Something like that but:

 

in set_true.lst it is MBR Write True instead of False

 

menu.lst is not ok yet .... 

 

Ah! Fixed, thank you.

 

As for menu.lst, is it the setting of mbr_flag that is not okay or is it the if statement?

 

EDIT: Found https://www.rmprepus...d-insmod-delmod and am changing my menu.lst

 

so far:

cat --hex --skip=0x11BC --length=1 (hd0)+1 | set mbr_flag=
if #%mbr_flag%==#0
    configfile /boot/grub/linux.lst
else
    configfile /boot/grub/windows.lst
fi

Edited by DapperDeer, 29 June 2020 - 09:12 PM.

[wimb]

It should be --skip=0x1BC instead of --skip=0x11BC

The cat output used as input for set mbr_flag needs to be processed in memory to get mbr_flag variable with value 1 Or 0

 

 

menu.lst

cat --hex --skip=0x1BC --length=1 (hd0)+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
echo %mbr_flag% > (md)0x220+1
cat --skip=63 --length=1 (md)0x220+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
pause
if #%mbr_flag%==#0 configfile /boot/grub/linux.lst
if #%mbr_flag%==#1 configfile /boot/grub/windows.lst

Your menu.lst seems a mixture of Grub2 and Grub4dos ....

 

Something else came to my mind:

Your Grub4dos screenshot shows 3 NTFS partitions and ext2 for Linux partition and your Linux has NTFS support.

Your Windows is on 1st partition with FileSystem NTFS

 

Partitions: https://imgur.com/B47DkXA

Windows Explorer, bootmgr and Boot dir: https://imgur.com/uVe7sEq

 

Could it be that your original boot problem comes from Windows being in memory in conflict with the Linux FileSystem ?

Windows does not know anything about ext2  .... and you are first in ext2 FileSystem and try to boot Windows on NTFS partition.

Maybe VM Ware via USB-SATA adapter connected to your HDD can handle both FileSystems without conflict ....

 

BTW It is better to avoid using the 4th partition table entry since that entry is easily destroyed as it is used by some apps and grub4dos partnew command.

It is good practice making never more than 3 primary partitions for MBR partitioning.

Also avoid making logical drives by creating extended partitions.

 

Instead of Linux booting from ext2 partition you might test with knoppix runtimelivecd.iso located on FAT32 partition and booting from RAMDISK

 

see also - That avoids conflict with ext2 partition

[Wonko the Sane]

I disagree.

There is no need to use the in memory complication, let's keep things as simple as possible.

cat --hex --skip=0x01B0 --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~10,2%
set mbr_flag

or:


cat --hex --skip=0x01B0 --length=1 (hd0)0+1 | set mbr_flag=
set /A mbr_flag=0x%mbr_flag:~10,2%
set mbr_flag

Should do nicely.

See also (shameless plug ):
http://reboot.pro/to...ite-hex-values/

And I disagree again , there is nothing "bad" in using logical volumes inside extended, and of course one can use the 4th partition table entry just fine a long as he/she needs not to use partnew or similar approached, let us not invent limitations.

The line is whether one is doing advanced things or not, if he/she does he/she needs to know the consequences of his or that setting, but suggesting to not do this or not do that is unneeded.

What I would NOT do would be to have separate linux. lst and windows.lst, you can use goto inside the same, single, menu.lst, and I would later embed it in the grub4dos, something *like* this would do:

timeout 0
default 0

title This is Linux, item 0

echo here is Linux
pause
cat --hex --skip=0x01BC --length=1 (hd0)0+1
cat --hex --skip=0x01BC --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag

set mbr_flag=%mbr_flag:~10,2%

set mbr_flag

pause
if #%mbr_flag%==#01 goto 1
#do whatever boots Linux

goto 0

title this is Windows, item 1
#do whatever boots Windows
echo here is Windows
pause

Wonko

[wimb]

There is no need to use the in memory complication, let's keep things as simple as possible.

cat --hex --skip=0x01B0 --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~10,2%
set mbr_flag

....
See also (shameless plug ):
http://reboot.pro/to...ite-hex-values/

And I disagree again , there is nothing "bad" in using logical volumes inside extended, and of course one can use the 4th partition table entry just fine a long as he/she needs not to use partnew or similar approached, let us not invent limitations.

.....

 

Ok indeed it can be done easier without using the memory location, but the code needs some corrections.

Using a single menu.lst that can be embedded in grub4dos is also a good idea 

cat --hex --skip=0x01BC --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~11,1%

Avoiding possible sources of error is not a limitation, but is an improved approach based on experience ....

[wimb]

A working solution using Grub4dos could be:

 

menu.lst

timeout 0
default 0

title Status mbr_flag 0 Or 1
echo Status of mbr_flag 0 Or 1 ?
cat --hex --skip=0x1BC --length=1 (hd0)0+1
cat --hex --skip=0x1BC --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~11,1%
echo mbr_flag=%mbr_flag%
echo
pause
if #%mbr_flag%==#0 goto 1
if #%mbr_flag%==#1 goto 2

title Linux
# do verification
echo if verification ok then enable booting Windows - write mbr_flag=1
write --offset=0x1BC --bytes=1 (hd0)+1 1
cat --hex --skip=0x1BC --length=1 (hd0)0+1
cat --hex --skip=0x1BC --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~11,1%
echo mbr_flag=%mbr_flag%
echo press any key to reboot
pause
reboot

title Windows 10
echo disable next time booting Windows - write mbr_flag=0
write --offset=0x1BC --bytes=1 (hd0)+1 0
echo Status of mbr_flag
cat --hex --skip=0x1BC --length=1 (hd0)0+1
cat --hex --skip=0x1BC --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~11,1%
echo mbr_flag=%mbr_flag%
echo press any key to boot Windows with (hd0,0)/bootmgr
pause
chainloader (hd0,0)/bootmgr

[Wonko the Sane]

Ok indeed it can be done easier without using the memory location, but the code needs some corrections.

NO.

The code *needs* NOT any correction.

 

The 11,1 vs the 10,2 only depends on what you want, I prefer 01 (and 00) over 1 and 0, because I tend to reason in bytes, but - as hinted earlier - if you prefer 0 and 1 you can still have the whole byte and use either set /A or set /a to turn it in a numerical value, otherwise in the if check you are comparing a string and #01=#01 works EXACTLY as  #1=#1.

 

As a side note, since a byte is a byte, 01 is a "unique" value, whilst:

01
11

21
31
41
51
61
71
81
91
A1
B1
C1
D1
E1
F1

would be all good with 11,1.

 

Personally I would however use 42 as the check value. 

 

 

Using a single menu.lst that can be embedded in grub4dos is also a good idea  

 

Sure it is, and that is actually *needed*, otherwise it would be trivial to workaround the check.

 

As well it will be *needed* to remove from the grub4dos (and/or GRUB2) used in the "first boot" sequence (very likely a grldr loaded from grldr.mbr written to mbr+hidden sectors[1]) any possibility to drop to command line.

 

 

 

 

Avoiding possible sources of error is not a limitation, but is an improved approach based on experience ....

One thing is warning about possible issues, another one is advising to not do this or that, to be "kosher" one (and one only) primary and at the most one (and only one) Extended should be in the MBR leaving not one, but two slots free.

 

Wonko

 

[1] personally I would NOT use the normal grldr.mbr+grldr, but rather the umbr, writing the actual grldr in the unused space before first partition, since this is related to some form of "secure" booting, in a "static" context ("static" in the sense that once a machine is configured it remains unchanged) the more we make it complex to exit the intended flow, the better.

[Wonko the Sane]

 

A working solution using Grub4dos could be:

Not really.

 

The default needs to be the Linux entry, ALWAYS.

That entry needs to check if the flag is set and in ALL cases but the one where the mbr_flag is the expected value it must continue booting to Linux.

ONLY in the case the mbr_flag is correct, then proceed to the Windows entry or however proceed to boot windows.

 

I mean, what happens to this check:

if #%mbr_flag%==#0 goto 1
if #%mbr_flag%==#1 goto 2

 

if the value is (for whatver reason) not 0, nor 1?

 

Maybe *something like* this would be "better" (in the sense to be less prone to misuse/errors):

timeout 0
default 0

title Boot Entry
echo Status of mbr_flag 0 Or 1 ?
cat --hex --skip=0x1BC --length=1 (hd0)0+1
cat --hex --skip=0x1BC --length=1 (hd0)0+1 | set mbr_flag=
set mbr_flag=%mbr_flag:~10,2%
echo mbr_flag=%mbr_flag%
echo
pause
if not #%mbr_flag%==#42 goto 1

echo disable next time booting Windows - write mbr_flag=0
write --offset=0x1BC --bytes=1 (hd0)+1 0
echo press any key to boot Windows with (hd0,0)/bootmgr
pause
root (hd0,0)
chainloader (hd0,0)/bootmgr

title Linux
#insert here whatever is needed to boot Linux
#the setting of the byte that will be read as mbr_flag
#must happen in Linux, after verification and before the rebooting

Wonko

[wimb]

 

The default needs to be the Linux entry, ALWAYS.

That entry needs to check if the flag is set and in ALL cases but the one where the mbr_flag is the expected value it must continue booting to Linux.

ONLY in the case the mbr_flag is correct, then proceed to the Windows entry or however proceed to boot windows.

 

 

Yes you are right and all output to the screen about mbr_flag and what is tested should be invisible .....  remove or reditrect output to nul by using > nul

Sure, the final version must be different from the developers version. And I think B cannot be used anymore .....

I think there is now enough information given to make it happen ....

[DapperDeer]

It should be --skip=0x1BC instead of --skip=0x11BC
The cat output used as input for set mbr_flag needs to be processed in memory to get mbr_flag variable with value 1 Or 0

cat --hex --skip=0x1BC --length=1 (hd0)+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
echo %mbr_flag% > (md)0x220+1
cat --skip=63 --length=1 (md)0x220+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
pause
if #%mbr_flag%==#0 configfile /boot/grub/linux.lst
if #%mbr_flag%==#1 configfile /boot/grub/windows.lst

 
Your menu.lst seems a mixture of Grub2 and Grub4dos ....
 
Something else came to my mind:
Your Grub4dos screenshot shows 3 NTFS partitions and ext2 for Linux partition and your Linux has NTFS support.
Your Windows is on 1st partition with FileSystem NTFS
 


 

Could it be that your original boot problem comes from Windows being in memory in conflict with the Linux FileSystem ?
Windows does not know anything about ext2  .... and you are first in ext2 FileSystem and try to boot Windows on NTFS partition.
Maybe VM Ware via USB-SATA adapter connected to your HDD can handle both FileSystems without conflict ....
 
BTW It is better to avoid using the 4th partition table entry since that entry is easily destroyed as it is used by some apps and grub4dos partnew command.
It is good practice making never more than 3 primary partitions for MBR partitioning.
Also avoid making logical drives by creating extended partitions.

Kexec from Linux into Grub4dos into Windows was possible during XP days. Now that I think about it maybe I'll try my bootloader with XP... but nonetheless, we had a working version of this with Windows XP.

Also, I've talked with my architect and have been informed that the byte change won't pass with our regulators. I really appreciate the help you guys have given me, apologies for the dead end.

I feel ridiculous not having thought of trying my method with Windows XP sooner. I'm going to sleep right now however but this will be the first thing I do in the morning.

[Wonko the Sane]

Also, I've talked with my architect and have been informed that the byte change won't pass with our regulators. I really appreciate the help you guys have given me, apologies for the dead end.

You can still experiment, it is well possible that this (or that) area of RAM is not re-initialized on a warm boot/re-boot, so you can write the flag somewhere in memory.

 

As well, as hinted before, you can make a snapshot of (relevant part of) memory before booting Linux, (saving it in memory) check/validate it in Linux, kexec to grub4dos, restore saved memory area, reload grub4dos an from it boot to windows.

 

@wimb

Yep, now this possible (but not possible because of regulators) approach seems to me like "develpoed enough"

 

Wonko

[DapperDeer]

Partitions: https://imgur.com/B47DkXA

Windows Explorer, bootmgr and Boot dir: https://imgur.com/uVe7sEq

I finally figured out what the problem was.

I did not have GRLDR.MBR in my C:\ drive and I had to use the bootlace.com utility.

Soon as I put it in after using the bootlace utility, I was able to successfully boot and login to Windows.