Swapping multi-boot-related notes

Post Reply New Topic

This morning I called MicroSoft Support to see whether anyone there could help me keep from again having to re-install Win7 into my multi-boot system, and at one point the tech there actually said he was learning from me!
** bows modestly **

me: "XP's 'repair console' can 'fixboot' and even 'fixmbr' when necessary, but Win7's 'startup repair' cannot do that in my system."
tech: "How many drives in your system, and where is Windows 7 installed?"
me: "Win7 is installed in the second partition on my third drive."
** much discussion and note swapping over the next hour or so **
tech (paraphrased): "Win7's 'startup repair' will only work when Win7 is in a partition on the first drive in a system."
me: "So, a re-installation is my only option for getting my Win7 back into the mix?"
tech: "Yes, and we will not charge you for this call since we have no 'fix' other than for you to re-install your Windows 7."

Overall, that tech was a very pleasant fellow and he and I had quite a discussion about various issues and conflicts at the boot sector, and I pointed him toward some Linux-related information.

Last edited by leejosepho on 04 Sep 2010, 2:06 pm, edited 1 time in total.

Told you so. You are becoming the go-to expert.

A manager called to see whether my Win7 is working now, and just a few minutes ago he said he was on his way here ...

Sadly, Microsoft intentionally breaks bootloaders through patches. Would you like me to dig up the dirt?

Not unless you believe doing so would actually be helpful, but I have heard some bits and pieces about that.

I might experiment/test with SuperGRUB a bit to see whether or how well it can actually boot Windows systems directly from their respective locations. Ideally, and like I did in BASIC on my Commodores many years ago, any multi-boot system ought to have each of its systems completely independent and isolated or "firewalled", then accessed only by a "neutral" menu system capable of starting each. Some folks might say GRUB already does that, but it does not. Rather, it replaces proprietary stuff subject to the the kind of damage you have mentioned.

Like anyone might logically expect, SuperGRUB (running from a system-boot CD) can boot an OS in any partition containing that OS's own boot loader -- I am booting Mint without first calling anything on "C" -- but that does not get anyone past any conflicts where Microsoft is the at-least-circumstantial "bully" in the boot sector on "hd0,0" ("C"). So, and just thinking out loud a bit here while knowing only a little about the MS EULA ...

The computer owner owns his or her hard drive/s, and s/he allows Microsoft to install stuff to the boot sector on his or her "C" drive ...

The computer owner owns his or her hard drive/s, and s/he might want to also install other stuff to the boot sector on his or her "C" drive ...

The computer owner has agreed to not modify Microsoft stuff, but Microsoft has not agreed to refrain from ever even unintentionally hijacking control over the entire boot sector on his or her "C" drive ... and none of that is likely to ever change.

I know there are people who know how to write and flash-in a custom BIOS, but does anyone here know of anyone writing a custom BIOS that can do what SuperGRUB can do? SuperGRUB has made it possible for me to boot Mint without either my "C" or my Mint (GRUB) even knowing the other exists, and it can also find and run whatever Microsoft has written on my "C".

(PMs welcomed)

your posts are really interesting leejosepho, I registered just to reply

If I am correct, are you wanting a boot loader that is independent of any OS, i.e. no specific OS has control over the initial boot loader or what appears on it?

GRUB and GRUB 2 can us chainloading, It allows you to tell the boot loader the location of an OS' native boot loader. You could then have a boot loader for each OS (for linux you would install the boot loader on the partition not the boot sector). Then install the OS independent grub on a usb stick or floppy drive. the usb or floppy would hold the menu.conf file and boot loader and you would load that up when you wanted to boot an OS.

This way the independent boot loader only holds the locations of the boot loader for each OS but not the actual information to boot the OS.

Ive never actually done this myself though.

Welcome to WP!



Yes, and you just led me to see GRUB could already do that. Ultimately, however, and to avoid having to use a stick or disc of any kind, it would be nice to have something like GRUB right in the initial loader (BIOS) I see passing control of my machine on to the running of whatever is on my first-drive's boot sector. In that way, and as you have mentioned, each OS could have its own loader within its own space (or wherever its author and the machine's owner might agree is safe) ... and Windows could still be dominant on "C" in a system such as my own (or subject to an owner's personal preference or selection) without anyone having to be concerned about the kind of trouble I have recently had. Or, and as done manually by many multi-booters in days past, the initial loader (BIOS) could automatically turn drives on or off or switched to make the desired OS available as "C" ... but I would not want that for myself since I have 5 (or actually, just 4) operating systems sharing a common "DataDocs" (My Documents) folder on yet another drive.

you could use the MBR with grub, to solve the independence problem you could create a small separate partition to store the grub config file and nothing else that way you dont need to use a floppy disk. However you then need to be careful of your other OS' if you reinstall them especially windows it could overwrite the MBR, if that happens however you just need to install grub again and point it to the grub partition.

for example

-MBR - GRUB-
--DISKS--
---GRUB partition (<20mb)---
---other OS---
---other OS---

I wonder if there is a way to make the MBR read only?

The problem with writing any extra code to a BIOS is they tend to use proprietary code with no source available, some motherboards support coreboot (i cant post links) which is a Free Software alternative to proprietary bios.

coreboot supports payloads, which correct me if im wrong (im reading it off there site) coreboot initialises the hardware only then runs a payload of which can be anything from a bootloader to OS' directly, coreboot can boot a linux kernel straight from the rom chip for example.

If your motherboard supports it this may be a solution to look at, though a slightly more risky option that other options, you may brick your motherboard if you cant flash the bios if a problem occurs.

Certainly, but my goal here is to get to a place where *no* boot loader or menu for *any* OS will *ever* be in the way or able (apart from being malicious) to overwrite another, and without *ever* giving overall control to the loader or menu for *any* OS on the machine. Within Windows, EasyBCD (third party) can put Linux into Win7's BCD after the GRUB loader has been written to the Linux partition or drive (assuming Win7 is on "C"), but, and mostly because of GRUB, I believe, I have ended up having to completely re-install systems after some little thing went wrong while doing that. Then from the other side of things (and when GRUB installs as it should), letting GRUB take over as the main loader and menu on "C" makes it vulnerable if an indispensible Windows loader ever needs repair ... and that kind of problem can happen with Windows even when Linux is nowhere within sight. So again, my own experience suggests getting to a place where *no* boot loader or menu for *any* OS will *ever* be in the way or able to overwrite another. I do greatly enjoy doing this stuff, but re-installations are now taking up far too much of my time!



My BIOS has a "virus warning" to catch and stop any attempt to write to my MBR, but Windows needs to write to it for installations and typically steps past that somehow anyway. So, backup is the best "protection" I know for the MBR.



That makes sense to me, but I am at least ten years behind at any given moment ...



... and that is at least one reason why.

Update:

Over these past couple of weeks I had managed to make my third hard drive a little shaky, so I wiped it last night and started over with Win7 and Mint ... and Mint is getting its updates at the moment.

I installed Win7 first so its loader would be there for GRUB to later add to Mint's menu, but I did *not* put GRUB anywhere other than on Mint's partition ... and for now I am using SuperGRUB (plus about 30 keystrokes!) to get to Mint's menu (with Win7 in it) after staring my machine. I can take the SuperGRUB disc out of the picture whenever I might want to get to Windows a few seconds sooner, but SuperGRUB only needs three or four keystrokes to get to Windows directly.

I like Gnu - said lifestudent Lee.
Full control - and its free!
I'll finally enjoy Mint,
when Seven takes the hint,
and stops $%&*@ around with me!

The problem with the MBR is any OS has access to it, GNU/Linux and others tend to give you the option about writing to the MBR the problem with windows is in trying to simplify things there isnt as far as I am aware an option to stop it writing to the MBR.

If windows writes to the MBR however removing for example grub its really easy to fix you just need to install grub on the MBR again, it doesn't remove grub config files as they are kept on a partition either the OS boot partition or a separate partition as i suggested.

just as windows will write over grub on the MBR if you installed gnu/linux and didnt take care to look at what its doing it could write grub to the mbr removing windows from loading. The good thing about gnu/linux is that fact that it does try to detect and add your OS' to grub which windows doesn't.

no matter what you do the MBR record will always be vulnerable to matter what OS or boot loader is installed.

All your OS' can have there own boot loader as you did with installed Mints boot loader on its partition the problem is the initial boot loader all you need to be careful with is not to let windows go near the MBR. If your going to keep installing windows you will likely just have to stay away from using the MBR for the initial boot loader.

The goal here is not to deny OS-access to the MBR, but to give a typical non-geek multi-booter some protection against the possibility of collateral damage within it. At least in my own system here, I have no problem with letting Windows have exclusive access and control at my MBR ... and now I just have to tell you this bad joke:

Some folks arrived at "Heaven" and were taking a look around, and they became curious about a cluster of others being left alone over in an area all by themselves. After asking around a bit, the new arrivals were told those other folks did not much seem to care for the idea of playing well with others, and the rest of us had decided to not bother with trying to change their minds.


Understood, and that is what I am doing right now. The Windows loader has been written "over there", of course, since there is no other way to get into Windows at all (as far as I know). However, I have located some software, utilities and tools I believe will make it possible for me to put something dependable and "automatic" -- no more CD-boot and 30 key strokes -- between the Intel "hardware-ID loader" in my BIOS (or wherever it is) and the Windows-system "boot loader" on my first drive without having to alter either. That kind of thing really already exists, of course, but I want to do that from something other than a USB device.