On Tue, Dec 08, 2009 at 11:42:36AM -0500, Jeff Mahoney wrote:

On 12/08/2009 11:24 AM, Greg KH wrote:

...

On Tue, Dec 08, 2009 at 11:15:17AM -0500, Jeff Mahoney wrote:

...

Hi everyone -

Occasionally I take a break from kernel hacking. Recently, I was working on improving the reiserfs support in grub so that it doesn't take forever to load when there is a journal with outstanding transactions that need to be replayed.

The thing is that the grub 0.97 code is truly awful. Every file system implementation has to implement strangely chosen primitives and, outside of the code itself, has 32k in memory which it has to manage itself and not exceed. This is the crux of the reiserfs /boot performance issue in bnc#538795.

On top of that, the upstream grub developers refuse to accept fixes or features against 0.97, forcing distributors to carry patches around forever.

The good news is that GRUB2 lifts a whole lot of restrictions. It's modular in design, has a cleaner implementation, and has native support for more file systems. It supports LVM and MD RAID volumes. It supports DMRAID volumes (though I'm not sure how well here). The upstream development community is interested in maintaining it.

The bad news is that it's a boot loader. There may be bugs lurking in there. That are tough to track down and leave you with an unbootable system.

So who wants to help test? :)

What about using syslinux instead? That's what some distros are thinking of moving to instead of GRUB2 in the near future...

syslinux doesn't have anything remotely close to the feature set that GRUB2 has. AFAIK, it doesn't support anything beyond FAT, isofs, and ext[23] or support RAID or LVM.

Add btrfs support, and that's all you really need from a bootloader.

It works great for the purposes it was intended, but I don't think it really works that well as a flexible option.

grub2 might be considered "too" flexible :) have fun, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/12/8 Greg KH :

On Tue, Dec 08, 2009 at 11:15:17AM -0500, Jeff Mahoney wrote:

...

So who wants to help test? :)

What about using syslinux instead?  That's what some distros are thinking of moving to instead of GRUB2 in the near future...

The Syslinux Project covers lightweight bootloaders for MS-DOS FAT filesystems (SYSLINUX), network booting (PXELINUX), bootable "El Torito" CD-ROMs (ISOLINUX), and Linux ext2/ext3 filesystems (EXTLINUX). The project also includes MEMDISK, a tool to boot legacy operating systems (such as DOS) from nontraditional media; it is usually used in conjunction with PXELINUX and ISOLINUX. Looks like using syslinux drops support for reiserfs, xfs, ext4 at moment. To me, I'm happy using a /boot partition that's ext2, nevermind ext3. Fedora configures a small /boot partition, going that route, and having YaST Boot loader do mount /boot or mount -oremount,rw /boot as appropriate would reduce complexity. Something that concerned me, about the Unbuntu GRUB2 was it using config files in /etc, and then a binary file in /boot. That seems to make it harder to consolidate /boot amongst several installations of same & different distro's, as the Master /etc *must* be present. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. wrote:

What about lilo? >:-)

+1. -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE wrote:

2009/12/9 Per Jessen :

...

Carlos E. R. wrote:

...

What about lilo?  >:-)

+1.

Serious?

Completely. I only use lilo, I have never had reason nor inclination to switch to grub. /Per -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Felix Miata wrote:

On 2009/12/09 10:00 (GMT+0100) Per Jessen composed:

...

Rob OpenSuSE wrote:

...

...

Per Jessen wrote:

...

...

...

Carlos E. R. wrote:

...

...

...

...

What about lilo? Â >:-)

...

...

...

+1.

...

...

Serious?

...

Completely. I only use lilo, I have never had reason nor inclination to switch to grub.

Must be nice to always make perfect edits to lilo.conf and always remember to run it before rebooting. I'm not that perfect, [snip]

Nor am I, but I rarely have reason to edit any lilo.conf - because lilo was deprecated in yast, I have to do one or two things manually during installation, but after that I really don't touch it. Stefan Seyfried summed it up very well: lilo just works, period. /Per -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 12/09/2009 10:44 AM, Rob OpenSuSE wrote:

If you run multiple distro-releases which you boot from a master spot, then not having the lilo map files is a big advantage. Don't think lilo(8) reintroduction is feasible for enthusiast community, they would probably just de-camp to a more comfy boot loader, rather than lose the features and convenience GRUB has provided.

I'm not going back to lilo! Maybe it was OK when my system only had one kernel and the penalty for making a new kernel without updating lilo was so great that I didn't forget more than twice. Now my system boots 3 different openSUSE distributions with multiple kernels in each, and I generate a new kernel on a daily basis. Keeping lilo current would be a big hassle. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/12/9 Stefan Seyfried :

On Wed, 09 Dec 2009 10:58:05 -0600 Larry Finger wrote:

...

Now my system boots 3 different openSUSE distributions with multiple kernels in each, and I generate a new kernel on a daily basis. Keeping lilo current would be a big hassle.

No. You'd just chain two bootloaders together: one in the MBR that selects the distro to boot and the second in the root partition that then selects the kernel from the distribution. Ok, you'd need to add the newly compiled kernel to the config, but that's true for Grub, too.

And if you do it the best way, you don't have to change anything at all. New kernel no problem, and only "tried and trusted" boot code *NOT* new installs gets run. ( that's just reminded me to make sure there's an option not to install any boot code in oS-11.3 after the time wasting required to check it all in 11.2 ) There's better things to do in life, than moving through multiple boot loaders and have in effect nested menu's of options. Then when you have a boot issue, where do you start? 2009/12/9 Per Jessen :

Rob OpenSuSE wrote:

...

If you run multiple distro-releases which you boot from a master spot, then not having the lilo map files is a big advantage.

I only run one distro - having multiple distros running in production is just hassle.

Well if you have have a production server, with a backed up copy of /boot directory, then you you'll have much more chance of booting from it, when you need to than with lilo(8). GRUB is reliable to in a sane configuration, and far more boring when you want to change something (and if it's a server boring is good). Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/12/9 jdd :

and on a server you can't get a hand on or with no screen, the Grub boot editor is not that usefull...

But it does no harm. So actually the point is irrelevant, and if you need console access for some reason, GRUB's runtime flexibility helps. 2009/12/9 Per Jessen :

Rob OpenSuSE wrote:

...

2009/12/9 Per Jessen :

...

Rob OpenSuSE wrote:

I don't know anything about grub, but the chance of me restoring a /boot directory and successfully booting the system with lilo is 100%.

Out of those who have used both, not many go back to lilo(8). Remember there's some gotcha's concerning reiserfs with lilo to, have to avoid tail packing. So it's not really a solution to perverse ppl deciding to have /boot on reiserfs. IIRC that was one of the reasons, GRUB replaced lilo in the distro for most configurations in first place. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, Dec 09, 2009 at 02:15:56PM -0500, Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 12/09/2009 02:08 PM, Rob OpenSuSE wrote:

...

2009/12/9 jdd :

...

and on a server you can't get a hand on or with no screen, the Grub boot editor is not that usefull...

But it does no harm. So actually the point is irrelevant, and if you need console access for some reason, GRUB's runtime flexibility helps.

Exactly. My development nodes are rack mounted in my basement. I'm sure you can imagine that, as a kernel developer, I reboot rather often and things don't always go smoothly during the boot process.

I have 6 releases of SLES and openSUSE on each node. Each instance has its own /boot (in the root fs) and shares a /machboot grub instance which chainloads grub from the root fs of the install I'm booting.

Yeah, similar here. I don't want to miss the flexibility of grub when installing multiple systems on test machines either. In particular since I frequently need to install test instances and want to do this with as little manual intervention as possible. Having LVM support and not requiring a separate /boot would bring me even closer to this goal. So grub2 seems to be an option worth exploring. I'm not sure why syslinux has even brought up here. In the entire thread I did not see a real argument for it except the killall one: 'other distros consider using it' - someone else is making or has made or is making the decision for us. It would be nice if this discussion would center around what features we need for openSUSE (from servers to whatever ultraportable devices) and what bootloader would be the most likely one to deliver them instead of everyone advocating her/his pet bootloader. Moreover this might give us the chance to finally go and simplify the maze of a the bootloader configuration we currently have at openSUSE.

All this is done remotely via serial console and using the grub runtime tool works perfectly for me.

Lucky guy. Almost none of my test machines has serial still. Cheers, Egbert. -- Egbert Eich (Res. & Dev.) SUSE LINUX Products GmbH X Window System Development Tel: +49 911-740 53 0 http://www.suse.de ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2009 06:32 AM, Per Jessen wrote:

Egbert Eich wrote:

...

It would be nice if this discussion would center around what features we need for openSUSE (from servers to whatever ultraportable devices) and what bootloader would be the most likely one to deliver them instead of everyone advocating her/his pet bootloader.

+1.

...

...

All this is done remotely via serial console and using the grub runtime tool works perfectly for me.

Lucky guy. Almost none of my test machines has serial still.

Unless we're talking IPMI Serial-over-LAN, a serial connection also only works when you're fairly close to the box.

Or if you have a terminal server. They're pretty cheap on ebay for small ones. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkshF2UACgkQLPWxlyuTD7ICFgCePwRr3ScINvgBe2IjgjLTeqMh U58An0JQZlZ0a9ftCCTWX7u+kBAYMJM8 =dyKn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE wrote:

Desirable Features in replacement Boot programs

Add support for btrfs boot partitions to that, as it might become a choice for default or at least widespread file system within the next few openSUSE iterations. Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2009 04:47 PM, Carlos E. R. wrote:

On Thursday, 2009-12-10 at 13:31 -0000, Rob OpenSuSE wrote:

...

2009/12/10 Egbert Eich <>:

...

...

It would be nice if this discussion would center around what features we need for openSUSE (from servers to whatever ultraportable devices) and what bootloader would be the most likely one to deliver them instead of everyone advocating her/his pet bootloader.

...

So this is what I can think of at moment, for a structure, there must be other things that are problems for GRUB as we use it.

...

GRUB 0.97 isn't offering :

...

* EFI support

...

* Reliable ReiserFS boot partition

...

* LVM support

...

* upstream support (no central collection of fixes)

...

Desirable Features in replacement Boot programs

...

* Text Config file, easy for user to hack & YaST to parse for config options

...

* Run-time flexibility - try out test kernels, boot from newly available partitions NO map files!

...

* Boot from all media HDD, USB, CD/DVD

...

* Eye Candy for non-technical users (boot magic (came with COL) allowed mouse selection and was "loved")

...

* Be direct & efficient if no frills required

...

* Low maintenance, good upstream support

My idea when I suggested lilo was that, perhaps, there is no current bootloader that supports all situations. Perhaps we need to have more than one, and lilo is a posibility.

And, perhaps, "lilo" can be automatically run on halt/reboot if a modification is detected, to regenerate the map file.

If there is a situation where the supported boot loader doesn't work, it should be fixed. Lilo is a workaround. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkshbLkACgkQLPWxlyuTD7LRZQCfTRGGJA6RVprDIXCww/lwFezA eLQAnjbZuVPEhBmkY3tRntodFYhWtMmF =EaYe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. wrote:

On Thursday, 2009-12-10 at 16:48 -0500, Jeff Mahoney wrote:

...

If there is a situation where the supported boot loader doesn't work, it should be fixed. Lilo is a workaround.

I believe that some people are still using the no longer supported lilo in oS because their setup is not supported by grub.

For the record, I'm one of them. GRUB's install doesn't result in a bootable disk on my main workstation. The problem might be in the IPL code already, no error message from stage 1 or 1.5 appears. (And also FTR, I vastly prefer grub to lilo.) I'd test GRUB2, but I don't have enough time to set up a spare system with factory for that. I'd have to do it with 11.1, if that's possible. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/12/11 Stefan Seyfried :

2009/12/10 Jeff Mahoney :

...

If there is a situation where the supported boot loader doesn't work, it should be fixed. Lilo is a workaround.

only one linux partition, which is XFS, on a ThinkPad.

According to past discussion on this list, this is a "no no"! Jiri Strain - "Re: [opensuse-factory] XFS Boot Problem" http://lists.opensuse.org/opensuse-factory/2008-12/msg00009.html http://lists.opensuse.org/opensuse-factory/2008-12/msg00030.html Unfortunately due to the poor organisation of openSUSE.org, the paper written explaining boot configurations that work, I cannot find though I know it was included in an answer in the thread above. Are there any good reasons why there cannot be supported boot configurations : 1) Normal partitions or RAID1, / ext3/ext4 with /boot sub-directory 2) Normal partitons or RAID1, / "exotic" file system, with /boot small ext2/ext3/ext4 partition 3) ReiserFS, currently somewhat broken; fix desireable 4) LVM, currently "exotic"; direct support desirable 5) btrfs, currently "exotic"; direct support desirable With Installer warning when a possibly broken boot partition is chosen by the expert user. What are the reasons not to insist on a small /boot partition when using things like LVM (like Fedora install makes by default) or a filesystem that won't be reliably booted? To me it looks like in trying to be very flexible about it, the end-users end up with either non-boot or performance problems, described by Jeff when starting this thread. Putting together proposed Boot loader solutions in a summary GRUB 0.97 - no project * "tried & tested" limitations known * widely deployed x86 "standard", Linux, BSD & Solaris syslinux - http://syslinux.zytor.com/wiki/index.php/The_Syslinux_Project * few choices of filesystem support lilo - http://freshmeat.net/projects/lilo/ * static - uses map files * confused end users even when it was most popular boot method - poor diagnostics on failure - poor recovery on failure - less friendly config file than GRUB 0.97 Das U Boot - http://u-boot.sourceforge.net/ * small " typically U-Boot is stored in relatively small NOR flash memory * aimed at embedded, lacking "friendly" features for standard PCs GRUB2 * doubts about configuration * most likely to gain btrfs support, most filesystem choices today Summary page in Wiki - http://en.wikipedia.org/wiki/Comparison_of_boot_loaders To me the strongest candidate to meet most of the requirements is GRUB2. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/12/11 Per Jessen :

Rob OpenSuSE wrote:

...

Are there any good reasons why there cannot be supported boot configurations :

1) Normal partitions or RAID1, /  ext3/ext4 with /boot sub-directory

Shouldn't be a problem.

...

2) Normal partitons or RAID1, / "exotic" file system, with /boot small ext2/ext3/ext4 partition

Ditto.

...

3) ReiserFS, currently somewhat broken; fix desireable 4) LVM, currently "exotic"; direct support desirable 5) btrfs, currently "exotic"; direct support desirable

I _think_ they all work with lilo, please correct me.

lilo's weakness becomes a strength in these cases due to simplicity of blocklists. But remembering how hard it was to support ppl on mail list & forum in past, I'm afraid lilo(8) just is going to have significant support costs for the masses. When GRUB was introduced, the typical users really did like it and prefer it.

...

With Installer warning when a possibly broken boot partition is chosen by the expert user.

Hmm, do we need to warn the _expert_ user?

It would seem so, from reading this Mailing list. Ways to get totally reliable configurations are ignored, and this results in trips to Bugzilla. If you don't tell the end-user they are doing something unreliable during an installation (like is done if you pre-mkfs system partitions and do not allow format); they very likely in their expertise expect their flakey configuration to simply work and get upset when it doesn't.

...

lilo - http://freshmeat.net/projects/lilo/    * static - uses map files    * confused end users even when it was most popular boot method          - poor diagnostics on failure          - poor recovery on failure          - less friendly config file than GRUB 0.97

Rob, your bias is showing :-). Let me add some positive points:

* just works, hardly ever fails. * easy text-file config * tried and tested.

No, lilo(8) never "just worked" for people with less stable systems. Remembering the effort needed to explain things like booting windows with lilo, using Bios Disk codes for example, I do think it is fair to say GRUB is easier. There were good reasons, why the distro moved to GRUB "legacy", and it was a popular decision, and regarded as a great improvement. Inflicting lilo(8) on end users again, will cause a "revolt". I actually liked lilo(8) and regarded myself as a relative expert on it, I was dubious of GRUB's requirement for boot time filesystem support, but it did not take long for GRUB's advantages to become apparent. I also do not miss explaining lilo's error codes to ppl, or why they cannot boot, because they forgot to make map files. There really is a reason, why the BSD's and Solaris chose GRUB over their own variant of lilo. lilo IMO makes a good fall back boot loader, but when things go wrong because of user errors, or hardware errors the diagnostics are awful, and that increases support costs. As lilo's last release is 2007, I would have doubts about support for the newer boot methods like EFI http://en.wikipedia.org/wiki/Extensible_Firmware_Interface Also according to the links I referenced, lilo's architecture support is narrow, which might not seem important today, but could be if say ARM netbooks take off in next few years. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/12/11 Per Jessen :

...

No, lilo(8) never "just worked" for people with less stable systems.

But it does just work for people with more stable systems and also for experienced people with less stable ditto.

Please, rather than repeat the same "just works" despite folk explaining why it does not for them, test lilo's popularity by advocating it become the default again with a Fate entry "Real users do not need GRUB's features and GRUB-0.97 is an unmaintainable mess!" At the moment Jeff's item is only on +10, not too hard to beat if using lilo(8) again truly is popular with end users. lilo is a known quantity, so no investigation is really needed, right? As pointed out, lilo(8) does not support reiserfs tail packing option. The diagnostics are also very basic. Usage is more error prone, and the consequences of errors are worse than with GRUB. The drawbacks mentioned with GRUB2 might be overcome in future, perhaps for example a config file generator can short cut the "nasty" scripts and allow re-use of current YaST code (speculation). Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2009 08:50 AM, Per Jessen wrote:

Rob OpenSuSE wrote:

...

2009/12/11 Per Jessen :

...

...

No, lilo(8) never "just worked" for people with less stable systems.

But it does just work for people with more stable systems and also for experienced people with less stable ditto.

Please, rather than repeat the same "just works" despite folk explaining why it does not for them, test lilo's popularity by advocating it become the default again with a Fate entry "Real users do not need GRUB's features and GRUB-0.97 is an unmaintainable mess!"

Sure - https://features.opensuse.org/308520

...

As pointed out, lilo(8) does not support reiserfs tail packing option.

Lack of that will probably see people walking away in droves, yeah.

btrfs supports tail packing as well.

...

The drawbacks mentioned with GRUB2 might be overcome in future, perhaps for example a config file generator can short cut the "nasty" scripts and allow re-use of current YaST code (speculation).

Why wait - the drawbacks of GRUB2 have already been overcome - it's called lilo ...

You're welcome to use it, but it's not a serious alternative. It is not flexible. It can't handle dynamic file systems. It can't handle a real graphical boot setup (AFAIK). We're trying to make openSUSE *more* user friendly, not less. I understand that you're an expert user, but that just means that you should have access to the expert tools you want to work with - not design the system around them. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksiansACgkQLPWxlyuTD7KjnwCfX1xRkyjhpDAPH5cxTBtavfWn PpsAoJvupEAa48EQDSObSFOQD+NfHDi9 =I7Pk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-12-11 at 11:15 -0000, Rob OpenSuSE wrote:

Please, rather than repeat the same "just works" despite folk explaining why it does not for them, test lilo's popularity by advocating it become the default again with a Fate entry "Real users do not need GRUB's features and GRUB-0.97 is an unmaintainable mess!"

I did not propose lilo to become the default. I proposed to have lilo as an alternative for those cases where grub does not currently work or work well.

As pointed out, lilo(8) does not support reiserfs tail packing option. The diagnostics are also very basic.

grub error 17 doesn't say much, either. Many people ask in the lists without looking up the error number in info first. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksiwZEACgkQtTMYHG2NR9UO1wCeJ+hh4kLaNzFVHRZ8Np8WvXm/ vY0An1ji+pA/RVJK/Ep4pxmQbauzaTn6 =/4lx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2009 05:21 PM, Per Jessen wrote:

Carlos E. R. wrote:

...

On Friday, 2009-12-11 at 11:15 -0000, Rob OpenSuSE wrote:

...

Please, rather than repeat the same "just works" despite folk explaining why it does not for them, test lilo's popularity by advocating it become the default again with a Fate entry "Real users do not need GRUB's features and GRUB-0.97 is an unmaintainable mess!"

I did not propose lilo to become the default. I proposed to have lilo as an alternative for those cases where grub does not currently work or work well.

For those openSUSE members who have not yet discovered the voting in openFATE, please review the well-obscured scoring&voting mechanism in the upper right hand corner of the website.

I have no idea how important this weighting is, but Jeff Mahoney seemed to think it had some importance.

It's an easy way to see how people feel about a feature that avoids a lot of "no way" and "me too" comments in the discussion. So why shouldn't I use it? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksiyaQACgkQLPWxlyuTD7KBmgCfUYW6Q5N8W7zqqoHTI5IcW8BX g9EAoKQz1pwaH57eA126ii5RT0PyBWmj =Ruy7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Jeff Mahoney wrote:

...

...

3) ReiserFS, currently somewhat broken; fix desireable 4) LVM, currently "exotic"; direct support desirable 5) btrfs, currently "exotic"; direct support desirable

I _think_ they all work with lilo, please correct me.

btrfs is copy-on-write, which naturally introduces lots of fragmentation. As a way to combat this, it has an online repacker. Even if your system is able to boot immediately, that block map can become inaccurate at seemingly random times.

I'm curious - is there no way of selectively disabling that? /Per -- Per Jessen, Zürich (0.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2009 11:10 AM, Jeff Mahoney wrote:

On 12/11/2009 11:10 AM, Per Jessen wrote:

...

Jeff Mahoney wrote:

...

...

...

...

3) ReiserFS, currently somewhat broken; fix desireable 4) LVM, currently "exotic"; direct support desirable 5) btrfs, currently "exotic"; direct support desirable

I _think_ they all work with lilo, please correct me.

btrfs is copy-on-write, which naturally introduces lots of fragmentation. As a way to combat this, it has an online repacker. Even if your system is able to boot immediately, that block map can become inaccurate at seemingly random times.

...

I'm curious - is there no way of selectively disabling that?

I'm not sure. I don't think you'd _want_ to.

Actually, that's not true. You wouldn't want it kicking in while running an i/o intensive workload. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksib0cACgkQLPWxlyuTD7ItxACdFL3xNrlTX18OBDcvY+0exu6U 5N4AoJR79ruAw2UlG9pvVA6mC/GTGoIU =Y9Uv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2009 04:02 AM, Rob OpenSuSE wrote:

2009/12/11 Stefan Seyfried :

...

2009/12/10 Jeff Mahoney :

...

If there is a situation where the supported boot loader doesn't work, it should be fixed. Lilo is a workaround.

only one linux partition, which is XFS, on a ThinkPad.

According to past discussion on this list, this is a "no no"!

Jiri Strain - "Re: [opensuse-factory] XFS Boot Problem" http://lists.opensuse.org/opensuse-factory/2008-12/msg00009.html http://lists.opensuse.org/opensuse-factory/2008-12/msg00030.html

Unfortunately due to the poor organisation of openSUSE.org, the paper written explaining boot configurations that work, I cannot find though I know it was included in an answer in the thread above.

Are there any good reasons why there cannot be supported boot configurations :

1) Normal partitions or RAID1, / ext3/ext4 with /boot sub-directory 2) Normal partitons or RAID1, / "exotic" file system, with /boot small ext2/ext3/ext4 partition 3) ReiserFS, currently somewhat broken; fix desireable 4) LVM, currently "exotic"; direct support desirable 5) btrfs, currently "exotic"; direct support desirable

With Installer warning when a possibly broken boot partition is chosen by the expert user.

What are the reasons not to insist on a small /boot partition when using things like LVM (like Fedora install makes by default) or a filesystem that won't be reliably booted?

To me it looks like in trying to be very flexible about it, the end-users end up with either non-boot or performance problems, described by Jeff when starting this thread.

I realize that I'm probably not a typical user with respect to how many kernels I have installed at once, but I don't like having to have to correctly size a /boot partition for all eventualities. Running out of space in /boot is also a source for upgrade problems.

syslinux - http://syslinux.zytor.com/wiki/index.php/The_Syslinux_Project * few choices of filesystem support

Though Greg did mention that btrfs support is forthcoming.

GRUB2 * doubts about configuration * most likely to gain btrfs support, most filesystem choices today

There were patches posted to the btrfs list a while ago for this, so it's pretty definite. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksiaBoACgkQLPWxlyuTD7IhXACfSRpSe6jq3OitWV1SiJjsgmP3 j2IAn26aaiE1acgdrHnqDK0dDC+VjtDs =AuWp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 09/12/2009 17:36, Per Jessen a écrit : and on a server you can't get a hand on or with no screen, the Grub boot editor is not that usefull... jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, 9 Dec 2009 01:14:36 +0100 (CET) "Carlos E. R." wrote:

...

Something that concerned me, about the Unbuntu GRUB2 was it using config files in /etc, and then a binary file in /boot. That seems to make it harder to consolidate /boot amongst several installations of same & different distro's, as the Master /etc *must* be present.

What about lilo? >:-)

Come on, get serious! Lilo just works, so there is really no point in using it. It would spoil all the fun! -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Dne úterý 08 Prosinec 2009 17:31:51 Josef Reidinger napsal(a):

Jeff Mahoney write:

...

Hi everyone -

Occasionally I take a break from kernel hacking. Recently, I was working on improving the reiserfs support in grub so that it doesn't take forever to load when there is a journal with outstanding transactions that need to be replayed.

The thing is that the grub 0.97 code is truly awful. Every file system implementation has to implement strangely chosen primitives and, outside of the code itself, has 32k in memory which it has to manage itself and not exceed. This is the crux of the reiserfs /boot performance issue in bnc#538795.

On top of that, the upstream grub developers refuse to accept fixes or features against 0.97, forcing distributors to carry patches around forever.

The good news is that GRUB2 lifts a whole lot of restrictions. It's modular in design, has a cleaner implementation, and has native support for more file systems. It supports LVM and MD RAID volumes. It supports DMRAID volumes (though I'm not sure how well here). The upstream development community is interested in maintaining it.

The bad news is that it's a boot loader. There may be bugs lurking in there. That are tough to track down and leave you with an unbootable system.

So who wants to help test? :)

-Jeff

Hi, I looked at grub2 some time ago. I think that its main problem is incredible magic configuration. Part of configuration is autodetected and part is written from simplified configuration file. Problem is that it doesn't support many case which we handle now (handle by perl-Bootloader and in the yast). It decreased possibility of boot setup (of course you can hack generated config file but it is not possible to read it automatic). Also as long as some configuration tweaks must be done via hacking scripts, it is not possible to parse it by yast. So if you use grub2, then you must configurate it on your own. (when I try Ubuntu with grub2 I found, that ubuntu does allow user almost none options to setup on boot) Josef

The (autogenerated) configuration, as used e.g. in Ubuntu, is from my POV really too much magic and too little flexibility. On the other hand, it should not prevent you from writing menu.lst (or grub.conf in the Ubuntu file naming) manually and so install the Stage1 part. menu.lst looks semantically very similar to Grub1, OTOH the syntax is different. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

I disagree. Its semantic is much richer. It support probing, searching and testing during boot. It can use variables, conditionals, loops and functions ( grub2 manual say itself, that it is similar to bash script ). I think that no one expect, that perl-Bootloader is can parse that configuration file (if it does correct it is halting problem). What is possible to do is parsing /etc/grub/default which is really simple.

I think grub2 needs a different way: * create additional scripts for /etc/grub.d Run grub-mkconfig at the end to create the grub.cfg file. So, perl-Bootloader would not be needed to touch grub.cfg at all. But I'm not the expert here - I just suggest to look out of the box for new ways of doing.

BTW I cannot find command in grub to load 64-bit kernel, I see only 16-bit and 32-bit one ( http://grub.enbug.org/CommandList )

You don't do this with grub right now either, do you? The same works for me with my grub2 package, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126