Jump to content











Photo
- - - - -

Grub4DOS Disk Read Error Happens on Physical Hardware but not VM


  • Please log in to reply
60 replies to this topic

#26 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 25 June 2020 - 08:23 PM

I've used BOOTICE to add a WIM boot entry (it doesn't actually go anywhere I think) and make my Win10 boot in Minimal Safe Mode, and still have this same problem.

 

I think Wonko is right that there's something happening within/around the BIOS and my kexec call. When I get to the Windows Boot Manager, my keyboard is still non-functional.

 

There is NO USB for booting. This is all on the hard disk that Windows sits on.

 

BIOS -> Grub2 -> Grub4DOS -> Internal HDD Win10 is OK

BIOS -> Grub2 -> Linux -> kexec Grub4Dos -> Internal HDD Win10 FAILS

[Contained in VM]: BIOS -> Grub2 -> Linux -> kexec Grub4dos -> USB-SATA HDD Adapter is OK

 

Ok thanks for the info to make things clear to me.

Where is Grub2 and Grub4dos located ?



#27 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 25 June 2020 - 08:34 PM

Ok thanks for the info to make things clear to me.

Where is Grub2 and Grub4dos located ?

 

Grub2 is (I believe) installed in the MBR of the drive. 

grub-install /dev/sdc is the command I give it.

 

Grub4Dos' exe is located on my Linux partition. 



#28 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 26 June 2020 - 01:30 PM

Could it be that you can use the bootsequence

 

BIOS -> Grub2 -> Linux -> BIOS -> Grub2 -> Grub4dos -> Internal HDD Win10 is OK

 

Where you in Linux determine whether the Windows 10 entry in Grub4dos Menu appears to be true or false

 

In that case kexec is not used anymore

 

Linux boot entry which does integrity checks, changes the variable to true, and reboots



#29 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 June 2020 - 03:06 PM

Could it be that you can use the bootsequence

 

BIOS -> Grub2 -> Linux -> BIOS -> Grub2 -> Grub4dos -> Internal HDD Win10 is OK

 

Where you in Linux determine whether the Windows 10 entry in Grub4dos Menu appears to be true or false

 

In that case kexec is not used anymore

But that is not a "boot" sequence, it is a "reboot" one.

1) BIOS -> Grub2 -> Linux

2) Reboot

3) BIOS -> Grub2 -> Grub4dos -> Internal HDD Win10 is OK

 

Though it would probably be possible to create a sort of "report" of the checks done in Linux and have either GRUB2 or grub4dos verify this "report". :unsure:

 

:duff:

Wonko



#30 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 26 June 2020 - 03:25 PM

But that is not a "boot" sequence, it is a "reboot" one.

1) BIOS -> Grub2 -> Linux

2) Reboot

3) BIOS -> Grub2 -> Grub4dos -> Internal HDD Win10 is OK

 

Though it would probably be possible to create a sort of "report" of the checks done in Linux and have either GRUB2 or grub4dos verify this "report". :unsure:

 

 

Yes it involves a reboot, but that was also the case in the original approach ....

 

Linux boot entry which does integrity checks, changes the variable to true, and reboots



#31 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 26 June 2020 - 05:16 PM

Could it be that you can use the bootsequence

 

BIOS -> Grub2 -> Linux -> BIOS -> Grub2 -> Grub4dos -> Internal HDD Win10 is OK

 

Where you in Linux determine whether the Windows 10 entry in Grub4dos Menu appears to be true or false

 

In that case kexec is not used anymore

 

Linux boot entry which does integrity checks, changes the variable to true, and reboots

 

The problem with using Linux to check true/false is that there is no way to make "Clean" equal to False after setting it to true. 

 

Grub2 -> Linux -> Clean = True -> Reboot

Grub2 -> Windows 10 -> Reboot

Grub2 -> Windows 10

 

Unfortunately, this comes back to my original problem/thread of being unable to edit anything on the filesystem. 



#32 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 June 2020 - 08:21 AM

Unfortunately, this comes back to my original problem/thread of being unable to edit anything on the filesystem. 

Well, not only the filesystem exists.

 

You have at very least 2048-whatever GRUB2 install takes, likely more than 2000 unused sectors before first partition.

(and don't come out saying that you cannot use any of them as you already partially "ruined" that area (LBA1 to LBA 2047 should in theory be unused/00) by installing GRUB2)

 

And you have also (at least in an installed grub4dos, cannot say on an installed GRUB2) a whole usable sector on LBA1 (reserved as the optional copy of a previous MBR).

 

Then you might have some excess sectors here and there between partitions and possibly even a few in the "no man zone":
http://reboot.pro/to...-dsfo/?p=166592

 (which is technically at the same time part of the filesystem but not a part of it :w00t: and totally inaccessible via the filesystem)

 

But even in the MBR itself you have some bytes that you can use.

 

Also, memory normally survives a warm reboot (though needs to be tested specifically).

 

:duff:

Wonko



#33 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 28 June 2020 - 07:56 AM

In Grub4dos we can read the MBR using grub command

cat --hex (hd0)+1

At offset 0x1B8 we have 4 bytes for Disk Sgnature in my case C01C 117F - 2 bytes 0000 for free use - 2 bytes of first partition entry - 8001 (80=active byte)

 

The interesting 8 bytes of MBR are shown with grub command

cat --hex --skip=0x1B8 --length=8 (hd0)+1

We can use grub4dos to write at offset 0x1BC just one byte being 1 or 0 for true and false respectively

The effect is illustrated with

write --offset=0x1BC --bytes=1 (hd0)+1 1
cat --hex --skip=0x1B8 --length=8 (hd0)+1
write --offset=0x1BC --bytes=1 (hd0)+1 0
cat --hex --skip=0x1B8 --length=8 (hd0)+1

In TinyHexer we can show the effect at offset 0x1BC byte 31 = 1 and byte 30 = 0

 

== 

 

You can modify Grub4dos file menu.lst to use and see the effect of switching MBR in True Or False

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write False - Boot (hd0,0)/bootmgr
cat --hex --skip=0x1BC --length=1 (hd0)+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
write --offset=0x1BC --bytes=1 (hd0)+1 0
cat --hex --skip=0x1BC --length=1 (hd0)+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
pause
chainloader (hd0,0)/bootmgr

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write True - Boot (hd0,0)/bootmgr
cat --hex --skip=0x1BC --length=1 (hd0)+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
write --offset=0x1BC --bytes=1 (hd0)+1 1
cat --hex --skip=0x1BC --length=1 (hd0)+1 | set mbr_flag=
echo mbr_flag=%mbr_flag%
pause
chainloader (hd0,0)/bootmgr



#34 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 28 June 2020 - 10:17 AM

How to put the result of reading MBR True/False byte into grub4dos variable mbr_flag ?

 

More Info in Grub4dos Guide given by Steve - steve6375  :)  and in redirection and piping

Use cat to read MBR byte and copy string result to memory location (md)0x220+1

Then use cat with skip to read memory byte into variable mbr_flag

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write False - Boot (hd0,0)/bootmgr
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%
write --offset=0x1BC --bytes=1 (hd0)+1 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
chainloader (hd0,0)/bootmgr

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write True - Boot (hd0,0)/bootmgr
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%
write --offset=0x1BC --bytes=1 (hd0)+1 1
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
chainloader (hd0,0)/bootmgr

 



#35 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 29 June 2020 - 05:19 PM

Wimb, I thoroughly appreciate all your hard work in getting a writable mbr_flag to function. I've not yet tested it on my system, but I will be doing that later in the day and will report back with my progress.

 

In the meantime, I was instructed to install Windows 7 and see if my method worked for that OS to see if Win10 was causing me an issue. After installing Win7, I ran into what appears to be the same issue. Upon trying to boot, Windows tells me that it's unable to find drivers for my boot device. This coincides with Win10 and tells me that Windows is truly not loading the drivers necessary for it to find the hard drives. Is there some way I can track what drivers Windows loads during boot? I figure if I track a working boot method and my non-working boot method, I can find the missing drivers needed and then find a way to force Windows to load them during/after Grub4Dos.



#36 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 05:24 PM

Try to Install without using VM ware.

It is well known that VM-ware is using special drivers that become part of the installation.

Often Windows installed on VM is giving troubles for booting on real hardware.

 

After booting with Win10XPE.wim from USB then use WinNTSetup for Install of Win 10 or 7 on HDD partition.

 



#37 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 29 June 2020 - 05:59 PM

Try to Install without using VM ware.

It is well known that VM-ware is using special drivers that become part of the installation.

Often Windows installed on VM is giving troubles for booting on real hardware.

 

After booting with Win10XPE.wim from USB then use WinNTSetup for Install of Win 10 or 7 on HDD partition.

 

 

I'm not installing Windows through VM. I am using a Windows USB and physical hardware - no VM involved whatsoever in the Windows installation process. The only time a VM comes into play is when I have to install Grub2/Grub4Dos and my Linux Kernel but this is done after the Windows installation. 



#38 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 06:06 PM

OK then I misunderstood the way of Install of Windows 10.

 

In that case booting through Linux and kexec might be the cause of the problem.

Well you have a working solution:

 

Grub2 > Linux > Reboot > Grub2 > Grub4dos > Windows 10



#39 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 29 June 2020 - 06:39 PM

How to put the result of reading MBR True/False byte into grub4dos variable mbr_flag ?

 

More Info in Grub4dos Guide given by Steve - steve6375  :)  and in redirection and piping

Use cat to read MBR byte and copy string result to memory location (md)0x220+1

Then use cat with skip to read memory byte into variable mbr_flag

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write False - Boot (hd0,0)/bootmgr
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%
write --offset=0x1BC --bytes=1 (hd0)+1 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
chainloader (hd0,0)/bootmgr

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write True - Boot (hd0,0)/bootmgr
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%
write --offset=0x1BC --bytes=1 (hd0)+1 1
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
chainloader (hd0,0)/bootmgr

 

attachicon.gifMBR_SetFalse_20200629.jpg

 

I think the boot process would be something like:

 

Power On:

    -> Grub4Dos

        Grub4Dos checks the variable and determines that it is false. Thus, it only shows the menu entry for Linux.

    -> Linux

        Linux verifies the filesystem, changes the variable to true, and forces a reboot.

    -> Grub4Dos

        Grub4Dos checks the variable and determines that it is true. Thus, it only shows the menu entry for Windows.

        On selecting Windows, Grub4Dos changes the variable back to false.

 

I have a few questions:

Would this be easier on Grub2? I'm not sure how editing specific bytes using memory addresses works. 

If our verification stamp checks whitespace, would this method still work? Wonko mentioned a bunch of specific unused sectors which may be true but could render the stamp invalid nonetheless. 

Why specifically the memory address 0x01BC? Would any byte within the range 0x01F0 - 0x01FD work?



#40 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2020 - 06:44 PM

In the meantime, I was instructed to install Windows 7 and see if my method worked for that OS to see if Win10 was causing me an issue. After installing Win7, I ran into what appears to be the same issue. Upon trying to boot, Windows tells me that it's unable to find drivers for my boot device. This coincides with Win10 and tells me that Windows is truly not loading the drivers necessary for it to find the hard drives. Is there some way I can track what drivers Windows loads during boot? I figure if I track a working boot method and my non-working boot method, I can find the missing drivers needed and then find a way to force Windows to load them during/after Grub4Dos.

 

No.

 

The issue is not at driver level, it happens earlier.

Both the Windows 10 and the Windows 7 work just fine (by themselves and after a "clean" BIOS boot).

Either your Linux distro (more likely) or kexec (less likely) destroys *something* in the BIOS values.

 

When you chainload BOOTMGR, it:
1) reads in real mode *something* in these BIOS values
2) passes these values to "self" and when it switches to protected mode uses these vaues to load drivers.

 

If these values are wrong or missing the driver cannot be loaded or cannot be loaded properly.

 

It is possible - at least in theory - that you could:

1) boot BIOS->grub4dos (or BIOS->GRUB2->grub4dos)
2) from grub4dos dd/save a portion of memory (containing these values)[1]
3) proceed to your Linux, verify whatever you need to verify and kexec to grub4dos
4) from grub4dos restore this portion of memory
5) proceed to chainload BOOTMGR with the right values

 

Knowing which locations of memory contain these values will be the hardest part (personally I do not have any idea from where to start, though you could make two "full"[2] memory dumps and compare them).

 

Besides it is also possible that *something* in either your Linux or kexec "locks" some BIOS interrupts.

 

:duff:

Wonko

 

 

 

[1] the a1ive's version of GRUB2 does have a dd command so it might be possible to use directly that GRUB2

[2] let's say from 0x00000000 to 0x00FFFFFF for a start, though modern BIOS tend to use higher addresses, hopefully you can run BIOS function INT 15h, EAX=0xE820 

https://wiki.osdev.o...emory_Map_(x86)

https://wiki.osdev.o..._EAX_.3D_0xE820

from grub4dos



#41 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 06:51 PM

I think the boot process would be something like:

 

Power On:

    -> Grub4Dos

        Grub4Dos checks the variable and determines that it is false. Thus, it only shows the menu entry for Linux.

    -> Linux

        Linux verifies the filesystem, changes the variable to true, and forces a reboot.

    -> Grub4Dos

        Grub4Dos checks the variable and determines that it is true. Thus, it only shows the menu entry for Windows.

        On selecting Windows, Grub4Dos changes the variable back to false.

 

I have a few questions:

Would this be easier on Grub2? I'm not sure how editing specific bytes using memory addresses works. 

If our verification stamp checks whitespace, would this method still work? Wonko mentioned a bunch of specific unused sectors which may be true but could render the stamp invalid nonetheless. 

Why specifically the memory address 0x01BC? Would any byte within the range 0x01F0 - 0x01FD work?

 

Good idea to use only Grub4dos in your booting scheme.

 

I think Grub4dos is a lot easier and don't know if the same can be done with Grub2.

At offset 0x01BC we have two unused bytes just between the Disk Signature and the Partition Table.

The range 0x01F0 - 0x01FD is part of the partition table and will be used when making 4th primary partition entry and is also used in case of partnew ....

I expect no problem with the verification stamp, but of course that needs to be tested.



#42 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2020 - 06:53 PM

I think the boot process would be something like:

 

Power On:

    -> Grub4Dos

        Grub4Dos checks the variable and determines that it is false. Thus, it only shows the menu entry for Linux.

    -> Linux

        Linux verifies the filesystem, changes the variable to true, and forces a reboot.

    -> Grub4Dos

        Grub4Dos checks the variable and determines that it is true. Thus, it only shows the menu entry for Windows.

        On selecting Windows, Grub4Dos changes the variable back to false.

 

I thought that Your first boot had to be GRUB2.

 

You only need that GRUB2 is able to read the flag, while you can use grub4dos to write it.

 

 

 

I have a few questions:

Would this be easier on Grub2? I'm not sure how editing specific bytes using memory addresses works. 

If our verification stamp checks whitespace, would this method still work? Wonko mentioned a bunch of specific unused sectors which may be true but could render the stamp invalid nonetheless. 

Why specifically the memory address 0x01BC? Would any byte within the range 0x01F0 - 0x01FD work?

1) the means/tools are not important, most that can be done in grub4dos can be done in GRUB2 and viceversa.

2) that is up to your EXACT verification method, I don't think that is feasible (it will take a few hours) to verify the whole disk.

3) It is NOT a "memory address" it is the offset in the MBR (first absolute sector on disk or LBA0).

0x1F0-0x1FF (again MBR offset) are partially the 4th partiton entry an the two "Magic Bytes" 55AA, you cannot use that space "at random".

BUT, instead of the "flag" byte, you could change the partition ID of the NTFS volume you have Windows 10 on from 0x07 to (0x17 (hidden NTFS) or possibly even 0x27).

 

:duff:

Wonko



#43 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 07:28 PM

 

BUT, instead of the "flag" byte, you could change the partition ID of the NTFS volume you have Windows 10 on from 0x07 to (0x17 (hidden NTFS) or possibly even 0x27).

 

 

Good idea  :)

The method can be used as well to modify in the MBR at offset 0x1C2 the partition type byte of the first partition , your Windows partition.



#44 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 29 June 2020 - 07:34 PM

I thought that Your first boot had to be GRUB2.
 
You only need that GRUB2 is able to read the flag, while you can use grub4dos to write it.

 
I apologize if I insinuated that at any point but no, it is not a requirement to use Grub2.
 

1) the means/tools are not important, most that can be done in grub4dos can be done in GRUB2 and viceversa.
2) that is up to your EXACT verification method, I don't think that is feasible (it will take a few hours) to verify the whole disk.
3) It is NOT a "memory address" it is the offset in the MBR (first absolute sector on disk or LBA0).
0x1F0-0x1FF (again MBR offset) are partially the 4th partiton entry an the two "Magic Bytes" 55AA, you cannot use that space "at random".
BUT, instead of the "flag" byte, you could change the partition ID of the NTFS volume you have Windows 10 on from 0x07 to (0x17 (hidden NTFS) or possibly even 0x27).
 
:duff:
Wonko


I don't understand enough of the difference between it not being a "memory address" and it actually being "the offset in the MBR", but I will take your word for it.
Am I able to view and modify either or both of the partition ID flags or the custom mbr_flag from within my Linux kernel?

 

Using these specific bytes as our variable seems like a very workable solution.



#45 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 07:51 PM

 
I apologize if I insinuated that at any point but no, it is not a requirement to use Grub2.
 


I don't understand enough of the difference between it not being a "memory address" and it actually being "the offset in the MBR", but I will take your word for it.
Am I able to view and modify either or both of the partition ID flags or the custom mbr_flag from within my Linux kernel?

 

Using these specific bytes as our variable seems like a very workable solution.

 

It is good first in Windows to study the MBR of your Disk by using TinyHexer

 

I don't know what tool to use in Linux to modify MBR bytes but anyway you can use kexec to arrive at Grub4dos which you know can do it.



#46 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 29 June 2020 - 07:58 PM

I will study my MBR using TinyHexer; am I correct in thinking the boot process will look something like:

 

Power On:
    -> Grub4Dos: var == false, Linux entry.

    -> Linux: verify integrity, kexec Grub4Dos

    -> Grub4Dos: var = true, reboot.

    -> Grub4Dos: var == true, Windows entry.

    -> Windows: var = false, boot.


Edited by DapperDeer, 29 June 2020 - 07:58 PM.


#47 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 08:08 PM

I will study my MBR using TinyHexer; am I correct in thinking the boot process will look something like:

 

Power On:
    -> Grub4Dos: var == false, Linux entry.

    -> Linux: verify integrity, kexec Grub4Dos

    -> Grub4Dos: var = true, reboot.

    -> Grub4Dos: var == true, Windows entry.

    -> Windows: var = false, boot.

 

Yes but last two steps are

> Grub4dos if var==true then set var==false and Windows boot

 

Just do the experiments and you know if it works according to your idea.



#48 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 08:24 PM

The method can be used as well to modify in the MBR at offset 0x1C2 the partition type byte of the first partition , your Windows partition.

 

I think it is not good to change the Windows partition type to false since you want to boot with Windows

It is better to just use only the mbr_flag switching from true into false and then boot with Windows



#49 DapperDeer

DapperDeer

    Newbie

  • Members
  • 28 posts
  •  
    United States

Posted 29 June 2020 - 08:42 PM

We can use grub4dos to write at offset 0x1BC just one byte being 1 or 0 for true and false respectively
The effect is illustrated with

write --offset=0x1BC --bytes=1 (hd0)+1 1
cat --hex --skip=0x1B8 --length=8 (hd0)+1
write --offset=0x1BC --bytes=1 (hd0)+1 0
cat --hex --skip=0x1B8 --length=8 (hd0)+1

For Grub4Dos, I think I'll have a few menu files:

menu.lst:

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

linux.lst:

default 0
timeout 5

title Linux
	root (hd0,3)
	kernel /boot/bzImage 
	initrd /boot/initramfs.img

Linux's Init Script:

...
output = subprocess.run([kexec_cmd, "-ly", "--real-mode", chain_exe, "--config-file=/boot/grub/set_true.lst"])
...

set_true.lst:

default 0
timeout 5

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write True - Boot (hd0,0)/bootmgr
	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%
	write --offset=0x1BC --bytes=1 (hd0)+1 1
	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
	reboot

windows.lst:

default 0
timeout 5

iftitle [if exist (hd0,0)/bootmgr] Boot Win10 - MBR Write False - Boot (hd0,0)/bootmgr
	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%
	write --offset=0x1BC --bytes=1 (hd0)+1 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
	chainloader /bootmgr

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


#50 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 29 June 2020 - 08:53 PM

Something like that but:

 

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

 

menu.lst is not ok yet .... 






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users