Problem with boot loader - no choice but on MBR - I wonder why
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Problem with boot loader - no choice but on MBR - I wonder why
Linux ditrribution designers! Please! I don't want GRUB on MBR . . . period . . .
I am so unhappy when a distribution forces to install GRUB/LILO in MBR and leaves out the choice to install on PBR of / or /boot partition. This is a serious mistake! This will even rule out options for work around with any commercial boot loader such as System Commander in the following scenario.
Most of PC today come with a SATA II disk channel and an ATA133 channel[/SIZE][/COLOR] for DVD/CD. Their boot order can be remapped with BIOS, meanwhile some OS has fixed hierarchy when an OS probes into physical PCI-E root bridge. With this changeable hierarchy, it would cause problem booting all Unix like OS[/SIZE][/COLOR] without help of 3rd party boot manager when one changes block device mapping. Dell and Gateway would be seriously affected by this problem. I was not even aware of the problem untill very recently since I never worked anything else but SCSI disks like universally trouble free and flexible Seagate Cheetahs (with legacy style jumper pins). I have used System Commander on multiple SCSI disks up to 7 disks over 12 plus years and every OS booted as supposed to untill the age of SATA/SAS.
Let GRUB manage just /boot in every OS (of course multiple grub installation would be necessary) and let commercial boot loader do its job. Commercial boot loaders will not be able to chain GRUB nor find kernel location if it is installed anywhere other than PBR.
If anyone know how to go back and re-install GRUB in PBR? That would be a great help. I can edit fstab, mtab, grub.conf menu.lst from CD boot and OS loaded to a ram disk then mounting any partition without any problem on 2.4.x and 2.6.x kernel. I also know how to put back 512 byte MBR/PBR/EPBR pages from saved images thereof from floppy using dd, debug and disksave since I have kept CHS table and sector numbers on a spreadsheet per disk.
Would you mind setting your font back to something normal - I find that objectionable to look at.
What distro are you talking about? Most, if not all give you the option to install grub on a designated partition rather than the MBR. Granted, it can be hard to work out how sometimes (I find the "simpler" distros like Ubuntu harder to do these sorts of things on).
Boot a live CD (or a working distro), and mount the relevant partition, say sbd4
#mount /dev/sdb4 /mnt
Then use grub-install to install grub on sdb4
#grub-install --root-directory=/mnt /dev/sdb4
Note that some distros (OpenSuse for example) have grub-install set to install to the MBR, and may require some modification. That said, OpenSuse's installer let's you put grub elsewhere (but another that is hard to find)
I use Bootitng as a boot manager, I have at least 10 primary partitions in a multi-boot scenario. When I went to install Ubuntu 7 or something, it did as the OP's case in that it did not ask anything about boot loader and just installed it in the MBR that is normally controlled by my boot manager.
When I re-booted after Ubuntu finished the installation I had no boot menu show up, only Ubuntu booted.
I was a little pissed also...
I had to re-install my boot manager in it's partition, use it to recover all the other partitions that went missing so I could re-build the boot menu. All I did for Ubuntu is add an entry in the boot menu and pointed it to it's partition for booting and it booted up, I did not have to go through instructions provided in the previous link to "re-install grub".
Grub has stages, the first stage is in the MBR, the next is in the PBR. You don't need to install the first stage in the PBR to boot it with another boot loader, because that's not what the first stage does. What you need to boot the partition is the second stage which is already in place.
Let's make request to Linux and GRUB development community
4 Major Requests to Linux and GRUB development community
1.Give us more choices where to put GRUB/LILO/SILO - should never be defaulted on MBR alone
2.Make GRUB Stage 2 script. ‘menu.lst’ more consistent with true device address
3.Linux device file system mapping to enable over 16 partitions per drive
4.Turn off LVM setup by default unless user ask for it in setup.
Yes, I major problem was open SUSE. It is at most tastefully illustrated with top notch art design and of most user friendly package that I admire the painstaking efforts of development communities but it comes with some serious oversight in its boot loader setup. Even if it had such optional setting button somewhere, they are not easily accessible in order to completely disable MBR write and LVM build. Mishap can not be avoided on some beginner like myself. Meaning some damage occur to pre-existing boot loader and partitioning scheme. I have not worked with Ubuntu but Linux developers certainly should listen to our voice.
Of course, I must admit that the GRUB is very intelligent as far as finding root partition where kernel resides with support of some basic Unix command like “find” since it can read nearly all the variants of ufs but a serious shortcoming comes from it’s block device nomenclature which are way too simple in the age of multiple block device interface including SATA, FC, USB, 1394 and like beside historic ANSI ST412/ST506 descendant (16 bit wide MFM, ESDI, IDE and ATA group) and ANSI SCSI (8 and 16 bit).
I have totally been ignorant and never knew anything but SCSI until a few month ago. SCSI was so comfortable due to it’s manual jumper setting along with dedicated BIOS setup in real mode access per HBA to the end.
SCSI and Unix worked well together except some Unix ignored more than 4 physical drives and also multiple HBA (e.g., early SCO). Other than that it has always been trouble free. But the production of legacy SCSI drives are coming to a halt. I am stocking enough units of familiar and hardy ST3146855LW spares for the next 5 year usage. These SCSI still outperform SATA II WD Velociraptors at the expense of space and thermal factor.
I am just a graphic artist and photographer a far from Unix IT engineer. However I have noticed undisciplined trends and difference in device enumeration methods amongst different operating system. Once you embed 446 byte initial codes on to MBR or PBR, grub blindly points to what is written in menu.lst text file. If this text file had enough device address information in it such as c0t0d0p0:b (controller ID, target ID, disk ID, partition ID, slice ID and like) instead of just (hd0,0,b) then everything would have worked. GRUB even understands hardware device mapping convention ‘hard-wired’ in the order of historic** or cultural*** hierarchy tradition. That is why when you add a ATA drive on SATA system, GRUB refused to boot because text written device map no loner matches what GRUB see the in the reality. ATA becomes hd0 whist SATA or SCSI become secondary group may be of hd1. I further discovered that GRUB is intelligent enough to remap/swap the device hierarchy or even hide device specified by script and retains it in memory until OS kernel boots but it simply goes by pre-written text script without applying modified environment.
Note**** I assume that “ST”506 means “Schugart Technology” after the name of physicist Alan Schugart (1930 – 2006) who started out as an IBM engineering manager inventing disc drives together with his team, also invented SCSI, then founded Seagate Technology, and later build restaurant business rated with 5 stars and became a writer.
I would like to see someone come up with something like “Joint Unix Device File System Standardisation Committee” together with boot loader designer, Unix developer and chipset manufacturer.
Current GBUB is not very user friendly and forcing it to be on MBR can be harmful. Further it fails to read ext2 or ext3 when BRUB resides on usf2 and fetched from ufs environment.
Such committee also should standardise devfs (device file system) currently having fixed and prewritten 16 device mapping within a disk drive e.g., sd (disk itself) sd1 – sd15 makes total 16 in the age of 1 terabyte drive. NTFS become faster when devided into multiple 64GB partitions. NTFS is not a very intelligent file system as it is advertised. Its bitmap and mft (like giant fat split up to two compornents) and other metafile structure for added extended attributes have been revised without logical order along with it’s updated ifs (installable fs driver). But disc write method is still same as early 1990 era nothing more than RAW version of OS/2 HPFS. In fact HPFS was much more fault tolerant and efficient since its superblock aligned both directions from the mid point of partition. You do pay a price in term of file access speed with a large NTFS partition. Drawback of NTFS is well covered up by successive advancement of disc technology, faster CPU and increased memory. In NTFS, real mft updates do not occur until idle state or sometimes until system shutdown.
Currently some linux installation aborts and refuses to perform disk write when it sees partition count per disk exceeding 16. e.g., Fodora 9. Another distribution makes unsuccessful attempt to consolidate pre-existing partitions to logical volume and leaves some damages behind e.g., SUSE. Whilst others do not get affected and installs correctly but can not access above sda15 which is quite O.K. e.g., Debian. Or else ignore extended partition and go ahead without even looking at logical partitions e.g., most of Unix. That’s an admirable trait better than just O.K. I only create and auto-mount a single common vfatfs access point in /mnt and auto mount pcfs at /share or /export/share with user,rw,exec access anyway.
Currently, since SATA & USB use through ASPI layer for device enumeration, they are assigned as SCSI block device but it will have problem with the presence of true SCSI. If you have combination of ATA, SCSI, SATA and USB, device nomenclature and hierarchy may appear different amongst Linux themselves. Yes, Redhat, SUSE, Debian and of course Solaris assigned different block device map.
Intel Dual Core 3 GHz
775 Socket 945 Chipset
SATA II two 300GB discs
ATA133 one 75GB disc & DVD
geForce 6600GT PCI-E
My Other Typical Systems - Trouble Free:
Two Intel Pentium Tualatine 1.4GHz (In real world faster than P4 2GHz)
One ICP GDT8623RZ/80803/256MB or One Adaptec 39160
4 Seagate ST3146855LW
One Adaptec 29160 only for CD and scanner
1 Plextor PX40i
1 Plextor PX820i
You know, you could always write a bootloader that does exactly what you want. Perhaps the process of writing it would explain to you why bootloaders work the way they do. But, writing such a rant here is really pointless. Even if we wanted to, there's nothing we can do about it. OTOH, I believe there is a guy here somewhere that has 100 partitions bootable from grub.
You seem to basing all your arguments on distros forcing you to install grub on the MBR, which I doubt is correct, and you haven't provided any evidence of this. You inability to find the correct option may (and note I say may) reflect poor installer design, but neither Ubuntu nor SuSe do any such thing.
Try installing Windows sometime and tell us how that goes.
I've installed over 100 OSs, many generations of the same in some cases. When I installed Ubuntu 7.04 or whatever it was, I looked hard for any link to a custom boot loader configuration and it never presented itself. Because I am a die hard multi-boot kind of person, installing grub or lilo in the partition is extremely important to me, which Ubuntu 7.04 never offered me in any way/form/fashion.
I don't use Ubuntu, it's just taking up un-used space on my drive. It pissed me off during installation, and does not have any advantage over any other Linux OS on my multi-boot system. Because it wasted my time, I can't find time to waste on it.
Most distros probably default to installing Grub to mbr but, I don't know of any that require it ('cept windows). There may be some but usually you just need to look for options as indicated in post above, clicking the Advanced button on Ubuntu (same on Linux Mint).
Limitation of 15 partitions is scsi/sata as ide drives can have up to 63. Also, as indicated above, look for posts by 'saikee' on using Grub as I believe he is over 160 partitions on his computer.