Re: [PATCH] Support RAID on virtio devices, and others
Colin Watson wrote:
GRUB only supports RAID on a relatively small number of device types, as
implemented by grub_util_getdiskname. I received a bug report noting
that this doesn't work for RAID arrays with virtio block devices (often
used in kvm) as components. This is difficult to support using the
approach taken by grub_util_getdiskname, as virtio devices use dynamic
major numbers.
find_root_device in util/getroot.c seemed to be exactly what I wanted:
it just trawls /dev for the appropriate major and minor numbers. This
code is not performance-critical, so that should be fine.
Not true. Even in current state grub-mkconfig is taking considerable
time to complete on my system with numerous kernels. Unless someone
implements a cache (it can be invalidated after 5 minutes) not to go
through the same probing procedure on every grub-probe call I object
against adding any additional delay in probing procedure
I made the
function naming more consistent, added support for a default directory
in its interface (this may have problems on Cygwin; does anyone care
about RAID on Cygwin? If so, perhaps they can propose improvements), and
changed the RAID code to use it.
Bazaar users can merge this from:
bzr+ssh://bzr.sv.gnu.org/grub/people/cjwatson/raid-virtio/
=== modified file 'ChangeLog'
--- ChangeLog 2009-10-21 12:22:05 +
+++ ChangeLog 2009-10-25 01:32:02 +
@@ -1,3 +1,22 @@
+2009-10-25 Colin Watson cjwat...@ubuntu.com
+
+ Support RAID on virtio devices, and others.
+
+ * util/getroot.c [__MINGW32__] (find_root_device): Rename to ...
+ [__MINGW32__] (grub_find_device): ... this.
+ [! __MINGW32__ ! __CYGWIN__] (find_root_device): Rename to ...
+ [! __MINGW32__ ! __CYGWIN__] (grub_find_device): ... this. Use a
+ reasonable default if dir is NULL.
+ [! __MINGW32__ __CYGWIN__] (find_cygwin_root_device): Rename to
+ ...
+ [! __MINGW32__ __CYGWIN__] (grub_find_device): ... this.
+ (grub_guess_root_device): Update callers.
+ * include/grub/util/getroot.h (grub_find_device): Add prototype.
+
+ * util/raid.c (grub_util_getdiskname): Remove.
+ (grub_util_raid_getmembers): Use grub_find_device rather than
+ grub_util_getdiskname.
+
2009-10-21 Felix Zielcke fziel...@z-51.de
* config.guess: Update to latest version from config git
=== modified file 'include/grub/util/getroot.h'
--- include/grub/util/getroot.h 2009-04-11 09:40:39 +
+++ include/grub/util/getroot.h 2009-10-25 01:22:15 +
@@ -19,12 +19,15 @@
#ifndef GRUB_UTIL_GETROOT_HEADER
#define GRUB_UTIL_GETROOT_HEADER 1
+#include sys/types.h
+
enum grub_dev_abstraction_types {
GRUB_DEV_ABSTRACTION_NONE,
GRUB_DEV_ABSTRACTION_LVM,
GRUB_DEV_ABSTRACTION_RAID,
};
+char *grub_find_device (const char *dir, dev_t dev);
char *grub_guess_root_device (const char *dir);
char *grub_get_prefix (const char *dir);
int grub_util_get_dev_abstraction (const char *os_dev);
=== modified file 'util/getroot.c'
--- util/getroot.c2009-07-20 20:03:18 +
+++ util/getroot.c2009-10-25 01:22:15 +
@@ -172,8 +172,8 @@ grub_get_prefix (const char *dir)
#ifdef __MINGW32__
-static char *
-find_root_device (const char *dir __attribute__ ((unused)),
+char *
+grub_find_device (const char *dir __attribute__ ((unused)),
dev_t dev __attribute__ ((unused)))
{
return 0;
@@ -181,13 +181,22 @@ find_root_device (const char *dir __attr
#elif ! defined(__CYGWIN__)
-static char *
-find_root_device (const char *dir, dev_t dev)
+char *
+grub_find_device (const char *dir, dev_t dev)
{
DIR *dp;
char *saved_cwd;
struct dirent *ent;
+ if (! dir)
+{
+#ifdef __CYGWIN__
+ return NULL;
+#else
+ dir = /dev;
+#endif
+}
+
dp = opendir (dir);
if (! dp)
return 0;
@@ -225,7 +234,7 @@ find_root_device (const char *dir, dev_t
/* Find it recursively. */
char *res;
- res = find_root_device (ent-d_name, dev);
+ res = grub_find_device (ent-d_name, dev);
if (res)
{
@@ -328,8 +337,8 @@ get_bootsec_serial (const char *os_dev,
return serial;
}
-static char *
-find_cygwin_root_device (const char *path, dev_t dev)
+char *
+grub_find_device (const char *path, dev_t dev)
{
/* No root device for /cygdrive. */
if (dev == (DEV_CYGDRIVE_MAJOR 16))
@@ -350,7 +359,7 @@ find_cygwin_root_device (const char *pat
/* Cygwin returns the partition serial number in stat.st_dev.
This is never identical to the device number of the emulated
- /dev/sdXN device, so above find_root_device () does not work.
+ /dev/sdXN device, so above grub_find_device () does not work.
Search the partition with the same serial in boot sector instead. */
char devpath[sizeof (/dev/sda15) + 13]; /* Size + Paranoia. */
int d;
@@ -386,12 +395,12 @@
Re: [PATCH] Support RAID on virtio devices, and others
Am Sonntag, den 25.10.2009, 10:27 +0100 schrieb Vladimir 'phcoder' Serbinenko: find_root_device in util/getroot.c seemed to be exactly what I wanted: it just trawls /dev for the appropriate major and minor numbers. This code is not performance-critical, so that should be fine. Not true. Even in current state grub-mkconfig is taking considerable time to complete on my system with numerous kernels. Unless someone implements a cache (it can be invalidated after 5 minutes) not to go through the same probing procedure on every grub-probe call I object against adding any additional delay in probing procedure We have a bug report in Debian[0] open that grub-probe is very slow due to the use of ioctl(BLKFLSBUF) A comment above it says this is needed due to a bug in the Linux kernel. Is there a safe way to check if this is still needed with a recent Kernel? This seems to be added 2003, so things could have changed now a bit. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508834 -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Support RAID on virtio devices, and others
On Sun, Oct 25, 2009 at 10:27:49AM +0100, Vladimir 'phcoder' Serbinenko wrote: Colin Watson wrote: GRUB only supports RAID on a relatively small number of device types, as implemented by grub_util_getdiskname. I received a bug report noting that this doesn't work for RAID arrays with virtio block devices (often used in kvm) as components. This is difficult to support using the approach taken by grub_util_getdiskname, as virtio devices use dynamic major numbers. find_root_device in util/getroot.c seemed to be exactly what I wanted: it just trawls /dev for the appropriate major and minor numbers. This code is not performance-critical, so that should be fine. Not true. Even in current state grub-mkconfig is taking considerable time to complete on my system with numerous kernels. Unless someone implements a cache (it can be invalidated after 5 minutes) not to go through the same probing procedure on every grub-probe call I object against adding any additional delay in probing procedure But this code is not called from grub-probe; it is only called from grub-setup (grep for grub_util_raid_getmembers to confirm for yourself). A grub-mkconfig run shouldn't go anywhere near this. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Announce] Initial GRUB2 on Yeeloong
Vladimir 'phcoder' Serbinenko wrote: Hello, I'm here to announce that grub2 port for yeeloong has already had its first output. You can see it here: http://robertmh.files.wordpress.com/2009/10/grub-yeeloong.jpeg (Thanks to Robert Millan for hosting the image) On the image you can see standard shell waiting for input. What already works: booting as ELF from pmon, loading modules, graphics output if gfx card is already inited (is a case when booted from pmon), platform-independent parts What doesn't work: keyboard and disks Now keyboard works Not checked: linux booting (works on qemu) It also has stubs (e.g. rtc is just counting number of calls) and hardcodes (e.g. RAM size) but is already something. Compiling: get mips branch of http://repo.or.cz/w/grub2/phcoder.git git branch removed due to general move to bazaar. Now it's available under http://bzr.savannah.gnu.org/r/grub/people/phcoder/mips/ ./autogen.sh ./configure --target=mipsel --with-platform=yeeloong make Create a font.bin as explained here: http://grub.enbug.org/gfxterm ./grub-mkimage -O elf -o grub.elf -d . -f font.bin sm712 gfxterm sh normal Now it's: ./grub-mkimage -O elf -o grub.elf -d . -f font.bin sm712 gfxterm sh normal at_keyboard Boot it as if it was linux kernel Enjoy starring at unresponsive prompt -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Support RAID on virtio devices, and others
On Sun, Oct 25, 2009 at 10:37:01AM +0100, Felix Zielcke wrote: We have a bug report in Debian[0] open that grub-probe is very slow due to the use of ioctl(BLKFLSBUF) A comment above it says this is needed due to a bug in the Linux kernel. Is there a safe way to check if this is still needed with a recent Kernel? This seems to be added 2003, so things could have changed now a bit. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508834 I think this is only an issue in very specific situations. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Support RAID on virtio devices, and others
On Sun, Oct 25, 2009 at 10:27:49AM +0100, Vladimir 'phcoder' Serbinenko wrote: Not true. Even in current state grub-mkconfig is taking considerable time to complete on my system with numerous kernels. Unless someone implements a cache (it can be invalidated after 5 minutes) not to go through the same probing procedure on every grub-probe call I object against adding any additional delay in probing procedure I've been thinking for a while that grub-probe does a few too many things, perhaps if it is split in separate commands, and the upper layer makes appropiate use of them (e.g. by remembering results so they don't need to be re-obtained), we could optimize this without need for a cache in the lower layer. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
On Sat, Oct 24, 2009 at 7:04 PM, Peter Cros pxwp...@gmail.com wrote: I can use grub-mkrescue to create an El Torito image and burn CD which boots and can run menu. Is that what you mean, or is there a way to boot direct from iso? Thanks Nevermind, multiboot /grub.img works, with some bugs in gfx for bios boot on apple. (font missing no text on gfx, textmode is ok). -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Bean wrote: On Sat, Oct 24, 2009 at 4:34 AM, rubisher rubis...@scarlet.be wrote: [snip] As it seems that you have some experience with powerpc, may be can you advise me with some your tips (how did you build your image, a sample of one your menuentry?): I also tried to follow recipe of http://grub.enbug.org/TestingOnPowerPC i.e. # cd /usr/lib/grub/powerpc-ieee1275 (where *.mod stand) # /usr/bin/grub-mkelfimage -n --directory=/usr/lib/grub/powerpc-ieee1275 --output=/boot/grub/grubof.modules *.mod (-n for pseries) but this image sadely make panicing ofs: DEFAULT CATCH!, exception-handler=fff00300 at %SRR0: 00c3c25c %SRR1: 8000b002 Call History @ - c3c1f0 close-package - c58060 (poplocals) - c3a758 (init-program) - c7e298 boot - c7ec7c evaluate - c4a638 invalid pointer - d83655 invalid pointer - f invalid pointer - f catch - c38fe8 bt-task-boot-on-this - d140d8 (poplocals) - c3a758 catch - c38fe8 execute-device-method - c58bcc (poplocals) - c3a758 (select-boot-seq) - c59ba4 Client's Fix Pt Regs: Client's Fix Pt Regs: 00 001001f4 deadbeef fffc 04 0001 08 1000 030002001000 0003 7000 0c 2280 00c17100 00c18000 0009c4b0 10 00db8c20 00db8939 00c57d80 00c58060 14 18 00c13000 00c38000 00c14d40 00c16ec0 1c 00c2 00c3fdf0 00c11ea0 00c10fa8 Special Regs: %IV: 0300 %CR: 8480%XER: 2008 %DSISR: 0800 %SRR0: 00c3c25c %SRR1: 8000b002 %LR: 00c3c1f0%CTR: %DAR: Virtual PID = 0 ofdbg At this point I am worry that the change of optimization compile option (-Os - -O0) break something or am I facing to some issue related to my ofs or something else in config file (e.g. I just figure out that I didn't change my grub.cfg with the usage of lasetest describe image grubof.modules: I didn't remove the 'insmod ext2', thought?) Hi, Don't include all modules, the boot image seems to be broken when it exceed certain size. The following list should be enough: minicmd fat part_msdos normal sh ls linux in the grub shell, use ls command to list detected devices. Thanks; at least i didn't encountered anymore ofs panic but in grub rescue sheel 'ls' just return an empty line; I can just grab 'lsmod' info: sh:grub lsmod NameRef Count Dependencies linux 1 boot,elf elf 2 gzio gzio3 ls 1 normal,extcmd extcmd 2 sh 1 normal normal 4 boot boot6 part_msdos 1 fat 1 minicmd 1 but if I try to add another module (e.g. scsi or what else) it always respond: error: invalid arch independent ELF magic ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Sun, Oct 25, 2009 at 11:22 PM, rubisher rubis...@scarlet.be wrote: at least i didn't encountered anymore ofs panic but in grub rescue sheel 'ls' just return an empty line; I can just grab 'lsmod' info: sh:grub lsmod Name Ref Count Dependencies linux 1 boot,elf elf 2 gzio gzio 3 ls 1 normal,extcmd extcmd 2 sh 1 normal normal 4 boot boot 6 part_msdos 1 fat 1 minicmd 1 but if I try to add another module (e.g. scsi or what else) it always respond: error: invalid arch independent ELF magic Hi, You shouldn't need scsi, which is used by ata module to access pci bus, but openfirmware would export the boot disk for you. Use these command: set debug=disk ls This should print some debug information in grub console. -- Bean gitgrub home: http://github.com/grub/grub/ my fork page: http://github.com/bean123/grub/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Macbook, Efi, Display mode
Then you should be able to add EFI display support quite easily during the make menuconfig step A new improvement here! Besite EFI display stuff, now I have also CONFIG_FB_NVIDIA enabled. This gives me boot output on booting. but not on shuting down. So, now I have - graphical menu - terminal output on booting greetings, Stefan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB 1.97 released
Hi, I'm proud to announce the release of GNU GRUB version 1.97. GRUB, also known as the GRand Unified Bootloader, is a modular, portable bootloader that supports a number of platforms, including standard BIOS-based PCs, IEEE-1275 platforms (such as the OLPC and some PowerPC/Sparc64 hardware) and coreboot, the free (as in freedom) pre-boot initialization framework. http://www.gnu.org/software/grub/ This release of GRUB is a significant breakthrough compared to GRUB 1.96. Among a long list of improvements (excerpt from NEWS file is attached), GRUB 1.97 includes support for booting the kernels of FreeBSD, OpenBSD and NetBSD, it detects the Ext4 filesystem which is commonly used with the kernel Linux, and it implements a robust mechanism for booting from GPT drives, by embedding itself in the BIOS Boot partition. A source tarball for the new release can be found at: http://alpha.gnu.org/gnu/grub/grub-1.97.tar.gz and its GPG detached signature [*]: http://alpha.gnu.org/gnu/grub/grub-1.97.tar.gz.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-1.97.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 DEA2C38E and rerun the `gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.61 Ruby 1.8.7 GCC 4.4 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. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. * Add support for loading XNU (MacOS X kernel). * ACPI override support. * Integrated gptsync. * Password protection support. * Partition manipulation tool. * Add `keystatus' command. * Unicode fonts are now used by default. * Add `hdparm' command. * Add support for getting the current date and time from CMOS as variables. * Add `drivemap' command. * Add support for RAID levels 4,6 and 10. * update-grub is replaced by grub-mkconfig. * When booting from PXE, PXE can be used to load files. * High resolution timer support. * Image loaders now support IO buffering. * Add `crc' command. * Add Cygwin support. * Add x86_64 EFI support. * Use LZMA compression instead of LZO. * Support for saving the environment from and loading the environment from a file. * Allow the UUID to be used as device name. * The `search' command can use UUIDs now. * Add support for IEEE 1275 on i386. * Create partmap.lst and use it to automatically load partition map modules. * grub-mkconfig supports os-prober to add operating systems to the boot menu. * The ATA driver supports devices bigger than 2 TiB. * Add support for the UDF, AFS and EXT4 filesystems. * The ISO9660 filesystem supports the Joliet extension * Add support for loading kernels of FreeBSD, NetBSD and OpenBSD. * Add new command `sleep'. * Support for direct access to AT keyboards. * New utility `grub-fstest'. signature.asc Description: Digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub2 problems
Hi, What is the dependancy of the grub boot loader and the grub.cfg file. I had a perfectly working grub2 install. I changed my grub.cfg file, assuming that grub would automatically use the new one, but grub failed to boot showing massed of errors in the grub.cfg file it saw. This was fixed by re-installing grub2 using grub-install. (ubuntu karmic) Is this a grub bug, or is it by design? Kind Regards James ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 problems
Am Sonntag, den 25.10.2009, 20:27 + schrieb James Courtier-Dutton: Hi, What is the dependancy of the grub boot loader and the grub.cfg file. I had a perfectly working grub2 install. I changed my grub.cfg file, assuming that grub would automatically use the new one, but grub failed to boot showing massed of errors in the grub.cfg file it saw. This was fixed by re-installing grub2 using grub-install. (ubuntu karmic) Is this a grub bug, or is it by design? Did you choose the right device in the debconf prompt on package install? If you didn't then grub-install does not get run on package upgrades. So it could be that the grub2 active in /boot/grub and MBR + embed area didn't understand your changes. It would help to see what those errors were. sh.mod could have been broken/not loaded but that should only happen if you did something which you shouldn't do, like using grub-mkimage yourself. Or the embed core.img was out of sync with /boot/grub but that should only happen if you run grub-install on the wrong device or choose the wrong device in the debconf prompt so the package does it wrong. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
My personal repository
Hi, I have switched from git to bzr, the repository is moved from github to launchpad: https://launchpad.net/burg -- Bean My repository: https://launchpad.net/burg ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: My personal repository
Bean wrote: Hi, I have switched from git to bzr, the repository is moved from github to launchpad: https://launchpad.net/burg Hello.Would you consider using bzr.sv.gnu.org rather than launchpad for this? This would make collaboration easier. In fact I'm interested in merging your changes that are usable into experimental -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ntldr support
Agree.
A 'ntldr' or 'chainloader --ntldr' command is not mandatory. But it is
'nice to have' because it allows to boot even if the boot
code (6 sectors) in the area behind the PBR is not present for whatever
reason. See my previsions mail with the test case.
--
Regards,
Christian Franke
I've just checked the 0.97 release and find the ntldr patch is not
included. What version of grub2 was the original ntldr.diff patch
against??
I would definitely would like to see this implemented. Plenty of ppl
out there with bootmgr is missing error messages requiring
Win7/Vista
bootup into recovery console to correct..This solution would rectify
that. Also means could bootup into XP or Win7/Vista with
separate entries in grub.conf, rather than navigating the Vista
bootloader to do it. Eg:
menuentry XP on /dev/sda1 {
root (hd0,1)
ntldr /ntldr }
menuentry Win7 on /dev/sda2 {
root (hd0,2)
ntldr /bootmgr }
Nando
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Should the website still say that GRUB 2 is currently under development?
Am Sonntag, den 25.10.2009, 19:21 +0100 schrieb Felix Zielcke: Am Montag, den 10.08.2009, 17:28 +0200 schrieb Robert Millan: On Mon, Aug 10, 2009 at 03:25:26PM +0200, Felix Zielcke wrote: Am Freitag, den 31.07.2009, 18:19 +0200 schrieb Robert Millan: On Thu, Jul 30, 2009 at 11:45:35AM -0400, Pavel Roskin wrote: On Thu, 2009-07-30 at 15:05 +0200, adrian15 wrote: Felix Zielcke escribió: I think the currently under development part can be now removed. Or would it be better to wait for the 1.97 release? (which hopefully comes before December) That would be nice because Debian freezes at December. I don't see anything wrong with being under development. I hope that GRUB 2 will be under development even after the 1.97. I don't see how Debian can have any problem with that. It depends. If we say GRUB 2 is under development but we don't say anything about GRUB Legacy, people might think GRUB 2 is not ready. Oh I even forgot that there was in the meanwhile even someone in #grub who was a bit scared of GRUB 2 because of this sentence. But luckly not that scared to not ask how stable it is now. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ntldr support
On Mon, Oct 26, 2009 at 10:28:21AM +1100, Nando wrote: I've just checked the 0.97 release and find the ntldr patch is not included. What version of grub2 was the original ntldr.diff patch against?? Unfortunately it missed the time for 1.97 release, but we expect to include this with 1.98. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH,HURD] Fix GNU/Hurd menu entry generation
Hello,
The patch below fixes menu entry generation for GNU/Hurd.
Samuel
2009-20-26 Samuel Thibault samuel.thiba...@ens-lyon.org
* util/grub.d/30_os-prober.in: Add GNU/Hurd support
* util/grub.d/10_hurd.in: Translate grub device name into mach
device name.
Index: util/grub.d/30_os-prober.in
===
--- util/grub.d/30_os-prober.in (révision 2657)
+++ util/grub.d/30_os-prober.in (copie de travail)
@@ -155,7 +155,28 @@
EOF
;;
hurd|*)
- echo ${LONGNAME} is not yet supported by grub-mkconfig. 2
+ cat EOF
+menuentry ${LONGNAME} (on ${DEVICE}) {
+EOF
+ prepare_grub_to_access_device ${DEVICE} | sed -e s/^/\t/
+ GRUB_DEVICE=`${grub_probe} --device ${DEVICE} --target=drive`
+ mach_device=`echo ${GRUB_DEVICE} | tr -d '()' | tr , s`
+ HURD_FS=`${grub_probe} --device ${DEVICE} --target=fs`
+ case ${GRUB_FS} in
+ *fs)hurd_fs=${GRUB_FS} ;;
+ *) hurd_fs=${GRUB_FS}fs ;;
+ esac
+ cat EOF
+ multiboot /boot/gnumach.gz root=device:${mach_device}
+ module /hurd/${hurd_fs}.static ${hurd_fs} --readonly \\
+ --multiboot-command-line='\${kernel-command-line}' \\
+ --host-priv-port='\${host-port}' \\
+ --device-master-port='\${device-port}' \\
+ --exec-server-task='\${exec-task}' -T typed '\${root}'
\\
+ '\$(task-create)' '\$(task-resume)'
+ module /lib/ld.so.1 exec /hurd/exec '\$(exec-task=task-create)'
+}
+EOF
;;
esac
done
Index: util/grub.d/10_hurd.in
===
--- util/grub.d/10_hurd.in (révision 2657)
+++ util/grub.d/10_hurd.in (copie de travail)
@@ -48,6 +48,7 @@
*fs) hurd_fs=${GRUB_FS} ;;
*) hurd_fs=${GRUB_FS}fs ;;
esac
+mach_device=`echo ${GRUB_DEVICE} | tr -d '()' | tr , s`
for i in /hurd/${hurd_fs}.static /hurd/exec ; do
if test -e $i ; then
@@ -73,7 +74,7 @@
EOF
prepare_grub_to_access_device ${GRUB_DEVICE} | sed -e s/^/\t/
cat EOF
- multiboot ${kernel} root=device:${GRUB_DEVICE}
+ multiboot ${kernel} root=device:${mach_device}
module /hurd/${hurd_fs}.static ${hurd_fs} --readonly \\
--multiboot-command-line='\${kernel-command-line}' \\
--host-priv-port='\${host-port}' \\
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH,HURD] Fix GNU/Hurd menu entry generation
On Mon, Oct 26, 2009 at 02:40:01AM +0100, Samuel Thibault wrote:
+ mach_device=`echo ${GRUB_DEVICE} | tr -d '()' | tr , s`
[...]
+mach_device=`echo ${GRUB_DEVICE} | tr -d '()' | tr , s`
for i in /hurd/${hurd_fs}.static /hurd/exec ; do
if test -e $i ; then
@@ -73,7 +74,7 @@
EOF
prepare_grub_to_access_device ${GRUB_DEVICE} | sed -e s/^/\t/
cat EOF
- multiboot ${kernel} root=device:${GRUB_DEVICE}
+ multiboot ${kernel} root=device:${mach_device}
I think you missunderstand what GRUB_DEVICE is (not surprising, because the
variable name is quite misleading). Did you observe wrong entry generation
in grub-mkconfig?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH,HURD] Fix GNU/Hurd menu entry generation
Robert Millan, le Mon 26 Oct 2009 02:48:48 +0100, a écrit :
@@ -73,7 +74,7 @@
EOF
prepare_grub_to_access_device ${GRUB_DEVICE} | sed -e s/^/\t/
cat EOF
- multiboot ${kernel} root=device:${GRUB_DEVICE}
+ multiboot ${kernel} root=device:${mach_device}
I think you missunderstand what GRUB_DEVICE is (not surprising, because the
variable name is quite misleading).
Ah, that's possible, is it actually DEVICE? If so, then you can
probably skip that part of the patch indeed.
Did you observe wrong entry generation in grub-mkconfig?
I didn't try that part of my patch as there are other things that
prevent grub2 from working from inside GNU/Hurd itself.
Samuel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
