34 replies to this topic

[Wonko the Sane]

Type
Help map
in the grub4dos console.
It mentions flags and id type??
Could a flag of 0x80 mark it active?

The point is that there is no need to have it active if grub4dos is used to boot the dos.

 

It is possible that *something* else remains to be fixed, there was recently an issue with partition ID :

http://reboot.pro/to...protected-mode/

quick jump to the relevant posts:

http://reboot.pro/to...-mode/?p=206513

http://reboot.pro/to...-mode/?p=206546

 

Later grub4dos versions should have been patched to use "--in-situ=FLAGS_AND_ID" (but haven't had the occasion to test).

 

BTW, both Tinybit and YaYa did not provide a valid example, so how to actually use the feature is unclear (at least to me).

 

Tinybit:

 

Hey, yaya accepted the proposal of --in-situ=FLAGS_AND_ID. The original FLAGS is still in the lower byte, and the higher byte is used for partition ID.

 

Yaya (via Google Translate):

 

 

2018-03-26 (yaya)
   The function map increments the --in-situ=FLAGS_AND_ID parameter.
   The low byte is FLAGS, 0/1=3 active partition flags after clearing the partition table/empty partition table last 3 items, default 0.
   The high byte is the partition ID, specified with 0xnnnn.

 

Wonko

[Tmp2k]

So here's what I've got...
 

map --in-situ (hd0,5)+1 (hd0)
map --hook
root(hd0,0)
chainloader +1

And here's what happens...  https://photos.app.g...E56cGxXDyGv4Kw7

I'm not 100% sure, but should the parttype be 0x06?

Edited by Tmp2k, 17 August 2018 - 04:07 PM.

[steve6375]

try --in-situ=0x0680  or 0x0600 ?? unsure ??

[Wonko the Sane]

So here's what I've got...
 

map --in-situ (hd0,5)+1 (hd0)
map --hook
root(hd0,0)
chainloader +1

And here's what happens...  https://photos.app.g...E56cGxXDyGv4Kw7

I'm not 100% sure, but should the parttype be 0x06?

Exactly  (if it is MS-DOS up to 6.22).


Should be map --in-situ=0x0600 (hd0,5)+1 (hd0)

and/or, if the --in-situ parameter doesn't work, use my "workaround" batch:
http://reboot.pro/to...e-3#entry206546
that - half-@§§ed as much as you like - at least:
1) is usable
2) is tested and works


Wonko

[Tmp2k]

Cheers, I hadn't seen your previous reply when I posted but I was halfway through reading the other thread you linked. I see now, it makes sense. I'll try the flags and if not your batch file, although I'll probably have more questions about how to call a batch file in G4D but we'll cross that bridge if we come to it

[Wonko the Sane]

... although I'll probably have more questions about how to call a batch file in G4D but we'll cross that bridge if we come to it

Been there, done that

http://reboot.pro/to...-mode/?p=206550

As a side note (hopefully you won't need it this time) using grub4dos without playing with its batch language is only half (or less than half, more like one third) of the fun.


Wonko

[Tmp2k]

So in-situ=0x0600 didn't work and I can't seem to call your batch script.

I've tried saving it in the root of the 1st partition alongside menu.lst I've tried renaming it "chgpartID.g4b" and "chgpartID". I've tried calling it with /chgpartID 0x06 and /chgpartID.g4b 0x06 but whatever I do I just get Error15: File not found 

map --in-situ (hd0,5)+1 (hd0)
map --hook
/chgpartID 0x06
root(hd0,0)
chainloader +1

[Tmp2k]

I was using an old version of G4D, 0.4.2 or something I think.   I was doing some more digging and I downloaded a version of grldr from yaya's post on this URL  https://github.com/c...dos/issues/172 with the in-situ=CHS flag working.  

 

I tried this and it does seem to do the trick, however, if I try to chainload io.sys I get this message and the system hangs..

 

https://photos.app.g...KKY8cKkQN2jvza6 (BTW The drive is actually labelled "NULL")

 

If I try and chainload +1 I just get Nonsystem disk or disk error, Replace and press any key when ready.

 

More testing:  If I use the 2 methods above but point it at (hd0,4) instead of (hd0,5) chainloding io.sys still hangs, but chainloading +1 works.

 

So it seems that either if I use map --in-situ or newpart I still can't get anything other than (hd0,4) to boot.  Despite the data on (hd0,5) being a clone of that on (hd0,4)

Edited by Tmp2k, 17 August 2018 - 11:19 PM.

[Wonko the Sane]

Well, strangely enough Error 15: file not found does actually mean "file not found" .

 

In your particular case you are removing the "current root".

For the experiment, copy the chgpartID to the volume and call it with a full path, like (hd0,0)/chgpartID.g4b, or put it in a floppy image that you map before the command.

AND use command line ALWAYS when experimenting, 

 

The issue is then with too many "hidden sectors" (actually "sectors before").

The 0x3FBC43 in your screenshot means 4176963 sectors * 512 bytes = 2138605056 bytes, that is nearly 2 GB, it is entirely possible that DOS 6.22 won't boot from such a high location on disk.

 

It is always confusing (to me at least) what is the low byte and what is the high byte, maybe the idea is map --in-situ=0x0006 ?

 

Why the good programmer guys do not provide actual full, explicit examples remains a mystery to me  .

 

Wonko

 

P.S.: Just tested, the map --in-situ=0x0600 seemingly works just fine with grub4dos-0.4.6a-2018-06-12

Using 0x0600 the extended partitions remain visible, using the 0x0601 ony the remapped (hd0,0) remains visible.

[Tmp2k]

I'm wondering if it is just the amount of sectors before the partition I'm trying to boot then as using either method, the only difference is the location of the partition on the disk and the 1st logical drive works in both cases.  I just assumed DOS would boot from anywhere under the 1023cyl limit.  I'll try shrinking the partitions and seeing what happens.