https://bugzilla.novell.com/show_bug.cgi?id=223773 User suse@tlinx.org added comment https://bugzilla.novell.com/show_bug.cgi?id=223773#c45 L. A. Walsh <suse@tlinx.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suse@tlinx.org --- Comment #45 from L. A. Walsh <suse@tlinx.org> 2008-07-02 17:27:56 MDT --- "You are not authorized to access bug #144773." -- I'm still being blocked when going to look at this. -
I agree with comment #37: XFS really does suck, especially when it comes to booting Linux on a PC. Fortunately we do not support it any more for new installations, an ext2 /boot partition is highly recommended.
I've been using XFS on root, with certainty, since 9.0 (I remmber getting being bitten by a SuSE9.2 bug where the xfs driver on the installation disk was fault and couldn't read old partitions. I am 'fairly' sure that I've been using it since 7.3. I've never had any problems except when a disk-cable was going bad. Hardly XFS's fault. But I also use lilo. Grub doesn't have accessible documentation. lilo seems more reliable than grub for most purposes -- and grub, while it looks cool -- seems awfully complex for what it does. lilo has been good for dual and triple boot systems (Linux, Win98+Win2k), and dual mode booting on that Win98 partition (native & under VMWare). I've even used the BIOS re-ordering in lilo to allow booting from sda -- as well as the dynamically adjusting hidden/non-hidden partitions that I needed at one point for Win98 (this isn't recent, I'll mind you...). With a simple adjustment in lilo.conf, I could boot off a cloned removable hard disk -- and change the its boot params while it was still a 2ndary hard disk. Then on bootup, hit the BIOS, one-time boot switch (F12?) and boot from the removable instead of the fixed -- and the system would come up off the 2ndary, while calling it "hda" (the old fixed drive became hdb). It was trivial to figure out and it just worked! The same was not true for grub. It always "knew" better than to write to the 2ndary drive without referring to it by BIOS id 0x8[1-3], trying to configure the 2ndary drive to be "0x80" would have grub do its installation on the 1st disk -- not what I wanted. After multiple attempts, I went back and reinstalled lilo -- no problems. I think Grub was taking a higher-level view of the hard disks -- and wouldn't be so easily 'fooled' by a simple text-label change in its config files. I can see that being a benefit if the order changes and you *don't* want the boot order to change -- but in the opposite case, where I wanted the old behavior -- it did everything to protect me from what I needed to do. Maybe grub is expecting more file-driver functionality to be present when the OS isn't fully "awake"? I find it annoying to go from a working lilo+xfs, and now am told that because grub can't deal w/xfs, xfs isn't supported for booting from anymore. Why not continue to support lilo+xfs? It's just that grub -- is a much more complex beast and demands more from the drivers (and users) -- which is fine if one doesn't need to understand or tweak what's going on, whereas lilo being fairly primitive seems to have fewer failure points. Also, I get the _feeling_ (perhaps wrong), but that lilo is still used alot in the kernel development group. That might mean it gets tested more and might be good, at the very least, as a fall-back when grub gets too demanding... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.