Goofy, Grumpy GRUBs

[l_l_r]

Hi:

Old GRUB

The following two entries are from "A grub menu booting 100+ systems of DOS Windows, Linux, BSD and Solaris" (http"//justlinux.com/forum/showtread.php?t=143973).

title DOS 7.10 @ hdc1
hide (hd0,0)
unhide (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
root (hd1,0)
makeactive
chainloader +1

title Win98 @ hdc2
hide (hd0,0)
hide (hd1,0)
unhide (hd1,1)
root (hd1,1)
makeactive
map (hd1) (hd0)
map (hd0) (hd1)
chainloader +1

Without too much thinking, I created a DOS entry analog to DOS 7.10 above as follows:

title NWDOS (DR-DOS) 7
unhide (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
root (hd1,0)
makeactive
chainloader +1

The result: disaster--Win XP on (hd0,0) was wiped out!

Well, I really could not find any information whether was it possible to install a classic MS-DOS, PC-DOS, or DR-DOS system on a modern PC with large SATA hard drives. I just tried it. But, even if the answer was no, it most likely was not the reason for the disaster. The likely suspicion falls on the grub entry. I did not find critical to hide the Win XP directory, (hd0,0), since DOS could not recognize an NTFS. Actually, after the manipulation, the DOS directory should have appeared to be (hd0,0). (DOS always looks for the first visible directory on the first hard drive.) But that could not, and similarly it could not be so in the DOS 7.10 entry in the quoted article.

Unless I basically misinterpret something, the basic difference between the DOS 7.10 and the Win98 entries is in the location of the root statement. In the case in the DOS 7.10 entry it is after the map statements whereas in the Win98 entry before the map statements. In both cases the original location designations are used. Unless the two map statements do something more than just swapping the appearance of the two hard drives, the DOS 7.10 entry is incorrect.

But, what really does a map statement is also questionable. The swapping the values of two ordinary variables always requires a third temporary variable to store one of the values before overwriting it as it is being semantically outlined below:

x swap y; z
z <- x
x <- y
y <- z

So, how on earth can the two map statements achieve the same thing that in ordinary programming requires three assignment statements? How can one use those values in the second map statement that were overwritten just before by the first map statement?

It seems that to solve the puzzle one needs a complete definition of one single map statement first, and then just after that an explanation how the subsequent two map statements constitute a swap. All meaningful explanations, and helpful suggestions are welcome.

New GRUB

The installation of many Linux distros proceeds without asking whether a bootloader should be installed, and if so then where. Most likely one ends up with a rewritten MBR. If you got more operating systems on your system, number of errors can occur, the correction of which need various skills. In the case of the new grub, one has to deal with the holistic grub.conf file that should not be touched. But, if some of the systems are missing, only a miracle could correct the situation without touching it.

In my experience, neither the old nor the new grub can recognize a freeBSD partition. In the case of the old grub, the information is available to correct the situation. In the case of the new grub, however, I have not been able to locate the pattern for a freeBSD entry. In the old grub menu.lst the root of my freeBSD entry is (hd0,2,a). Can someone provide with the lines for the new grub entry? Thanx l_l_r.

[cybertron]

Sorry about the delay getting your post validated - posts by new users sometimes get thrown into the moderation queue and have to be approved before they'll show up. I approved both of your posts, although it looks like they're the same. If so, let me know and I can merge them or delete one if you want.

[saikee]

l_l_r,

Welcome to Justlinux!


The need to use "map", "hide" and "unhide" commands in Grub1 depends entirely how the operating systems are originally installed.

Although I have not tested everything exhausively the same facilities are available in Grub2 under different command names.

The reason for re-mapping the drives is because Dos, Win9x, BSD and Solaris systems need to be installed in primary partitions but there is a maximum of 4 in each hard disk. In my original arrangement I installed every of the above system as the first recognised primary partition of the first bootable disk (hd0). Having each one working satisfactorily I then moved the disk and added more systems to it. Say if this disk is now the 4th disk (hd3) then the two map statements with enable the two disks (hd0) and (hd3) "tempoararily" change position when Grub1 executed them at boot time.

I have not tested the sensitivity of the position of the commands but if you declare the partition you want to boot first and re-map the drives later, as I have done, you will find a much better success rate than interpreting the commands in your own way. For example the map statement only involves two disks and there is no third temporary hold storage

Grub1 will also list a partition if it exists. For those it cannot read, like a NTFS or one from BSD it simply says the filing system "unknown". This is totally alright because Grub1 in this case only boot up the boot loader inside that partition by an "indirect" technique called "chainloading".

Grub1 only need to read the filing system if you want it to boot the system directly. In such a case, say a Linux, Grub1 has to find the kernel to load it. This constitutes a "direct" booting.

Grub1 only specifies the partition number by a number. If your partition number has a third parameter denoting the BSD sub-part then this is not a standard Grub1 but one that has been "doctored" by the operating system provider. I know a reference like (hd0,2,a) is used by the Grub in Solaris system which can also be used as an ordinary Grub1. However a standard Grub1 does not accept the third parameter. Again you need to use the third parameter "only" if you boot that system directly. If you chainload its boot loader then you simply use a standard Grub1 to boot up the "doctored" Grub.

Every decent boot loader can boot up another boot loader. Therefore you can use Grub1 to boot Grub2, either Grub tio fire up a Lilo, NTLDR or Vista/Win7's bootmgr and vice versa.

I have used Grub2 sufficiently to confirm that it is just as powerful, if not more powerful, than Grub2. For example while Grub1 cannot read a NTFS partition Grub2 can and I have installed Grub2 inside a WIndows to boot everything.

I have not installed a BSD recently to confirm that it has no problem with it but I do not expect a problem. Like I said above if Grub (either Grub1 or Grub2) cannot read a partition it can load its boot sector and pass the control to the second boot loader. The command
chainloader +1asks Grub1 and Grub2 to load the specified partition at the "+1" position and that is from the second sector onward.

That has never been a need for a boot loader to read the filing system of the partition in the "indirect" booting described above.

I suppose theremust be a PC operating system that cannot be fired up by either Grub1 or Grub2. It is just that I haven't been able to find one yet.

[l_l_r]

Hi saikee:

You have just hit the nail on its head by referring to the sequence of installation of the operating systems. Had I started with the DOS installation, the mishap never could have occurred. But, I had just created the DOS partition, and left it to be populated later. So, based on the actual scenario, we faced with a postmortem analysis. As such, it does not allow any loose inferences. Accordingly, I have scrutinized the steps were taken, and exposed the questionable moves. On other issues it seems that we are not exactly on the same wavelength. While I have no conceptual problems with the individual GRUB statements, I have had questions on the role of their sequence, and perhaps the unproved statement that two maps correspond to a virtual swap without exactly knowing what a single map statement does. Please note this is a postmortem analysis, and we have to be careful and precise. ( I like to remind you that during our algebra and calculus studies we frequently had to prove quite obvious looking statements like for instance the complex zero equal to the real zero.)

In addition to the analysis, some additional information on the subject of the installability of an old DOS system on a relatively new machine would not hurt.

As far as the GRUB story concerned, the picture is messy--saying the least. The central development of the old GRUB may be abandoned, but there are various improved versions with the various distributions. So, how is possible to improve something, the coding of which is claimed to be way too messy? Maybe that claim is way too prejudiced?! And, how can the new GRUB be called by the same name as the old one if it is not backward compatible. The user accustomed using the menu.lst that should have been preserved independently of the internal structuring of the program. Even if it was really necessary to introduce a new scripting language for the interface, then that language should have defined precisely with numerous examples of transcribing the old GRUB entries using the new formalism. The proposed indirect way of interfering with the grub.cmpf file is good for one thing: to create a slew of new problems from an existing minor one. Just who is financing this project?!

I think that collecting the existing operating system entries, and being able to boot a particular system are two separate issues. In my experience Windows XP on NTFS are recognized by all Linux distros but one: MANDRIVA. On the other hand, FreeBSD is not recognized by any of them. Nonetheless, FreeDSD can be booted by the old GRUB as described in the 0.97 version of the GRUB Manual under 4.2.3, on page 13. This uses two parameter as (hd0,a), but other references use the primary partition number, too, as (hd0,2,a). What I am looking for GRUB 2- is a description corresponds paragraph 4.2.3 of the old manual. Thanx l_l_r.

[saikee]

Grub1 and Grub2 both have two parts. The first part for occupying the MBR is exactly 512 bytes large. For Grub1 the stage2 is very large at 120k bytes. The equivalent of Grub2 is core.img and it is only 24k bytes.

I don't know why the maintainers stopped Grub1 development but I can understand starting Grub2 from a clean slate is a common practice for any complex computer program.

Both Grub1 and Grub2 can be installed together inside the same distro. Grub1 has a shell but Grub2 must be used as part of the Linux kernel.

In manual booting, that is when Grub is loaded and there is no Linux around the two are very similar in manipulation. For example if there is a Dos system in 2nd partition of the 1st disk I wish to boot it will be known as (hd0,1) in Grub1 and (hd0,2) in Grub2, as Grub2 has aligned itself using the same notation as Windows calling the first partition from 1. The Dos can be booted up by Grub1 with command
root (hd0,1)
chainloader +1
bootThe syntax in Grub2 is
set root=(hd0,1)
chainloader +1
bootJudging from the above the Grub1 users have no fear to change to Grub2.

I am not entirely sure but I believe there may be changes later on to make Grub1 command syntax usable in Grub2 as I notice the subtle changes in v1.98.

Grub2 Manual is available directly from GNU/Grub but there are many nice guides currently available. The best one is from the Xubuntu Forum but Ubuntu Forum also produced one too.

I think if you try to boot systems manually with Grub you will get a better satisfaction with both Grub. Grub1's menu.lst is not executable by Grub2 and so is Grub2's grub.cfg incomprehensible by Grub1. The common denominator is you can as either Grub to display the menu.lst or grub.cfg at the screen and alter the syntax on-the-fly to boot the system up manually.

The other alternative is to tell each Grub to restore or duplicate itself inside its root partition so that every Linux can be booted indirectly using "chainloader +1".

If a user has Grub1 first and then installs Grub2 then both systems are kept but the MBR link is with the most recent Grub. The user can install the older Grub1 again to change the MBR link. Both menu.lst and grub.cfg are inside the same directory with two sets of system files.The two will not get mixed up and either one can be put into use at any time.