[opensuse-factory] GRUB2 / FATE 308497
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksee5UACgkQLPWxlyuTD7LfzgCeNNBHRMuyP8scWJrOfSjFkXiV fZkAoJoT9lBFwPxlzRRoA5UFjKzDMhUu =i06N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/8 Jeff Mahoney <jeffm@suse.com>:
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? :)
Ubuntu are using GRUB2 already, I have a 2 disk box I can "safely" use for boot loader experiments. Sign me up! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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... thanks, greg k-h -- 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/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. It works great for the purposes it was intended, but I don't think it really works that well as a flexible option. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksegfwACgkQLPWxlyuTD7Jw4wCfdPvAN+dUYbo2nEnsfPz53Ml8 ooEAn397rRjnGshusUN21Le0x6nxBUYy =c/UE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/08/2009 12:26 PM, Greg KH wrote:
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.
I'd prefer not to need a /boot at all. On my workstation that means LVM. On my server that means LVM and RAID1. So, syslinux doesn't really provide all I need from a bootloader. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksfuI4ACgkQLPWxlyuTD7I/MQCeOO6DEIm79B9hc8tuXHXlkZF7 b+MAnRwvCP/fqPID4NwsTd49NWL9dZnb =d5e/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/8 Greg KH <gregkh@suse.de>:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2009-12-08 at 16:59 -0000, Rob OpenSuSE wrote:
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.
What about lilo? >:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkse6+4ACgkQtTMYHG2NR9WoeACfbQ5lGvCxb65zN6gd0RX13tlW a50An2TKJqVPRud0hfcbkcyhFgkG4T3l =g1rD -----END PGP SIGNATURE-----
2009/12/9 Per Jessen <per@computer.org>:
Carlos E. R. wrote:
What about lilo? >:-)
+1.
Serious? I used to love hacking around with lilo.conf(5) it was "exciting", GRUBs just too boring, as mistakes aren't fatal enough. How much support inquiries has the GRUB feature of *not* needing a map file for kernel & initrd blocks saved? Enthusiasts who meddle with things, really have appreciated GRUB features like TAB completion and editting of boot cmdlines (which actually has re-covered system few times for me to). -- 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 <per@computer.org>:
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
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, and welcome Grub's ability to recover on the fly from configuration mistakes, and to experiment without actually changing the installed configuration. -- " We have no government armed with power capable of contending with human passions unbridled by morality and religion." John Adams, 2nd US President Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- 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
2009/12/9 Per Jessen <per@computer.org>:
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.
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. Rob -- 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
On Wed, 09 Dec 2009 10:58:05 -0600 Larry Finger <Larry.Finger@lwfinger.net> 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. -- 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
2009/12/9 Stefan Seyfried <stefan.seyfried@googlemail.com>:
On Wed, 09 Dec 2009 10:58:05 -0600 Larry Finger <Larry.Finger@lwfinger.net> 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 <per@computer.org>:
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
Rob OpenSuSE wrote:
2009/12/9 Per Jessen <per@computer.org>:
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).
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%. Anyway, there is little need to argue grub vs lilo - lilo works very well, it doesn't have any shortcomings that I'm concerned about; my vote is +1. /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
2009/12/9 jdd <jdd@dodin.org>:
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 <per@computer.org>:
Rob OpenSuSE wrote:
2009/12/9 Per Jessen <per@computer.org>:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/09/2009 02:08 PM, Rob OpenSuSE wrote:
2009/12/9 jdd <jdd@dodin.org>:
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. All this is done remotely via serial console and using the grub runtime tool works perfectly for me.
2009/12/9 Per Jessen <per@computer.org>:
Rob OpenSuSE wrote:
2009/12/9 Per Jessen <per@computer.org>:
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.
The reiserfs issue is just one manifestation of a core design issue that makes lilo unsuitable for anything beyond simple file systems. It just keeps a block map. So, if that mapping changes either via a dynamic underlying device, defragmentation, or copy-on-write, then you can't boot anymore. Personally, I moved to grub years ago and haven't looked back. I bet it's back there filling the screen with LI LI LI LI LI LI again because some black magic changed underneath it. No thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksf92wACgkQLPWxlyuTD7J4ZACgh3jIOFwF8sDAur+39jtozXMu ubMAoJzLBELgYGZat61oZLz0pzdmydBZ =jLZn -----END PGP SIGNATURE----- -- 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 <jdd@dodin.org>:
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
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. /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/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
2009/12/10 Egbert Eich <eich@suse.de>:
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 -- 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 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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkshbHwACgkQtTMYHG2NR9WEtgCfcZjM0CBUj/Whh2zJXJHbs24a XJwAn0/dJci2a99s4Rxpk3pACAt3+RZJ =4L9w -----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/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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-12-10 at 16:48 -0500, Jeff Mahoney wrote:
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.
I believe that some people are still using the no longer supported lilo in oS because their setup is not supported by grub. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkshgd8ACgkQtTMYHG2NR9WUxACeKrhL9Fxy/RY2OSq5QR6MJCyK nxcAn3fSPThmMyA4qZ/BQrNmBSp0pZPS =Z2+o -----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/10 Jeff Mahoney <jeffm@suse.com>:
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. ;-) Have fun anyway, seife -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/12/11 Stefan Seyfried <stefan.seyfried@googlemail.com>:
2009/12/10 Jeff Mahoney <jeffm@suse.com>:
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
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.
With Installer warning when a possibly broken boot partition is chosen by the expert user.
Hmm, do we need to warn the _expert_ user?
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. /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
2009/12/11 Per Jessen <per@computer.org>:
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
Rob OpenSuSE wrote:
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.
Maybe we just need a two-step change into Expert mode: 1) Choose Simple or Expert mode 2) Are you sure you are an expert? Yes|No :-)
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.
But it does just work for people with more stable systems and also for experienced people with less stable ditto. Rob, that is not a useful argument _unless_ we assume that the majority of openSUSE users have unstable or often changing systems. I'm not convinced that's a reasonable assumption to make. In fact, I think most people have stable systems, because they need to work on or with them. /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
2009/12/11 Per Jessen <per@computer.org>:
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
Rob OpenSuSE wrote:
2009/12/11 Per Jessen <per@computer.org>:
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.
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 ... /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 08:50 AM, Per Jessen wrote:
Rob OpenSuSE wrote:
2009/12/11 Per Jessen <per@computer.org>:
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
Jeff Mahoney wrote:
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 sounds like a significant drawback, okay.
It can't handle a real graphical boot setup (AFAIK). We're trying to make openSUSE *more* user friendly, not less.
Yes, I agree - we just haven't decided which kind of user. Which is what Egbert Eich already mentioned.
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.
Yeah, I pretty much agree with too. However, back when we had SuSE Linux, one of the things that made it popular was that it was very flexible - it was virtually turn-key for the newcomer, and also helped the expert with the tedious stuff. Today, as an expert user, I more and more often feel left out in the rain, having to do more of the tedious stuff myself. Maybe that's the way to go, I'm not so sure. /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 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
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. -- 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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2009 04:26 AM, Per Jessen wrote:
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.
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. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksiaH4ACgkQLPWxlyuTD7Lp8wCfXrlsFWih5eushVdwNxsk4uJw N8QAnRXpWuWdzNgpDQvf7/MGP2oMiL+V =pxd1 -----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, 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. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksibvkACgkQLPWxlyuTD7JxeQCgkaD1IE5XuPEGuU1qgD3i1BYz HtQAniaXDF/B09M43H5mTezqflObsDvp =UYiP -----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 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
2009/12/11 Jeff Mahoney <jeffm@suse.com>:
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.
One would hope the btrfs does "housekeeping" like that when general I/O is relatively idle. Like RAID background I/O sync ups. Hopefully the proposed "online defragger" for ext4 will have some way (madvise()?) of minimising disruption to priority tasks (rather than be the new locate(1) to destroy "interactivity").. Anyway expert lilo users can disable such features by using a different filesystem for /boot stuff and not using btrfs except where the features suit. Anyway looking at the pro/cons it looks like GRUB2 stands as the most realistic possibility to fulfill the requirements, worth doing some testing. If it gets picked up by more distro's, then there'll likely be increasing pressure to support it. 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 04:02 AM, Rob OpenSuSE wrote:
2009/12/11 Stefan Seyfried <stefan.seyfried@googlemail.com>:
2009/12/10 Jeff Mahoney <jeffm@suse.com>:
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
Rob OpenSuSE wrote:
2009/12/9 Per Jessen <per@computer.org>:
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.
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.
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.
Maybe openSUSE isn't targetting the enthusiast community? Well, who knows what openSUSE is targetting these days, sigh. /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
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
jdd wrote:
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
Ah, I wasn't aware of that. Well, we rent a lot of servers in external/remote datacentres. Of course, they all boot with lilo. /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 Wed, 9 Dec 2009 01:14:36 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> 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
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 -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast (language,time,basesystem,ntp) -- 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
Jiri Srain write:
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
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. 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 ) Josef -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast (language,time,basesystem,ntp) -- 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
2009/12/9 Josef Reidinger <jreidinger@suse.cz>:
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.
As a matter of interest, why does menu.lst file get parsed? I let install create it. Have found an entry using the symlinks work fine, and doesn't need updates to menu.lst on kernel updates. Honestly, most of the reaons I have to go into these files, are to fix mistakes made by the tools software. Things like offering boot option into non-active Windows Recovery partitions on other disk and just cannot be safely booted. On forum there's few users who maintain their own /boot seperate from releases precisely because it is generally less trouble than the auto stuff. May be there's good reason to inspect the file, and modify it? At moment the benefit is not clear to me.? One of the real advantages GRUB brought in 0.97 was wide compatability across distro's and most of the time, solving boot erorrs after an install, was very doable with nothing more than text editor, and occasinally doing a GRUB install by hand. Those file completion options and edit feature of boot line, are widely used by community support. Time I used Live CD and did GRUB re-install using YaST to test it, wasn't really any easier, or less skilled, because I had to understand exactly what it was doing, to know when a version was made that would work. The netconfig stuff, seems to substitute a well understood file, that can partly be dynamically enhanced, but manage to do it in a baffling enough way, that most sysadmins probably just give up and go to static (which is the state once even a small modification is made). Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, 08 Dec 2009 11:15:17 -0500 Jeff Mahoney <jeffm@suse.com> wrote:
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.
Did anyone try Das U-Boot on an x86 PC? It is at least reasonably easy to port Linux drivers to it on embedded systems, so that might make it easier to get new filesystems supported. I always wanted to try it on a PC but I'm still pretty busy getting all my boards into upstream U-Boot ;) -- 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
I've just copied the Fedora grub2 package and made some changes for it and put it into my obs project home:a_jaeger:branches:openSUSE:Factory as package grub2. It can be installed in parallel to grub - and once you have installed it, you have to create the grub2.cfg file yourself - I did this via: grub2-mkconfig > /etc/grub2.cfg That one did not boot, so I had to manually change the file to use "rw" (remove the ro from /etc/grub.d/10_linux). I'll patch the package now. Also graphical boot via bootsplash did not work for me, no idea what to change for that. I added my usual cmdline options to /etc/default/grub (GRUB_CMDLINE_LINUX) Hope this is a starting point for others to evaluate grub2 further. If you have any patches, feel free to send them to me... Use at your own risk ;) 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
2009/12/8 Jeff Mahoney <jeffm@suse.com>:
The good news is that GRUB2 lifts a whole lot of restrictions. <snip> 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.
Have paid some attention since your message, to GRUB2 as used in Kubuntu, that I was installing on a desktop alongside oS-11.2 for comparative reasons. This might not be a relevant issue, but just in case it matters and helps I'll report it here. Chainloading from oS GRUB "legacy" into Ku's GRUB2 and then booting oS-11.2's kernel did "work" but resulted in only 1 core being used, with oS-11.2 really crawling compared to usual (worse than running single cpu). oS-11.2 - /boot/grub/menu.list entry : # # Rob : 2009/12/10 : Ubuntu 9.10 Entry # title Kubuntu 9.10 - 2.6.31-16-generic kernel (hd0,11)/vmlinuz-2.6.31-16-generic root=/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034520-part13 splash=silent showopts vga=0x31a initrd (hd0,11)/initrd-2.6.31-16-generic title Kubuntu GRUB2 rootnoverify (hd0,11) chainloader +1 Ku-9.10's - /boot/grub/grub.cfg menuentry "Desktop -- openSUSE 11.2 - 2.6.31.5-0.1 (on /dev/sda10)" { insmod ext2 set root=(hd0,1) search --no-floppy --fs-uuid --set 92d04e50-24f0-4dda-a597-b46297002d65 linux /vmlinuz-2.6.31.5-0.1-desktop root=/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034520-part10 resume=/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034520-part6 splash=silent quiet showopts vga=0x31a initrd /initrd-2.6.31.5-0.1-desktop } -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (16)
-
Andreas Jaeger -
Carlos E. R. -
Carlos E. R. -
Egbert Eich -
Felix Miata -
Greg KH -
jdd -
Jeff Mahoney -
Jiri Srain -
Joachim Schrod -
Josef Reidinger -
Larry Finger -
Per Jessen -
Rob OpenSuSE -
Robert Kaiser -
Stefan Seyfried