[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lilo removal in squeeze (or, "please test grub2")



>> Maybe, but ext4 support is not really crucial. Simply make /boot ext2.

Actually ext3 works fine.

> Having /boot on a separate partition for robustness, security or 
> advanced features (encrypted LVM and stuff) is one thing, but having it 
> because the default bootloader doesn't support current (ext4) and future 
> (btrfs) filesystems seems like a hack to me.

Until the bootloader is itself a Linux kernel (so it can directly use
Linux fs drivers), the bootloader will always be playing catch-up.
I've been using a /boot partition forever, because I have / on LVM.
Nowadays, I use Grub2 on several of my machines, so I could put /boot
directly in LVM, but why bother?

The thing that I would find more useful is to get rid of things like
update-grub, and instead have the bootloader generate the bootlist on
the fly.  I.e.: install the bootloader, and never touch it again.

> Also, the config has become so complicated you need another config
> file (/etc/default/grub) to configure how it will be generated :(

Yes, that sucks as well.

> * LILO is not developed anymore
> * Grub1 is not developed anymore

I've used Lilo a few times in the past and found it very useful because
of its simplicity: tell it where are the files to boot, and on which
drive to install itself, and that's it.

For Grub1 (and worse for Grub2), you have to worry about the difference
between "where the files are now" vs "where the files will be when
I boot", then multiply that by the different sorts of files (Grub2
modules, Grub config file, kernel/initrd files) and then you have to add
the fact that the grub-install scripts try to hide these differences
from you.  E.g. I could never use Grub1's "grub-install" and be
confident of the result, so I always used /usr/sbin/grub to install
Grub1 instead.  With Grub2 this is not even an option, so I use
`grub-install' and then I just hope for the best.  Luckily, my setups
are usually simple.


        Stefan


Reply to: