-
A Dos primary partition for all boot loaders?
Edited 11/5/10 - Warning ! - The proposed primary Dos primary partition here is suitable mainly for new installation. It will not suit existing single MS installation due the the rigidity of drive letter created when the MS Windows was first installed. Please see Post #2 for further explanation.
The single Dos partition is alright for new installations if one is prepared to retored Grub everytime a MS system overwriting the MBR. Also MS systems are backward compatible so install from old to new to minimise the work. For example Win2k's NTLDR cannot boot Xp so Xp must be installed after Win2k to avoid repair with the Recovery Console.
A member of Justlinux once write in his signature that "a MS Windows may die one day but not Dos". This is quite accurate as I have found out.
I have found many advantages of putting a Dos in the first partition sda1 in my boot disk. Inside it I have NTLDR, which boots only the Win2k and XP, bootmgr which boots the Vista and Win7 (but able to pass control to NTLDR too) and Grub which can boot all operating systems. Here is the content of my sda1
Code:
linux-8w65:/mnt/sdb21 # ls /mnt/sda1
1st_bcd boot BOOTSECT.BAK DRVSPACE.BIN pagefile.sys SUHDLOG.DAT
1st_bcd.LOG BOOT.--- BOOTSECT.DOS IO.SYS ProgramData SYSTEM.1ST
1st_bcd.LOG1 Boot.BAK COMMAND.COM MSDOS.--- $RECYCLE.BIN System Volume Information
1st_bcd.LOG2 boot.ini CONFIG.DOS MSDOS.SYS Recycled WINDOWS
arcldr.exe BOOTLOG.PRV CONFIG.SYS NETLOG.TXT RHDSetup.log
arcsetup.exe BOOTLOG.TXT d899a95043109a710a NTDETECT.COM service.log
AUTOEXEC.BAT bootmgr DBLSPACE.BIN ntldr SETUPLOG.TXT
I have highlighted the relevant boot loaders in different colors. As you can see they can live happily together. The Grub here is Grub1 or Legacy Grub. Grub2 is less versatile, has many restrictions, needs longer commands and is not preferred here.
Red is for Dos own boot files
Blue is for the NTLDR's essential boot loader files
Purple is the bootmgr boot loader. Its BCD data is inside the /boot dirctory.
Magenta is where Grub is housed
The /boot (showed up as \boot in Dos) directory has both the bootmgr other files as well as the grub directory which has the 3 essential Grub1 files highlighted in magenta here.
Code:
linux-8w65:/mnt/sdb21 # ls /mnt/sda1/boot/grub
bash1 menu.lst menu.lst.backup stage1 stage2
Advantages
(1) All the NT MS Windows systems can be placed in the logical partitions because they all need just their boot loaders in a primary partition marked "active" (or bootable in Linux term). In my case I have Win7 in sda6, Win2k in sda7, Vista-64 in sda8 and Xp in sda9. XP and Win2k can only be booted by NTLDR whereas Vista and Win7 are booted by bootmgr. Basically bootmgr takes over the bootsector and provide an alternative to switch to NTLDR within its booting menu. Naturally both bootmgr and NTLDR can fire up Dos in the sda1 too.
(2) Grub can be conveniently house in sda1 as it can read a Dos partition with filing system in FAT32 (Type c). It only needs two files, stage1 and stage2, inside and optionally the 3rd file menu.lst. Without the menu.lst Grub boots to a Grub prompt. Any installed system can be fired up manually in a Grub prompt so it is a pretty powerful set up.
(3) One can write a Grub boot menu before any other operating system is installed. That has to be the coolest thing to do and you know what you can generate such menu by a Bash script just like this
Code:
for ((i=1;i<=60;i++));do echo "title @ sda$i";echo "root (hd0,$(($i-1)))"; echo "chainloader +1"; echo "
";done > /mnt/sda1/boot/grub/menu.lst
In the above I mounted the sda1 partition on a mounting point /mnt/sda1. The loop shows I intend to boot 60 partitions.
I have only assembled the 4 MS system (all booted from sda1) and one Linux in sda19 and my menu.lst, after a few editings, currently stands as
Code:
title W2k/Xp, Vista/Win7 and MS Dos @ sda1
root (hd0,0)
chainloader +1
title @ sda2
root (hd0,1)
chainloader +1
title @ sda3
root (hd0,2)
chainloader +1
# sda4 is an extended partition and not bootable
# sda5 is the common swap used by all Linux
chainloader +1
title @ sda6
root (hd0,5)
chainloader +1
title @ sda7
root (hd0,6)
chainloader +1
title @ sda8
root (hd0,7)
chainloader +1
title @ sda9
root (hd0,8)
chainloader +1
title @ sda10
root (hd0,9)
chainloader +1
title @ sda11
root (hd0,10)
chainloader +1
title @ sda12
root (hd0,11)
chainloader +1
title @ sda13
root (hd0,12)
chainloader +1
title @ sda14
root (hd0,13)
chainloader +1
title @ sda15
root (hd0,14)
chainloader +1
title @ sda16
root (hd0,15)
chainloader +1
title @ sda17
root (hd0,16)
chainloader +1
title @ sda18
root (hd0,17)
chainloader +1
title OpenSuse 11.3 @ sda19
root (hd0,18)
chainloader +1
title @ sda20
root (hd0,19)
chainloader +1
title @ sda21
root (hd0,20)
chainloader +1
title @ sda22
root (hd0,21)
chainloader +1
title @ sda23
root (hd0,22)
chainloader +1
title @ sda24
root (hd0,23)
chainloader +1
title @ sda25
root (hd0,24)
chainloader +1
title @ sda26
root (hd0,25)
chainloader +1
title @ sda27
root (hd0,26)
chainloader +1
title @ sda28
root (hd0,27)
chainloader +1
title @ sda29
root (hd0,28)
chainloader +1
title @ sda30
root (hd0,29)
chainloader +1
title @ sda31
root (hd0,30)
chainloader +1
title @ sda32
root (hd0,31)
chainloader +1
title @ sda33
root (hd0,32)
chainloader +1
title @ sda34
root (hd0,33)
chainloader +1
title @ sda35
root (hd0,34)
chainloader +1
title @ sda36
root (hd0,35)
chainloader +1
title @ sda37
root (hd0,36)
chainloader +1
title @ sda38
root (hd0,37)
chainloader +1
title @ sda39
root (hd0,38)
chainloader +1
title @ sda40
root (hd0,39)
chainloader +1
title @ sda41
root (hd0,40)
chainloader +1
title @ sda42
root (hd0,41)
chainloader +1
title @ sda43
root (hd0,42)
chainloader +1
title @ sda44
root (hd0,43)
chainloader +1
title @ sda45
root (hd0,44)
chainloader +1
title @ sda46
root (hd0,45)
chainloader +1
title @ sda47
root (hd0,46)
chainloader +1
title @ sda48
root (hd0,47)
chainloader +1
title @ sda49
root (hd0,48)
chainloader +1
title @ sda50
root (hd0,49)
chainloader +1
title @ sda51
root (hd0,50)
chainloader +1
title @ sda52
root (hd0,51)
chainloader +1
title @ sda53
root (hd0,52)
chainloader +1
title @ sda54
root (hd0,53)
chainloader +1
title @ sda55
root (hd0,54)
chainloader +1
title @ sda56
root (hd0,55)
chainloader +1
title @ sda57
root (hd0,56)
chainloader +1
title @ sda58
root (hd0,57)
chainloader +1
title @ sda59
root (hd0,58)
chainloader +1
title @ sda60
root (hd0,59)
chainloader +1
You will find I have arranged every partition to be chainloaded. Grub can chainload any operating system as long as there is a boot loader residing in the boot sector.
Every MS system, from Dos to Win7, ever invented by M$ always has a boot loader inside its boot sector. Therefore they are always chainloadable. This is true for all BSD and Solaris systems that have to be installed in a primary partition.
For Linux the system will be chainloadable if the boot loader, be it a Grub1, Grub2 or Lilo, is placed in the root partition where the Linux is installed.
Therefore whenever I install a Linux all I need to do is to tell its installer that I want my boot loader to be inside the Linux partition and it will be fired up by my pre-fixed menu.lst like a clockwork.
(3) The MS boot loaders NTLDR and bootmgr can be nuked and rebuilt without affecting their masters (Dos, Win2k, Xp, Vista and Win7). I have rebuilt these boot loaders manually just to ensure we can do it.
(4) Dos partitions in Fat32 can be accessed by most of the operating systems invented for PC.
(5) There is no better way to learn the MS boot loaders than starting with Dos which every MS Windows must support.
(6) The Dos operating system can actually be omitted in the Dos partition if needed. This is to say the partition sda1 can be data only and has no operating system inside!
(7) Grub does not need to occupy the boot sector of sda1, leaving the bootmgr fully functional to proceed to booting all MS systems.
How to set it up?
(1) Just make a partition sda1 of your chosen size and specify it to have Type "C". This can be done by either command
or
make sure to mark it "bootable".
(2) Format it by command
Code:
mkfs.msdos -F32 /dev/sda1
This partition is ready for use but cannot boot itself. To make it bootable you need to run a Dos system, either from a CD or a floppy. The command to transfer a MS Dos across is just
This should transfer a booting code into the boot sector of sda1 and deposit three files "Command.com", "io.sys" and "MSDOS.sys"
(3) Place Grub inside
To do this you need to boot up a Linux Live CD. Find out where the two essential files "stage1" and "stage2" by asking the kernel with the command
Code:
find / -name stage1
Once locate the directory containing stage1 (stage2 will be in the same location) change directory to it, make a mounting point for sda1, mount the sda1 partition, make the /boot /grub dircetory and copy the two files across
Code:
mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1
mkdir /mnt/sda1/boot
mkdir /mnt/sda1/boot/grub
cp stage* /mnt/sda1/boot/grub
To setup Grub in the MBR is to invoke a Grub shell in a Linux root terminal with commands
Code:
grub
root (hd0,0)
setup (hd0)
quit
The above Dos partition in fact has lots of booting technology inside. Apart from able to boot any MS and Linux system it can used to demonstrate the difference of (hd0) and (hd0,0) which many users may not even know the difference. The (hd0) is the MBR and the (hd0,0) is the first partition of the first disk. Since my sda1 contains the MS boot loader bootmgr these command in a Grub prompt (obtainable by pressing the "c" key at a text Grub screen) will fire up the bootmgr residing in the boot sector of sda1
Code:
root (hd0,0)
chainloader +1
boot
whereas
Code:
root (hd0)
chainloader +1
boot
fires up the the menu.lst in the /boot/grub directory of sda1.
The above information tells me that the MBR is occupied by the file "stage1". The command "setup (hd0,0)" I issued earlier modifies stage1 and hard-coded the hard disk address of "stage2". When the Bios reads the MBR it loads stage1 into memory. Grub is then able to load its stage2 which is its brain. With stage2 available Grub can check if a menu.lst is available and load it if there is one. When nothing is found Grub defaults to a Grub prompt and the user still has its full functionality.
Last edited by saikee; 06-06-2010 at 07:01 AM.
-
This post has been reserved for addendum to Post #1.
Rigidity of MS Windows drive letter
When a MS Windows, from Win2k to Win7, is installed the drive letter is embedded into the system. This makes it hard to move the operating system to another partition. There are ways of working round it but the effort is not worthwhile. Thus it is advisable to adhere to the original drive letter.
As an example if a Vista has been installed in a "C" drive no new partition of the type recognised by it, (in Fat16, Fat32 or ntfs types) can be installed in front of the Vista partition in the hard disk. If one is added then the boot loader has no choice but to assign the new partition as the new "C" drive and the Vista is relegated to a "D" drive, thereby upsetting the drive letter originally embedded inside. The resulting Vista will not boot up.
If however the same Vista is installed in a "D" drive with another MS partition in front. Then it is MS practice to install Vista boot loader in the "C" drive. The Vista partition in this case can be moved around as long as there is no another MS partition in between it and the bootable "C" drive.
I have tested Vista, Win7 and Xp in various way and can confirm that these MS systems can be freely moved around with partitions as long as the drive letter embedded in the original installation is respected.
In relation to the Post #1 my recommendation is to have a "C" drive as a Dos primary partition. This will automatically make every MS Windows to install its boot loader there. In my case I have Vista orginally in a "C" and Win7 in a "D" drive. On migration I could copy the Win7 across and rebuilt its boot loader manually as it is still in a "D" drive. For the Vista I needed to do a new re-install.
When I have a bit more time I shall do a thread describing to how rebuild the boot loaders for Dos, Win2k/Xp and Vista/Win7 as they are quite easy to do.
Last edited by saikee; 05-11-2010 at 09:18 AM.
-
Firstly, thanks for yet another valuable guide. You might just be the next Boot King
I have a few questions, primarily for clarification purposes.
1. bootmgr installs on the bootsector of sda1 ?
2. The excerpt
Code:
title W2k/Xp, Vista/Win7 and MS Dos @ sda1
root (hd0,0)
chainloader +1
brings up the bootmgr, which is installed on the bootsector of sda1 ?
3. How is this bootmgr installed to the bootsector of sda1? Is it while installing say Win 7, we choose sda1 as the location where the bootmgr should install?
If bootmgr is installed to the bootsector of sda1, then that means that other bootmanager, such as ntldr is not sitting at the bootsector of sda1, but just as a file on the fat32 filesystem?
4. Since MS OS's wanna be "C" when they startup, and according to your previous guide(s), shouldn't hiding (using grub's hide parameter in menu.lst) all partitions which have MS recognizable filesystems (FAT, NTFS) before the MS partition we want to boot from come in handy? I noticed you used no such thing in your menu.lst here.
5. Function of "chainloader +1". The following excerpt...
Code:
title @ sda7
root (hd0,6)
chainloader +1
...it chainloads whatever boot loader is installed at the boot sector of 7th partition of sda. Right?
Thanks for your insights
Last edited by crazy4nix; 06-06-2010 at 03:20 PM.
-
Answers
(1) Yes.
(2) Yes.
(3) Actually when you install Win7 the partition sda1, for being a Dos partition, is the "C"drive that bootmgr sees first. The "C" drive is always the location it places its bootmgr.
You install Win2k/Xp first so that the sda1 boot sector is occupied by NTLDR. When Win7 is installed later it replaces it with bootmgr's own version.
bootmgr can load NTLDR directly so no need for NTLDR using the boot sector of sda1. That is how M$ solved its booting mess. We might as well make use of it.
Bootmgr actually cannot boot up a NT version of Windows directly. It simply fires up NTLDR. IT is NTLDR that boot whatever systems contained in boot.ini.
4. If you boot each MS system individually then you need to hide the other MS systems. The Dos partition here is to install Dos, Win2k, Xp, Vista and Win7 all collectively so that every one can see each other (except Dos which can only see Fat32 due to technical limitation). Thus the Dos partition has all the boot loader for the Dos and the other 4 Windows (NTLDR serves Win2k/Xp and bootmgr serves Vista/Win7). On top of it I put Grub inside because the /boot directory is common to Grub and bootmgr. This is definitely "cool"!
5. Correct. In order for it to work there must be a boot loader inside that partition's boot sector.
I have been shifting my 4 MS Windows around and thought I could put all the boot loaders together like I did. It is a great conduit to understand how the various boot loaders can live in harmony. If we understand how the boot loaders work we can make them sing for us!
Grub1 for example doesn't reside in the boot sector. I didn't know about it until I did this thread. The Grub here simply has hard coded the stage2 location of the hard disk in the MBR, leaving the boot sector entirely to bootmgr, which according to the published information must be able to boot all the MS Windows that I can install in the disk. What MS did not expect is that I use a Dos partition as the "C" drive and slip in Grub inside too.
Had the "C" drive been a NTFS Grub can't go inside as it cannot read a NTFS filing system. That is why Dos Fat32 was used, plus it is a bonus to boot up a Dos in addition to 4 Windows.
I did get a kick out of using one Dos partition to boot every operating system in the PC, including one Dos and 4 Windows, So enjoy it!
Last edited by saikee; 06-06-2010 at 03:56 PM.
-
Thanks for your prompt reply... Your way is truly a very ingenious scheme of booting... I must say...
I was surprised to read "Grub1 doesn't reside in the boot sector." This would mean that linux installations can simply be copied around using file copy simply... since nothing is installed at the boot sector of linuxs' root partition. And then a simple update of menu.lst would still boot a linux operating system copied in this way to a new partition. Could you confirm this please? Thanks.
-
Been doing this for years myself.
I am busying moving Linux between Msdos disk and gpt disk (able to cross 2TB barrier) at the moment.
If I want to move a Linux from sda3 to sdb9 the steps are
(i) Format sdb9
(ii) Mount both sda3 on /mnt/sda3 and sdb9 on /mnt/sdb9
(iii) Cd to /mnt/sdb9 and tar the partition across by
Code:
tar cf - . | ( cd /mnt/sdb9; tar xf -)
(iv) Edit /mnt/sdb9/etc/fstab to change the partition reference from sda3 to sdb9
(v) Do the same for /mnt/sdb9/boot/grub/menu.lst
(vi) Invoke a Grub shell and do
Code:
root (hd1,8)
setup (hd1,8)
setup (hd0)
The last one is optional for making the Linux taking charge in the MBR of sda disk. The second last command makes the Linux chainloadable by another boot loader.
The only things you need to watch out for are
(a) Distros embedded with Selinux, typically the Red Hat family (RHEL, Fedora, etc) don't like to be moved. You have to disable Selinux by adding "enforcing=0" in the kernel boot statement, otherwise you get a booting screen but can't enter into it.
(b) Mandriva family ( Mandriva, PCLinuxOS) has a feature that it keeps a record of the installed partition. In the event after it has been moved the kernel would wait between 1 to 2 minutes for the original partition to occurs before firing itself up at the new location. I have not found a way to get over this one yet.
Apart from the above Linux is pretty easy to move around between partitions and disks I would say.
-
Thank you for detailed explanation... as always... It all makes sense now
-
What about mixing in Windows 9x?
Example: DOS, Windows 98 SE, Windows XP and Windows 7 on one hard drive, besides multiple Linux instances.
Would the second primary partition, that would be allocated for Windows 98, have to be made hidden before XP and Win7 were installed? Or is there another way around it?
I'm taking the old Multiboot with GRUB Mini HOWTO into account.
The procedure I'm considering is hiding the respective partitions with Grub1 before chainloading onto the install floppies for Windows 98 and Windows XP. Windows 7, that I am aware of, does not have a floppy image available to then load up the DVD, nor can you chainload an optical disc from Grub after (un)hiding the partitions.
Now that I come to think of it, is (un)hiding persistence from one hardware boot to the next?
saikee, I've been reading up on more than 10 threads you've started over the years trying to figure this last part out. Thanks for all the valuable contribution you've given to anyone trying to untangle the multi-boot mess, you are indeed a guru on this topic.
-
Scheme example of combined approach with Windows 9x
Originally Posted by PedroPalhoto
Example: DOS, Windows 98 SE, Windows XP and Windows 7 on one hard drive, besides multiple Linux instances.
ATTENTION: not tested yet (awaiting peer warnings before wasting more hours on this than necessary).
To clear up, I'll leave an example of what I believe (at the moment) could be achieved to max out this combined approach. Has anyone tried anything similar?
Grub entries:
1. FreeDOS 1.1 + Windows 3.1; Windows XP; Windows 7 [More Win2k to Win8 instances could be installed/accessed from this entry]
2. MS-DOS 6.22 + Windows 98 SE
3. Some other OS or combination of OSes that requires a primary partition.
4 to 60: Other OSes that can boot up from logical partitions
FreeDOS and Windows 3.1 would be installed together on the first primary partition. MS-DOS 6.22 and Windows 98 would be installed together on the second primary partition.
By hiding the second partition from the first and vice-versa, the respective hidden Windows(es) could not see their counterpart primary partition while operating. With this approach I'd probably reduce each system partition's size from the suggestions saikee gave in another thread, and have a shared FAT32 logical 'Apps' partition. The 'Apps' partition would have a "Program Files" folder for each system's managed installed applications (i.e. '\Progs98', '\ProgsXP', '\Progs7'). This partition should be created before any Win2K to Win8 system partitions. To avoid wasting additional disk space with application redundancy, there could also be a common folder for as many portable apps that would work interchangeably on any Win32 OS, such as '\AppsW32'. FreeDOS and MS-DOS 6.22 could share portable applications and data on a shared logical partition below the 8GB limit.
Here's the drive lettering sequence I predict, from each boot.
FreeDOS, Win3.1, WinXP and Win7 view:
C: - FreeDOS (with Grub, NTLDR and bootmgr bootloaders) [1st primary partition]
D: - Small (~1GB) shared Data partition below the 8GB limit (MS-DOS limitation) [can be a logical partition]
E: - Common Apps partition [FAT32, logical]
F: - Windows XP system partition [NTFS, logical]
G: - Windows 7 system partition [NTFS, logical]
MS-DOS 6.22 view:
C: - MS-DOS 6.22 + Windows 98 SE [2nd primary partition]
D: - Small (~1GB) shared Data partition
Windows 98 SE view:
C: - MS-DOS 6.22 + Windows 98 SE
D: - Small (~1GB) shared Data partition
E: - Shared Apps partition
[the NTFS from F: onwards should also be available to Windows 98 if a third party NTFS driver is used]
Partition Table Example Scheme (grub/linux view):
1. 1GB FAT16/32 FreeDOS (with Grub, NTLDR and bootmgr bootloaders) [primary]
2. ~5.5GB FAT32 MS-DOS+Win98 [primary]
3. 512MB (left hidden for some other OS or combination of OSes that might require a primary partition) [primary]
4. Extended Partition [rest of the available drive space]
5. 1GB FAT16/32 Shared Data [logical]
---- 8GB Limit for MS-DOS
6. 30GB+ FAT32 Shared Apps [logical]
7. 20GB NTFS WinXP system partition [logical]
8. 30GB NTFS Win7 system partition [logical]
9 and onwards. Other Operating Systems [logical]
With this rationale, are there any alarms that go off in your mind before I spend some time testing this out?
-
I have moved on since I did this thread. My system has been replaced by two SSD in Raid0 to enable me to fire up Win8, WIn7 or Ubuntu in 12 to 15 seconds. I have ceased to play with Dos and put my attention into the newer MS Windows and GPT partitions.
I did manage to install 5 MS Windows, Win2000, Xp, Vista, Win7 and Win8, all in logical partitions and found out it can be controlled/booted by the bootmgr.exe of Win8. I also spend more time on the Grub2 as that is the only way to work with hard disk larger than 2TB. Grub1 can't cope with large disks or do GPT partitions.
Older MS Windows demand a lot of time as they need drivers for everything. Newer MS Windows are much more Linux like that seldom ask for a driver.
I am still interested in boot loaders but with newer ones instead of the older one for Dos and Win98.
-
"Why?!?"
Originally Posted by saikee
I have moved on since I did this thread. [...]
Thanks for the update saikee, I read some of GPT threads. I might eventually need a GPT reference in the future, keep up the great work.
And as such, this might leave me as one of the last people still with this interest for DOS/Win9x multi-boot and at the same time wanting to document it. I might as well give some background for anyone asking the recurring "WHY?!?".
I am developing a retro hobby video game that I'd eventually like to get running on older systems. I'd like to understand older APIs and be able to exercise getting around difficult constraints as the programmers of yesteryear had to go through, understanding hardware, OS and library architecture decisions that were made in the past. I enjoy understanding the whole computational process and today's high level APIs remove some of what I find to be interesting details and the possibility to spew out creative solutions.
In essence it is just a multi-port tech/artistic endeavour I've always had an urge to engage in. It is akin to what Ninja/The Dreams referred to in his Behind the scenes of a C64 Demo, that To get a real feel for the end result, I would eventually like to test the alternate ports on as much real hardware as feasible, and not rely just on emulators. To avoid having too many machines or having to physically switch out hard drives, I can take full advantage of these multi-boot capabilities, in this case for an IA-32 PC, which can still simultaneously be my main development machine. Don't worry though, the more modern SDL or SFML libraries should be used in the base port.
-
Test Successful (almost)
Originally Posted by PedroPalhoto
[...]I['ll] spend some time testing this out[...]
I went away with testing out the theory, and it worked. Boot thread 'A' had DOS 6.22, Windows 98 SE, Windows XP and Windows 7. Boot threads 'B' and 'C' had MS-DOS 7.10 (customized pack) and FreeDOS 1.0, respectively. I could get Windows 3.11 for workgroups with MS-DOS 7.10 or Windows 3.1 with FreeDOS with some tweaks, but it was beside the point for testing the original hypothesis.
Here's the actual hard drive configuration:
Code:
01. DOS6_WIN98 2GB [PRIMARY,hidden,bootable,FAT16] (C:)
02. DOS7_10 2GB [PRIMARY,hidden,bootable,FAT16] (C:)
03. FREEDOS1_0 2GB [PRIMARY,hidden,bootable,FAT16] (C:)
04. EXTENDED PARTITION (until end of drive)
05. DOS_COMMON 1.847GB [LOGICAL,FAT16] (D:)
06. W32_COMMON 30GB [LOGICAL,FAT32] (E:)
07. WinXPSys 10GB [LOGICAL, NTFS] (F:)
08. Win7Sys 20GB [LOGICAL, NTFS] (G:)
There are still some kinks to iron out, such as aligning drive letters when other hard drives with primary partitions are present, the DOS_COMMON drive that doesn't appear in all OSes correctly, and FreeDOS that refuses to get to the prompt, running into an illegal instruction. The latter should probably be fixed when I burn a CD and install FreeDOS 1.1 without all the bells and whistles.
One major hurdle I wasn't aware of along the way: Windows 98 had to have its system.ini file edited to limit memory to 768MB to get it to boot. Several grub MBR setups were made between installs, so get ready to be booting a grub floppy/optical disc every once in awhile. Currently I'm not in the mood to redo all of the setup to get a nice easy to follow sequence documented, so that'll have to wait. Anyway, the point is, it is possible to mix both approaches I was questioning in a previous post. And the hidden partitions stay hidden unless you unhide them. Grub's map function (not used for these tests) is the one that is volatile on each reboot.
Last edited by PedroPalhoto; 05-24-2013 at 03:29 PM.
Reason: typo
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|