On Mon, Jul 16, 2012 at 10:41 AM, Camaleón <noela...@gmail.com> wrote: > On Sun, 15 Jul 2012 12:14:10 -0400, Tom H wrote: >> On Sun, Jul 15, 2012 at 10:12 AM, Camaleón <noela...@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've explained twice (IIRC; I'm replying quite late to this thread because I've been busy...) and I'm not sure that I'm going to do a better job a third time but I'll try. The block lists are used when grub's installed in a PBR because there's no space for a stage 1.5/core.img (which can read some filesystems) so the next step in the boot process has to be encoded and found using the blocks that it occupies on the disk. >>> 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. More than that. Some Windows licensing and anti-virus/malware software installs stuff into the post-MBR gap so grub, on an msdos-labeled disk has to fight for space there... >>> 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. You're welcome. >> 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). I don't see why providing grub1 is a plus. This autumn'll be the 3-year anniversary of Ubuntu defaulting to grub2. It was a premature release except for the use of 9.10 as a grub2 "have fun, hit some bugs, and file bug reports" step for 10.04 LTS. The v1.98 that ships in Squeeze and 10.04 isn't as good or as featureful as the latest grub2 but it's good. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=syf5wysfaouyt5fkudy530g-v6gdhaoyoesehbmf2u...@mail.gmail.com
