65 replies to this topic

[Luca's]

so, my question seems to become: is there a way to launch from grub4dos a cmd file that tells a dos program (like ptedit) to edit the master partition table entries?
thank you!
jaclaz are you still there?

[was_jaclaz]

jaclaz are you still there?

Yes, I am, though I am starting to think that you are not (or at least that you are not following).

Re-read, slowly this post:
http://www.boot-land...?...pic=14&st=1

And in fact at that sourceforge address version 0.4.3 is shown...

can you see the bolded part?

Unless otherwise stated all comments, hints, howto etc., will always be related to the NEWISH experimental version.

I had to resort to diskpart from the recovery console, to erase all the partitions.

Yep, and you have now a different partition setting.

That was the problem we were talking about.

Let's try again. with these new settings:

partnew (hd0,0) 0x07 27342630 3984120

partnew (hd0,1) 0 0 0

partnew (hd0,2) 0 0 0

Please note that EITHER
you install to the MBR grldr.mbr AND copy grldr on EACH partition
OR
copy to EACH partition NTLDR, grldr and BOOT.INI with entry pointing to C:\grldr

BEFORE issuing the above commands .

This way we:

• overwrite first partition entry
• delete second one
• delete third one

It should work normally. (only third partition visible/booting)



Now try:

partnew (hd0,0) 0x07 6715170 20627460

It should work normally. (only second partition visible/booting)

Now try:

partnew (hd0,0) 0x07 63 6175107

It should work normally. (only first partition visible/booting)

Now try:

partnew (hd0,1) 0x17 6715170 20627460

partnew (hd0,2) 0x17 27342630 3984120

It should work normally. (only first partition visible/booting)

partnew (hd0,0) 0x07 6715170 20627460

It may work normally. (only third partition visible/booting) or it may bluescreen.

What happens?

so, my question seems to become: is there a way to launch from grub4dos a cmd file that tells a dos program (like ptedit) to edit the master partition table entries?

YES.
http://homepages.tes...no-answers.html

But the question is about the tool to make the changes, what we are still missing is WHAT changes can be made and HOW to make them without having windows bluescreen.

There are however several DOS programs able to do that, but you will need to boot to DOS (possibly in an image, since the partitions are NTFS, and then have an autoexec.bat or anyway a .bat -NOT .cmd - to execute the changes).
http://www.mdgx.com/secrets.htm#FDPT

These ones should be the "right" one, Editpart:
http://www.partition...m/utilities.htm

jaclaz

[Luca's]

can you see the bolded part?

Yep, i must say it was not so visible to the naked eye.. But anyway, SORRY.

I have done all the things you told me.
As foreseen, all the commands work but the last (it bluescreens)

Based on your suggestions, here is the code i propose to exchange the partiton table entries' order (it both makes data and setups first entry)

Partnew (hd0,3) 0x17 (hd0,0)+1

Partnew (hd0,0) 0x07 (hd0,1)+1

Partnew (hd0,1) 0x17 (hd0,3)+1

Partnew (hd0,3) 0 0 0

BTW, yes, the commands work also for primary partitions. I have tested this code and it reaches the goal (it also sets partitions active and un/hides them as desired).

It seems the next step is to make these commands be allowed to run in a menu script from grub4dos. How?

[was_jaclaz]

Let's see if I have understood the set of "proposed" commands.

Partnew (hd0,3) 0x17 (hd0,0)+1

This one copies current 1st partition to 4th entry and hides it.

Partnew (hd0,0) 0x07 (hd0,1)+1

This one copies current 2nd partition to 1st entry and unhides it.

Partnew (hd0,1) 0x17 (hd0,3)+1

This one copies current 1st partition to 2nd entry and hides it.

Partnew (hd0,3) 0 0 0

This one clears contents of 4th entry.

In other words you are using 4th entry as temporary store to exchange entries in 1st and 2nd entry for first and second partiton. :cheers:

Thus, you verified that:

• as long as there are NO "duplicate entries" in the MBR, no matter if hidden or unhidden (i.e. if there is a duplicate entry, even if hidden, it will bluescreen)
• as long as first entry in partition table is valind and unhidden, that partition is bootable (and visible WITHOUT Filter driver)

Very good.

Now we'll have to ask tinybit if he could provide a switch to allow the using of partnew from within a menu.lst.

Proposed:

partnew <part> <type> <start> <length> --nike

where --nike could stand for:
noprobs I know everything (just do it)


I'll PM tinybit to raise his attention to this, just in case he does not have a chance to see it.

Have you checked that partnew NEVER runs from menu.lst (or it does run with "hardcoded" syntax, but not with the "enhanced" one)?

Now that we have a working - though not yet actually easily implementable method - let's find how to replicate it - temporarily, waiting for tinybit's take on the matter - with grub4dos booting DOS.

Since partitions are NTFS, booting DOS from them is out of question, so an image is needed.

This image needs to be able to "see" the stick, at least as physicaldevice in order to access the MBR and change entries.

Can you try following these threads:
http://www.boot-land...?showtopic=3963
http://www.boot-land...?showtopic=4260
(possibly just a "simple" image as per first one will be enough)

Since you have devised this clever "exchange routine", editpart is not actually needed (while it may be useful if using "harcoded" partition entries).

A simpler hex editor, command line driven, would be more suitable.

To follow your original "exchange routine" a suitable app seems to me the FreeFdisk:
http://www.ibiblio.o...sk/fdisk131.zip
It's /MOVE command seems like it will do the trick.

All in all the easiest way from DOS would be to save two (or n) copies (each one properly set) of the MBR and simply overwrite "real" MBR with either of the two (or three, or n).
For this latter approach MBRWIZARD:
http://mbrwizard.com/
http://mbrwizard.com/reference.shtml
and it's /save and /restore commands seem to me a good choice.

There may be other ways, such as simply copying the n MBR's to some hidden sectors, that could possibly be "ported back" to grub4dos, but again we will need a "safety removal switch" for dd command....



jaclaz

[cdob]

Partnew (hd0,3) 0x17 (hd0,0)+1

This one copies current 1st partition to 4th entry and hides it.

Actually this dosn't copy full partition definition.
Partnew does read starting address and length from 1st partition.
A new 4th entry is created.
The main difference: CHS definition is not copied, a new CHS definition is created.
There maybe (and are at first testings) different CHS definition at 1st partition and 4th partition.
That's not a copy.
DOS and partition boot sector use CHS definition.

Can grub4dos copy whole partition entry?

There may be other ways, such as simply copying the n MBR's to some hidden sectors, that could possibly be "ported back" to grub4dos

Random ideas: given two MBR files mbr0123.08a and mbr0123.08a
Recognice the sort order 0123 and 1023: partition definition is edited already

ls (hd0,0)/mbr1023.08a && dd if=(hd0,0)/mbr1023.08a of=(hd0) count=1

ls (hd0,1)/mbr0123.08a && dd if=(hd0,1)/mbr0123.08a of=(hd0) count=1

but again we will need a "safety removal switch" for dd command

A -force would be nice

ls (hd0,0)/mbr1023.08a && dd if=(hd0,0)/mbr1023.08a of=(hd0) count=1 -force

Or copy partition entries with dd.


Another approach: use a continuous image file

title partnew (hd0,0) disk image

partnew (hd0,0) 0x00 (hd0,0)/XP_disk.img

previously partition entry (hd0,0) copied to (hd0,1) with a disk editor.
Does work in real life. Just installed XP that way.

Again the above question: how to restore (hd0,0) to previous state within menu.lst?

[was_jaclaz]

Partnew (hd0,3) 0x17 (hd0,0)+1

Actually this dosn't copy full partition definition.
Partnew does read starting address and length from 1st partition.
A new 4th entry is created.
The main difference: CHS definition is not copied, a new CHS definition is created.
There maybe (and are at first testings) different CHS definition at 1st partition and 4th partition.
That's not a copy.

Right.
It is the creation of a new entry taking the LBA data from the actual partition.

I would be curious to know what it was the CHS before and what it is after.

If the stick/device was "properly" sensed/partitioned with a geometry of nx255x63, the recreated CHS should be identical.

DOS and partition boot sector use CHS definition.

On this I have some reserves, for NTFS.

Another approach: use a continuous image file

title partnew (hd0,0) disk image

partnew (hd0,0) 0x00 (hd0,0)/XP_disk.img

previously partition entry (hd0,0) copied to (hd0,1) with a disk editor.
Does work in real life. Just installed XP that way.

Again the above question: how to restore (hd0,0) to previous state within menu.lst?

I don't understand the above.

Could you explain it giving some details?

Sometimes it is difficult to follow you, as you give as assumed or implied lots of things....

jaclaz

[Luca's]

In other words, you are using 4th entry as temporary store to exchange entries in 1st and 2nd entry for first and second partition.

Yesss that was my intention.

Let me specify one thing, though.
[Forget for the moment the fact that, with partnew, the CHS definition seems not to be copied]
An important point is that, if enhanced syntax is used, the exchange routine i proposed is portable only when you have no more than 3 primary partitions on disk (4th entry must be blank).
I preferred enhanced syntax because of what you told me:
that, except for 'Type', the partnew command would have "copied" all values from the existent entries, not only 'StartSector' and 'NumSectors'.
But what about if one needs 4 primaries? I propose to use harcoded syntax, and simply overwrite the 1st and the 2nd entries with the desired "StartSector" and "NumSectors" values.
Anyway yes, duplicate entries are not allowed by windows in the MBR (no matter if they're hidden or not); and the partnew command never works in scripts, neither with the hardcoded syntax nor the enhanced one.

Now, back to the CHS definition problem. How can i verify partnew does not copy it?
Please take a look at this screenshot (it's the situation after having made data first)

Is it here that you see the CHS definition has not been copied?
Even if actually i still don't know what concept the abbreviation CHS stands for, i further ask:
when you say

DOS and partition boot sector use CHS definition

do you mean if i don't copy it too, the windows setups on the usb stick won't work (even if setups-partition entry is ordered first in the partition table, it is active and unhidden)?

Apart from that,
this code

ls (hd0,0)/mbr1023.08a && dd if=(hd0,0)/mbr1023.08a of=(hd0) count=1

ls (hd0,1)/mbr0123.08a && dd if=(hd0,1)/mbr0123.08a of=(hd0) count=1

causes me some trouble.
What's 'Ls' for? I didn't see it in grub4dos readme. I know i could search on google, but i'm not so confident with linux bashes. I also don't understand what the first and second commands exactly perform... Need they be in a commandline, or are they paired in a script? On which partition should i place dd? And above all: why mbr1023.08a and mbr0123.08a are on two different partitions?
Anyway i wish i can avoid having configuration files on data partition [ (hd0,1) ]
I also hope - just hope - to get over the difficulties and be able to follow the partnew menu script path.

where --nike could stand for:
noprobs I know everything (just do it)

Well i already said you know one more than the devil..
Actually i cannot help appreciating the quotation from the ancient Greek. I'll pretend i didn't see the final 'Just do it', for at most i'd prefer, as a switch,
--adidas
Aha, discussing i devised a solution!
A matter of tastes...

Joking aside, i'll do really be grateful to you if you could ask tinybit to add a switch to allow partnew menu scripts. I trust in your power.
In fact, even if i have to (and want to) thank you for all the links and know-how you have provided onto the DOS way, and even if i had plunged for first into that way, i now think grub4dos is the best solution (well, yes, if the problem put forward on CHS can be overcome). Not only i think so because it would take some time to me, to learn now how to create a DOS ramdrive, but also for, got to this point, if you have, say, a menu in grub4dos to launch a DOS image, and then have to launch another script from there (i mean if you adopt an approach involving more than one step), you'd do quicker by manually exchanging the partition table entries with beeblebrox, or at most by using the grub4dos commandline.

I hope partnew scripts are not inhibited due to some security policy, or else our wait could be longer than expected: but i prefer to wait a grub4dos enhancement rather than to plunge myself into the DOS image way: i'd leave it as the last resort.
Hope it's okay for you.
Let me know.

[Luca's]

title partnew (hd0,0) disk image

partnew (hd0,0) 0x00 (hd0,0)/XP_disk.img

I don't understand the above.

i add myself to the list.

.

[was_jaclaz]

CHS and LBA are two different "conventions" about how to address a sector.

Initially, only CHS was used, and this soon led to the first hard disk barrier (528 Mb) :
http://www.pcguide.c...d/bios/size.htm
http://www.pcguide.c...izeMB504-c.html

Later a BIOS translation or ECHS scheme was used, leading to another "main" hard disk barrier (8 Gb):
http://www.pcguide.c.../sizeGB8-c.html

The usual Int13h needed to be extended:
http://www.pcguide.c...bios_Int13h.htm
http://www.pcguide.c...tensions-c.html

On a PROPERLY set partition entry, as long as the partition starts and ends within the 1024th cylinder ( 8 Gb limit) CHS and LBA should be interchangeable).

For anything above cylinder 1024 the CHS results in "a suffusion of yellow":
http://www.thateden.co.uk/dirk/

Some "formatting" utilities, including the "famous" HP USB one, may (and often does) produce an "unbalanced" partition entry.

This is WRONG.

CHS and LBA data should always be balanced, ALWAYS.

And moreover, head and sector data SHOULD be aligned to non-fractional Cylinder.

Theoretically, whenever a BIOS detects a LBA type of partition:
http://www.win.tue.n...on_types-1.html

• 0c FAT32 LBA mapped
• 0e FAT16 LBA mapped
• 07 NTFS (always LBA mapped) Or not?

the CHS part should be alltogether ignored.


LBA is geometry independent, while CHS is geometry dependent.

Various BIOS and various OS may use the CHS and LBA info differently, and moreover detected device geometry may change.

You may want to play a bit with this:
http://www.boot-land...?showtopic=2959

By re-calculating the CHS from LBA data based on the geometry seen by BIOS, as grub4dos commands do, should actually be an advantage, as long as the initial partition data is "correct", i.e. respects non-fractional Cylinder/Head.

Your (Luca's's) initial partitioning was WRONG, as one of the entries started on 1023/8/5 and ended on 1023/15/32 - this also led beeblebrox to wrongly detect a geometry of 61209x16x32 instead of the "correct" one 1950x255x63, that was later detected once properly partitioned.

I wrote my small batches exactly to prevent this possibility:
http://www.boot-land...?showtopic=5000

Standard Windows Disk Management usually behaves well.

Vista diskpart DOES NOT (unless Registry is tweaked):
http://www.911cd.net...showtopic=21186

Other utilities may or may not work properly, usually not because of the apps themselves but because of what the users tell them to do, compare with my previous statement about Acronis and and Partition Magic and with the note to the /SORT command in MBRWIZ:
http://mbrwizard.com/reference.shtml

Your post brings us back to the initial question :

What is the reason for three primaries?

Nothing prevents you from using one primary and ANY number of Logical Volumes inside Extended, which would leave or even ONLY Logical Volumes inside Extended.
This way you can have in the MBR:

• entry 0 (empty) to be filled each time with the result of the grub4dos partnew command
• entry 1 pointing to Extended Partition
• entry 2 empty
• entry 3 empty

in the EPBR:

• entry 0 actual partition
• entry 1 link to next EPBR

and so on....
http://www.goodells....boot/ptedit.htm


To sum up:

• as long as you have proper partition entries there will be NO problems, as CHS will be calculated from LBA data using correct BIOS geometry, besides, using NTFS partitions this won't be a problem. (a "bad" BIOS that needs CHS won't probably work at all with a NTFS partition and definitely not if you go beyond 1024th cylinder anyway)
• the current limitation to the use of partnew is a (VERY understandable) security feature

Nonetheless, using a pre-made partition entry is somewhat "safer", though the resulting menu.lst will be device specific.

@tinybit
A possibility for adding the run partnew from a menu.lst entry while keeping a relatively safe setup could be to allow it running ONLY in a menu.lst entry protected by hashed password.

And this brings us back to the two features we talked about:
menu.lst password protection:
read here:
http://www.boot-land...?showtopic=5862
http://www.boot-land...?...ic=2984&hl=

UUID instead of "tag" files, from README_GRUB4DOS.txt:

******************************************************************************
*** New command 'uuid' to identify partitions ***
******************************************************************************

Usage:

uuid [DEVICE] [UUID]

If DEVICE is not specified, search for filesystem with UUID in all partitions
and set the partition containing the filesystem as new root (if UUID is
specified), or just list uuid's of all filesystems on all devices (if UUID is
not specified). If DEVICE is specified, return true or false according to
whether or not the DEVICE matches the specified UUID (if UUID is specified),
or just list the uuid of DEVICE (if UUID is not specified).

Example 1:

find --set-root uuid () 7f95820f-5e33-4e6c-8f50-0760bf06d79c

which will find a partition with uuid=7f95820f-5e33-4e6c-8f50-0760bf06d79c
and set the partition as root if found.

Example 2:

uuid ()

which will print the uuid of the current root device.

jaclaz

[Luca's]

Jaclaz... I LOVE YOU...


Both for how much you know and your clarity you deserve a on behalf of everybody. it is a pleasure to speak with people like you.

Only word i must add is, if i will implement my commands in a script, i won't need neither UUID nor "tag" files. Anyway thank you, good to know how UUID works. I will then read about password protection....
As for the rest, all that is left for me to do now, is just wait for tinybit to answer my prayers..
I don't know, granted that s/he is disposed to change the grub4dos partnew routine, how much could it take to change it in order to allow only password-protected partnews: anyway i will wait for someone to give me a whistle..

[was_jaclaz]

Jaclaz... I LOVE YOU...

@Others
Unfortunately NOT translatable to English easily:

@Luca's
http://www.mymovies....attute/?id=5318

"Signore alla farmacia"



Hopefully tinybit will post something in a few days time...



jaclaz

[Luca's]

"Signore alla farmacia"

Hopefully tinybit will post something in a few days time...

let's hope. anyway, if so, might you please make me know here? thanks a lot.

see you...

[cdob]

If the stick/device was "properly" sensed/partitioned with a geometry of nx255x63, the recreated CHS should be identical.

Yes, that's true.
Previously I made some worst case tests with bad CHS examples to get results.
Sorry details are lost, did render USB stick.

New examples, partitions created with XP diskmanager[codebox]copy 0 -> 3copy 1 -> 2Type Boot BCyl BHd BSec ECyl EHd ESec SlartSector NumSectors0B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 982 254 63 - 11374020 4417875emptyemptypartnew (hd0,3) 0x00 (hd0,0)+1partnew (hd0,2) 0x00 (hd0,1)+10B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 982 254 63 - 11374020 441787507 00 0 - 708 1 1 - 982 254 63 - 11374020 44178750C 00 0 - 0 1 1 - 707 254 63 - 63 11373957partnew (hd0,2) 0 0 0partnew (hd0,3) 0 0 00B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 982 254 63 - 11374020 4417875emptyemptypartnew (hd0,2) 0x0B 63 11373957partnew (hd0,3) 0x07 11374020 44178750B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 982 254 63 - 11374020 44178750B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 981 254 63 - 11374020 4417875There are 240 Heads BIOS: Fake entry 2 added manually0B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 982 254 63 - 11374020 441787507 80 0 - 0 1 1 -1023 239 63 - 63 51196257emptypartnew (hd0,3) 0x07 (hd0,2)+10B 00 0 - 0 1 1 - 707 254 63 - 63 1137395707 00 0 - 708 1 1 - 982 254 63 - 11374020 441787507 80 0 - 0 1 1 -1023 239 63 - 63 5119625707 80 0 - 0 1 1 - 981 209 63 - 63 51196257[/codebox]@Luca'sIn general: different CHS may cause errors. That's a weak point. This may work today, but cause errors in future at different machines.Creating a new solution: find weak points. Solve the weak points. Or ignore them. But keep them in mind. If there are errors in future, remember them.As for windows installation: I don't know. This has to be tested.README_GRUB4DOS.txt[quote]Just like a whole logical partition, a contiguous partition image file canalso be used with PARTNEW: partnew (hd0,3) 0x00 (hd0,0)/my_partition.imgThe type 0x00 indicates a type-auto-detection of the image MY_PARTITION.IMG.The above command will create a new primary partition (hd0,3) with a propertype and with contents/data being exactly that of the contiguous file(hd0,0)/my_partition.img.PARTNEW will automatically correct the "hidden sectors" in the BPB and themodification will be permanent. And PARTNEW modifies the partition tablepermanently.[/quote]This gave another idea: don't use different partition at USB. Use different image files instead. E.g. add more than four images.I created a floppy like image XP_disk.img. Contents[quote]$WIN_NT$.~BT$WIN_NT$.~LSNTDETECT.COMtxtsetup.sif[/quote]partnew map this image as a partition. XP can be installed from this partition.entry 0 holds partition definition to image fileentry 1 points to whole USB drive: grldr, menu.st and image files[code]partnew &#40;hd0,0&#41; 0x00 &#40;hd0,1&#41;/XP_disk.img[/code]
As jaclaz pointed already, entry 1 can be fixed. There is no need to change this.
Change entry 0 only.
This is a more secure approach: USB drive definition is not changed.

[was_jaclaz]

So, we need tinybit to add another parameter / possibility to partnew, allowing to specify "correct" geometry on "stupid" BIOSes?

Or could this (as long as partition entries are re-calculated/reset at each boot) be considered an advantage:

By re-calculating the CHS from LBA data based on the geometry seen by BIOS, as grub4dos commands do, should actually be an advantage, as long as the initial partition data is "correct", i.e. respects non-fractional Cylinder/Head.

I.e. did the stick with the "weird" 240 cylinders work/boot on that particular PC? unsure:

I do like the idea of the XP_disk.img

I guess we can use the usual (hd1) mapping and migrate.inf at it.

So, if I get it right we could have:

• entry 1 "fixed" to the Extended Partition (pointing to EPBR of it) switching between visible/invisible
• entry 0 "variable" with partnew "switching" from XP_disk.img and actual bootsector of (one of the) Logical Volume(s) inside Extended

A non "Filter Driver featured" OS will see just entry 0 (either XP_disk.img or one Logical Volume among the one or more present in the Logical partition)
When using a "Filter Driver featured" OS, one could unhide entry 1, thus being able to acces ALL volumes inside Extended, (optionally blanking entry 0 or leaving it pointing to XP_disk.img)

VERY, VERY good!



jaclaz

[Luca's]

I don't understand.
Again, how can i verify that the CHS definition has somehow been altered?
I still also don't understand if, roughly speaking, this CHS is a trouble or not. What sort of errors may happen in the future? Data not correctly copied to disk? Usb stick burning out? I don't understand. Sorry to be so ignorant....but you jaclaz and cdob seem not to totally agree on this point.

Anyway i have some more questions:
If

we could have:
· entry 1 "fixed" to the Extended Partition (pointing to EPBR of it) switching between visible/invisible
· entry 0 "variable" with partnew "switching" from XP_disk.img and actual bootsector of (one of the) Logical Volume(s) inside Extended

then could i have also a Vista_disk.img to switch to?
Where would these images stay? On what partition?
If entry 0 is variable, so that i can switch among the images and the

actual bootsector of (one of the) Logical Volume(s) inside Extended

why, here, CHS is not a problem? It seems to me that i would have to overwrite partition table values the same, wouldn't i?

I believe that the XP_disk.img way is clever and we could eventually adopt it.
But please can we keep on testing if CHS is actually changed/copied or not? If the work is done correctly, at the moment i don't see why the 'ask tinybit for a partnew enhancement' way should be abandoned.

[tinybit]

I am sorry to have kept you waiting. No problem for writing to disk by a command in a menu. But how and in what manner we should implement it?

Jaclaz, do you mean only a password-protected entry would be allowed to have special write access to disks?

Should we allow the write without taking any protection measures?

For the time being I cannot deal with the CHS translation issue. I will think it out later.

[was_jaclaz]

@tinybit

I was thinking about a way to prevent possible malicious use of the partnew (or of the dd) command for deleting partitions or however manage the HD.

I am guessing that was the original concern of the coder that limited it's use to "direct" command line entries.

If there is a way to allow the use of such "destructive" commands also from menu.lst ONLY if the corresponding entry is protected by a password AND the password is NOT "plain text", I presume we still have a reasonable safety while allowing "advanced" tricks/tweeaks.

If someone downloads blindly a disk image containing a bootable grub4dos, in the instructions it is said to use a given password to access the menu.lst and "have a surprise", and the "someone" is gullible enough to do that before checking in any text editor the contents of menu.lst, I presume that he actually "deserves" the "surprise" .

Notheless, providing an additional explicit confirmation seems to me only too logic and inobtrusive enough for final user:

grub4dos is about to change permanently contents of MBR of (hdx,y).
Input Y (CAPITAL) to confirm, or press any other key to skip.

@Luca's
The consequence of an unbalanced CHS/LBA is debatable.
BIOS of newish machines, when a LBA mapped partition type is detected should ignore completely the CHS values.
On the other hand some older BIOS will use CHS nonetheless, at least for the initial part of booting.
Some BIOS have an actual limit to 512 (read 528) Mb in size.
Some BIOS may have an 8Gb one.
Dos 6.22 and earlier, as well as NT 3.51 and probably NT 4.00 need CHS data.

On the other hand, modern machines will normally "adopt" a nx255x63.

Both cdob's and my concerns, in these we have a similar approach, are relative to always adopting the most standard possible setup in order to prevent possible problems, though of course and expecially in these debatable issue, we may, at least temporarily, wait for the problem to actually be confirmed by "field experiments".

In other words, it is a problem, but not right now, a "vital" one.

BTW anything above the 8 Gb will result in "a suffusion of yellow" if accessed through CHS, so, and we may soon get there , it could be convenient to buy a 16 or 32 Gb stick and simply leave first 8 Gb empty!

jaclaz

[cdob]

I.e. did the stick with the "weird" 240 cylinders work/boot on that particular PC?

Sorry for the confusion. Actually I report some CHS warnings, not a detailed report.
A 240 heads hint http://www.pcguide.c...izeGB738-c.html
Real Thinkpad T60 BIOS handle internal hard drives at 240 heads, but USB drives as 255 heads drive.
Well does BIOS map CHS or USB firmware?

@Luca's
E.g. BeeblebroxNT list CHS part.
CHS is not copied. A copy may use the same CHS pattern or different one.
As for XP instllation: I still also don't understand if, roughly speaking, this CHS is a trouble or not.
Take this as a warning. Installation may work at some machines and fail at others.
Or installation may work at all machines.

At current knowledge I don't trust partnew for DOS and windows based systems.
The possible limitation is DOS or boot sector.
Linux booting dosn't use CHS.

The secure work arround:
entry 0 holds current XP installation partition definition
entry 1 points to whole USB drive

partnew changes entry 0.
entry 1 is fixed. Not to be changed by partnew.

I maybe wrong / overly precautious now, don't like to risk data.
This may change in future.

then could i have also a Vista_disk.img to switch to?
Where would these images stay? On what partition?

Shure, a Vista_disk.img is possible too.
Idea was: there is a entry 1 points to whole USB drive. That's a primary partition.
All images are at entry 1 partition.

why, here, CHS is not a problem?

The image used a nx255x63 pattern, partnew created a equal CHS copy.
Again CHS maybe importand or not.

@tinybit
Keep current precautions: Disable partnew and dd from scripts.
This are high risk commands. Disable makes sence.

But add antother option
dd --force
partnew --force
--force allows dd and partnew at scripts.

If I request --force I my destroy my data.
That's my fault then.

In addition:
A partcopy command would be nice
partcopy (hd0,0) (hd0,1)
Copy hd0,1 entry to (hd0,0)
Copy full partition entries, do not validate settings.
Again: disable from script by default. But possible at --force.

[Luca's]

Okay thanks for all the explanations...
While waiting for further developments, just two questions in the meantime:

@cdob

E.g. BeeblebroxNT list CHS part.

mmm, where? what values?

CHS is not copied

do you evict it from my last screenshot?

@jaclaz

we may, at least temporarily, wait for the problem to actually be confirmed by "field experiments"

yep, i hope so.

[was_jaclaz]

mmm, where? what values?

Time for you to read my good ol' page:
http://home.graffiti...B/USBstick.html

CHS is not copied because only LBA is used and CHS is calculated from LBA values with a given geometry.

You may also want to re-read my previous post:
http://www.boot-land...?...=7138&st=33
and particularly:

You may want to play a bit with this:
http://www.boot-land...?showtopic=2959

@cdob

The secure work arround:
entry 0 holds current XP installation partition definition
entry 1 points to whole USB drive

This may pose a problem, see the comment to the /SORT command of MBRWIZ:
http://mbrwizard.com/reference.shtml

/Sort - It isn’t uncommon for the partition entries in the MBR to be unsorted after reinstalling Windows or restoring a Ghost or Acronis disk image. This means that the partition order in the MBR won't match the order on disk. Normally this wasn’t a problem until Windows NT/2K/XP came along with its new boot loader, and the requirement that each partition entry in the boot.ini must point to the actual partition number. This option will sort the entries in the MBR to match their physical order on disk.

That's the reason why I previously theorized using:

So, if I get it right we could have:

• entry 1 "fixed" to the Extended Partition (pointing to EPBR of it) switching between visible/invisible
• entry 0 "variable" with partnew "switching" from XP_disk.img and actual bootsector of (one of the) Logical Volume(s) inside Extended

this way the Sort order should remain valid and we don't have duplicate entries (that may result in blue screen).
Of course Entry 0 could also point to the Primary or ro an image within Primary.

jaclaz

[tinybit]

According to discussion above and also with reference to discussion in the Chinese forum, I feel the disk write restrictions should rescind/cancel utterly(with absolutely no side conditions attached).

[Luca's]

ehm, i don't want to bother but...just to know...how should i proceed now?
wait for a grub4dos development or start testing cdob's way?
please tell me. thanks.

[was_jaclaz]

http://download.gna....-2009-03-03.zip

2009-03-03 fixed memory overflow issue with (rd). canceled restrictions on some disk write commands.

Time to start experimenting......

jaclaz

[Luca's]

Well, first of all thank you tinybit for enhancing grub4dos.

There are a few problems though.

I have overwritten grldr to setups partition, and modified menu.lst as follows:

color black/cyan yellow/cyan

timeout 30

default /default



title find and load NTLDR of Windows NT/2K/XP

Partnew (hd0,3) 0x17 (hd0,0)+1

Partnew (hd0,0) 0x07 (hd0,1)+1

Partnew (hd0,1) 0x17 (hd0,3)+1

Partnew (hd0,3) 0 0 0

find --set-root uuid () a7e931de-01a7-11de-abf5-005056c00008

chainloader /ntldr





title rehide setups partition

Partnew (hd0,3) 0x17 (hd0,0)+1

Partnew (hd0,0) 0x07 (hd0,1)+1

Partnew (hd0,1) 0x17 (hd0,3)+1

Partnew (hd0,3) 0 0 0

(i had found the setups partition uuid with ddlistw.cmd)

Well it behaves weirdly:
first of all it shows only the first 'title' choice (the 'Rehide setups partition' choice is not shown).
I should be right in argueing what it depends on: it only sees the 'title' entries with commands other than partnew. In fact, when i pressed 'e' to edit the first-title commands, it showed just the final part with find and chainloader. No trace of partnews.

Nonetheless, i have tried to launch the first 'title' choice. Execution of the find command results in an error: it says it cannot find file. so, wrong uuid?
Anyway i'm quite sure partnew commands are not seen, for i've also checked, within windows, if the first 'title' choice execution produced something: but no change to the partition table at all.

I don't know to what all this is due to, but certainly i have to fix it.

EDIT: as per the 'uuid'-command results, uuid of the setups partition is 9A4826F44826CEB7. i don't understand why this discrepancy, anyway, using that value, the find command works.

[Luca's]

oops.
i've realized that "lowcasing" the partnew-command writing, everything works perfectly as desired.
i didn't knew the grub4dos syntax parser is case-sensitive. anyway sorry for having been hasty.

so, next step? do i need to test the stick on legacy machines?