Re: Loadlin and Squeeze kernel 2.6.32
On Sun, 15 Jul 2012 12:14:10 -0400, Tom H wrote:
> On Sun, Jul 15, 2012 at 10:12 AM, Camaleón <noelamac@gmail.com> wrote:
>> Which, generally speaking, it translates into...? I mean, what are
>> those "block lists" and how are they effectively affecting the boot
>> process from a user's point of view?
>
> Let's assume that grub1/grub2 have to load "/boot/grub/camaleon" in
> order to boot.
>
> If they're using block lists, they'll locate that file as starting on
> xxx block of yyy partition.
>
> If they're using an intermediate stage (grub1's stage 1.5 or grub2's
> core.img), they'll locate that file by name.
>
> Block lists are supposed to be less reliable/more fragile/(fill in with
> the negative flavor that suits you).
I'm not sure to had get it (sorry, I must be a bit dense...). Can you
provide a user case for someone using block lists and another case when
they're not in use?
I have installed GRUB in both (MBR and boot sectors) since many years and
have not experienced any difference nor problem with this. In fact, this
has been the recommended method when windows is already installed.
>> On systems with multiple operating systems in the same hard disk I've
>> always found a more dangerous approach to install GRUB (or any other
>> bootloader) in the MBR that inside a partition because you completely
>> relay on the bootloder capabilities to boot all of the installed
>> systems and also the MBR could be always overwritten when you install a
>> Windows system.
>
> When multi-booting Linux distributions, there's no problem installing
> grub in the MBR. I have a netbook on which quantal, rawhide, and sid are
> installed and grub's uninstalled in rawhide and sid and installed in the
> MBR via quantal.
Booting multiple linux or *nix flavours can be also tricky when using
GRUB legacy with different filesystems (that is, GRUB legacy cannot
directly boot from ext4 unless it has been patched, IIRC).
> When multi-booting Linux and Windows, installing grub in the MBR *can*
> be hazardous to your health and that of your box...
Yes, the problem arises when windows is being reinstalled afterwards,
users will then need to reinstall GRUB all over again.
(...)
>> Why does openSUSE provide such option while others no and what kind of
>> changes generates? As I said, I don't know, maybe option a) writes
>> specific GRUB code into the MBR while option b) uses generic bootstrap
>> data. Differences between the two? That a) does not need the bootable
>> flag to be present while b) does? Who knows :-?
>
> No worries.
>
> I've done some googling...
>
> 1) The generic boot code's the DOS MBR code that
> fdisk/fixmbr/bootrec/bootsect writes to the MBR with the right
> option(s). The DOS MBR code's less sophisticated that grub's; it simply
> loads the partition marked active.
Ah, thanks for confirming.
> 2) OpenSUSE does this because it doesn't believe in installing grub in
> the MBR (but its installer allows you to do so).
That can be indeed the reason although their installer defaults change
over the time, I can't say what's the current proposed setup, if
installing GRUB into the MBR or dropping the bootloader into a partition.
Or maybe they just adjust this value "on the fly" based on the user's
disk layout, I can't recall... what I remeber from the openSUSE installer
is that:
1/ It was very powerful and fully customizable (from a user's point of
view).
1/ It still provided GRUB Legacy (openSUSE delayed the migration to GRUB2
precisely because of this, the integration between YaST and GRUB2 was not
an easy task).
Greetings,
--
Camaleón
Reply to: