Re: Determining if GRUB is the bootloader in use on a system
IMO, you shouldn't use a BPB as an identifier, because the user can modify it arbitrarily. Instead, what do you think about just searching the string GRUB from a boot record? GRUB will have the string even for the future, and I don't think LILO will have the string itself (except when the user might insert the string into a BPB :). Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Fix for grub-install
From: Pavel Roskin [EMAIL PROTECTED] Subject: Fix for grub-install Date: Tue, 17 Jul 2001 18:51:12 -0400 (EDT) There is one minor fix that I'd like to make in grub-install.in - it should recommend using `--recheck', not editing device.map by hand. Some people will edit it anyway, but it's a different story. I would agree, if the grub shell were so reliable. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: grub-md5-crypt
From: Jason Thomas [EMAIL PROTECTED] Subject: grub-md5-crypt Date: Thu, 2 Aug 2001 16:52:03 +1000 BTW, re lines 70-79 of the grub-md5-crypt script: read -r *is* the portable way, see SUSv2. All shells likely to be under /bin/sh must support it. I personally tested ash, bash, and zsh. Are there any specific reports of breakage with a sh that claims POSIX compatibility? On Solaris 8, /bin/sh has the builtin command read, but this doesn't support the option -r. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: grub command works, but GRUB boot loader hangs
From: Ben Liblit [EMAIL PROTECTED] Subject: Re: grub command works, but GRUB boot loader hangs Date: Sun, 05 Aug 2001 16:18:45 -0700 So this leaves me with some specific questions: I don't think there is anyone who can answer the questions, except for you, because we don't have such an experience. If you are capable of programming, try to debug GRUB, please. Otherwise, we will never fix your problem. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Patch: Better PCI network device detection
From: Frank Mehnert [EMAIL PROTECTED] Subject: Patch: Better PCI network device detection Date: Fri, 27 Jul 2001 11:59:00 +0200 - PCI ethernet cards will be testet first. If a known PCI device was found, the belonging probe function is called _immediatly_! That's a good idea. - The number of the PCI bus the device resides on is passed to the probe function too. Some cards have to do PCI config register manipulations and therefore has to know the PCI bus number. This affects nearly all PCI ethernet cards. But why people want to make a GRUB branch of Etherboot so much? As I said, what we should do is NOT make our own version of Etherboot. See the source code of a recent version of Etherboot, and you should understand that those problems you reported above have already been fixed in Etherboot. Thus I said that we should update the drivers, again and again. Why does nobody understand my intention? *sigh* Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: GRUB passes invalid mem= parameter to Linux kernel on systemwith 512 MB of physical RAM
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Re: GRUB passes invalid mem= parameter to Linux kernel on system with 512 MB of physical RAM Date: 01 Aug 2001 15:22:03 -0600 Better yet, is there a way for Grub to detect a newer version of linux, and set the default based on that? No. As you may know, Linux doesn't have something like a feature flag. One possibility might be the boot protocol version, but it would be definitely a Wrong Thing to use the version number for information on the implementation of Linux, since it simply defines how a boot loader should interact with a Linux boot header. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
come back
Ok, I came back to Japan yesterday. I will be busy for a while, because of house-moving and some desk works, but I'll try to read and reply e-mail about GRUB accumulated in my mailbox from now on... Give more time to me. [BTW, why are ordinary French people so poor at English? That was all I felt inconvenient in France...] Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
I'm in a travel
Just for your information: Currently, I'm travelling in Europe for a conference and satellite meetings. And, I can read/write e-mail, but I cannot often do that, so I won't reply any mail about GRUB for a while. Incidentally, I'm now in Copenhagen, and I will go to Marseille in five days. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [branden@debian.org: Bug#104508: grub: cannot get past stage1on my SCSI disk]
From: Jason Thomas [EMAIL PROTECTED] Subject: [[EMAIL PROTECTED]: Bug#104508: grub: cannot get past stage1 on my SCSI disk] Date: Sun, 15 Jul 2001 16:15:49 +1000 curious about this message above, any clues as to why it would be mentioning /dev/sda1 when the machine is using devfs? Perhaps because of the output from df. Maybe grub-install should always try to convert device names to canonical ones, so that you may not suffer from symbolic links... IMO, Linux devfs is just problematic. *sigh* BTW, Jason, please ask bug reporters for more information, when you get reports. This case, it would be better to ask him to run grub-install with the option --debug and send the output. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: grub floppy
Does this patch fix your problem? Index: ChangeLog === RCS file: /cvsroot/grub/grub/ChangeLog,v retrieving revision 1.424 diff -u -r1.424 ChangeLog --- ChangeLog 2001/07/13 08:02:04 1.424 +++ ChangeLog 2001/07/13 08:07:44 @@ -1,3 +1,9 @@ +2001-07-13 OKUJI Yoshinori [EMAIL PROTECTED] + + * util/grub-install.in (convert): Recognize the naming scheme + for Linux devfs floppy devices. Reported by Jason Thomas + [EMAIL PROTECTED]. + 2001-07-07 OKUJI Yoshinori [EMAIL PROTECTED] * netboot/compile: New file. This was also missing... How many Index: util/grub-install.in === RCS file: /cvsroot/grub/grub/util/grub-install.in,v retrieving revision 1.27 diff -u -r1.27 grub-install.in --- util/grub-install.in2001/02/28 11:19:39 1.27 +++ util/grub-install.in2001/07/13 08:07:44 @@ -81,6 +81,7 @@ -e 's%/part[0-9]*$%/disc%'` tmp_part=`echo $1 | sed -e 's%.*/[sh]d[a-z]\([0-9]*\)$%\1%' \ -e 's%.*/fd[0-9]*$%%' \ + -e 's%.*/floppy/[0-9]*$%%' \ -e 's%.*/\(disc\|part\([0-9]*\)\)$%\2%'` ;; gnu*) ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Bug-grub] Re: grub floppy
From: Jason Thomas [EMAIL PROTECTED] Subject: Re: [Bug-grub] Re: grub floppy Date: Sat, 14 Jul 2001 13:59:07 +1000 well that made the boot floppy but it doesn't work. Please investigate if that's because of grub-install. If you invoke the grub shell directly and install GRUB into your floppy manually, then does it work well? Also, see what grub-install does by tracing the execution (e.g. bash -x grub-install). if I use the dd method to create boot floppy it works. That's good to know, but I need to know if the problem is due to GRUB commands or the grub shell. Regards, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [bonnaud@iut2.upmf-grenoble.fr: Bug#104558: grub does not workwith DAC960 hardware RAID controller]
From: Jason Thomas [EMAIL PROTECTED] Subject: [[EMAIL PROTECTED]: Bug#104558: grub does not work with DAC960 hardware RAID controller] Date: Sat, 14 Jul 2001 09:57:28 +1000 should a small modification be made to the grub-install script, or should I tell this user to use the grub shell for something like this? Tell him to read the manual first. He should write a device map file by hand, and the information is available from the manual. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [branden@debian.org: Bug#104508: grub: cannot get past stage1on my SCSI disk]
Many possibilities can be thought, but I guess that's simply because his device map is wrong. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newerext2 filesystems]
That was fixed in the acient times. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: cross-platform GRUB
From: Christoph Plattner [EMAIL PROTECTED] Subject: Re: cross-platform GRUB Date: Tue, 10 Jul 2001 08:39:35 +0200 So GRUB can be installed to DOS or windows partitions (not FAT32, AFAIK) and can boot several OSes. FAT32 is supported. If not, that must be a bug. So I think, it would be a good idea, to deliver also a already build (binary) distribution of GRUB after the first GRUB Release ! Gordon has already made binary distributions. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: BIOS calls in Grub
From: Adam Agnew [EMAIL PROTECTED] Subject: BIOS calls in Grub Date: Tue, 10 Jul 2001 16:41:28 -0400 (EDT) (www.linuxbios.org). But in order to do so, I would need to take out the code in Grub which depends on a legacy BIOS (for such things as INT13) and replace it with code which does not. See the source code. You should obtain an idea from the grub shell, to do that. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: geometry (fd0) command
Hello Jeff, I took a look at the bug, but I didn't fix it, because I was very sure that it would take long to do that, and the bug was not fatal. Instead, I filed the information to the file BUGS for the future. I will fix the bug, when we rewrite the code base from scratch, unless someone submits a patch. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: in preset-menu prevents compilation
Thanks for your contribution. I've applied your patch. Next time, however, please don't forget to write ChangeLog entries. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Gunzip problem
From: Thierry Laronde [EMAIL PROTECTED] Subject: Re: Gunzip problem Date: Fri, 29 Jun 2001 16:48:26 +0200 If no one wants to fix this, I will look at it after the Debian Conference. Done. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
prepare_0_90
As usual, I have made a branch tagged with prepare_0_90. I think the current status is stable enough, so we should be able to release the branch whenver we like. Gordon, do you want to release 0.90 yourself, or do you want me to do that? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: prepare_0_90
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Re: prepare_0_90 Date: 05 Jul 2001 19:34:32 -0600 Let's make it simpler... if you want it to happen quicker than next week, you should do it yourself. I'm not in a hurry. So I'd leave the task to you. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
update your automake
[If you are not a developer, you don't have to read this mail.] As I said yesterday, GRUB now requires automake-1.4h or later, instead of my own version. As I wrote in README, the version is available from sources.redhat.com and its mirror sites by FTP. Unfortunately, automake-1.4h has a bug which affects us. Normally, you don't care about the bug, but make distcheck will fail, because it won't remove docs/grub.cps in the taget `distclean'. If you don't like the bug, you can apply my patch to your local copy of automake-1.4h. The patch has been sent to [EMAIL PROTECTED] right now by me, so you will be able to find the patch in the mail archive, even if you don't subscribe to the mailing list. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Grub + elf section table
I have checked in Julien's patch for ELF section table support to the CVS. I don't think that can break anything, but it is preferable that you ensure that your kernel is booted well. Okay, the rest is to update the manual and to use automake-1.4f instead of my own version of automake. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Gunzip problem
From: Thierry Laronde [EMAIL PROTECTED] Subject: Gunzip problem Date: Fri, 29 Jun 2001 11:08:57 +0200 In order to avoid the decompression of the initrd, there are several alternatives. But I need your advice in order to know which is best. See the function install_func in the file builtins.c, for instance. That's quite easy. b) Remove the decompression in grub_read : the question is : why do we need that? I assume that you are thinking only Linux here. Linux decompresses itself, so you don't understand why. Usually, an OS image doesn't (wouldn't) decompress itself, because that's just ugly. Clearly, that is not a task for an OS image. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: PATCH: Fix for multiple initrd files
You need to consider compatibility. GRUB must _replace_ an initrd image when one executes the command initrd more than once, by default. So one way would be to add an option to instruct initrd to change the behavior so that it concatenates multiple images. Another way would be to add another command newly. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: PATCH: Fix for multiple initrd files
From: Dave Cinege [EMAIL PROTECTED] Subject: Re: PATCH: Fix for multiple initrd files Date: Fri, 29 Jun 2001 18:50:15 -0400 You need to consider compatibility. GRUB must _replace_ an initrd image when one executes the command initrd more than once, by default. Why? I can think of no reason why a person would place more then one initrd call per entry, except as a mistake. I said compatibility. If you cannot see how important backward compatibility is, that is okay, and I just won't apply your patch. We have been trying to keep compatibility with much effort, and I don't want to break the policy merely for initrd. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Initrd unzipped ?
From: Thierry Laronde [EMAIL PROTECTED] Subject: Initrd unzipped ? Date: Mon, 25 Jun 2001 19:36:04 +0200 It seems that when one uses an initrd with Linux, the initrd is unzipped. If I'm right, since Linux is able to unzip the initrd too, and since it first moves the initrd to a ramdisk, this is not practical (one waste memory). I'm not sure. The code is derived from Erich's version of GRUB as is, so there might be a reason for that (e.g. ancient Linux didn't support gzip-loading? Erich?) Anyway, at least 2.0.38 supports gzip-loading, so I think it would be better to disable the automatic decompression behavior in GRUB. If nobody objects to that, I'll do that. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: netboot on IBM Thinkpad A21p
From: Sebastian Kirsch [EMAIL PROTECTED] Subject: Re: netboot on IBM Thinkpad A21p Date: Mon, 25 Jun 2001 23:22:27 +0200 I searched for 'thinkpad', but failed to find anything of relevance. Sorry. Use the word EtherExpressPro instead. Just for fun, I tried putting timer.[ch] and eepro100.c from etherboot 5.1.0 into grub -- it compiled all right, but the machine I tried it on halted with 'Probing...' on the display. First, please make sure that the genuine Etherboot driver works with your chipset well. I think it would be possible that the current version of Etherboot might not work with some cards. In this case, you need to patch Etherboot rather than GRUB, because the drivers are derived from Etherboot. As far as I can tell, the probe routines changed completely in 5.1.0, and etherboot finally got a real nanosecond timer instead of an uncalibrated delay loop. You are right. The point is how to mimic the timer in GRUB. I'll try and see whether I can cobble something together, knowing exactly zilch, zero, nothing about device driver programming. Good luck! Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCH] bootp --with-configfile
From: Thierry Laronde [EMAIL PROTECTED] Subject: Re: [PATCH] bootp --with-configfile Date: Fri, 22 Jun 2001 08:35:38 +0200 Do you want me to retrieve your version and propose a patch for the documentation accordingly ? No, thank you. I just want to update the documentation, as late as possible. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: netboot on IBM Thinkpad A21p
See the archive of this mailing list. That's a known bug of the device driver. So it is necessary to update the drivers to a later version of Etherboot. Any volunteers? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCH] bootp --with-configfile
So I've checked in your patch with some modification, though I haven't updated the documentation yet. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Help please, PXE for freebsd
If you see the archive of the mailing list, you should recognize that GRUB's support for FreeBSD is poor. There is no way to tell /boot/loader or the real kernel from which disk it should be booted. So I must say that we need volunteers to improve the support again. Unfortunately, however, the reality is that nobody works on GRUB for FreeBSD at the moment. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: VSTa-FS patch
So I've checked in the patch for VSTa filesystem support with some modification. I mainly modified the files to let them conform to the GNU standard style. Other changes are described in ChangeLog. One problem is that there are two warnings when compiling fsys_vstafs.c: ../../stage2/fsys_vstafs.c: In function `vstafs_read': ../../stage2/fsys_vstafs.c:189: warning: declaration of `a' shadows global declaration ../../stage2/fsys_vstafs.c:191: warning: declaration of `curr_ext' shadows global declaration As I don't know much about the internal, I didn't fix them, but I bet that they should be fixed, instead of ignoring them. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Copy with Grub
From: Dotlacil Jaroslav [EMAIL PROTECTED] Subject: Copy with Grub Date: Thu, 21 Jun 2001 09:14:55 +0100 (MET) I've this question: Could I copy any files from protected partition (WindowsNT or Linux) to dos partition with grub ? No, GRUB's support for filesystems is all read-only. But that sounds like you seek for a house of cards. If you allow anyone to boot DOS, he/she can fundamentally do anything he/she wants to do, even for NT and Linux. So if students don't have to use DOS, you can protect the machines, by requiring a password to boot DOS. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: initrd and grub
I don't know, but can you try a later version first? You can download the latest version from the CVS, or just use the latest package of Debian's, as Jason integrated many changes in the CVS version. If that won't fix your problem, I'll take a look. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: initrd and grub
From: Susumu Takuwa [EMAIL PROTECTED] Subject: Re: initrd and grub Date: Thu, 21 Jun 2001 12:20:50 +0900 With GRUB CVS version, I tried the same initrd images and got the same result. Then, mention what the result was more precisely. You haven't written what commands you executed, what was displayed by GRUB, the configuration of your system, etc. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: patch to handle different lma and vma
So I have checked in my own patch to fix the different LMA and VMA problem. I think my patch is better than Rogelio's, because mine checks if a memory segment contains the entry address, instead of just choosing the first one, and mine doesn't increase global variables at all. But I haven't tested it yet. If you have a Multiboot OS image which has different LMA and VMA, check if the code works well, and report the result to this list, if there is anything wrong. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: an estimated date of 0.90
We should ask him if he would be willing to assign his copyright to the FSF, before he starts working with the official source repository, to make our lives easier (considering that the paperwork by the FSF usually takes several weeks). Because Erich agreed that he would assign his copyright of GRUB, I think we should give care to assignments/disclaimers a bit more from now on. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: grub boot floppy
Why not just grub-install (fd0)? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Bug-grub] Re: an estimated date of 0.90
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Re: [Bug-grub] Re: an estimated date of 0.90 Date: 15 Jun 2001 09:49:01 -0600 As one of the people involved in the (several) migrations, could you explain what was irritating about them? 1. They (including you) didn't ask me about the migration at all, although it had a both user-visible and developer-visible impact. Why didn't they confirm what those who were really using the developmental environment thought about it? If it had been unavoidable, like a hardware crash, I would have had no complaint. But this case was not. 2. I heard from loic that the GRUB project had been moved to Savannah suddenly. So I asked him if we would need to change the CVS repository inevitably, which was the very thing that I wanted to avoid, because I had written down the location in the manual and README. I, however, have no reply until now. Thus I had to check if the old location was still active and if it was the same as the new one actually myself. That check seemed to be ok, so I concluded that I wouldn't have to modify the manuals. But this was just experimental, so no evidence reveals that this is theoretically correct. Is there any good explanation for why he (or other admins) hasn't given essential information to GNU developers? My endurance is NOT infinite. The cooperative spirit only exists where the work is being done cooperatively. On subversions, only about 3 people were doing the work, so the decision to upgrade to Savannah was mostly up to them. That is not a matter of my anger, as long as that doesn't hinder other people. Don't forget that system administration needs communications with users as well as other administrators. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Pb with SCSI card : solution
From: Thierry Laronde [EMAIL PROTECTED] Subject: Pb with SCSI card : solution Date: Tue, 12 Jun 2001 22:13:56 +0200 Some times ago, I have reported some problems with an old Adaptec SCSI card. using the completion TAB was producing a reboot. Isn't that the same problem listed in the FAQ? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Bug-grub] Re: an estimated date of 0.90
From: Jason Thomas [EMAIL PROTECTED] Subject: Re: [Bug-grub] Re: an estimated date of 0.90 Date: Thu, 14 Jun 2001 10:38:07 +1000 On that note would having automated cvs snapshots available for download, or at least manual ones at points were you guys think its stable, be a solution rather than an offical release. I think a version of cvsweb can solve this completely, which supports dynamic archiving of CVS modules. I heard that Debian had such a cvsweb package. I would think alot of people know little about using CVS or even how to get to it from your page, I know it took me a while to find it. It's because the FSF decided that all GNU projects should move to Savannah with no agreement. That was really radical and irritating for me, so I have little will to update the web pages for their selfish reasons. (That's one of the reasons why I'm not very interested in working for GNU any longer. Where is the cooperative spirit?) Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
RE: an estimated date of 0.90
Sergey, please use this mail list. From: Sergey Tzukanov [EMAIL PROTECTED] Subject: RE: an estimated date of 0.90 Date: Thu, 14 Jun 2001 09:56:56 +0400 I can't insist on the inclusion, but the patch was written for real life and it would be nice to see it in the official GRUB. There is the latest version 0.4 with some fixes on http://tzukanov.narod.ru. That's good. I think it would be easier for you and us to wait until the code becomes somewhat stable, though. Another option is to give you write permission to the CVS and let you maintain the code in the official source tree yourself. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: grub port of etherboot SiS 900 driver
From: Michael Clark [EMAIL PROTECTED] Subject: grub port of etherboot SiS 900 driver Date: Thu, 14 Jun 2001 00:05:57 +0800 Here's a patch that adds grub support for the SiS 900 PCI ethernet card. This is a port from Marty Conner's port of the sis900 driver from etherboot-5.1.0. That's great. But IMO, it is not desirable that GRUB would have drivers from various Etherboot versions. So, wouldn't you like to update all the drivers to 5.1.0? That might not be so easy, but undoubtedly that would be worthwhile doing. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
an estimated date of 0.90
I think that it is really necessary to release a test version of GNU GRUB, as soon as possible. This is clear, if you see how many times the same bugs in 0.5.96.1 have been reported. That is just time-consuming both for users and for developers, and we can relax the situation by publishing the current CVS version almost as it is. Unfortunately, I have no spare time in this week, but I expect that I will have some time for fun in next week. So, the test version 0.90 will be made until 23 June 2001. One thing that should be done is to apply at least patches for fixing bugs. Others will be delayed until 1.0, because of lack of time. This mail is to urge myself. :-) Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: an estimated date of 0.90
From: OKUJI Yoshinori [EMAIL PROTECTED] Subject: an estimated date of 0.90 Date: Thu, 14 Jun 2001 01:46:57 +0900 This mail is to urge myself. :-) Ah, and Gordon, of course. ;) Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: an estimated date of 0.90
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Re: an estimated date of 0.90 Date: 13 Jun 2001 17:27:05 -0600 Let me know what you'd like from me. As I said before, I'd like you to proofread the manual thoroughly. And, you can apply patches to the CVS, instead of me. Some patches need to be modified, though. FYI, I have these pending patches: * VSTa-FS This can be applied as is mostly, and the author has already assigned the copyright. * EEPro100 fixes I don't think either of these is good for GRUB. Rather, we should update the driver from a recent Etherboot release. * `--with-configfile' option to `bootp' I think the name should be shorter, but the patch is not bad. * via-rhine fix I'm not sure if the same thing as EEPro100 fixes is appliable to this. * ELF section table loading support I haven't proofread this patch carefully, but I think this is ok. * `--force-bpb' We shouldn't integrate the patch with the official version, until the command `install' itself can set up a BPB correctly. * different LMA and VMA fix This should be applied, but the patch is bad, because it uses global variables unnecessarily. * /dev/ida/*, etc. handling for Linux I don't know if this should be applied, because the information from the author is too little. * JFS If the author requests the inclusion... * SiS 900 driver I have already said the answer in another mail. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: GRUB Manual: typo
I fixed all of the typos you reported. Thanks for your contribution. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: make distclean
From: Jason Thomas [EMAIL PROTECTED] Subject: make distclean Date: Mon, 28 May 2001 17:43:41 +1000 One thing I've noticed is that make distclean does no remove the generated info files from the docs directory. It's a GNU standard. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: cannot boot: error 18
From: Andras BALI [EMAIL PROTECTED] Subject: cannot boot: error 18 Date: Sat, 26 May 2001 20:05:12 +0200 My BIOS does NOT recognize the hard disk as 17gb large but as 8147 (or something about) megabytes large. It says that it uses LBA mode. What is your BIOS? But if I try to boot, grub says it's loading stage 1.5, then it suddenly halts with 'error 18' (before loading stage 2). Could someone please explain me what the problem is? Lilo used to work fine... See the manual for what the error number means. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Bug#98785: grub: cant install
Which did you execute those commands in the native environment or in the grub shell? Is there any difference between them? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: GRUB Manual: French translation completed !
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Re: GRUB Manual: French translation completed ! Date: 28 May 2001 14:18:48 -0600 OY BTW, Gordon, do you think we should change the license term to OY the GNU Free Documentation License? That's fine with me, for the part of the document that I've contributed. Ok, then the rest is the part written by Erich. Erich, what do you think about this? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: menu on dumb terminals
From: Klaus Reichl [EMAIL PROTECTED] Subject: menu on dumb terminals Date: Fri, 25 May 2001 10:40:12 +0200 * GRUB shell: --batch Output of --batch is ugly, maybe the terminal dumb setting could be used for --batch to make it more natural. I think this is a good idea. * Fast selection of menu entries with keys (numbers as shortcuts?) - I remember discussions on the list about that already, it didn't make it to the mainstream, however. IMO, this shouldn't be added at the moment. The source code is already contaminated enough. So I like to clean up the code before adding ugly hacks any more. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: persistent install failures on HP Omnibook 4100
First of all, don't use the command install, unless you are familiar with GRUB internals, as described in the manual. Obviously, you don't know how the command works, since you didn't specify the `p' option, so use the command setup instead. I guess the problem may be due to the boot drive passed by your BIOS. If my guess is correct, you can get GRUB work well with setup. Send a report to this list, if GRUB still doesn't work even with setup. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Whistling in the dark
From: Nick Christopher [EMAIL PROTECTED] Subject: Whistling in the dark Date: Mon, 21 May 2001 09:33:22 -0400 Wondering how this effects grub? Why? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Making MENU on dumb terminals work
[[EMAIL PROTECTED] is added to Cc:.] From: Klaus Reichl [EMAIL PROTECTED] Subject: Re: Making MENU on dumb terminals work Date: Thu, 17 May 2001 10:13:32 +0200 (MET DST) Are there responsibles for administrative files like NEWS/TODO/BUGS/... or can thing be added here by everybody? The files should be modified by those who understand the whole project precisely. You may add items into NEWS, BUGS, INSTALL, etc. when you are making user-visible changes by your own decision, but I'd recommend discussing the changes before applying patches for them actually, since they must have a significant impact for the users. The file TODO should be maintained by the official maintainers (Gordon and me), because the items in the file represent future directions officially. Who takes care about generated files in the distribution wrt. to the version of the generator (e.g. configure)? Those who check in patches which affect the configuration. You wouldn't have to take care about this so much, because running make will regenerate the configure script appropriately, if you specify the option --enable-maintainer-mode to configure. I assume conflicting things are primarily discussed in bug-grub, or in private email? Basically, you should always use the mailing list. I don't like closed development. That isn't a Good Thing at all. That is just harmful. I have seen several projects that failed, because they had closed mailing lists, which made it quite hard for other people to take part in them. Send email privately, only if you are certain that you have a special reason to do that. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Warning fix for gcc-2.96
From: Pavel Roskin [EMAIL PROTECTED] Subject: Warning fix for gcc-2.96 Date: Mon, 14 May 2001 16:23:51 -0400 (EDT) gcc-2.96 from RedHat 7.0 emits a warning for almost every file when I compile the CVS version of GRUB: Note that there is no formal version such as 2.96 in GCC. See http://gcc.gnu.org/gcc-2.96.html. My understanding it that '##' is useless because the preprocessor cannot glue (in its own words, paste) the colon after the result of the macro expansion for EXT_C. Fortunately, we don't even need it. Feel free to apply your patch to the CVS yourself. If the macro doesn't require the concatenation really, I have no objection to your patch. However, don't forget that we shouldn't add any workaround for gcc-2.96, as GCC developers pointed out. That is a Red Hat's fault, so we shouldn't be blamed. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Time to fork the netboot code?
From: Mario Klebsch [EMAIL PROTECTED] Subject: Re: Time to fork the netboot code? Date: Thu, 10 May 2001 09:14:54 +0200 OTOH, tghe drivers for booting have to be simple. Why have to? There is no reason that drivers must be simple. Allthough the requirements differ, I am sure, it is possible to have both drivers in one source file, when using advanced preprocessor tricks. But this would at least require, that both driver flavours are maintained by the same set of people. If not, we will face the same problem, that we have today, with the etherboot drivers. I disagree. Most problems we faced are that Etherboot drivers don't work at all with several NICs and that they don't work well with multiple NICs. It's not hard to just incorporate drivers from another software package, in my experience with GNU Mach. So my suggestion would be to define a 'non-OS' network driver API, which is usable for all bootstrap projects, agree with these projects upon this API and then convert the existing drivers to the new API. I bet that this never be realistic. As long as I see, Key Yap has no interest in GRUB, and I feel even that he might assume that GRUB is a competitor. Consider why UDI is not widely used. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Time to fork the netboot code?
From: Mario Klebsch [EMAIL PROTECTED] Subject: Re: Time to fork the netboot code? Date: Thu, 10 May 2001 18:32:40 +0200 Why have to? There is no reason that drivers must be simple. I am sorry, I should have written 'should be simple'. I agree that it would be better that drivers are simple, but I don't think they _should_ be, as long as they are not too large or too complicated for us. IMO, it is much more important if they satisfy our needs. Isn't it the same problem? The developer of our driver does not regard our requirements (at least not that much, that we are satisfied). In Japan, there is an aphorism like A big thing covers a small one (my translation may be inappropriate, though). This means that even if a thing has extra parts, it satisfies you. For example, even when a small dish is enough for your meal, you can use a big dish with little trouble instead. I think our situation is very similar to this case. Normal OS drivers have (maybe a lot of) extra code for us, but they have features enough for us. They are designed to be used simultaneously (opposed to Etherboot), and they very often work better than Etherboot, because of the number of the users/developers. Anyway, most of GRUB users use GRUB to boot Linux and/or *BSD, so if their drivers don't work with their NICs, it isn't very important that GRUB works with their NICs. In addition, AFAIK, there is no card that works better with Etherboot than Linux or *BSD. Another reason that I'd like to use Linux or *BSD drivers is that they work on multiple architectures, while Etherboot is just an i386 boot loader, so their drivers often assume only the i386 architecture. Unfortunately, GRUB is also just an i386 boot loader at the moment, but I believe that GRUB should support multiple architectures in the future. To satisfy this demand, it is very important to find out a way to port GRUB code to other architectures efficiently, and their drivers are far better from the point of this view. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Time to fork the netboot code?
From: Chip Salzenberg [EMAIL PROTECTED] Subject: Re: Time to fork the netboot code? Date: Tue, 8 May 2001 11:40:29 -0700 extra feature anyway. So transition to a more powerful set of device drivers would be necessary. Hm. Has anyone started on this? No, AFAIK. However, you cannot do this alone. It is necessary to implement real memory management and handle protected-mode interrupts and real-mode ones concurrently, using v86-mode. That is exactly the plan which should be done after 1.0 release. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: SILO/GRUB coordination
So what was this thread for?? Will SILO developers join us? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Time to fork the netboot code?
From: Chip Salzenberg [EMAIL PROTECTED] Subject: Time to fork the netboot code? Date: Mon, 7 May 2001 18:23:11 -0700 Sadly, though I've tried to share this code, nobody wants it. The Netboot project doesn't care about such a feature, since netboot's code is designed to be flashed into NIC ROMs; and if you can do that, then you obviously are going to plug your cable into the NIC with the special ROM, so searching is unimportant. Meanwhile, the GRUB project doesn't want to keep modified versions of files that come from the Netboot project. s/Netboot/Etherboot/ Result: Nobody else gets my neat feature. *sigh* Have you seen my message: URL:http://www.mail-archive.com/bug-grub@gnu.org/msg0.html I don't think it is a good thing to use Etherboot drivers as is or maintain our own version of Etherboot drivers. As you said, Etherboot drivers have defects (for us), but IMO, it is NOT feasible to maintain ethernet drivers by ourselves, considerring that we are a small community, and the netboot feature of GRUB is an extra feature anyway. So transition to a more powerful set of device drivers would be necessary. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Maintainers? [Re: Booting from CD]
From: Thierry Laronde [EMAIL PROTECTED] Subject: Re: Maintainers? [Re: Booting from CD] Date: Thu, 26 Apr 2001 10:52:02 +0200 FWIW, I consider that you have pushed GRUB to a great state, and may I suggest that you officially release the cvs version ? There are no huge bugs, all the stuff is quite usable, and I think this version is a milestone. But YMMV... The worst point is that Multiboot Specification 0.7 hasn't been finished yet. I think it would be admissible that next GRUB version won't support all of the new features, but the spec itself MUST be complete. It is quite bad to bundle a beta version of the spec with a official GRUB distribution. Also, the manual contains several FIXME sections. This must be solved before 1.0 release. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Maintainers? [Re: Booting from CD]
From: Gordon Matzigkeit [EMAIL PROTECTED] Subject: Maintainers? [Re: Booting from CD] Date: 25 Apr 2001 16:10:01 -0600 So, it's almost inaccurate to call me a maintainer. Okuji has pulled that load almost entirely by himself for a long time now. Last I talked with him, he found it tiring, and is enjoying working on other projects in Ruby (http://www.ruby-lang.org/). I'm now working on an intelligent MySQL shell written by Ruby, so I have no spare time to devote myself to GRUB. I still have an interest in GRUB (perhaps because I know it could be much better), but I don't think I can do much work for GRUB (in a foreseeable future), in particular, user support. I must say, all I can do for now is to say, Yes, your patch is right. Please apply it to the CVS or No, you are wrong. Don't apply your patch to the CVS. I can't do anything more than advise. I have to say that Grub has a track record of burning people out (that is why I stepped forward in the first place to annex it from Erich Boleyn). So, if you want to work with Grub, either know how to pace yourself, or else be prepared to be overwhelmed. That's right. *sigh* Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Couldn't boot from CD on IBM ThinkPad 600X
From: Jeff Sheinberg [EMAIL PROTECTED] Subject: Re: Couldn't boot from CD on IBM ThinkPad 600X Date: Sat, 31 Mar 2001 13:49:10 -0500 Please post the patch directly to this list. The savannah web interface is not working for me. I have the same opinion. I often work in an off-line environment, so using on-line data is painful. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Fw: Grub + elf section table
Last week, you told me on the bug-grub mailing list that if I wanted to
be able to use the elf section table with grub, I should post a patch.
So that is what I have done :-)
This little patch is to be applied on a grub-0.5.96.1 source tree, that
I download on the Web.
I have tested it with my kernel, and it seems to work fine.
If you found some bug, or if my patch would not fit the "way of
thinking" of grub, please let me know and I will be very happy to try to
improve it and to make it more useful.
Best regards.
Julien
diff -cr grub.old/stage2/boot.c grub/stage2/boot.c
*** grub.old/stage2/boot.c Mon Mar 26 22:06:45 2001
--- grub/stage2/boot.c Fri Mar 30 01:29:01 2001
***
*** 493,499
else
/* ELF executable */
{
! int loaded = 0, memaddr, memsiz, filesiz;
Elf32_Phdr *phdr;
/* reset this to zero for now */
--- 493,500
else
/* ELF executable */
{
! int loaded = 0, memaddr = 0, memsiz, filesiz, symtab_err = 0;
! int tab_size = 0, sec_size = 0;
Elf32_Phdr *phdr;
/* reset this to zero for now */
***
*** 548,554
errnum = ERR_EXEC_FORMAT;
else
{
! /* FIXME: load ELF symbols */
}
}
}
--- 549,624
errnum = ERR_EXEC_FORMAT;
else
{
! Elf32_Shdr * shdr = NULL;
! int j;
!
! mbi.syms.e.num = pu.elf-e_shnum;
! mbi.syms.e.size = pu.elf-e_shentsize;
! mbi.syms.e.shndx = pu.elf-e_shstrndx;
!
! /* we should align to a 4K boundary here for good measure */
! if (align_4k)
! cur_addr = (cur_addr + 0xFFF) 0xF000;
!
! tab_size = pu.elf-e_shentsize * pu.elf-e_shnum;
!
! grub_seek(pu.elf-e_shoff);
! if (grub_read ((char *) RAW_ADDR (cur_addr), tab_size)
! == tab_size)
! {
! mbi.syms.e.addr = cur_addr;
! shdr = (Elf32_Shdr *) mbi.syms.e.addr;
! cur_addr += tab_size;
!
! printf (", shtab=0x%x", cur_addr);
!
! for ( j = 0; j mbi.syms.e.num; j++ )
! {
! /* This section is a loaded section, so we don't care */
! if (shdr[j].sh_addr != 0)
! continue;
!
! /* This section is empty, so we don't care */
! if (shdr[j].sh_size == 0)
! continue;
!
! /* Align the section to a sh_addralign bits boundary */
! cur_addr = (cur_addr + shdr[j].sh_addralign)
!- (int) shdr[j].sh_addralign;
!
! grub_seek(shdr[j].sh_offset);
!
! sec_size = shdr[j].sh_size;
!
! if (! (memcheck(cur_addr,sec_size)
!(grub_read ((char *) RAW_ADDR(cur_addr), sec_size)
! == sec_size) ))
! {
! symtab_err = 1;
! break;
! }
!
! shdr[j].sh_addr = cur_addr;
! cur_addr += sec_size;
! }
! }
! else
! symtab_err = 1;
!
! if ( mbi.syms.e.addr RAW_ADDR(0x1) )
! symtab_err = 1;
!
! if ( symtab_err )
! {
! printf ("(bad)");
! mbi.syms.e.num = 0;
! mbi.syms.e.size = 0;
! mbi.syms.e.addr = 0;
! mbi.syms.e.shndx = 0;
! cur_addr = 0;
! }
! else
! mbi.flags |= MB_INFO_ELF_SHDR;
}
}
}
diff -cr grub.old/stage2/i386-elf.h grub/stage2/i386-elf.h
*** grub.old/stage2/i386-elf.h Mon Mar 26 22:06:45 2001
--- grub/stage2/i386-elf.h Fri Mar 30 01:20:34 2001
***
*** 95,100
--- 95,114
(h.e_ident[EI_VERSION] == EV_CURRENT) (h.e_type == ET_EXEC) \
(h.e_machine == EM_386) (h.e_version == EV_CURRENT))
+ /* section table - ? */
+ typedef struct
+ {
+ Elf32_Word sh_name;/* Section name (string tbl index) */
+ Elf32_Word sh_type;/* Section type */
+ Elf32_Word sh_flags; /* Section flags */
+ Elf32_Addr sh_addr;/* Section virtual addr at execution */
+ Elf32_Off sh_offset; /* Section file offset */
+ Elf32_Word sh_size;/* Section size in bytes */
+ Elf32_Word sh_link;/* Link to another section */
+ Elf32_Word sh_info;/* Additional section information */
+ Elf32_Word sh_addralign; /* Section alignment */
+ Elf32_Word sh_entsize; /* Entry
Re: ELF symbols
From: Johan Rydberg [EMAIL PROTECTED] Subject: ELF symbols Date: Thu, 29 Mar 2001 17:21:14 +0200 In stage2/boot.c i found the following line: * FIXME: load ELF symbols */ Well, when will this be fixed? When someone sends a patch. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Couldn't boot from CD on IBM ThinkPad 600X
From: Anton Safonov [EMAIL PROTECTED] Subject: Couldn't boot from CD on IBM ThinkPad 600X Date: Thu, 29 Mar 2001 14:23:30 +0200 Have found strange problem! I have a bootable CD with GRUB on it and trying to boot from it on subject. Tried several versions, got: 0.5.94: "stage1 " 0.5.97: "GRUB Read error" What could be the reason? It is likely that the BIOS is buggy. Please try to investigate a workaround. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: location guarantees of multiboot info objects
From: "Rogelio M. Serrano Jr." [EMAIL PROTECTED] Subject: location guarantees of multiboot info objects Date: Fri, 30 Mar 2001 09:24:21 +0800 (PHT) are there guarantees as to where grub loads the objects pointed to by the multiboot info struct? What do you mean by objects? are everything loaded after the kernel? The Multiboot Standard 0.6 doesn't specify any way to define the locations of Multiboot modules. The next version will have some restrictions on them. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: loading kernels with different LMA and VMA (fwd)
From: "Rogelio M. Serrano Jr." [EMAIL PROTECTED] Subject: Re: loading kernels with different LMA and VMA (fwd) Date: Thu, 29 Mar 2001 01:41:45 +0800 (PHT) It does help. The remaining problem now is what physical address to use for an entry address if the entry address that i get from the elf header is virtual? Maybe GRUB should jump to (LMA + (entry point) - VMA) instead of (entry point), because GNU linker sets every symbol to VMA rather than LMA, though I don't know what other linkers do. One thing I care is that this change could break existing Multiboot kernels which might set their entry points explicitly. Does anybody have any objection to this change? could this be the reason why the grub implementation assumes that LMA = VMA? No. In the past, GRUB always used VMA incorrectly, and I changed GRUB would use LMA but I didn't change the way to deal with an entry point. Now I realize that this was my mistake. Sorry. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Elf kernel
From: Julien BORDET [EMAIL PROTECTED] Subject: Elf kernel Date: Wed, 21 Mar 2001 10:10:49 +0100 I have a problem with grub that may be a bug. I boot with grub a ELF kernel, and then I want to have some link information about it. So I want to retrieve the ELF information (flags[5]). But neither flags[4] nor flags[4] of the mbi is set. Is this normal ? Any idea ? GRUB doesn't support for loading ELF symbols at the moment. That's a fault, of course. Send a patch, if you want the feature. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: A rather silly question about memory maps.
From: "Groman" [EMAIL PROTECTED] Subject: A rather silly question about memory maps. Date: Tue, 13 Mar 2001 19:56:59 -0800 Question #1: Does GRUB at it's current CVS stage support guaranteed memory maps?(as in the multiboot standard) Yes. Question #2: If GRUB supports memory maps, does it mark the areas where it puts vital data as reserved? No. The memory map indicates which areas of memory is usable as ordinary RAM, as the spec says, regardless of the contents of the areas. Question #3: If GRUB marks occupied areas as available(with modules, multiboot info and the kernel), how hard would it be to modify GRUB to give an option of marking those areas as reserved? It doesn't matter how hard. GRUB _must not_ mark such areas as reserved, to comply with the spec. Question #4: Am I totally blind and is there something about these areas in the multiboot standard? Unfortunately, Multiboot Standard 0.6 wasn't strict enough, so you can mistake the real intentions easily. I'm currently working on Multiboot Specification 0.7, and I hope that my work will solve such a confusion. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Can't boot with 550K of memory
From: Krzysztof Leszczynski [EMAIL PROTECTED] Subject: Re: Can't boot with 550K of memory Date: Thu, 8 Mar 2001 21:32:52 +0100 I tried several boot loaders and found that PXE version of SYSLINUX just worked :-) but all others including bpbatch didn't. There must be something in SYSLINUX that makes strange architectures work. That depends on which version of Linux you use. Older Linux cannot be located at other than 0x9, so you cannot boot such a kernel on lower memory machines. Recently, H. Peter Anvin added support for putting a kernel and its command-line at arbitrary addresses into the Linux/i386 boot protocol, so there is no surprise that syslinux supports the new feature. Unfortunately, GRUB doesn't utilize the feature at the moment, and it is not trivial to add support for lower memory machines. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: GRUB bootp not working with WD/SMC NICs
From: Peter Kaczuba [EMAIL PROTECTED] Subject: GRUB bootp not working with WD/SMC NICs Date: Wed, 7 Mar 2001 13:10:44 +0100 There seems to be a problem in bootp not working when using the WD/SMC NIC driver. I tested this on several machines that have a WD/SMC ISA NIC using GRUB 0.96.1 or 0.97 from CVS. On a machine that has a 3COM 90x PCI NIC all went fine. GRUB does recognize the WD/SMC NICs correctly with the right memory addresses but when running bootp the only answer is "sleep". I checked out the ethernet packets GRUB was sending with a sniffer and in deed only junk arrived to the server (something like "fragmented IP packet" with bogus IP and MAC addresses). Does your NIC work with Etherboot? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: via-rhine driver
From: Mario Klebsch [EMAIL PROTECTED] Subject: via-rhine driver Date: Wed, 7 Mar 2001 21:56:01 +0100 1. I configured grub to support three different network drivers (via-rhine, 3x90x and PCI based ne2k). The NIC in my test system was a via-rhine board. I added its PCI vendor- and device ID to the list of known PCI cards. But after executing the bootp command, my via-rhine was probed to be a 3c90x. :-( Of course, all paramerters (including the MAC-address) were wrong. It seems, the probe()-routines are not checking PCI-vendordevice-IDs. Try the CVS version of GRUB. 2. My via-rhine does not work. I had a look on the source an I wonder, wether via-rhine is under active development. Is anybody is working on via-rhine.c? It would be a big help, if there is anybody to discuss internal problems with. Please make sure that the problem is the via-rhine driver itself, rather than because you enabled multiple network drivers. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Grub Lover
From: "Tom Browder" [EMAIL PROTECTED] Subject: Grub Lover Date: Sat, 3 Mar 2001 07:32:06 -0600 But I noticed the menu looks much different from my original installation: the screen is wider and not as attractive as the menu before (same version). How different? Other than color, how may the menu apearance be customized? What do you want to customize? P.S. My windows machine is the one hooked up to the world, but my Linux box is used heavily and modified often. I have attached an Excel spreadsheet that I have found to be very useful in recording my system disk parameters. Maybe it will be useful to others. Please don't distribute data produced by proprietary software to this list. As a GNU maintainer, I have the responsibility to deprecates use of proprietary software. See http://www.gnu.org/philosophy/, for more information. (Personally, I think it is up to you what programs you use, because that is also your freedom, IMO. But my personal idea is a different matter here.) Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCHES] saving, displaying and using information given viabootp
I think I should have told you my idea, before you have finished the work. The way you want is quite similar to the diskless images. In the diskless images (pxegrub and nbgrub), you can specify a configuration file on a remote host dynamically using the tag 150, so you can control client machines completely from the remote host. Therefore, what you need here is not an ad hoc environment variable, but the functionality that loads a remotely defined configuration file even in stage2. To do that, you just need to add an option to bootp/dhcp, so that bootp/dhcp overwrites the name of a configuration file and loads the file, just like what pxegrub/nbgrub does. For example, add --with-configfile into bootp, and build your GRUB images, like this: $ cat EOF embedded_configfile bootp --with-configfile $ ./configure --enable-card --enable-preset-menu=embedded_configfile Or build GRUB normally and put the file "embedded_configfile" in a local disk as the default configuration file. Then, you can control what your client machines do from a remote host, as long as your BOOTP/DHCP server is set up properly. IMO, this is a cleaner way, since this doesn't break any of GRUB paradigms. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Serial support - one more point
From: Christoph Plattner [EMAIL PROTECTED] Subject: Serial support - one more point Date: Fri, 02 Mar 2001 22:16:58 +0100 The problem I see is, that the menu file or the preset menu file is executed after the ethernet probes, etc. I see. Then, what do you think about sending the automatic bootp/dhcp request _after_ loading a preset menu? I don't think this is difficult to be implemented. On the other side, there is nearly no BIOS, too, which can handle poorly the serial line. We don't use BIOS for serial controllers anyway. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCHES] saving, displaying and using information givenviabootp
From: Christoph Plattner [EMAIL PROTECTED] Subject: Re: [PATCHES] saving, displaying and using information given viabootp Date: Fri, 02 Mar 2001 23:03:58 +0100 Or we make the stage2-diskless module automatically in the build process with cat start diskless stage2-diskless as we do cat start pre_stage2 stage2 and cat nbloader diskless nbgrub I don't like that, because: 1) There is no guarantee that the image "start" will load the whole image of "diskless", since the number of the sectors (of "stage2") is embedded in "start". You must recreate "start", according to that of "diskless". 2) It is generally a Bad Thing to have many different images. That is difficult for users to understand and for maintainers to maintain. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
prepare next test release
Because we haven't released any GRUB test version for a while, we need to prepare for making a test release now. So I and Gordon will concentrate on the manuals rather than new features. I expect that this will take about two weeks. The test release will be called ``0.90'', because we won't release 0.6 but 1.0. I really hope that we won't have to release 0.91. As a maintainer, I think I should tell you what prevents us from making a public release. The requirement is that GRUB supports all the features in Multiboot Specification 0.7. For now, the missing features are disk I/O ports detection support and graphics support. I have preliminary code for the former using Virtual 8086 mode, but the code is not ready even for testers. The latter is relatively easy to implement, because the basic code is already included in the official GRUB source tree. I guess that it will take at least one week to debug the v86 code, and I have been (and will be) quite busy, so I haven't touched the code for several weeks. If you are willing to work on it, let me know, and I will send you my local source tree. For this work, you need deep knowledge on the Intel x86 architecture and GNU assembler. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Patch for EtherExpressPro100
From: Christoph Plattner [EMAIL PROTECTED] Subject: Re: Patch for EtherExpressPro100 Date: Thu, 01 Mar 2001 00:54:01 +0100 Again, I think we should speek about the future strategy to be able to really copy in the current etherboot-drivers only. I won't, because I plan to use device drivers in other software rather than Etherboot. Possibly, Linux, NetBSD, or OSKit. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Patch for EtherExpressPro100
From: HORIKAWA Kazunori [EMAIL PROTECTED] Subject: Re: Patch for EtherExpressPro100 Date: Wed, 28 Feb 2001 01:11:08 +0900 I checked ehterboot. Current version of etherboot has already fixed it. So, patch is not needed. Ok, then I'll update only the eepro100 driver, as I have too little time to update all the drivers. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Patch for EtherExpressPro100
From: Christoph Plattner [EMAIL PROTECTED] Subject: Re: Patch for EtherExpressPro100 Date: Tue, 27 Feb 2001 22:35:08 +0100 This leads me to the question, how we will treat the GRUB 'netboot' tree in sync with etherboot. One idea was to have real a separate tree for the driver files, so that they can be quite copied in. What will be the strategy for that ? I have no plan about that. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Fw: GRUB: Hercules console and vbeset command
I'm sorry that I couldn't have enough time as soon as I got your patch, but I finally added hercules support into the CVS version. Because I didn't think the code should be written in assembly, I translated it to C with inline assembly. In addition, I separated the hercules console type from the normal console type. Note that I haven't tested the code, because I have no hercules terminal here. If you find any error, let me know, please. Thanks, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
--disable-auto-linux-mem-opt (Was: Re: ack! grub bug...)
With the CVS version, you can now specify `--disable-auto-linux-mem-opt' to the configure script. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCH] Displaying boot file name after calling bootp
From: Thierry Laronde [EMAIL PROTECTED] Subject: [PATCH] Displaying boot file name after calling bootp Date: Sat, 24 Feb 2001 22:32:24 +0100 The information about the name of the boot file is, for me, needed, Why? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [patch] grub-install for FreeBSD
From: HASEGAWA Tomoki [EMAIL PROTECTED] Subject: [patch] grub-install for FreeBSD Date: Mon, 26 Feb 2001 20:49:53 +0900 (JST) I hack grub-install utility for FreeBSD(-4.2). I test only installation to /dev/ad0 on my FreeBSD-4.2-STABLE machine, but even da or so will work. Many thanks for your contribution! I'll apply your patch. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [PATCH] default_entry and fallback
From: Thierry Laronde [EMAIL PROTECTED] Subject: [PATCH] default_entry and fallback Date: Mon, 26 Feb 2001 17:33:07 +0100 By default, if the default is wrong, it is reset to 0. Some users were a bit puzzled about that, expecting the default to be set to fallback. That's a good idea. Thanks. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: A tangential plea for documentation
From: Matthias Granberry [EMAIL PROTECTED] Subject: A tangential plea for documentation Date: 24 Feb 2001 04:02:06 -0600 In some of the .S files that ship along with the GRUB (stage1.S in particular), there is a line at the start of the file reading: /* -*-Asm-*- */ I'd bet nearly anything that this is an emacs-related mode line. Is there anyone here that can explain these to me or at least tell me where to look? Clearly, the question should be asked to Emacs people, so I mention only the pointer: the section "Local Variables in Files" in the Emacs manual. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: ack! grub bug...
From: Jeff Garzik [EMAIL PROTECTED] Subject: Re: ack! grub bug... Date: Thu, 22 Feb 2001 19:29:04 -0500 Because at that point, we are working around a grub-specific problem in the kernel, which is caused by grub working around a now-resolved kernel problem! :) It's a workaround for a workaround, and that is not good engineering. Yeah, I know. But bad things cannot be removed immediately, merely because they are bad. BTW, I just got confirmation from Alan Cox that 2.2.19pre backports the stable-for-a-while-now 2.3/2.4 ram detection code. Note that this is mainly a distro issue, -tangent- and related to the current discussion but not directly affecting the discussion. [not using mem=XX unless required has always been policy... its just that 2.2.17 kernels have shoddy ram detection] I think that makes it clear that I and you are sitting in different fields... Because you are an OS distributor, you can control most of the software programs the user installs, so if you ship your distribution with a newer kernel, you don't have to care about older kernels. But I have to do, because many GRUB users still use older (and buggy) kernels. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: ack! grub bug...
From: Jeff Garzik [EMAIL PROTECTED] Subject: Re: ack! grub bug... Date: Fri, 23 Feb 2001 10:02:39 -0500 This will solve the problem... for problematic machines. However, it is merely a bandaid... policy is that mem=XX is an -override- parameter, to be used only when necessary. IMHO we should move back towards defaulting grub to --no-mem-option in general, in the future. (apparently, it cannot be done now, for the general grub release) Agreed. I keep that in mind. I guarantee that we will change the default behavior, once a public version is released, so that we can introduce some incompatibility. As for now, I think MandrakeSoft will make a vendor patch that defaults to --no-mem-option, since we can control our kernel versions a bit more... Because I don't like that there are so many variants of GRUB, what do you think about that we add a configure option into the official GRUB, so that you can change the default behavior optionally? For example: $ ./configure --disable-automatic-linux-mem-option With this option, all you need to modify is grub.spec, and you don't have to touch the source code itself. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Jeff Garzik jgarzik@mandrakesoft.com] Re: ack! grub bug...
From: Christoph Plattner [EMAIL PROTECTED] Subject: Re: [Jeff Garzik [EMAIL PROTECTED]] Re: ack! grub bug... Date: Thu, 22 Feb 2001 09:16:16 +0100 So the user can decide himeself using kernel paramters, like kernel /boot/vmlinuz mem=$MEM root=/dev/hda2 etc If there is enough information, also things like NFSROOT and IP configuration can be setup. That would make GRUB incompatible against older versions. That is unacceptable for now. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk)
From: Marty Connor [EMAIL PROTECTED] Subject: Re: [Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk) Date: Thu, 22 Feb 2001 10:08:00 -0500 What I am wondering is if txb at 0x1 is incompatible with something that grub is doing. I think the only drivers that do this are tulip and realtek. I would try defining USE_INTERNAL_BUFFER and see if that might change your result. Just a thought. The macro is always defined in GRUB. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: Source for booting CDs
From: Thierry Laronde [EMAIL PROTECTED] Subject: Source for booting CDs Date: Wed, 21 Feb 2001 11:27:53 +0100 As far as I know, GRUB started from the *BSD bootloader, and this license is a free one, AFAIK. Does it cause a problem to start working with it in order to include the support in GRUB ? No, but GNU recommends GPL rather than BSD-style license, so please avoid using code under BSD-style license, whenever you can use alternative code distributed under GPL (or LGPL). Also, note that I prefer code whose copyright is assigned to the FSF, to code whose copyright someone else retains. This does _not_ mean that you shouldn't steal code from other software, but I'd recommend writing code from scratch yourself, if that is feasible. For examples, I stole code from Etherboot, because I didn't think it would be worthwhile implementing network drivers myself and Etherboot was under the term of GPL, while I wrote the serial device driver myself, because that was really easy and I could find no FSF-copyrighted serial driver. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: FYI: GRUB size reduced
From: Thierry Laronde [EMAIL PROTECTED] Subject: FYI: GRUB size reduced Date: Wed, 21 Feb 2001 16:27:53 +0100 The result is a 66372 Ko stage2, and I find this size reasonable for an installation floppy, if combined with the use of an extended format (I have not tested at the moment the patches from Jochen). In my experiment, I obtained the size 50kb. The key was to get rid of fancy features (such as password) from stage2.c. At the moment, this is the only way to reduce the size of stage2. However, I think it will be the best way to compress the most part of stage2, in the future. The size of pre_stage2 is about 86kb by default, and the size of pre_stage2.gz is about 46kb. Because the bootstrap code is 1kb and the code size of gunzip.c is about 5kb, if stage2 decompresses pre_stage2 on the fly, the size of stage2 would be 52kb. This size is comparable to that of stage2 obtained by omitting many features in the tricky way, even though nothing is disabled here. That is one of the things I want to do in GRUB 2. A plan related to that is to move the user interface from the core image to an external module (except for the minimal interface required for recovering). For instance, as the menu interface need not to be supported, unless a configuration file is found, the functions used for the menu interface can completely be removed from the core. This will reduce the size of the core image greatly, and, if we are lucky, the image will be able to be embedded right after a MBR (so you won't have to use Stage 1.5 any longer). Because the empty space after a MBR is usually merely 31kb (the size we can use for real code is 31 - 1 - 5 = 25kb), this will be a big challenge! Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Jeff Garzik jgarzik@mandrakesoft.com] Re: ack! grub bug...
From: Pixel [EMAIL PROTECTED] Subject: [Jeff Garzik [EMAIL PROTECTED]] Re: ack! grub bug... Date: Wed, 21 Feb 2001 23:40:39 +0100 (CET) It works around a kernel bug. That is wrong in and of itself. A kernel bug fix belongs in the kernel, not in grub. You're just talking about an utopia. Because Linux was (is?) poor at memory detection, people wanted GRUB instead of Linux to probe memory. IMO, most of the code of any boot loader is wasted for workarounds, because of stupid kernels, buggy BIOSes, and so on... Newer machines have several regions of reserved memory outside and inside these regions. grub's actions are suicide on newer laptops, and machines like servers with lots of memory. Laptops have special sections of memory above 1MB which must be reserved... Ditto for ACPI tables. Using mem=XXX completely eliminates any information that the BIOS has provided to the OS. That looks like a failure in Linux's kernel parameter scheme. The mem= option was designed for older PC architectures, so the real evil is the option itself. In fact, if you want to limit the size of memory used by Linux, you need to specify the option anyway, and Linux will hang up. This means that the problem is in Linux rather than in GRUB. Grub cannot do this on kernel 2.4, and probably should not do it on kernel 2.2. I must check for kernel 2.2... I think the 2.2 bug is fixed. Definitely not for 2.4. It makes the kernel unstable to do so. And, the Linux bootstrap interface never provide the version number of the kernel itself, so GRUB can do nothing, whether you use Linux 2.2, 2.4, or 2.0. Note that Linux 2.0.x and older Linux 2.2.x are still in use, so we shouldn't disable the automatic passing of the mem= option. IMO, that problem should be fixed in Linux rather than GRUB. And, the command "kernel" supports the option `--no-mem-option' so that you can specify that GRUB shoulnd't pass the mem= option automatically, anyway. *sigh* Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: VSTa FS patch
commit-grub is not the right place to send a patch. Use bug-grub instead. And, more importantly, your patch doesn't include any copyright or license notice, so I cannot integrate your patch. Also, you should write ChangeLog entries. Regards, Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: TODO : Add more --disable-FOO...
From: Thierry Laronde [EMAIL PROTECTED] Subject: TODO : Add more --disable-FOO... Date: Tue, 20 Feb 2001 16:47:58 +0100 Using defines (with builtins functions), one can achieve some high flexibility on compile time. But, for basic usages, this is unpractical. So we can group via --disable-package several functions that belong to the same group. I think Bash-like strategy would be better. That is, grouping options is performed at the configure level but not at the source level. Please take a look at Bash source distribution. So, question : do you think that adding the #ifdef NAME_FUNC / #endif for all the functions that are not core boot ones, and adding 4 or 5 "packages" options in configure is the good way to go ? I'm not sure. If you want to reduce the size significantly, you will have to omit many things as well as some of the builtin functions. For example, omitting long help messages decreases the size very much (I don't remember exactly). If you want to boot a single kind of operating system, you can disable support for other operating systems. Because boot floppies are somewhat special, I don't see if there exists the best way generally. Possibly, if you want to get as small size as that of grub-0.5, you will have to disable fancy features that are difficult to be ommited just by cpp, such as file name completion. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: O_SYNC and FreeBSD 4.2-RELEASE
From: John Fremlin [EMAIL PROTECTED] Subject: O_SYNC and FreeBSD 4.2-RELEASE Date: 19 Feb 2001 00:05:11 + When I tried to compile GRUB 0.5.96.1 it couldn't find a definition for O_SYNC. I hope this isn't crucial because I disabled it with the patch below. Thanks for your report, but that problem has already been fixed in the CVS version. I'm sorry for the inconvenience. Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 -problem in understanding !
From: Christoph Plattner [EMAIL PROTECTED] Subject: Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in understanding ! Date: Wed, 14 Feb 2001 10:06:52 +0100 If I don't use GRUB in the "diskless" mode, and load the kernel plus modules manually per tftp, the kernel works. Then, perhaps your Etherboot program doesn't clean up the status of the network card properly, before it executes GRUB. Because in GRUB, the difference between diskless booting and network booting is only their formats (not essential), I don't think GRUB should be blamed here. Which version of Etherboot do you use? Okuji ___ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
