38 replies to this topic

[Wonko the Sane]

It remains "queer".

 

the "find --set-root ntldr" is wrong, misses the initial slash on the path/filenamem, should be "find --set-root /ntldr" , the error 15 is "normal".

 

the rootnoverify (hd0) .....................Error: No such command: rootnotfy is also normal the commans is "rootnoverify", you typed rootnotfy.instead

 

The strange is that once you get:

Will boot ntldr from drive=0x80, partition=0x0 (hiden sectors=0x800)

when typing "boot" it should just boot, the feedback message from grubdos is saying that the file was found, loaded and has the right parameters (first disk, first partition).

 

Wonko

[ispy]

Hi W nko,

 

I have been back into the menu and updated results:

Option 1 - the previous error code 15 code - File not found, has now changed from find--set-root/ntldr to "Error: No such command: find--set-root/ntldr" (did this operation twice checked typo's same result - is there a space between the "/" possibly at the end of root. I will try this again & get back to you.

 

Edit getting back to you tried space @ end of root then forward slash tried it with no spaces between root & ntldr and tried space after forward slash all were same result option 1 stalled with same error message error no such command.

 

In respect of third option 

My mistake typed in rootnoverify (hd0) - no text displayed (Double checked typo's)

Chainloader +1 - again no text displayed

boot - Was returned to boot menu of XPPro & Q4OS

 

So I can report option(s) 3 & 4  now work 1 & 2 remain broken at time of writing this feedback

 

Best Regards,

 

David 

[Wonko the Sane]

Oh, my....

 

find[SPACE]--set-root[SPACE]/ntldr

 

as in:

command[SPACE]options[SPACE]parameter

 

Wonko

[ispy]

Hi W nko,

 

Okay options 1 & 2 are now working albeit some returned text resulted see below:

 

E.g.

Option 1

find --set-root /ntldr ....................returned value - (hd0,0)

Chainloader /ntldr   ....................returned - Will boot NTLDR bla bla... as per previous messages etc

boot                        ....................After pressing enter key returns to XP Q4OS menu

 

Not sure if this is normal but Hey Ho as they say

 

Option 2.

root (hd0,0)            ....................returned Filesystem type is ntfs, partition type 0x07

chainloader /ntldr   ....................returned Will boot NTLDR from drive=0x80, partition bla bla etc

boot                       .................... After pressing Enter then takes you to the menu.

 

So 1,2,3 & 4 now work with different statements being returned so what does this all mean & what significance does it have. Hope you find this info helps in some way. I will now reconnect the Q4OS drive to put things back to normal if thats okay?

 

I am writing a batch file (untested as yet) with an installer & uninstaller menu to auto load and undo the boot loader for those who wish to try this out & will write a small complimentary readme .rtf file for those who may want to undertake this operation.

 

Tell me would this work if say you had XP on a single drive then formed a second partition, formatted to Ext4 file system & booted both OS's off a single Hdd say three partitions one for XP one for Q4OS & one for Linux swap? or is grldr specific to the setup I have used? Big drives today could easily accomodate this kind of dual boot scenario really.

 

It's just my preference to use two separate drives so if one goes down the other with minimal work can continue. Incidently my Q4OS drive was sourced from a redundant SKY box I had so I salvaged the drive & used it, Yes yes I know I'm a cheap-skate  

 

Best Regards,

 

David 

[Wonko the Sane]

I was only trying to show you the possibilities.

 

Say that - for whatever reason - your second drive has a "blocking" issue, as an example the /boot/grub/i386-pc/core.img file has been deleted or renamed accidentally.

 

To the grub4dos embedded menu.lst this would have the same effect as your current test (the file is not found, so the entry for Q4OS won't work, the "fallback +1" provision will try booting the "next" entry which is "commandline" and thus allow you to issue commands).

 

Once in command line you have at your fingertips a number of commands, I showed you the ones you can use to get back to the NTLDR/BOOT.INI choices, but if you learn some grub4dos command line usage you could use the command line to troubleshoot the issue, check for the existence of files, attempt using the direct booting method, etc.  

 

 

 

 

Tell me would this work if say you had XP on a single drive then formed a second partition, formatted to Ext4 file system & booted both OS's off a single Hdd say three partitions one for XP one for Q4OS & one for Linux swap? or is grldr specific to the setup I have used? Big drives today could easily accomodate this kind of dual boot scenario really.

 

It's just my preference to use two separate drives so if one goes down the other with minimal work can continue. Incidently my Q4OS drive was sourced from a redundant SKY box I had so I salvaged the drive & used it, Yes yes I know I'm a cheap-skate  

Let's see together what the current "Q4OS entry does:

 

title find Switch to GRUB2 core.img To Boot Centaurus Q4OS <- (this is just the title, for your use it could also be "Mickey Mouse" since you cannot really-really read or select it it with timeout 1)
fallback +1 <- (this simply tells grub4dos in case of failute booting this entry to go to next one)
find --set-root --ignore-floppies --ignore-cd /boot/grub/i386-pc/core.img <- (this tells it to look in any disk drive/volume, excluding floppies and CD/DVD's, for the file "/boot/grub/i386-pc/core.img" and, once (if) it is found, establish root to that drive volume, for partitioned hard disks, the search order is (hd0,0), (hd0,1), ... (hd0,n) when n is the last volume on that disk it shifts to next disk (hd1,0), (hd1,1) ... (hd1, n) and so on. The net effect is that IF you have a "/boot/grub/i386-pc/core.img" in a volume of first disk it will never reach second disk, if you prefer, the entry works for you only because you happen to have NOT a "/boot/grub/i386-pc/core.img" on any volume on first disk)
kernel /boot/grub/i386-pc/core.img <- (the "/boot/grub/i386-pc/core.img" here is shorthand for the more proper "()/boot/grub/i386-pc/core.img" where () means "current root", i.e. what was previously established by the previous "find --set-root" command, the kernel command just says "load this (Linux) kernel")

boot<- (no, i am not completely crazy, at the end of a menu.lst entry - end that is marked by "next "title" line or by EOF - there is an implied "boot" command that simply (hopefully) boots whatever it was set/loaded previously)

 

So, suddenly , see the italics part above, it starts making a lot more sense to use not a "generic" file such as "/boot/grub/i386-pc/core.img" as "tag file" but rather use a more specific file or - even better - a volume UUID to make sure that the "right" volume is set as root.

 

As a side note Wonko - being notoriously cheap, actually most probably cheaper - totally approves of the re-use of disks gutted from redundant Sky boxes.

 

Wonko

[ispy]

Hi W nko,

 

So this whole exercise was show me howto get to the main menu of XP & Q4OS if things get stuffed up from the commandline grub4Dos. So that is ringing alarm bells with me in that, the assumption in my mind/or implied is things can easily get stuffed up & the commandline is going to be needed probably/in-frequently, is that a fair assumption, are we talking relative instability here?

 

So speculating would it be prudent to have a third option in the XP, Q4OS boot menu, a menu item that would take you to the commandline that could be precompiled with those 4 commandline option(s) in a sub-menu, they being inbuilt but alas that would require re-editing the grldr integral menu with Hex Editor thingy again. Or possibly easier solution, If that was not possible could grub4dos commandline be invoked from a batch file from XP working backwards in a sense therefore from the ntldr OOp's sorry boot.ini menu or Am I just vaping wishful smoke here??

 

I have to concede I virtually know zilch about linux systems as I think I have removed the doubt re my ignorance in the previous postings I have made. Q4OS was chosen as it seems pretty close to XP when skinned, dilusional I know & probably this kind of thinking will be repulsive to the linux community I will just keep my head below the parapit to avoid getting it shot off  . Life afterall is about bullet dodging to a large degree

 

Is there perhaps a backup strategy I could use to safeguard the XP Q4OS boot options that could be easily invoked to re-establish dual boot when this forthcoming stuff-up is likely to occur like backing up certain files, time to take a chill pill me thinks,  I know I will take the blue one or was it the red one  >  ?

 

20Mins after taking the medication - Normal service will resume, So the Mbr on the XP remains untouched is that correct & is the MBR on the Q4OS drive Mbr? is that looking for the grub2 or core.img file to load Q4OS? I suppose one answer raises countless further questions which maybe frowned on by rebootpro in the context of this posting, I will get back to my batch installer uninstaller & Readme file. It has certainly been an education Wonko I will need to do alot more reading on this subject especially if one wants to be become conversant with Linux.

 

Appreciated & with grateful thanks,

 

David the 

 

 

   

[Wonko the Sane]

Well, as a matter of fact:

1) the MBR of first disk is untouched

2) the MBR of second disk is untouched (and yes, it invokes the GRUB2)

3) the PBR of first volume on first disk (the XP install) is untouched

 

So the system "as is" is EXACTLY as foolproof as it was before.

 

Things that may go wrong (though they normally will NOT) :

1) the MBR code of first disk is corrupted -> you can change the disk order and boot to the second disk/Q4OS

2) the PBR code of first volume on first disk is corrupted  -> you can change the disk order and boot to the second disk/Q4OS

3) the MBR code of second disk is corrupted -> you won't notice since you are not using it
4) the NTLDR code is corrupted or the file is missing -> you can change the disk order and boot to the second disk/Q4OS

5) the grldr code is corrupted or the file is missing -> you can still boiot to XP or change the disk order and boot to the second disk/Q4OS

6) the menu.lst is corrupted or the file is missing -> no prob we have removed this (theorical and very minor)  point of failure

7) the core.img is missing or corrupted or you put another "/boot/grub/i386-pc/core.img" on first disk  -> you can still boot to XP (but not to Q4OS)

8) the grub.cfg is missing or corrupted ->  you can still boot to XP (but not to Q4OS, in this case you will enter GRUB2 "rescue mode", i.e. GRUB2 command line)

 

So, items #3 and #6 are not an issue.

Items #1, #2 and 4 are EXACTLY the same as before.

Item #5 is a new possible point of failure (but the consequence will be only partial)

Item #7 and #8 can be further mitigated by having a provision to:

1) identify more exactly the Q4OS volume via UUID

2) by-pass core.img and grub.cfg by having a provision to boot the Q4OS kernel and initrd directly from grub4dos

 

What is missing, in a catastrophic scenario that WON'T likely happen, is a way to mitigate #1 and #2 consisting in adding to the GRUB2 grub.cfg an entry capable of booting grub4dos, so that you can change disk order and still get to the NTLDR (and consequently) XP.

 

Since you will need to operate on the "Linux" side, you can safely ignore this, until you will get more familiar with the Linux and GRUB2.

 

Essentially - however - it revolves around adding where core.img is a copy of grub.exe (and optionally a menu.lst) and add an entry for it in grub.cfg.

Since the good Linux guys decided (stupidly) that it is not a good idea to configure the configuration file   you won't edit grub.cfg but rather (I believe) /etc/grub.d/40_custom and "update" GRUB2.

 

Now that you have learned the "hard way", you can get BOOTICE that includes an editor that allows to modify the embedded menu.lst in grub4dos:

http://reboot.pro/to...-bootice-v1332/

 

Wonko

 

.

 

[ispy]

Hi W  nko,

 

Many thanks for the clarification in respect of the mbrs  of both drives I can now enter that statement into the readme file that I'm about to write. It seems my concern about stability issues are minimal in respect of booting both OS's.

 

In respect of this statement:

 

Now that you have learned the "hard way", you can get BOOTICE that includes an editor that allows to modify the embedded menu.lst in grub4dos:

 

 

I'm all for easier, Easier infers the path of least resistance, painless time saving etc etc

 

I have downloaded Vers 1332 even though there is a later version but seems to hint "bugs". so with this gadget we can add the commandline option along with other options possibly, can it do sub menus or call sub routine files to say call those previous 4 options that you specified kinda auto-like?

 

Edit : Seems it is not as stable as I first thought when I reconnect the Q4OS drive back it has lost the XP Q4OS menu (that is both drives are connected) AFAIK I have not changed anything will investigate further?

 

The other percularity is that I am finding that there is a problem when rebooting Q4OS it stalls frequently when closing down I wind up at a black screen with only a moveable mouse cursar & just hangs there maybe need to look at Q4OS website to see if others experiencing this.

 

Phew I have managed to get the XPPro Q4OS menu screen back by going into legacy bios setup as the removal of the drive & subsequent re-connection somehow scrambled the boot order of the drives in the bios. I don't how this has happened as the settings should not get altered in the bios but somehow it has.

 

& so to the next revelation?

 

Best Regards,

 

David 

[Wonko the Sane]

Naah, it is just a tool (that besides many other useful capabilities) is comprising an editor that can modify the built in grub4dos menu.

 

The grub4dos menu is "monolithic", no actual submenues possible BUT this can be worked around by two other features.

#1 the possibility of loading other .lst files (to all effects they can be made to look and work as sub-menues) look for the command "configfile":and for "submenu" in the ( good ol') grub4dos officially unofficial guide:

https://web.archive....os/Grub4dos.htm

https://web.archive....rub4dos_htm.zip

 

 

#2 the possibility to run grub4dos batch files (that BTW have a syntax very, very similar to DOS/NT batch)

 

And of course I am lying there is a third one. let's say a mix of the two above (but very few or no kids want to play with these), shameless plug, but you can even load a dos, exit it and continue booting, COSMIAS approach:

#3 http://reboot.pro/to...-to-g4d-images/

 

To give you an idea of the possibilities of the grubdos batch language, try "my" (other shameless plug) mbrview.g4b, in the updated version by nando4 :

http://reboot.pro/to...l-for-grub4dos/

 

Wonko

[ispy]

Hi W nko,

 

Sorry for not getting back sooner been trying to find out why Q4OS is not shutting down & rebooting cleanly not really any the wiser but will keep looking. I will need to read up in respect of of the tutorials & sub-menu's to provide the commandline option as a third option for the menu. Quicky question Will the Bootice editor make the changes perminent or is it just read-only in respect of the integral grldr menu?

 

As to the last two paragraphs how do these work I'm not sure I've got a handle on the orthodox methods of grub4Dos let alone advanced varients to achieve a sub-menu system.

 

Post #33 gave me fright when we had only in the previous post been dicussing possible stuff ups low & behold my fear became alive but found out it wasn't anything to do with grub4dos but my sqwirly legacy boot settings.

 

Just a further "?" what are your views & experience in respect of this https://www.supergru...b2-disk-stable/

 

Anyways thanks for links,

 

Best Regards,

 

David 

[Wonko the Sane]

Still confused by the intricacies of the English language?

An editor edits, a viewer views.

You used a hex editor (not an hex viewer) previously to edit the menu, the BOOTICE editor is an easier to use tool to do the same.

 

The supergrub2 disk? it is an exceptionally good tool to have in case of emergency, if you run a Linux system (and even if you don't).

As a matter of fact it uses a very well configured set of menus and submenus, something that could get you inspired when/if you will want to complicate your current setup.

 

There is also the good ol* supergrub disk, that being based on good ol' grub has a menu system that is largely compatible with grub4dos:

https://www.supergru...uper-grub-disk/

the Author - for whatever (wrong BTW) reasons - is flattened on the good Linux guys' attitude about original grub (it is ooooold, it is is outdated, you shouldn't use it, GRUB2 is so much better, etc., etc. ) i.e. in "denial" mode about it, but it contains a number of good things, I was going to suggest you to check it as "lesson #2" on submenus.

It is "legacy", but legacy does not mean what they think it does, JFYI:

https://jdebp.eu/FGA...pejorative.html

 

 

Getting it nowadays has been (intentionally but senselessly ) made difficult, anyway you can find a copy here:

http://mirror74.boot...uper_Grub_Disk/

 

Wonko

[ispy]

Hi W nko,

 

Still confused by the intricacies of the English language? 

An editor edits, a viewer views. 

You used a hex editor (not an hex viewer) previously to edit the menu, the BOOTICE editor is an easier to use tool to do the same.

 

 

Yep & its the only language I can speak badly apart from inversely Bad Language which incidently I am capable of ranting fluently in   much to the dismay of the other half  . 

I have downloaded the Grub4dos disk from the link you have provided, always gud to have these tewls & yes the menus will be useful.

 

So if I wanted to add a third menu item say commandline for Grub4dos for Q4OS presumeably you would need a title entry first & know the correct syntax to boot straight to the commandline & presumeably back to the menu once the task was ended? will this mean we can use the grldr or will a menu.lst file need to be setup afterall?

 

Oh by the way I will need to Pmessage you shortly as something will shortly be coming up that i will need to advise you of

 

Best Regards,

 

David 

[Wonko the Sane]

Well, you already have a command line entry AND you can always drop to command line when a menu is displayed by pressing "c" (and by pressing ESC you get back to the menu).

 

First two lines of your embedded menu:

 

default 0 <- this means that if no action from the user, the selected menu entry will be the first one
timeout 1 <- this means "do boot the selected menu entry" after 1 second passed (hint: change this value to 5 or 10 for experimenting)

 

Wonko

[ispy]

Hi W  nko,

 

Just a quick note to say I have sent you a Pmessage. Will get back to you shortly

 

Best Regards,

 

David