Why most ditro force me to put GRUB on MBR?
There are so little information available regarding how to install GRUB on PBR of root partition making Unix like OS so difficult to coexist with other OS. GRUB between OS themselves have different partition identifying convention such as hd0,0 hd0,1. . . sda1, sda2, . . . c0t0d0p0 c0t0d0p1 and so on. Does anyone know a link to such information?
Most of today’s X86 desktop are equipped with a SATA II disk channel and a DMA133 DVD ATA channel embedded into Intel 82801GB in 900 series chipset. The block device map hierarchy or boot order can be easily changed by OS and BIOS within PCI-E root. I have also invested in buying several versions of commercial boot loader such as System Commander. But any of such stage 1 boot loaders are useless when GRUB installs on MBR. Most Linux distribution does not seem to offer alternative to MBR install except authentic Redhat up to version 9 ended in 2004. Again . . . I do not want GRUB in MBR in any condition!
I am aware of that some versions of Unix like OS (like Solaris OS and Debian Linux) themselves are far smarter than GRUB, LILO or Windows OS themselves. But, what can you expect from GRUB or LILO with their space constraint and non TSR requirement? Even smarter OS like Solaris still have to rely on Stage 1 and 2 on boot loaders. A universal boot CD with an X front editor ability to load on temporary ramdisk would be a great help to edit GRUB parameters
Such tool should have rw-, - - -, - - - access to at least ufs, jfs, ext, ntfs to edit menu.lst in kernel boot location, grub.conf, lilo.conf, fstab, mtab and like in /etc. there are some thoughtless trend to move some of these to /var or put in symlinked file into /proc. To my opinion, such movements violate the fundamental philosophy of UNIX structuring - the people’s OS – that is a community developed OS for the people themselves.
I have developed a habit to save MBR, PBR EPBR, each of their CHS address into 512 byte files and a spreadsheet very early back in 1990’s using debug then with disksave programme and flag partition manually. Yes this does work as an OS selector but it takes 5 plus minutes to change boot OS selection using 4 to 6 floppies sometime.
I have been an ardent SCSI supporter from 1990’s and totally ignored other technologies such as including ATA. IDE. SATA, SAS, Fibre Channel, 1394 and USB. SCSI was so comfortable not being plug and play to the end, you can see it’s order by viewing jumper setting. I am now paying a rather high price of frustration as the outcome from the fixation to SCSI only policy then now trying to work on the SATA ATA mixed system. However, SCSI would solved all the above mentioned boot problems. My last batches of Cheetah 15.5 still outperform SATA II Velociraptors at an expense of 6X space factor per gigabytes due to cooling fan requirement (a 4” fan per every 2 Cheetahs). I have been rather giving SCSI channels 2 or 3 IRQ and not to give more than single pooled IRQ to sound and video cards. SCSI has been completely trouble free when you only connect 4 disk per channel maximum and also separate CD, scanners and like from disk channels hence my average system has 3 channels. There are the troubles that you can invite on SCSI of course, by enabling int 13 hook more than two channels at any one time or over 7 disks. The trouble can show up next day or even one month later. Disks start acting as if all infected with MBR/PBR virus. That was only an incident I ever experienced on SCSI for the last12 plus years. Of course you have to change out the HBA cards very 5 years or so after U160 ASIC era due to thermal fatigue on embedded FIFO memory falling down to async transfer mode. It does not happen on i803xx RISC controlled HBA since memories are bulk DIMMs.
Ironically SCSI shined throughout the lifetime of it’s inventor Allan Schugart (also a brilliant writer) who invented disk drive at IBM and later founded Seagate. After his death, physical form of SCSI bus has come quickly to halt, but command set still survives on USB, modern IDE/ATA, SATA, SAS and FC as ASPI layer but they are not true SCSI that insisted to be of manual setting device to the end. Yes even if you had X-Front or Win GUI configurator but we were manually changing flip flop switch setter bits in flash rom in lieu of jumpers. Hence all SCSI had very rigid reserved memory area in C000 to middle D800 so were Nvidia display, and Turtle Beach sound and they did not co-exist well unless you change the order of plus-in manually about a douzen times. If sound and video had jumper settings they may have co-exited together happily.
I am debating wheather I should get another enclosure and move everything out from Dell Dimension Dual Core System and move back to old familiar SCSI and disable SATA? My big if question is where I can get DVD CD Writer on SCSI 320 or 160 platform? By the end of 90’s it was difficult to get decent support on CD RW on SCSI….