LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices

Reply
 
Search this Thread
Old 12-12-2011, 03:49 PM   #16
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001

Quote:
Originally Posted by Brains View Post
It don't matter which boot loader is the main boot loader in the MBR(s) of a multi-boot system, they all do the same thing and just pass it on to the partition you select.
And this is what you fail to realize: This is only true for booting different systems than Linux. If you have a multiboot system with five different Linux distributions only one distribution has to have a bootloader installed to the MBR. All the other distributions can be started from that bootloader without having themselves a bootloader installed on their partitions. It just isn't needed. While they have the capability to chainload to a different bootloader, they don't have to do that.
 
Old 12-12-2011, 10:35 PM   #17
Brains
Member
 
Registered: Apr 2009
Distribution: Debian testing
Posts: 258

Rep: Reputation: 42
With legacy grub, one was required to hit up LQ and spend days troubleshooting the grub.conf file. With grub2, simple commands take care of setting up grub.conf and enabling a crippled OS to boot up again.
 
Old 12-12-2011, 10:43 PM   #18
Brains
Member
 
Registered: Apr 2009
Distribution: Debian testing
Posts: 258

Rep: Reputation: 42
Quote:
Originally Posted by TobiSGD View Post
And this is what you fail to realize: This is only true for booting different systems than Linux. If you have a multiboot system with five different Linux distributions only one distribution has to have a bootloader installed to the MBR. All the other distributions can be started from that bootloader without having themselves a bootloader installed on their partitions. It just isn't needed. While they have the capability to chainload to a different bootloader, they don't have to do that.
Wrong:
Not sure about lilo, but grub works in stages, one stage will be in the MBR, the rest in the partitions.
And for all intensive purposes, why would you look at other boot loaders if all your operating systems are Linux using grub?
Multi-booting boot loaders do not support one operating system, Linux operating systems all use the same kernel, which can all be loaded with Lilo or grub. The only boot loader that will load Mac OS kernel is Darwin. Have you given that any thought?
 
Old 12-13-2011, 01:42 AM   #19
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,529
Blog Entries: 27

Original Poster
Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
There's a good description of the Linux boot process on Kim Oldfield's site here.

I understand from the discussion (thanks ) that the only generic software that can boot a Linux kernel is GRUB, GRUB2 or LILO. According to Wikipedia's Comparison of boot loaders, there are OS-specific tools that do the same such as AirBoot, Redboot and FreeLoader. There was also ASPLoader. They may be forks of GRUB or LILO, I haven't tried to find out yet.

All other MBR-resident solutions must use one of those residing in a partition boot sector. This includes Acronis "OS Selector", TeraByte "BootIt New Generation" (BING) and TeraByte "BootIt Bare Metal" (BIBM).

If that is correct, Wikipedia's Comparison of boot loaders's table column "Can boot ... Linux" is misleading to have "Yes" for at least some of the solutions listed instead of "Calls GRUB or LILO".

BING was great and presumably its replacement, BIBM, is great too but, for a computer on which Windows is rarely booted, the cost of running any MBR-resident software and then GRUB, GRUB2 or LILO (clutter, complexity and boot delay) does not justify the the benefit of the MBR-resident software (easy to use, pretty).
 
Old 12-13-2011, 01:59 AM   #20
Brains
Member
 
Registered: Apr 2009
Distribution: Debian testing
Posts: 258

Rep: Reputation: 42
So....
What is your point?
Might I remind you, the benefits to BING have nothting to do with booting operating systems, which means, nothing to do with MBR. The benefits are in the imaging and partition tools.....
You are dwelling on a null subject, any boot loader can run the MBR.....
If all you want is to boot your various partitions, than use grub, lilo, acronis, etc. etc. etc.
 
Old 12-13-2011, 02:51 AM   #21
hurry_hui
Member
 
Registered: Oct 2008
Location: Near Jakarta
Distribution: Slackware, Arch, Slax, Porteus, Tiny Core, Slitaz
Posts: 355
Blog Entries: 1

Rep: Reputation: 51
I just want to tell my opinion regarding bootloaders, I used grub-legacy, grub2, grub4dos, lilo, syslinux. All are used with simple disk setup.

Grub-legacy is self-service. It can fix itself as long as it can find stage1 and stage2. It can fix itself on grub interactive prompt. It doesn't need modules to work properly. It has limitation in that it cannot boot isos. It can be installed easily anywhere.

Grub2 requires its directory /boot/grub/ consisting modules intact. Without this directory, grub2 cannot do its job. It cannot fix itself although it can give user interactive prompt. When grub rescue happens user is required to insmod (inserting) certain modules manually by first setting prefix to /boot/grub/ location. It can boot isos via loopback and has many modules to support its job. It need to be forced to install on root partition.

Grub4dos requires a lot reading for user to use bootlace.com properly. Some features are not yet implemented (like installing on root partition), the user need to input some longer parameters instead. It works just like grub and grub2 combined. It has interactive prompt just like other grubs and it can boot isos via map feature. It requires grub.exe to work properly.

I cannot talk much about syslinux (extlinux) except it can boot isos via memdisk feature. I have no experience installing it on root partition.

Lilo is just work although it has no interactive prompt and cannot boot isos. I once had difficulty booting zenwalk. Using lilo from within slackware I can successfully boot it.

Sorry for my english.
 
1 members found this post helpful.
Old 12-13-2011, 11:16 AM   #22
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001
Quote:
Originally Posted by Brains View Post
Wrong
Nope, been there, done that.

Quote:
grub works in stages, one stage will be in the MBR, the rest in the partitions.
Partially wrong, grub needs the stages only on one partition, it is able to start a kernel and OS (that itself has no bootloader installed) from any other partition on any disk in the system after loading the stages from that one partition. Here also: Been there, done that. No problem at all. It is even possible to install grub (stages inclusive) on one partition, independent from any OS. It is still able to boot any other OS from any partition on any disk in the system.
 
Old 12-13-2011, 03:36 PM   #23
impert
Member
 
Registered: Feb 2009
Posts: 282

Rep: Reputation: 53
Quote:
With legacy grub, one was required to hit up LQ and spend days troubleshooting the grub.conf file. With grub2, simple commands take care of setting up grub.conf and enabling a crippled OS to boot up again.
How can anyone spend days troubleshooting Grub1? It's the easiest thing in the world to get running again! Much simpler than Grub2.

On my box, (20+ OSes - the number varies), every one has Grub 1 in the root partition. Every one except one is booted by chainloading. If I install a new OS I can boot it immediately by chainloading (if, that is, the installer allows me to put the boot loader in the root partition) even before I have updated the menu.lst entry in the OS that the MBR points to. If the installer refuses, or stuffs up putting the bootloader in the root partition, it's dead easy to boot manually from a grub prompt. Four commands: root, kernel, initrd, boot. Auto-completion fills in the details of the kernel/initrd version.

When I had Grub2 in the MBR, it gave me a list of around a hundred entries, including 20 or so each of memtest entries, single-user entries, old kernels, non-framebuffer entries, and who knows what.
Certainly, you can make it more sensible by running update-grub twice, once with os-prober enabled, then make your own custom file, then run update-grub again with os-prober disabled, so that you only get your own custom grub.cfg. You can play around with /etc/default/grub and the files in /etc/grub.d. And you can spend days doing that.

How much simpler it is to write a menu. lst: you only really need entries for default OS, timeout, and then title, root, kernel, initrd for each kernel you want included. Then in the OS that the MBR points to, you have title, root, chainloader +1, for each partition. You can write this one in about three minutes before you even install your OSes with title (eg): "Whatever in sda12", and so on. This way, I don't need to update-grub or edit the menu.lst for a new installation or a kernel upgrade.

Grub2 was supposed to be the answer to the multi-booter's dreams.
It solved a lot of problems that I didn't have by introducing a lot of problems I didn't need.

Fortunately you can always get rid of it, and you can just copy across Grub1 from an OS that has it, without even bothering about dependencies and package managers.

Well, this is an opinion thread, so I shan't apologise for the rant.

Quote:
It is still able to boot any other OS from any partition on any disk in the system.
Which is one of the things that make it brilliant.

Last edited by impert; 12-13-2011 at 03:44 PM. Reason: Added more interesting facts.
 
1 members found this post helpful.
Old 12-14-2011, 03:22 AM   #24
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,529
Blog Entries: 27

Original Poster
Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Thanks impert

AIUI, the arrangement of installing legacy GRUB (or GRUB2 or LILO) to each root partition has several advantages, especially when combined with a boot loader entirely resident in the MBR(s):
  1. There is no common /boot file system to accumulate redundant files.
  2. Shorter menu(s) when each root file system has several kernels.
  3. root partition boot sectors can be more safely restored unlike the MBR+ which includes the partition table so restoring it after partitions have changed ...
  4. If using a boot loader entirely resident in the MBR(s), can use one which is easier to use and re-install (especially on a system with no functioning OS) than legacy GRUB, GRUB2 or LILO.
  5. Each OS can install the boot loader best suited to it in its root partition.
  6. When an OS is scrapped, all its boot loader components are automatically removed when its partition is deleted or re-loaded.
... and one disadvantage: takes a little longer to boot.
 
Old 12-14-2011, 04:41 AM   #25
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 6,915
Blog Entries: 51

Rep: Reputation: Disabled
Multi-booting with lilo in the MBR, and other bootloaders in their distros' root partitions, is dead easy. Just a matter of putting in lilo.conf, for example:
Code:
other = /dev/sda3
  label = whatever
Then running lilo (which some people claim is inconvenient).
 
Old 12-14-2011, 05:32 AM   #26
impert
Member
 
Registered: Feb 2009
Posts: 282

Rep: Reputation: 53
@ catkin:

The main advantage of having a bootloader in each root partition, as I see it, is that you don't have to update your "main" menu.lst or grub.cfg (ie the one the MBR points to) every time there is a kernel change on another system, or you decide to replace Ubuntu with Zenwalk or whatever. Also, you don't need to keep track of the strange kernel options that some OSes seem to like (Fedora . . )

Except with OSes that Grub can't boot, you're not limited to chainloading, of course. It's perfectly feasible to manually write a menu.lst with all the kernels & versions & initrds & options explicitly set out, but you'll have to update it when things change. You can use Grub2 in the MBR to do this for you - I did for a while - but you'll have to boot into the OS that the MBR points to and run update-grub. Much simpler to chainload.

As for the slower booting, the major loss of time is human reaction time in choosing the OS. If you want choice, you have to live with that.

Redundant kernels accumulate in the different /boot directories if, like me, you're a bad housekeeper. I don't lose sleep over this. On most systems a new kernel is automagically placed as first entry on the menu.lst/grub.conf/grub.cfg, so the next boot will use it.

Quote:
root partition boot sectors can be more safely restored unlike the MBR+ which includes the partition table so restoring it after partitions have changed ...
This has never been a problem for me, as I have a brace of spare empty partitions.

I'm not sure what you mean in item 4. I find Grub1 easy to install (except for the broken version in Debian Squeeze). If there's something easier, I don't know of it.
 
Old 12-14-2011, 06:52 AM   #27
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,529
Blog Entries: 27

Original Poster
Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by impert View Post
I'm not sure what you mean in item 4. I find Grub1 easy to install (except for the broken version in Debian Squeeze). If there's something easier, I don't know of it.
Thanks impert

All good points and understood.

I used to use BootIt New Generation (BING) and am hoping that BootIt Bare Metal (BIBM) is equally sweet and can be installed in the MBR only. Version 1.06 doesn't like my hardware so I can't report about it yet. Will update this thread when I do (1.07-beta is OK on the hardware; waiting for TeraByte support to advise).

Installing legacy GRUB is mildly tedious because it's not available for Slackware64 unless the 32 bit libraries are installed so it has to be done from Knoppix -- and I don't install legacy GRUB often enough to be fluent with it whereas BING was so simple it did not require fluency. This despite being very comfortable at the command prompt and with text configuration files.
 
Old 12-14-2011, 11:45 AM   #28
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001
Quote:
Originally Posted by catkin View Post
[*]root partition boot sectors can be more safely restored unlike the MBR+ which includes the partition table so restoring it after partitions have changed ...
Simple as that: The bootloader part of the MBR is in the first 446 bytes, the partition table is in the following 64 bytes. So if you just back up the first 446 bytes instead of the whole 512 bytes that issue is simply not existent. Besides that, I don't see the point in backing up the MBR, you would need to start a live system to restore it, but if you have a live system running you can simply re-install the bootloader.
 
Old 12-14-2011, 12:11 PM   #29
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,529
Blog Entries: 27

Original Poster
Rep: Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176Reputation: 1176
Quote:
Originally Posted by TobiSGD View Post
Simple as that: The bootloader part of the MBR is in the first 446 bytes, the partition table is in the following 64 bytes. So if you just back up the first 446 bytes instead of the whole 512 bytes that issue is simply not existent. Besides that, I don't see the point in backing up the MBR, you would need to start a live system to restore it, but if you have a live system running you can simply re-install the bootloader.
Legacy GRUB's stage 1.5 is installed in first 30 kilobytes of hard disk immediately following the MBR (Wikipedia). Thus, to restore legacy GRUB the first 30.5 kB could be restored. Thinking about it some more, it could be done without affecting the partition table by:
Code:
dd if=MBR.backup of=/dev/sda bs=446 count=1
dd if=GRUB_1.5.backup of=/dev/sda bs=1 skip=512
The count=1 is probably not required but does no harm and guards against an accidentally too large MBR.backup file overwriting the partition table.

Would it not be possible to restore MBR.backup and GRUB_1.5.backup in this way from an OS booted from CD/DVD, USB device etc. such as Knoppix?

AFAIK if the "live system running" were a 64 bit system without the ability to run 32-bit programs, it could not be used to re-install legacy GRUB.
 
Old 12-14-2011, 12:19 PM   #30
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,267

Rep: Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086
The only loader that seems to have dropped out of favor ... in any case, I don't miss it ... is LILO, simply because if you forgot to issue the right command at the right time you could wind up with an unbootable system. Systems like Grub know how to read and use text files, and they also provide a limited number of on-the-spot commands.

I have even seen Windows shops that used these loaders (taking special care to replace Windows' endless attempts to put back its "NTLDR"), because this technique afforded them more flexibility in dealing with the occasional boot problem. Their standard boot configuration was to use (I think, Grub) to load NT.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Chainloading from Grub2 to syslinux on a USB drive Yotefn Linux - Newbie 7 04-04-2011 04:15 AM
[SOLVED] Grub/ Grub2/ Lilo - canīt install any of them properly! spoovy Slackware 26 11-19-2010 06:35 AM
Grub/Lilo/Syslinux on /dev/sda1 phantom_cyph Linux - Software 5 06-14-2008 08:56 AM
Syslinux as an alternative to GRUB/LILO AP81 Linux - General 6 12-05-2007 10:18 AM
Made a bootdisk with RedHat 7.1 to boot: Gave me SYSLINUX, not LILO:Want to use LILO Colonel Panic Linux - Software 0 08-17-2001 06:21 PM


All times are GMT -5. The time now is 04:25 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration