Weekly Edition
Return to the Development page
| |||||||||||||||||||
GRUB 2.00 released
Hello, all
I'm proud to announce the release of GNU GRUB version 2.00.
Since this version has a round number it has been paid special attention
to, and hopefully, represents higher quality.
This is the first time we include an official theme (starfield).
This version also includes EHCI driver.
Support for using GRUB as firmware on Yeeloong was added in GRUB 1.99,
and for 2.00 this support has been extended to Fuloong2F as well.
This is also the first time we release itanium and SGI mips port. Later
is experimental due to problems encountered with its firmware.
The release file is bigger than it should be because of autogeneration
issues. Other than the size these issues have no impact but their fixing
is scheduled for next release.
GRUB, also known as the GRand Unified Bootloader, is a modular, portable
bootloader that supports a number of platforms, including standard
BIOS-based PCs, EFI-based x86 (32-bit and 64-bit) and itanium systems,
IEEE-1275 platforms (such as the OLPC and some PowerPC/Sparc64
hardware), coreboot, the free (as in freedom) pre-boot initialization
framework, Yeeloong (laptop) and Fuloong2F (mini-box), free (as in
freedom) Loongson-2F-based (MIPS compliant CPU) systems, big-endian mips
ARCS systems (SGI), as well as bare i386 and mips (either endian) qemu.
Other major improvements include (extract from NEWS file):
* Appearence:
* Official theme for gfxmenu (starfield)
* Menu is organised with submenus.
* Better default video mode selection using EDID.
* New platforms:
* Itanium port.
* Fuloong2F support (including GRUB as firmware)
* Fuloong2E support (except GRUB as firmware)
* ARCS (SGI machines) port.
* qemu -M mips port.
* grub-mount to mount filesystems using GRUB FS drivers and FUSE.
* Changed security default so entries are locked by default if any
superuser is
defined.
* New drivers:
* EHCI.
* AHCI.
* ESCC serial.
* IEEE1275 serial.
* EFI serial.
* Network stack for BIOS, IEEE1275, EMU and EFI, including TFTP, HTTP
and DNS.
* VBE on coreboot support.
* New filesystem, filters and disks formats:
* DVH partition map.
* Plan9 partition map.
* Big-endian mdraid.
* Big-endian cpio.
* ODC and NEWC cpio.
* ExFAT.
* Minix3fs.
* Big-endian minixfs.
* RomFS.
* Squash4.
* Support non-512B disk blocks.
* LUKS and GELI support.
* LDM read support (no install yet).
* LZOP.
* Improved filesystem and disks formats support:
* HFS+ label support.
* Improved reiserfs support.
* multidevice, mirrored and raidz(2,3) ZFS support.
* RAID LVM (internal RAIDing) support.
* ZFS crypto support.
* ZLE and GZIP on ZFS support.
* Support ZFS up to 33.
* HFS string is now treated like mac-roman and not UTF-8
* HFS mtime support.
* Improved AFFS and SFS support.
* LZO-compressed btrfs support.
* cpio and tar symlinks support.
* Better FS detection to reduce false positives.
* New boot protocols:
* Ability to load another coreboot payload when on coreboot.
* Plan9.
* Freedos.
* Ntldr/bootmgr (to load Windows bootloader).
* chainloader --bpb support to patch FAT or NTFS BPB in memory to correct
wrong partition offset.
* PXE chainloading support.
* Darwin 11 (Mac OS X Lion) protocol support.
* Boot protocol improvements:
* Multiple initrd support.
* Basic illumos and xnu autoconfig.
* Testing and debugging:
* New grub-fstest commands: cat, zfsinfo, testload xnu_uuid
* grub-fstest recursive directory compare for quickly checking that
a directory is read correctly.
* Backtace on crash (if gdb module is loaded, x86 only)
* Disk cache statistics gathering.
* GDB stub and GDB support script.
* "make check" and "make bootcheck" expanded to almost all platforms
(except i386-ieee1275, mips-arc, sparc64-ieee1275, ia64-efi and emu)
* New `time' command.
* Performance:
* Lazy scanning to avoid accessing devices which aren't really used.
This avoids boot delay due to slow device scanning.
* Use CPU cache when accessing video memory.
* Search hints to first try the most likely device when searching for a
device with given UUID. This avoids slow scanning in most cases.
* Internationalisation:
* Updated to Unicode 6.0.
* $"..." syntax for translation in grub scripting language. This
allows easy
translation of grub.cfg at runtime.
* Translations to many languages included in official distribution.
* Scripting:
* $grub_cpu and $grub_platform variables for conditioning grub.cfg on
platform
at runtime.
* $feature_* variables to condition scripts on available features.
* Use of ids to identify menu entries.
* all_video module which is empty but depends on all video modules thus
allowing easy loading of all of them.
* Installation:
* grub-mknetdir script for easy creation of netbootable GRUB directory.
* Itanium and mips support in grub-mkrescue.
* grub-install support for all platforms except emu.
* PreP partition install support.
* No files conflict between flavours (except grub-mkrescue for ppc). This
allows easy install of GRUB for several platforms.
* grub-mkstandalone script for easy creating of image including all
modules
for platforms with generous limit on image size.
* program-transform-name now functions according to usual conventions.
Use --grubdir and --bootdir to get old behaviour.
* ADLER32 and CRC64 support (for XZ and hashsum).
* ofconsole renamed to console
* Experimental support for compiling with Apple toolchain.
* grub-mkdevicemap removed. Now all devices are detected on invocation of
any grub utility.
<http://www.gnu.org/software/grub/>
A source tarball for the new release can be found at:
http://ftp.gnu.org/gnu/grub/grub-2.00.tar.gz
or
http://ftp.gnu.org/gnu/grub/grub-2.00.tar.xz
and its GPG detached signature [*]:
http://ftp.gnu.org/gnu/grub/grub-2.00.tar.gz.sig
or
http://ftp.gnu.org/gnu/grub/grub-2.00.tar.xz.sig
[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:
gpg --verify grub-2.00.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys E82E4209
and rerun the `gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.11.5
GCC 4.7 is the recommended version for building it, although any version
starting with 4.1.3 is supported in this release.
I hope you enjoy using GRUB as much as we enjoyed developing it.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
_______________________________________________
gNewSense-dev mailing list
gNewSense-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gnewsense-dev
(Log in to post comments)
Congratulations! Posted Jun 29, 2012 4:13 UTC (Fri) by proski (subscriber, #104) [Link] Congratulations to the GRUB team! GNU GRUB is a fascinating project. It's like a little operation system with its kernel, libraries, command line utilities and a GUI.I discovered GRUB in 1998 and I was amazed by its ability to read filesystems and find the kernel. Another bootloader, LILO was commonly used those days and it used a more fragile way to load kernel. A patch for GRUB fixing i386 (the real 80386 CPU) support was one of my first serious contributions to free software. GRUB 2 is a different beast. It was rewritten from scratch. It's much more capable. And it's a fascinating project too!
Congratulations! Posted Jun 29, 2012 6:30 UTC (Fri) by mbar (subscriber, #73813) [Link]
Then why I have an urge to say: "duck and cover"?
Congratulations! Posted Jun 29, 2012 6:57 UTC (Fri) by fest3er (guest, #60379) [Link]
I'll build it and give it a go once. If it's still incapable of installing where I tell it to (installing somewhere else because it knows better than I), I'll go back to legacy with RH patches and stay there for a long time.
Congratulations! Posted Jun 29, 2012 7:45 UTC (Fri) by rvfh (subscriber, #31018) [Link]
FWIW Ubuntu (and others I believe) has been using it for quite a while, and it works great.
Congratulations! Posted Jun 29, 2012 10:00 UTC (Fri) by tpo (subscriber, #25713) [Link]
> FWIW Ubuntu (and others I believe) has been using it for quite a while, and it works great.
Except when it doesn't, or when it should do things differently (i.e. be configured in a different way), it's extremely difficult to find out how to do it. F.ex. is there documentation on how Ubuntu's integration with grub2 works in detail, so that one can tweak things?
There's a flood of howtos, forum posts, blog posts etc. Each outdated in its own way or covering only some specific aspect. A lot of howtos covering Grub1 and not saying so etc.
Congratulations! Posted Jun 29, 2012 9:46 UTC (Fri) by engla (guest, #47454) [Link]
A bit worrying that we have a stack of three big "kernels": UEFI, GRUB and Linux. It's the price of "maturity"?
Congratulations! Posted Jun 29, 2012 15:06 UTC (Fri) by mikemol (subscriber, #83507) [Link]
Just wait until your UEFI BIOS can send emails.
Congratulations! Posted Jun 29, 2012 15:22 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Maybe. ISTM that UEFI can do much of what GRUB was invented to do (provide a boot menu) and it would make sense to add whatever features are missing to make direct UEFI -> kernel boot work well. But I'm just being a backseat driver 8-)
Congratulations! Posted Jun 29, 2012 15:36 UTC (Fri) by etienne (subscriber, #25256) [Link]
And if you include BIOS (which is still needed if you want to boot a CDROM), that is four USB stacks - and you need a working USB stack at least to enter commands through the keyboard.
Probably the future is to remove the possibility to boot a CDROM and remove the possibility to enter a command at boot time or configure the BIOS, who needs that anyway? Two weeks ago a friend came to me with a non working PC, the PC would not boot; his hard disk was not recognised by a live Linux CDROM distro neither. It was quite nice to be able to finally enter the BIOS setup, see that the HD was not recognised there neither (so the IDE interface was disabled), and finally diagnose that the rotating motor of the HD was completely dead - the disk plates will never turn again. Soon, when your PC do not boot, the only solution will be to put it in the bin and go and buy another one.
Congratulations! Posted Jun 29, 2012 11:24 UTC (Fri) by alankila (subscriber, #47141) [Link]
Imho its ability to read filesystems is also sort of its downfall. It would have more sense to just leave some 100 MB unpartitioned space at start of every disk with grub installed and use some unspecified but grub-known format for files written there. Perhaps the filesystem could be designed to be good enough to be mounted as /boot, but I wouldn't care if it isn't...
LILO's great problem was that if you touched your kernel or initramfs files in any way, you got unbootable system, because the location of files changed and not enough effort was spent protecting these files such as marking them immutable to avoid accidentally constructing nonbootable system.
GRUB 1/2 requires generating the config file for the installed kernel suite, and also adds the twist that the filesystem needs to be readable to the boot loader (which used to be a problem for XFS and BTRFS, though not anymore). That both XFS and BTRFS work now is great, but I imagine it's always going to be playing catch-up, so I question the sense this design makes.
Congratulations! Posted Jun 29, 2012 12:11 UTC (Fri) by hawk (subscriber, #3195) [Link]
Why should it invent its own filesystem?
As grub already supports a bunch of commonly used filesystems it's easy enough to do essentially what you suggest would be done if there was a special "grubfs"; just create a small /boot filesystem that is of a type that grub does support and use whatever filesystem(s) you want for everything else.
Congratulations! Posted Jun 29, 2012 13:17 UTC (Fri) by alankila (subscriber, #47141) [Link]
I simply said that the filesystem is unspecified. Whether it's a real one or not doesn't matter to me. The reason why I would like to make it special and hide it from the OS is to reduce the complexity of the program and improve its reliability especially when facing future changes.
An approximation of this design is separate /boot, but IMHO the fundamentally bad idea which opened the whole can of worms is that grub reads ANY mountable filesystem, even if the filesystem was as simple as VFAT. But I understand defending this version of the argument is very difficult, and anyway all the effort has already been expended in getting every filesystem's every version work as well as possible. We might just as well roll with it, but in my opinion there is a lesson here, which says "We should not expect boatloaders to be as good as our operating systems when dealing with filesystems and hardware". Or something along the lines.
After all, people seriously thought about using a Linux kernel just to load another Linux kernel. I'm sure there's a yo dawg joke here somewhere.
Congratulations! Posted Jun 29, 2012 13:23 UTC (Fri) by joey (subscriber, #328) [Link]
Grub's filesystem support is entirely read-only. This makes it much simpler than actual linux filesystem implementations. We use grub2 in os-prober to probe the contents of all available filesystems, while avoiding modifying them; something the kernel's filesystem code often cannot do.
Congratulations! Posted Jun 29, 2012 13:28 UTC (Fri) by alankila (subscriber, #47141) [Link]
Yes, and it took long time until XFS and BTRFS could be used with GRUB.
Whether the code is simpler or not doesn't matter, the fact the code needs to exist is what I call into question.
Congratulations! Posted Jun 29, 2012 13:38 UTC (Fri) by hummassa (subscriber, #307) [Link]
Why would anyone use a sofisticated, journalling FS for /boot ???
/boot = ext2
Congratulations! Posted Jun 29, 2012 13:56 UTC (Fri) by alankila (subscriber, #47141) [Link]
Who has a separate /boot. One uses whatever filesystem one wants. The fact that GRUB is supposed to just work tends to make this the default setup. Then one gets dark warnings about how XFS might not work if the file was only written to journal and XFS did not get around to flushing the journal to disk. The illusion breaks.
I have RAID1 setups for most servers and there also GRUB is inconvenience, although it's still possible to make it work. In the past it used to flat-out fail trying to grok how the RAID is set up, probably because of reasons that don't directly relate to GRUB but to the os-prober. But if you now say "So why put /boot in the RAID? Just mount a partition on the disk separately", I say "But I have 2 disks in my RAID1. How can I mount /boot twice and have the files appear in both disk's copies when a new kernel is installed by my distro's package?"
If we had a separate 100 MB region set aside and understood by GRUB, it doesn't matter what RAID we have, GRUB scripts could be easily written to see that you have N disks, and to install the kernels on all the drives in such a way that it doesn't matter which one of them fails, and all of them can get a kernel up and going because everything is duplicated on all the drives.
The question here is not how to engineer around the issue using the design we have (separate /boot, ext2 filesystems, using RAID1 for /boot and say RAID5 for /), the question is that the design picked by boot loader implies that it needs to have almost the same capability as fully booted kernel. And that, IMHO, was a stupid choice.
Congratulations! Posted Jun 29, 2012 15:14 UTC (Fri) by mikemol (subscriber, #83507) [Link]
I have a separate boot. I'm certainly not the only one; there is still running hardware out there where the BIOS can only access a small fraction of the disk. This was made worse by the explosion in disk sizes over the ten years. If you don't use a separate /boot, you need to get lucky and hope that your GRUB1.x stage 1.5 (and 2?) are within the range BIOS can directly access.
As for the design picked by the bootloader: The filesystem drivers are modular. I expect that, if you wanted to, you could fairly trivially write a GRUB-specific filesystem driver. Heck, it could have a hardcoded table of files, with a hardcoded set of offsets at which to find them. Or it could look for a table of such values stored in a block of records at a known place...but now we're on our way to reinventing FAT.
I think you're confusing the full capability set of the Linux Kernel with the relatively meager capabilities required to understand filesystems.
Congratulations! Posted Jun 29, 2012 16:36 UTC (Fri) by alankila (subscriber, #47141) [Link]
What I'm frustrated at is that the thing doesn't work.
With the qualifying statement that it can be made to work, if you just spend enough time.
With the wishful thinking that it could just work properly every time regardless of filesystem and RAID if it had been done differently.
I've aired enough complaints for one thread by now.
Congratulations! Posted Jun 29, 2012 19:07 UTC (Fri) by khim (subscriber, #9252) [Link] With the wishful thinking that it could just work properly every time regardless of filesystem and RAID if it had been done differently. Except it can't. If you have dual-boot Linux/Windows system then often the only way to make the whole thing happy is to install Grub on Windows-provided NTFS partition and add it to Windows menu (search GRUB2DOS in Google for details). Now, this is obviously a PITA (why some versions of Windows kill MBR after each boot is good question) - but it works. You scheme will fall apart. And it's not obvious to me that software RAID users outnumber dual-boot systems users.
Congratulations! Posted Jul 2, 2012 13:48 UTC (Mon) by alankila (subscriber, #47141) [Link]
Let's just say that when I make a dedicated linux installation I expect to be able to use filesystem of my choice and (software) RAID solution of my choice without running into all sorts of crazy issues. I could not care less about the people who play with fire and install Linux on the same harddisk with some operating system, although I realize that it is an important use case for some people. I just think harddisks are cheap and worth the investment to avoid the need to deal with this fundamentally risky configuration where multiple operating systems are expected to cooperate one way or other.
My personal experience with GRUB has been one of long frustration because it has taken so long before it started to work properly. But hey! It wasn't a .0 release before either, so maybe I was wrong to expect it to just work. Then again, I heard a wise man say "optimism kills". I expect to run into trouble as soon as I deviate one bit from what the average person is doing.
Congratulations! Posted Jul 2, 2012 9:34 UTC (Mon) by rodgerd (guest, #58896) [Link]
Some of us like to, say, RAID our /boot drives. Which GRUB didn't handle because it had to re-implement RAID. Some of us have learned through bitter experience that LVMs have their use for boot volumes, as well. Again, GRUB has had problems with that.
Congratulations! Posted Jun 29, 2012 12:23 UTC (Fri) by slashdot (guest, #22014) [Link]
What happened to using a Linux kernel as the bootloader?
That's possible right now and would avoid duplicating all the drivers, but it seems to never have gotten popular for some reason.
Congratulations! Posted Jun 29, 2012 12:49 UTC (Fri) by cortana (subscriber, #24596) [Link]
On my system, GRUB's core image (that is, GRUB itself + enough modules to allow it to read files (configuration, additional modules, kernel, initrd) from /boot comes to 26 KiB.
If you have a hard disk using MBR, this image would be embedded in the gap between the end of the MBR and the start of the first partition. With a typical layout, the this is normally only 31 KiB. Could a minimal kernel be built to fit into such a small space?
If you're using GPT then things are easier: the conventional gap before the first sector disappears entirely, and is replaced by a dedicated partition for the boot loader (misnamed the "BIOS Boot Partition" in GRUB's case). This partition can be of any size, so you can build as complex a kernel/rescue system as you like as a "boot loader"...
Congratulations! Posted Jun 29, 2012 13:48 UTC (Fri) by joib (guest, #8541) [Link]
The "typical layout" these days is to put the start of the first partition at 1 MB (sector 2048). IIRC Windows has done that since XP, and within the last few years Linux distros have started doing the same in order to get correct alignment for 4K drives (and SSD's?).
Congratulations! Posted Jun 29, 2012 14:12 UTC (Fri) by cortana (subscriber, #24596) [Link] I think GRUB's decision to use a dedicated partition was borne of past experience--for example, some DRM software happily assumes it's OK to scribble over sectors in the gap... since partitions are not as scare a resource with GPT as their were with MBR, the balance is tipped in favour of having a dedicated partition to prevent this kind of thing happening again.
Congratulations! Posted Jun 29, 2012 19:13 UTC (Fri) by blitzkrieg3 (subscriber, #57873) [Link]
No way has windows done that since XP. There are a million articles out there that state that XP is not 4k aligned. Probably vista or some such.
Congratulations! Posted Jun 30, 2012 18:10 UTC (Sat) by elanthis (guest, #6227) [Link]
Indeed, XP installs to sector 63 by default. An article on LWN going over some of the history, and the problems XP's assumptions imposed: http://lwn.net/Articles/377895/
Congratulations! Posted Jun 29, 2012 15:24 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> Imho its ability to read filesystems is also sort of its downfall. It would have more sense to just leave some 100 MB unpartitioned space at start of every disk with grub installed and use some unspecified but grub-known format for files written there. Perhaps the filesystem could be designed to be good enough to be mounted as /boot, but I wouldn't care if it isn't...
I think there is some confusion because I don't see how that is any different than how things currently work with /boot partitions for grub to read.
GRUB 2.00 released Posted Jun 29, 2012 6:53 UTC (Fri) by steveriley (subscriber, #83540) [Link]
For any GRUB experts checking in here, one of our members at Kubuntu Forums has a vexing problem: GRUB appears convinced that two of the hard drives in his machine contain the Windows 7 bootloader, even though Windows is not present on his computer at all.
http://www.kubuntuforums.net/showthread.php?59333
He's resorted to disabling the OS prober, which at least cleans up his menu. If there's a better solution, it eludes us. So...any ideas?
GRUB 2.00 released Posted Jun 29, 2012 12:39 UTC (Fri) by slashdot (guest, #22014) [Link]
Read the source code of the OS prober.
I guess it's most likely finding the NTFS partition boot code for Windows 7, not sure if you can easily erase it or disable the check.
Probably the fix is to expand the check to also check that a file called "bootmgr" is present in the NTFS root directory (or "ntldr" in the pre-Vista case).
GRUB 2.00 released Posted Jun 30, 2012 8:53 UTC (Sat) by steveriley (subscriber, #83540) [Link]
Yup, that was the problem -- Bootmgr was present. Earlier I had suggested looking for NTLDR, which of course wasn't there. Completely forgot about Bootmgr!
GRUB 2.00 released Posted Jun 29, 2012 13:02 UTC (Fri) by cortana (subscriber, #24596) [Link]
Please file a bug against grub or os-prober too. I just had a look at the source code and the current version (1.53) seems to only detect Windows 7 if there's a file 'BOOT\BCD' on the filesystem, but it's possible that you have an older version that behaves as slashdot says.
GRUB 2.00 released Posted Jun 29, 2012 7:24 UTC (Fri) by alspnost (guest, #2763) [Link] I guess it's me, but I still find GRUB2 impossible to use. Gone are the happy days when compiling and installing new kernels was a routine experience, and when editing your GRUB config was a simple task. In my view, GRUB2 is just absurdly over-complex for 99% of all users. But I guess I'm missing something - pointers to a good quality instruction guide are welcome.
GRUB 2.00 released Posted Jun 29, 2012 7:51 UTC (Fri) by idupree (subscriber, #71169) [Link] I know Debian's done crazy things with their GRUB configuration, but my manual GRUB2 installation is dirt simple: grub.cfg: #timeout in seconds:
set timeout=3
#default counts menuentries in order from 0, i.e.
#this references "Arch-no-nouveau-pushed".
set default=1
menuentry "Arch-force-nouveau" {
linux /archboot/vmlinuz-linux cryptdevice=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:files root=/dev/mapper/files gpt nouveau modeset=1 printk.time=1
initrd /archboot/initramfs-linux.img
}
menuentry "Arch-no-nouveau-pushed" {
linux /archboot/vmlinuz-linux cryptdevice=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:files root=/dev/mapper/files gpt printk.time=1
initrd /archboot/initramfs-linux.img
}
menuentry "Arch-lts-fallback-3.0kernel" {
linux /archboot/vmlinuz-linux-lts cryptdevice=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:files root=/dev/mapper/files gpt nouveau modeset=1 printk.time=1
initrd /archboot/initramfs-linux-lts-fallback.img
}
menuentry "Rescue iso (sysresccd 2.7.0, kernel rescue64 3.2.x)" {
loopback loop /systemrescuecd-x86-2.7.0.iso
linux (loop)/isolinux/rescue64 docache isoloop=systemrescuecd-x86-2.7.0.iso
initrd (loop)/isolinux/initram.igz
}
menuentry "Arch memtest86+" {
linux16 /archboot/memtest86+/memtest.bin
}
(context - I have a dedicated bootloader partition. I mount its /archboot onto my Arch Linux /boot partition (using fstab). grub2-install takes care of what happens before this partition [I install grub using SysRescCD]. My distro's initramfs takes care of what happens after.)
GRUB 2.00 released Posted Jun 29, 2012 8:06 UTC (Fri) by HelloWorld (guest, #56129) [Link]
It should also be mentioned that entries like these can be put in /boot/grub/custom.cfg where they won't be overwritten the next time grub.cfg is regenerated.
GRUB 2.00 released Posted Jun 29, 2012 15:48 UTC (Fri) by Aliasundercover (subscriber, #69009) [Link]
All the layers get tiresome. A configuration file for a script to write a configuration file which gets interpreted like a script...
Some honor this as the "Unix" way but it feels like pushing on a string to me.
GRUB 2.00 released Posted Jun 29, 2012 16:54 UTC (Fri) by HelloWorld (guest, #56129) [Link]
If you don't want to use grub-mkconfig, nothing stops you from writing grub.cfg by hand, so what's the problem? I'm not saying everything is perfect with Grub2's configuration handling, it's just that I completely fail to see how Grub1 is any better.
GRUB 2.00 released Posted Jun 29, 2012 21:08 UTC (Fri) by Aliasundercover (subscriber, #69009) [Link]
Right, then we get back to grub.cfg getting trashed by the automatic tools. Pick your poison, complicated script to generate a script vs. care to backup and fix a less complicated hand written config file every time the automatic stuff gets loose with it.
GRUB 2.00 released Posted Jun 29, 2012 23:41 UTC (Fri) by HelloWorld (guest, #56129) [Link]
Entries in /boot/grub/custom.cfg won't be overwritten.
GRUB 2.00 released Posted Jul 8, 2012 16:21 UTC (Sun) by hodoscek (subscriber, #5290) [Link]
What about /etc/grub.d/40_custom file. This is official place to put your stuff that you want to boot. After changing the file just run
grub2-mkconfig -o /boot/grub2/grub.cfg
I use it all the times with Gentoo. But Ubuntu can do it too. So I still compile my own kernels and extend the 40_custom file, similar to grub1 or lilo in the ancient times. Not much changed :-)
Even simpler Posted Jul 12, 2012 12:35 UTC (Thu) by alex (subscriber, #1355) [Link]
I just have /boot/kernel-stable, /boot/kernel-linus and /boot/kernel-ajb and take care not to update all of them at once. I believe I also have the Gentoo default installed kernel just in case I hose all of my custom kernels but I've never needed to go that far.
Re: Gone are the happy days Posted Jun 29, 2012 13:17 UTC (Fri) by utoddl (subscriber, #1232) [Link] I used to try to let all my installed distros share a /boot partition, but I got tired of fixing up grub.conf and/or menu.lst after each update. So for the last several years I've had a dedicated non-distro based "master" boot partition with a hand-installed GRUB, the only purpose of which was to chainload to the various distro specific GRUBs on distro specific boot partitions. This has worked well for years. Now that GRUB has taken "Grand Unified" to heart and gone all probey on me and no longer wants to install boot code into anything other than the root of a disc, I suppose I'll have to come up with another strategy. Perhaps going back to a common /boot partition for all the distros is the way to go. How do you, my fellow LWN readers, handle boot partition issues with multiple distros on one box? I'm looking for a strategy that works with rather than against the expectations of the various distros and how they do updates.
Re: Gone are the happy days Posted Jun 30, 2012 0:31 UTC (Sat) by ralphdegennaro (subscriber, #35718) [Link]
I have a test box that I've done same and would like to do the same. I know it's a corner case to have Fedora, openSuse, Ubuntu, Kubuntu and Mageia on small test partitions. It'd be nice to have that setup work out-of-box tough.
What I could see as still problematic with a shared /boot is if distros have different versions of GRUB. When you do the install, each overwrites the other, right? And updates might create the wrong versioned config too, right? Excuse my ignorance if I'm confused...
I'll probably still end up installing one minimal to its own partition with its GRUB to sda. And then each distro's GRUB to their sda#. Last I looked, some OS's installers (like PC-BSD or other unmentionables) didn't support putting their boot loader not to the MBR. So I'll still need a USB stick to fix the "OS agnostic". Oh well....
Re: Gone are the happy days Posted Jul 10, 2012 16:04 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Grub2 offers the commands extract_entries_source and extract_legacy_entries_source, which read menu entries from another grub2/grub legacy configuration file. You can place these commands in your custom.cfg (usually /boot/grub{,2}/custom.cfg). I use them to read one distro's boot loader configuration from another one's so that in the end, all entries end up in the same menu. It makes sense to disable the os-prober script in /etc/grub.d when using this approach, otherwise you'll get many redundant entries.
GRUB 2.00 released Posted Jun 29, 2012 18:19 UTC (Fri) by theophrastus (guest, #80847) [Link]
just to profess my ignorance, i'm not even sure what version i've currently got installed. ok... "1.99", but what's this "version 2"?
> dpkg -l '*grub*' | grep '^ii'
GRUB 2.00 released Posted Jun 29, 2012 18:47 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
Grub 2 (version 1.99, on your system) is a rewrite of grub, and the old one has been thus named Grub 1. The latest version number of grub 1 is 0.97.
GRUB 2.00 released Posted Jun 30, 2012 18:15 UTC (Sat) by elanthis (guest, #6227) [Link]
Off topic, but... I think that versioning explanation exactly illustrates why the version scheme adopted by Chrome (and an a good amount of other software) makes so much more sense. :)
GRUB 2.00 released Posted Jul 1, 2012 22:16 UTC (Sun) by marcH (guest, #57642) [Link]
This is the first time I see the name "GRUB 1". On the other hand, searching for "GRUB legacy" (the official name) returns millions of hits.
GRUB 2.00 released Posted Jul 13, 2012 17:35 UTC (Fri) by danielos (subscriber, #6053) [Link]
I want to add my ignorance, I am using that version for 5 years, and so it is stable, what does it means exactly stable?
In announce I see new features not bugfix (I think there are of course).
And so Grub start new scheme .. 2.00, it is a price? 2 dollars? I suppose the first bug fix would be 2.01 ..
To me it looks as the first software to have this numbering. Anyone note this?
|
|||||||||||||||||||