Re: GNU GRUB maintenance
Am Donnerstag, den 08.10.2015, 21:28 -0400 schrieb Konrad Rzeszutek Wilk: > Also an kernel.org git account could be requested. It is there for > syslinux, dracut, bluetooth, etc. GRUB2 could be hosted there as > well? > What features does kernel.org provide which savannah.gnu.org doestn't have? Plain Web git and space for the tarballs is already available directly from GNU. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Development practices?
Am Dienstag, den 22.09.2015, 14:28 -0400 schrieb Konrad Rzeszutek Wilk: > > What if the companies that employ the committers allowed one day a > week > > to focus on GRUB2 review/maintaince/etc? Would that help? > > > > Or is it unrealistic to expect that from committers employer's? > > > > ping? Well my company only pays me for my in-firm training I make there. Due to the fact I'm not a full employee, I don't think I need to ask if I get some time paid for doing general Debian/GNU stuff. Instead of stuff with which the company earns its money ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Development practices?
Am Dienstag, den 08.09.2015, 13:57 -0400 schrieb Konrad Rzeszutek Wilk: > On Thu, Sep 03, 2015 at 03:34:29PM -0400, Konrad Rzeszutek Wilk > wrote: > I don't know enough about the community (or the history) to > > understand it but would very much appreciate input. > > And if I have offended somebody with my questions + feeble > > analysis: my deepest apologies - and please straighten me out! > > > > > > From what I have gathered so far the not enough reviewers > > is tied in folks being overworked - so there simply was no > > point of posting on the mailing list as nobody had the time > > to review it or test it properly? > > Hi Konrad, back in 2008/2009 (when Marco Gerards gave over Maintainance to Robert Millan) there were indeed not much people actively reviewing code. Active people on the mailing list was just given commit access. It was expected that they only commit stuff without posting which doesn't need a review and complies with the rules back at that time. Due to me missing a few years on the mailing list, I can't tell you unfortunately how it compares to today. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Your contributions to grub.enbug.org
Am Donnerstag, den 31.03.2011, 21:17 +0200 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Hello, when discussing after the temporary wiki problems it was decided > that it would be better to migrate the information from wiki into the > manual and developper manual where legal reasons permit. You have > contributed to the wiki, would you agree to consider that your > contributor agreement covers wiki as well? > I agree, too. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2 for DEC Alpha?
Am Donnerstag, den 04.02.2010, 22:24 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > > Matt Turner wrote: > > Hi, > > > > I learned today that GRUB 2 aims to be cross platform and already > > supports in some form PPC. > > > > Is there any interest in supporting the DEC Alpha (SRM) platform? > > > > > Is there still any interest in this? I have a possibility of buying > cheaply an Alpha Workstation. If I do I can lend a hand in porting but > I > don't want to do the whole porting myself. (nor I see any point if > nobody is interested in it) Debian squeeze will probable be released without the alpha Architecture [0] and Wikipedia tells there are no new Alphas sold since April 2007. I think there are more important things to do then adding support for an architecture which is already in the progress to die. [0] http://release.debian.org/squeeze/arch_qualify.html -- 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: beep support?
Am Dienstag, den 02.02.2010, 14:09 +0100 schrieb Samuel Thibault: > Hello, > > Some blind people have asked me about beep support. I think at some > point there was somebody working on a module to get sound support, but > there isn't such thing in the main grub2 source, only > case '\a': /* FIXME */ break; > ... > There's play command in commands/i386/pc/play.c but I still don't know what file format it actual plays. -- 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: grub-mkrescue no longer supports adding extra files
Am Dienstag, den 19.01.2010, 03:03 +0100 schrieb Michal Suchanek: > Hello > > in the past grub-mkrescue allowed for adding files into the rescue medium. > > This is no longer supported which I find quite annoying. The rescue > image does not support any font and I cannot put any menu on it. > > It would be nice if the overlay functionality could be restored. > > Thanks > > Michal It still does. It's just not anymore --overlay but SOURCE, i.e. grub-mkrescue --output=grub.iso overlay1 overlay2 ... -- 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: keyboard layout patches
Am Montag, den 18.01.2010, 00:10 + schrieb Carles Pina i Estany: > Hello, > > I've done a first version of keyboard_layout. Find a patch attached, or > check the branch: > bzr.savannah.gnu.org/srv/bzr/grub/people/cpina/keyboard_layouts Nice work, though I haven't yet looked at the patch itself. > > How could grub-mkinstall (00_header.in) know the current keyboard in the > system? I wold tweak 00_header.in to generate the keymap file and setup > it. I think that's completely distribution specific and maybe even can depend on the window manager/desktop enviromnent you use (if you use one). So I suggest to just use a variable in /etc/default/grub for that. -- 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: gfxmenu not working in debian testing ( aka squeeze )
Am Samstag, den 09.01.2010, 15:50 +0530 schrieb J. Bakshi: > Have I missed something in my config or the testing branch is still no > ready to support it ? > Seems like you missed my reply to your initial mail about this: Only Debian experimental (and my PPA for Ubuntu though) has Colin Bennets theming code (gfxmenu). -- 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: [RFC] Dynamic device.map
Am Donnerstag, den 07.01.2010, 23:27 -0600 schrieb Bruce Dubbs: > Colin Watson wrote: > > On Thu, Jan 07, 2010 at 04:18:37PM -0600, Bruce Dubbs wrote: > >> Robert Millan wrote: > >>> On Wed, Jan 06, 2010 at 04:00:23PM +, Colin Watson wrote: > >>>>> Just leave it with (/dev/foo). > >>>> You mean literally with the parentheses? I don't understand, > since /dev/ > >>>> names will be unintelligible to GRUB when running outside an > operating > >>>> system. > >>> Yes. This just means we'd have "set root=(/dev/foo)" statements > in grub.cfg, > >>> but those are just meant as a backward compatibility hack for > pre-UUID GRUB > >>> installs. > >> Are you are implying that UUID will be the only way? I don't use > >> initrd's on my systems so I need root=(hd0,x) or root=(/dev/foo). > >> AFAIK initrd is the only way to load with UUIDs. > > > > I think you're mixing up two different things. There are two 'root' > > variables involved: > > > > 1) GRUB's 'root' variable, its base for filesystem operations > > 2) The root= parameter passed to the Linux kernel, which > identifies > > the desired root filesystem > > > > Robert is talking about 1), but whether you use an initrd/initramfs > is > > only relevant to 2). > > OK, I didn't realize set root was capable of using UUIDs. I did know > that the two root entries were different. I got that mixed up with > the > search command combined with the root=UUID=... which I think needs > initrd. > > Do I have it right now? set root only supports plain GRUB devices. search --set sets $root (for GRUB, not for Linux) to the first device found with that UUID, LABEL or file. Depending on the other argument to search command. > Should 'set root' be renamed to 'set grubroot'? I think something > like > that would prevent some confusion. > >-- Bruce I don't get why there's a confusion at all. It should be clear that the value specified with the linux command is for it and not for GRUB. -- 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: GRUB 1.98 available in debian lenny, How to get fancy terminal ?
Am Donnerstag, den 07.01.2010, 10:13 -0500 schrieb Chris Jones: > On Thu, Jan 07, 2010 at 09:29:57AM EST, J. Bakshi wrote: > > > Hello everyone, > > > > I am happy to see the availability of grub 1.98 in debian lenny > after > > the up-gradation I did yesterday night. The /boot/grub folder now > > contains unicode.pf2, unicode.ppf as well as GRUBtheme folder > > containing winter etc. theme. Is there any doc to configure the > > themes, vga terminal etc, so that I can do some experiment with all > > these cool features ? > > debian lenny? [...] > or are you talking about testing or unstable? > > CJ Even lenny backports still has 1.97 beta3. I already thought I totally missed something but the usual Debian pages don't tell about some mysterious upload. Only Debian experimental (and my PPA for Ubuntu though) has Colin Bennets theming code (gfxmenu). But we don't ship them. The only docs about it that exist currently are the ones on Colin's site AFAIK: http://grub.gibibit.com/ But they're outdated now, the theme format has been changed and Colin's current themes don't work anymore AFAIK -- 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: GRUB update problems
Am Dienstag, den 05.01.2010, 13:58 -0500 schrieb Henry W. Peters: > > Felix Zielcke wrote: > > Am Dienstag, den 05.01.2010, 13:07 -0500 schrieb Henry W. Peters: > > > >> I run Debian Lenny sid/squeeze, the updater this morning just > >> "updated" > >> my GRUB2 version... (not sure of the version). > >> > > > > normally it doestn't make sense to have stable (lenny), testing > > (squeeze) and unstable (sid) in /etc/apt/sources.list > > Usually you only use one of them. > > > > > >> I probably need to get the display resolution in GRUB to correspond > to > >> > >> my ACTUAL desktop resolution... I'm guessing; so, until GRUB works > >> out > >> what appears to me, to be a 'bug' (?), or I can know what to do to > >> remedy... perhaps there is a workaround someone can suggest? > >> > > > > I think you didn't set a device in the debconf prompt which asked > for > > one. > > You need to run grub-install to update it. Else the graphical > terminal > > won't get anymore enabled by update-grub/grub-mkconfig. > > > > And also check GRUB_GFXMODE in /etc/default/grub, which is the > > resolution for GRUB if the graphical terminal is enabled. > > > > > Not to seem ungrateful, but grubspeak is not too helpful at the > moment, > but nonetheless, I did try several of your suggestions (perhaps not > correctly, because of maybe not understanding too well?)" > > # grub-install > > This was the message I got... I have no clue as to what "grub-install > [OPTION] install_device" means... this is to say, what is the option? The device where you want to have GRUB in MBR/bootsector. I.e. /dev/sda or /dev/sdb etc. Choose the disk your BIOS boots from. Or if you don't know just install to all you have. > Then I did check the /etc/default/grub file, & this is what I got (I > took out the '# at the GRUB_GFXMODE=1440x900' & changed the > resolution... I tried doing an '#update-grub' both in the terminal > while > booted & at startup in the recovery mode. Nothing seems to change... > maybe it's the 'install_device not specified.' problem?? Well if running update-grub shows an error about video.lst, then you must run grub-install first. Else check the generated /boot/grub/grub.cfg It should contain something like that: if loadfont /usr/share/grub/unicode.pf2 ; then set gfxmode=1440x900 insmod gfxterm insmod vbe if terminal_output gfxterm ; then true ; else # For backward compatibility with versions of terminal.mod that don't # understand terminal_output terminal gfxterm fi fi -- 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: GRUB update problems
Am Dienstag, den 05.01.2010, 13:07 -0500 schrieb Henry W. Peters: > I run Debian Lenny sid/squeeze, the updater this morning just > "updated" > my GRUB2 version... (not sure of the version). normally it doestn't make sense to have stable (lenny), testing (squeeze) and unstable (sid) in /etc/apt/sources.list Usually you only use one of them. > I probably need to get the display resolution in GRUB to correspond to > > my ACTUAL desktop resolution... I'm guessing; so, until GRUB works > out > what appears to me, to be a 'bug' (?), or I can know what to do to > remedy... perhaps there is a workaround someone can suggest? I think you didn't set a device in the debconf prompt which asked for one. You need to run grub-install to update it. Else the graphical terminal won't get anymore enabled by update-grub/grub-mkconfig. And also check GRUB_GFXMODE in /etc/default/grub, which is the resolution for GRUB if the graphical terminal is enabled. > & one more note, I also had a problem with GRUB (or what ever...) when > I > hit the restart/shut down routine... it would sometimes only do a log > off, & then I would have to do a restart from the log on screen, > well... > it's back with this recent version of GRUB. This has nothing to do with GRUB. > Any helpful help appreciated. > > Henry > > > _______ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- 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: grub-setup: error: no mapping exists for ... in GRUB2 v1.97.1 on fake (IMSM) RAID
Please use proper quoting. It doestn't make it easier to read if your answer is directly below my sentences without any special quoting. Am Sonntag, den 03.01.2010, 20:29 -0800 schrieb Lapohos Tibor: > > Thanks for your help. Please see my further questions below. > > Based on your input, I cannot make this work, right? > No. Probable we could implement support for the newly added metadata formats, but that's IMO very very low priority. The normal ones are more important, especially now that 1.1 became the default instead of 0.90. > I made a Baazar branch for metadata 1.x support, but it's still > broken. > At least RAID != 1. > > So it works for RAID 1, and it is "broken" for the other RAID levels? It seems so. I haven't found out why exactly yet. > But I tested RAID 1 only with grub-probe, not actual booting from it. > And it's a bit complicated to get grub-probe working, because the > devicename must macht the name stored in the superblock. > > Would I need to be able to achieve all this as I am assembling the > RAID devices? > You can also just rename the device files afterwards, but before you run grub-install or update-grub/grub-mkconfig. > If you want to try it nevertheless: > > bzr co http://bzr.savannah.gnu.org/r/grub/people/fzielcke/raid > > > Thanks, I'll give it a shot once I get a better grasp of what I'm > doing. > > > device.map isn't used at all for mdraid devices. > > But my device is not "mdraid" type device, is it? The kernel does not > detect it as it loads and starts running. The "mdraid" devices would > be formed of "fd" type partitions, would they not? > No. mdraid devices can have any partition type you want. As with any Linux filesystem etc. pp. fd has only the special meaning that Linux autoassembles them. But the prefered method is to let mdadm inside the initrd/initramfs handle it. And then it doestn't matter at all what partition type you use. /dev/mdXXX and /dev/md/XXX are all mdraid devices. As long as mdadm -Q --detail works on it. Doestn't matter what mdraid metadata you use. > > (hdX,Y) devices are normal disk devices though and not the RAID ones. > They're (mdX) and (mdX,Y) so it only works with RAID 1, but only by > using one disk of them. > > OK, I understand this. But then I must ask, how come the grub shell > (got into by booting from a usb key) lists (hdX,Y) devices for all > these "imsm" contained devices and partitions? Ok I should have written (hdx,y) devices are normal BIOS devices. > Thanks again for your help, > Tibor -- 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: revert in grub2
Am Freitag, den 01.01.2010, 23:05 +0300 schrieb Mihamina Rakotomandimby: > Manao ahoana, Hello, Bonjour, > > How to reproduce the "revert" LILO feature with GRUB2? > > I believe everyone here knows what it is, but a quick explanation for > those not knowing: > With LILO, I can setup a default image to boot on. > But, I also can setup the next entry to boot on, that may be different > to the default one. > After that first following boot, the default entry will be used. > > What usage? > It is usefull for me when testing a kernel on a remote > server. I set the default to a reliable boot image. I set the "revert" > to the testing one. I boot: it boots on the "revert" one. > If it ever doesnt boot, I initiate a hard reboot (electric cutoff) and > then it boots on the safe one. > > I play with LILO just for that feature, I would like to switch to > GRUB. > > Misaotra, Thanks, Merci. Experimental branch has grub-reboot to boot an entry only once for the next reboot. But unfortunately this currently due to a bug just defaults to grub-set-default, i.e. always boot that entry then. -- 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: grub.info
Am Dienstag, den 29.12.2009, 21:39 -0500 schrieb Bruce O. Benson: > > Someone on the list can chime in if they want and are able to check my > work in to svn (in whole or part). Then I can release copyright. It works the other way. You have to first assign copyright to FSF before we can commit your things to Bazaar, if they're copyright relevant. (We don't use anymore SVN now for a long time.) -- 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: grub-setup: error: no mapping exists for ... in GRUB2 v1.97.1 on fake (IMSM) RAID
Am Sonntag, den 27.12.2009, 17:50 -0800 schrieb Lapohos Tibor: > Thanks for your reply. > > What the OROM says is that both of my volumes are bootable. > /dev/md126 corresponds to Volume0, and its first partition (ext4) has > the boot flag set. > > My problem is that I cannot get grub2 installed on the device at all. > I did try, as you suggested, to set You're problem is that you're using metadata 1.x and not the older default 0.90. Which we don't support yet. I made a Baazar branch for metadata 1.x support, but it's still broken. At least RAID != 1. But I tested RAID 1 only with grub-probe, not actual booting from it. And it's a bit complicated to get grub-probe working, because the devicename must macht the name stored in the superblock. If you want to try it nevertheless: bzr co http://bzr.savannah.gnu.org/r/grub/people/fzielcke/raid > (hd0) /dev/md126 > > in the device.map file and then issue > > > grub-install --modules=raid /dev/md126 > > but I still get the same error message(s): > > grub-probe: error: no mapping exists for 'md126' > grub-setup: error: no mapping exists for 'md126' device.map isn't used at all for mdraid devices. > What is interesting is that, at the grub shell, I can do > > grub> probe -l (hd0,1) > > it returns "OS" which is the label I set for it, so the device can, > under certain circumstances, definitely be detected. Nevertheless, > grub-install does not seem to behave the same way. (hdX,Y) devices are normal disk devices though and not the RAID ones. They're (mdX) and (mdX,Y) so it only works with RAID 1, but only by using one disk of them. -- 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: Grub is the bootloader used on Win7?
Am Freitag, den 25.12.2009, 19:15 -0200 schrieb Renato S.Yamane: > Hi, > > I´m a GNU/Linux user, but I have a computer with Windows too (fresh > install, with NO Linux installed) > > Recently, my RAID5 failed, sometimes I get a corrupetd system and I > see Windows loading GRUB! > > Anyone now if Windows7 is using Grub as default bootloader (because I > don´t believe that Grub is installed on my BIOS)? > > - This is the first message error: > http://img31.imageshack.us/img31/7215/img0227s.jpg > > - When I press "Enter" I see this: > http://img10.imageshack.us/img10/5285/img0225jm.jpg > > - And this is the commands available: > http://img85.imageshack.us/img85/7056/img0229w.jpg > > Best regards and Merry Christimas! > Renato S. Yamane Official Windows 7 from Microsoft unmodified, i.e. not some preinstalled OEM Version does clearly not use GRUB4DOS nor plain GRUB Legacy nor GRUB 2. They still use bootmgr which they introduced with Vista, which is basically though the old ntldr from NT4/2000/XP just a bit modified. GRUB4DOS by the way is just a fork of GRUB and not made by us neither supported on this list. -- 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: Fix for grub_assert_fail undefined on NetBSD and other platforms
Am Donnerstag, den 24.12.2009, 22:55 +0100 schrieb Robert Millan:
> On Tue, Dec 22, 2009 at 09:39:07PM +0530, BVK Chaitanya wrote:
> > Hi
> >
> >
> > Attached is the patch, which removes use of undefined
> grub_assert_fail
> > function for catching bad-type-cast errors, with a better version
> > __attribute__((error("msg"))) gcc extension. With this extension,
> gcc
> > can give the exact location of the bad type cast at compile time.
>
> Is this really a kind of error we'd like to report at run time? Sorry
> if
> I'm missing something, but if we need additional code to handle it,
> and it
> was known at compile time, why do we do this?
__attribute__ ((error)) still reports it at compile time just like the
old grub_assert_fail method.
But the advantage is that you can specify the error message instead of
just getting a `ld: unknown symbol grub_assert_fail' error during
linking. And as BVK said above also the exact location where this
happened.
--
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: execution of update-grub in chroots might fail
Am Donnerstag, den 24.12.2009, 22:28 +0100 schrieb Robert Millan: > On Mon, Dec 14, 2009 at 11:56:21AM +, Colin Watson wrote: > > The simplest fix is to add '&& [ -e /boot/grub/grub.cfg ]' to the > test > > in memtest86+; > > Uhm should we make this check part of update-grub? Or even part of > grub-mkconfig? I don't think grub-mkconfig should check for that. And if it does then we should make it optional by adding something like --update as option to it. If people of other distributions compile GRUB 2 they should be able to just use grub-mkconfig directly to create their initial config without much hassle. > > that is, if the configuration file hasn't been generated > > already, it shouldn't be updated. (This check is in the memtest86+ > > postinst in Ubuntu.) This accounts for the OpenVZ problem as well as > for > > other reasons why GRUB might not actually be being used as a boot > > loader. > > > > You're right that it is suboptimal that every package has to > implement > > the check itself. My instinct is that the semantics of update-grub > ought > > to change slightly, so that it really is an *update* - that is, it > > shouldn't by default generate a configuration file if there isn't > one > > already. It could have a --force option (or better name?) for > > convenience, for use by the grub2 packaging itself, and for use by > the > > installer. Anything much more complex than that smells of > > overengineering to me. > > > > Note, though, that care would need to be taken to ensure that > > grub-installer is changed in step; it's important to minimise the > > chances of consequential installer brokenness. There's little > urgency on > > this so we could afford the time for a proper transition. For > example, > > update-grub could accept but ignore the new option for a while; > then, > > after the relevant version of grub2 has moved to testing, > grub-installer > > could be updated to use it; then, at some later point, the default > > semantics of update-grub could change. > > > > If that's too complicated, we could just add an --if-exists option > or > > something that does what memtest86+ and other similar packages need. > > There are very few packages in this boat, so it may not be worth > very > > much effort to deal with them. > > > > Robert, Felix, what do you think? > > I think it's fine to make this update conditional. My only concern is > that > external packages have a mechanism to add their stuff into grub.cfg > (this > was one of the key motivations for initial grub-mkconfig design). > In Debian at least they probable all rely that grub-pc etc. is installed first. If you have grub2 installed but no config then you probable don't want that e.g. memtest86+ suddenly creates it. -- 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: [RFC] Dynamic device.map
Am Donnerstag, den 24.12.2009, 22:17 +0100 schrieb Robert Millan: > On Thu, Dec 10, 2009 at 11:12:58AM +0100, Felix Zielcke wrote: > > Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan: > > > But first we'd need to figure out what we do with the "set > root=xxx" > > > backward compatibility hack. Has it been a while long enough that > > > we can remove support for GRUB installs that didn't come with UUID > > > support? > > > > Well we still have Arthur Marsh' bug open that search --fs-uuid > fails > > with right UUID even though ls (hdx,y) shows it. > > Uhm ISTR Vladimir fixed this one. Yes in the meanwhile he commited the fix. -- 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: Fix for grub_assert_fail undefined on NetBSD and other platforms
Am Dienstag, den 22.12.2009, 18:07 +0100 schrieb Grégoire Sutre: > This is on NetBSD 5.0 with gcc 4.1.3 (the default). > If I use gcc 4.4 instead, then I do not get any warning. It looks like gcc 4.3 introduced the error attribute. But this isn't documented at the gcc.gnu.org/gcc-4.X/changes.html pages. Only the gcc-4.3 manual avaible there explains it but not the gcc-4.2 one. -- 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: How to install grub on fakeraid (raid 0) which spans 2 TB?
Am Dienstag, den 22.12.2009, 18:02 +0100 schrieb "André Heynatz": > I have bought two 1 TB harddisks and one 2 TB harddisk (backup). > I want to use the 1 TB harddisks in a RAID 0 array (Intel ICH8R > Fakeraid). > > I wanted to install Linux, then create the data partition with > Win XP SP3 Disk Management Tool. The Linux install failed > because Ubuntu wanted to install GRUB1 which is not part of > the install CD. There was a bug that GRUB Legacy wasn't included on the karmic DVD but that should have been fixed already. So make sure you use a fresh image file. > I wonder that Ubuntu uses GRUB2 at all at the > moment because the FakeRaid support is still lacking which was > known before release (a severe regression). That's why grub-installer uses still GRUB Legacy in case /boot is on a dmraid. GRUB Legacy is complete dead for us, so if you want to have help for that you have to ask at some Ubuntu place or somewhere else. With GRUB 2 you could try the lucid (10.04) package out. At least grub-probe should work there. But I never tested if grub-setup works and so not if it actually boots correctly from a dmraid. -- 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: how 'default=saved' should work ?
Am Dienstag, den 22.12.2009, 15:15 +0100 schrieb Frédéric Boiteux: > Le Tue, 22 Dec 2009 13:51:30 +0100, > Frédéric Boiteux a écrit : > > > > Ah a french page on the wiki has this. > > > Unfortunately I don't know more then 1-2 french words. > > > Would be nice if someone could note there that this currently only > > > applies to the experimental branch. > > > Done. Thanks. > Fred. -- 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: how 'default=saved' should work ?
Am Dienstag, den 22.12.2009, 13:36 +0100 schrieb Frédéric Boiteux: > Le Tue, 22 Dec 2009 13:28:02 +0100, > Felix Zielcke a écrit : > > > It's only in the experimental branch avaible, which is in Debian > > experimental. > > We only do trunk uploads to sid. > Ok, thanks for the precision : I found the doc on the Grub2 wiki, but > didn't notice it doesn't apply to current Sid package ! > > Fred. Ah a french page on the wiki has this. Unfortunately I don't know more then 1-2 french words. Would be nice if someone could note there that this currently only applies to the experimental branch. -- 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: how 'default=saved' should work ?
Am Dienstag, den 22.12.2009, 13:25 +0100 schrieb Frédéric Boiteux: > Hello, > > I've recently updated my grub-legacy bootloader to Grub2 (using > latest grub-pc from Debian Sid), and I can't have the > 'default=saved' > option working with Grub2 :-( It's only in the experimental branch avaible, which is in Debian experimental. We only do trunk uploads to sid. > I've put following definition in /etc/default/grub : > > GRUB_DEFAULT=saved > That change would be enough then to enable it. -- 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: Does grub support "nfsroot" linux kernel command line?
Am Mittwoch, den 16.12.2009, 17:15 +0800 schrieb Nancy: > > I believe that is a kernel or initrd issue and not a boot issue. > Once the > > kernel is loaded, grub's job is done. You would never see a kernel > panic > > from grub. > > > Thanks for your information, Bruce. > Do you mind tell me weather grub 1.97 support bootp, tftpserver > command? any special configuration to compile those command in grub? No it doestn't. There's no network support at all yet in GRUB 2. Only booting via PXE is currently supported. -- 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: execution of update-grub in chroots might fail
Am Montag, den 14.12.2009, 13:36 +0100 schrieb Michael Prokop: > >> The simplest fix is to add '&& [ -e /boot/grub/grub.cfg ]' to the > >> test in memtest86+; that is, if the configuration file hasn't > >> been generated already, it shouldn't be updated. (This check is > >> in the memtest86+ postinst in Ubuntu.) This accounts for the > >> OpenVZ problem as well as for other reasons why GRUB might not > >> actually be being used as a boot loader. > > Is the memtest86+ maintainer of Debian aware of this (at least > temporary but working) solution or should I ping him? > > regards, > -mika- I doubt he is if that has not been mentioned in any memtest86 or memtest86+ (He maintains both) bug reports. -- 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: execution of update-grub in chroots might fail
Am Montag, den 14.12.2009, 11:56 + schrieb Colin Watson: > On Sun, Dec 13, 2009 at 11:08:04PM +0100, Michael Prokop wrote: > > For example postinst of memtest86+ uses: > > > > if [ "$1" = "configure" ] && [ -x "`which update-grub2 > 2>/dev/null`" ] ; then > > update-grub2 > > fi > > > > which is the recommended and suggested way to install grub menu > entries. > > Recommended where? (This implies the existence of documentation on the > subject, which I wasn't aware of ...) I wonder too why he wrote that. When I talked with him on IRC yesterday, I mainly said that using `update-grub || true' would be wrong. And neither me nor Robert (at leat until I was on IRC which was though later then he wrote this mail) not at all anything that says there's a written policy for interacting with GRUB things or even that the above thing is the recommended and suggested way. > > Problem > > === > > > > When executing update-grub the command might fail. For example it > > *does* fail inside chroots on openvz containers (see end of mail for > > full details regarding the setup in question): > > > > # update-grub2 > > grub-probe: error: cannot find a device for /. > > > > Then the installation of for example the memtest86+ package fails. > > Recommended fixes were (binded) mounting /proc, /sys and /dev, > though > > this is already present and doesn't help. > > > > The problem is NOT the grub package itself (it installs and updates > > just fine). The problem exists in packages that call update-grub but > > don't have a clean interface *when* (and how) to execute it. See > > #481468 and #550337 for example. > > The simplest fix is to add '&& [ -e /boot/grub/grub.cfg ]' to the test > in memtest86+; that is, if the configuration file hasn't been > generated > already, it shouldn't be updated. (This check is in the memtest86+ > postinst in Ubuntu.) This accounts for the OpenVZ problem as well as > for > other reasons why GRUB might not actually be being used as a boot > loader. We have alredy changed our postinst some time ago to only execute when either grub.cfg already exists or when grub-install gets run in the postinst. > You're right that it is suboptimal that every package has to implement > the check itself. My instinct is that the semantics of update-grub > ought > to change slightly, so that it really is an *update* - that is, it > shouldn't by default generate a configuration file if there isn't one > already. It could have a --force option (or better name?) for > convenience, for use by the grub2 packaging itself, and for use by the > installer. Anything much more complex than that smells of > overengineering to me. > > Note, though, that care would need to be taken to ensure that > grub-installer is changed in step; it's important to minimise the > chances of consequential installer brokenness. There's little urgency > on > this so we could afford the time for a proper transition. For example, > update-grub could accept but ignore the new option for a while; then, > after the relevant version of grub2 has moved to testing, > grub-installer > could be updated to use it; then, at some later point, the default > semantics of update-grub could change. > > If that's too complicated, we could just add an --if-exists option or > something that does what memtest86+ and other similar packages need. > There are very few packages in this boat, so it may not be worth very > much effort to deal with them. > > Robert, Felix, what do you think? > Why so complicated? We use just `touch /boot/grub/grub.cfg' in the grub-pc/install_devices part and then at the end of postinst we check if it exists and then run update-grub The same could be done in grub-installer now without needing to modify anything else. Sad that we can't make update-grub a trigger. At least as long as nobody comes up with a great solution which makes sure the system is always bootable even if it's not run or that the trigger is always run even if the dpkg/apt run aborts. Then we could control when update-grub gets run in our postinst instead of every package which wants/needs to run it. Then if we add a check for grub.cfg in the update-grub stub, the only question is if we should print a warning that it doestn't do anything or not in case grub.cfg doesn't exist. -- 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] Backup old boot sectors before installation
Am Freitag, den 11.12.2009, 17:26 +0800 schrieb Zhu Yi: > Add a feature to backup the old boot sectors before overwritting > them with grub2 boot and core images. Users can later recover the > previous boot sectors with grub-install --recover option. > > P.S. I found this might be a useful feature after I overwrote my > second PGP encrypted hard disk (Windows XP installed) boot sectors > by grub2 by mistake. > > Signed-off-by: Zhu Yi Someone already made a patch for this inside grub-setup See here and also for the discussion of it: http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00242.html -- 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: autogen.sh warnings
Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs: > On the other hand, config.guess is used to get build_cpu and build_os > and I don't see that being used at all right now by grub. Well just after the part you quoted from me, I thought I made it clear that the output of config.guess is used as an argument for config.sub So you just need both. At least as long as autoconf doestn't get changed. -- 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: [RFC] Dynamic device.map
Am Donnerstag, den 10.12.2009, 01:55 +0100 schrieb Robert Millan: > But first we'd need to figure out what we do with the "set root=xxx" > backward compatibility hack. Has it been a while long enough that > we can remove support for GRUB installs that didn't come with UUID > support? Well we still have Arthur Marsh' bug open that search --fs-uuid fails with right UUID even though ls (hdx,y) shows it. https://savannah.gnu.org/bugs/?26834 Also on Debian BTS and Launchpad. The good thing though is that only a grub_errno = GRUB_ERR_NONE; needs to be commited to have this fixed. Unfortunately he attached the full kern/device.c to the report not the patch Vladimir made for him. -- 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: autogen.sh warnings
Am Mittwoch, den 09.12.2009, 17:28 -0600 schrieb Bruce Dubbs:
> Felix Zielcke wrote:
> > Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
> >> config.guess, config.sub, missing, mkinstalldirs, and install-sh
> are
> >> only copied from /usr/share/automake- as a part of
> automake.
> >> AFAICT, they are not used in GRUB. I'm pretty sure they are the
> same
> >> on
> >> all architectures, but I could be wrong about that.
> >
> > config.guess and config.sub are used by configure.
>
> Called yes, and it will give errors if not present, but is the output
> used? Looking at configure, I don't think so.
Just looking at the second result for searching config.guess in
configure makes it pretty clear for what they're used:
$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
as_fn_error "cannot run $SHELL $ac_aux_dir/config.sub" "$LINENO" 5
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
$as_echo_n "checking build system type... " >&6; }
if test "${ac_cv_build+set}" = set; then :
$as_echo_n "(cached) " >&6
else
ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
test "x$ac_build_alias" = x &&
as_fn_error "cannot guess build type; you must specify one" "$LINENO" 5
ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
as_fn_error "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5
[...]
build=$ac_cv_build
The output of ./config.sub $(./config.guess) is used as build system
type, if you don't use --build option.
--
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: autogen.sh warnings
Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs: > config.guess, config.sub, missing, mkinstalldirs, and install-sh are > only copied from /usr/share/automake- as a part of automake. > AFAICT, they are not used in GRUB. I'm pretty sure they are the same > on > all architectures, but I could be wrong about that. config.guess and config.sub are used by configure. mkinstalldirs is used by the generated Makefile. Looks like configure checks if install-sh is there but except of this it isn't used. missing isn't used because we don't use automake and maintainer mode. -- 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: autogen.sh warnings
Am Montag, den 07.12.2009, 23:54 + schrieb Colin Watson: > > The real purpose of automake is to create a Makefile.in for > configure. > > GRUB doesn't use it for that. Is there any reason to not just add > the > > three files to the bzr repository and remove the automake line > from > > autogen.sh? > > These files do change from time to time, in ways that are important; > for > example, config.guess and config.sub are updated to support new > architectures or new variants of existing architectures. It's best to > have this done automatically rather than doing it once manually and > then > forgetting about it. > Well in the past I did sync config.guess and config.sub from the git repository for them once in a while, when I noticed the changes for them could be good for us. So if people use outdated autotools it means a downgrade for them. -- 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: mkrelpath doesn't do what it should...
Am Montag, den 07.12.2009, 03:24 -0800 schrieb David Miller: > In fact I don't see why these scripts don't do that, and relatively > resolve the /boot directory whatever seperately. Because it's faster to just call once for the directory make_system_path_relative_to_its_root() instead of once for every kernel you have. Colin even added caching for prepare_grub_to_access_device() because it can be slow if you have many many kernels. -- 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: mkrelpath doesn't do what it should...
Am Sonntag, den 06.12.2009, 23:30 -0800 schrieb David Miller: > I was trying to figure out why the kernel image paths generated > automatically for me by grub-mkconfig were not correct. > > I have /boot on a seperate partition, but in the generated config > files it uses paths like /boot/vmlinux-2632 etc. > > The problem is grub-mkrelpath and it's usage in the scrips such as > "10_linux". > > "/boot" is given to "grub-mkrelpath", and this results in > the identical "/boot" in rel_dirname. > > So all the paths emitted by 10_linux end up being "/boot" based > instead of "/" based. > > grub-mkrelpath seems to do the right thing if I pass it a full path, > f.e. giving it "/boot/vmlinux" emits the correct "/vmlinux" The one mount point case is now fixed in r1917 See Subject: `handling mount points in grub-mkrelpath' from me for the patch. > Casually inspecting make_system_path_relative_to_its_root() shows what > appears to be another bug. It seems to immediately break from the > loop when a different device number than "/"'s is seen, but what if I > have: > > /one/two/three > > Where / is /dev/hda1, /one/two is /dev/hda2 and /one/two/three is yet > another mount from /dev/hda3. It seems like the premature loop exit > in this function will give us the wrong result here. > > The loop needs to remember the string prefix point at which every > device number change occurs, and once the whole path has been > traversed it should unwind back to that point in order to emit > the result. Multiple mount points are an interesting case. Haven't thought about them. But they should be now handled correctly too. -- 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: handling mount points in grub-mkrelpath
Am Freitag, den 04.12.2009, 22:23 +0100 schrieb Robert Millan: > Hi, > > The old behaviour seems correct, so there's no need to break > compatibility. > > Please could you commit this in trunk? > Thanks. Commited 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]: Fix sparc64 build...
Am Freitag, den 04.12.2009, 13:34 -0800 schrieb David Miller: > From: Robert Millan > Date: Fri, 4 Dec 2009 21:58:25 +0100 > > > On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote: > >> > >> Thanks, but I don't feel comfortable enough with bzr yet. > >> > >> I had to struggle just to get things checked out, as the bzr > >> package in Debian stable is too old to use to access to repo. > >> > >> (For the record I disagree with the source control system choosen, > >> and the fact that a common current Linux distribution doesn't even > >> provide a version of the tool necessary to access the repo really > >> convinces me further of that.) > > > > For a Lenny system the following should do the trick: > > > > echo "deb http://backports.org/debian lenny-backports main" | sudo > tee -a /etc/apt/sources.list > > gpg --keyserver pgp.mit.edu --recv-keys 16BA136C > > gpg --export -a 16BA136C | sudo apt-key add - > > sudo apt-get update > > sudo apt-get install -t lenny-backports bzr > > That's not a straightforward and low barrier of entry for new > developers who want to simply check out the grub code and start > contributing. That's my point. > > Do you want lots of people involved, or do you want people to have > to jump through hoops and go out of their way to get at your tree? > > Heck, for this reason alone, subversion was a better situation. When squeeze is out we hopefully won't have that problem again that we have to use newer versions then Debian stable. I hope that the bzr repository formats are now enough stable for our use. > Mercurial, GIT, or pretty any other distributed source control system > would have worked out of the box with the client versions provided in > debian stable and other distributions. > > So, I still believe BZR was a bad choice of a source control system. > > And how many times have you guys wrecked your repository already? > :-) IIRC 3 times, but 2 times was because of the broken bzr-svn used to sync regulary SVN to Bazaar trunk. -- 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
handling mount points in grub-mkrelpath
Vladimir wanted to have this discussed on ML
The old shell function make_system_path_relative_to_its_root outputed /
if you gave it /boot and it was on a seperate partition.
grub-mkrelpath currently outputs /boot
This breaks booting at least with the 10_linux generated entries.
Attached is my fix for that, which I'll update today to Debian.
We already broke backward compatibility with the commandline for Xen.
IMO in this grub-mkrelpath case there's no need to break compatibility.
But maybe I can find a good way to handle this inside
util/grub-mkconfig_lib.in just for compatibility.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
2009-11-29 Felix Zielcke
* util/misc.c (make_system_path_relative_to_its_root): Correctly cope with
mount points.
=== modified file 'util/misc.c'
--- util/misc.c 2009-11-25 23:10:02 +
+++ util/misc.c 2009-11-29 19:19:28 +
@@ -500,7 +500,17 @@ make_system_path_relative_to_its_root (c
/* buf is another filesystem; we found it. */
if (st.st_dev != num)
- break;
+ {
+ /* offset == 0 means path given is the mount point. */
+ if (offset == 0)
+ {
+ free (buf);
+ free (buf2);
+ return strdup ("/");
+ }
+ else
+ break;
+ }
offset = p - buf;
/* offset == 1 means root directory. */
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: savannah Browse Sources Repository
Am Sonntag, den 29.11.2009, 04:30 +0100 schrieb Robert Millan: > On Sun, Nov 29, 2009 at 01:49:02AM +, Carles Pina i Estany wrote: > > > > Hello, > > > > >From this webpage: > > https://savannah.gnu.org/projects/grub/ > > > > Clicking on "Browse Sources Repository" (Bazaar one) appears: > > http://bzr.savannah.gnu.org/lh/grub > > > > I remember that last Sunday worked fine but not during the week. > Maybe > > restoring the backup on Sunday after the incorrect merge something > is > > not working? Or just a coincidence? > > Hi, > > The web frontend tends to break often. Anyway, there isn't much we > can do > about it. If you think it's necessary, you could file a problem > report on > Savannah admin project. I already did that but no reply from them :( https://savannah.gnu.org/support/?107133 -- 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: grub-install crash on GNU/Hurd
Am Sonntag, den 29.11.2009, 04:36 +0100 schrieb Samuel Thibault: > Here is the patch agains, with -w > > Samuel Looks fine to me. -- 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: grub_halt()
Am Freitag, den 27.11.2009, 22:24 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Felix Zielcke wrote: > > grub_halt is on i386-pc defined as `void grub_halt (int no_apm)' but > > everywhere else as `grub_halt (void)' > > util/grub-emu.c has a #ifdef for these 2 > > > > Shouldn't we just add an int parameter everywhere to make this more > > simple? > > > > > I think in future we'll have more different halt methods on different > platforms. So we could do: > grub_halt (int methods) > And have e.g. > GRUB_HALT_DEFAULT_METHODS > And e.g. on i386: > #define GRUB_HALT_DEFAULT_METHODS > (GRUB_HALT_APM|GRUB_HALT_ACPI|GRUB_HALT_HANG) Wouldn't be an enum then be better? But I don't know how to handle this with asm where currently grub_halt() on i386 seems to be actually defined. > > grub-emu fails to build on powerpc now because grub/cpu/halt.h > doestn't > > exist there: > > > https://buildd.debian.org/fetch.cgi?pkg=grub2;ver=1.97%2B20091125-1;ar > ch=powerpc;stamp=1259179180 > > It fails also on sparc because of this. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Booting TrueCrypt Windows Hard Drive
Am Freitag, den 27.11.2009, 13:11 +0100 schrieb Rob Power: > Sorry for the double post, but I didn't get the mail back, so I > thought I made a mistake in the sending. > Thanks anyway. > Rob > Ah I just noticed you use google mail for the list. I did that shortly once too and even though I had the list settings to get my own mails back, Google seemed to discard my own list replies. Checking the list archives always works, but it needs time until the recent mails show up: http://lists.gnu.org/archive/html/grub-devel/ -- 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: Booting TrueCrypt Windows Hard Drive
Am Freitag, den 27.11.2009, 12:52 +0100 schrieb Rob Power: > > Hi to all! > I have a similar problem with this configuration: > As Vladimir just replied 1 minute ago this mail to your 2nd reply, there's absolutely no need to post, now 3 times, the same mail. Seems like your mail system is broken, so I CC you this time. Sending the same mail over and over again, only _de_creases the chances that someone is willing to look at it. -- 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: gfxmenu available in experimental
Am Freitag, den 20.11.2009, 23:17 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Hello, all. After various delays with various cause I'm proud to > announce the availability of Colin's gfxmenu into experimental branch > of > grub2. I'm proud to announce it's finally avaible in Debian experimental (Thanks Robert) and in my Ubuntu ppa for the karmic users with all the Ubuntu changes merged in this time. Colin, I suggest you make a little update to the journal on your site. I could imagine that some people only follow that and not grub-devel. -- 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: fonts for gfxmenu, help needed
Am Mittwoch, den 25.11.2009, 23:38 -0500 schrieb Qianqian Fang: > hi list > > My friend brought me attention to this thread, and > I am very glad to see a better CJK support is now > on the agenda of grub. As a Chinese font developer, > I am willing to help, share information or build > fonts for this specific need. > > I wasn't really following how fonts were used in grub, > and still had the (wrong) impression that only 256 > glyphs are allowed for each file. After opening the > overlay_2009-07-19 tarball, I saw large files such as > unifont are included, so, I guess now grub is able > to handle the full unicode (or BMP) fonts including > CJK ones, is this correct? do they have to be bitmaps? Even with the old .pff font format the whole unicode was possible but it was just slow IIRC. At least it was slow with first version of .pf2 or grub-mkfont. The .pf2 format itself is bitmap but see below. As input for grub-mkfont they can be TTF. > If the answers to my above questions are "yes", then > I think you may consider a customized version > of "WenQuanYi Bitmap Song" [1], which is a multi-strike > bitmap font containing >27000 Chinese Han glyphs > at 9pt,10pt,10.5pt,11pt and 12pt sizes. The Latin > part of this font are not "monospaced", but we > can either merge it with other mono Latin fonts > (GPL compatible), or use fallback to get around it. > > I saw you already have the later version of > GNU Unifont installed, if that's the case, then > you can skip the 12pt of WenQuanYi Bitmap Song, > because most of the CJK glyphs in Unifont 5.1 > were ported from WQY's bitmap font last year by > Paul Hardy [2]. Yes in the Debian/Ubuntu packages we use Paul Hardy's version. > About format, I don't know if you can use ttf > file, or SFNT ttf file (with only embedded bitmaps). > WQY Bitmap Song has an SFNT TTF version [3]. It appears > that freetype2 works fine with it, but fontconfig > has difficulties. Using SFNT TTF, the uncompressed > font size is about 3M (with 9,10,11,12pt),which > is fairly lightweight. > > If grub happens to be able to process vector > ttf fonts, I would recommend DroidSansFallback [4] > or the derived WenQuanYi Micro Hei [5]. They both > covers a huge span of languages, and the second one > have a lot more CJK glyphs and both proportional > and monospaced species. As input format for grub-mkconf we support everything libfreetype supports, so TTF too. > Please let me know if you have any further comments, > > Qianqian -- 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
grub_halt()
grub_halt is on i386-pc defined as `void grub_halt (int no_apm)' but everywhere else as `grub_halt (void)' util/grub-emu.c has a #ifdef for these 2 Shouldn't we just add an int parameter everywhere to make this more simple? grub-emu fails to build on powerpc now because grub/cpu/halt.h doestn't exist there: https://buildd.debian.org/fetch.cgi?pkg=grub2;ver=1.97%2B20091125-1;arch=powerpc;stamp=1259179180 -- 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: [RFC][PATCH] Basic unit testing support for GRUB
Am Freitag, den 13.11.2009, 23:15 +0530 schrieb BVK:
> Hi,
>
>
> Attached is the (experimental branch) patch for unit testing that I
> have in mind for GRUB. Please let me know your comments.
>
> It provides "make check" target which would build and execute test
> programs from "tests" directory. We can write small programs to test
> specific functions in GRUB. For example, attached patch has sample
> program comparing grub_sprintf behavior against standard sprintf
> output (from glibc).
>
> Note that it currently has few gotchas, like using TARGET_CC instead
> of BUILD_CC, no support for XPASS, XFAIL tests, etc.
Thanks for your work.
A really useful test and hopefully not complicated to implement would be
if the config generated by grub-mkconfig (with e.g. 1 fake linux kernel)
can be parsed by sh.mod and only uses commands listed in commands.lst
Reasoning:
With current trunk grub-mkconfig this line ends up in grub.cfg:
menuentry "Debian, with Linux GNU/Linux" {menuentry "2.6.31-1-amd64, with
Linux " { insmod ext2
and of course this totally breaks the parser.
--
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: fonts for gfxmenu, help needed
Am Dienstag, den 24.11.2009, 19:12 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Michal Suchanek wrote: > > 2009/11/24 Robert Millan : > > > >> Hi, > >> > >> Help is needed in order to provide the last bit that will make > gfxmenu > >> functional: fonts of multiple sizes. > >> > >> The sample tarball at > http://grub.gibibit.com/files/overlay_2009-07-19.tar.gz > >> includes a set of prebuilt fonts. They were built using a Java > utility > >> which ended up being replaced with grub-mkfont in our repository. > >> > >> In order to provide the basic infrastructure so that theme authors > can > >> begin developing their artwork, we need GRUB to build fonts from > the original > >> unifont files (unifont.bdf or unifont.pcf.gz). > >> > >> Can someone figure out appropiate parameters for grub-mkfont, such > that > >> when applied on unifont.bdf or unifont.pcf.gz they will output > suitable > >> PF2 font files? A font file is suitable if it can be used to > replace the > >> prebuilt ones in overlay_2009-07-19.tar.gz and its themes can still > use > >> them. > >> > > > > I suspect what you are asking is impossible. > > > > As far as I understand unifont is a single bitmap font in a single > > pixel size and the tarball you sent contains multiple font faces in > > multiple sizes. > > > While usually it's a bad idea to scale bitmap font it can be done and > for our uses (mainly downscale and a bit of upscale) it may be > appropriate for our usage. grub-mkfont supports as input files everything libfreetype supports. TTF is supported and there's also a unifont.ttf. But our own .pf2 format is bitmap not outline. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gfxmenu available in experimental
Am Samstag, den 21.11.2009, 10:17 -0800 schrieb Colin D Bennett: > On Sat, 21 Nov 2009 16:43:57 +0100 > Robert Millan wrote: > > > On Fri, Nov 20, 2009 at 11:17:51PM +0100, Vladimir > 'φ-coder/phcoder' > > Serbinenko wrote: > > > Example menu is available at > > > http://grub.gibibit.com/files/overlay_2009-07-19.tar.gz > > > > Colin, we would need to know more details about the theme support > > files. > > > > Are all the theme files in that tarball written by you? Which > images > > did you make yourself? I'm specially interested in the terminal-box > > ones. > > It would be easier perhaps if I list the elements that I did not > create: > > - The 'winter' background. > - The Ubuntu theme logo image/text. > What is with the fonts? Helvetica is IIRC a font MacOS shipped with (or was it previous Windows versions? At least my local Vista doestn't seem to have it) And New Century Schoolbook seems to be a commercial font. But what about all the other fonts you use? Like all the 4x6.pf2 etc. ones? or lime or kate? -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Cryptography
Am Montag, den 16.11.2009, 14:48 +0100 schrieb Vladimir 'phcoder' Serbinenko: > 3) PBKDF2-SHA512 password support to increase security. To generate > the > encrypted password do: > grub-pbkdf2 [-c iteration_count] > It may not work on non-unix platforms due to terminal control > functions > (disabling echo) and /dev/random (retrieving salt). Patches are > welcome > PBKDF2 is imported from gnulib I suggest to name it grub-mkpasswd. Even in the case we only support one password hash this makes it easier for users to find then grub-pbkdf2 and to figure out what it does. -- 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: Slow grub boot when /boot/grub is not on first partition
Am Samstag, den 31.10.2009, 20:03 +0100 schrieb Vladimir 'phcoder' Serbinenko: > Simon Wagner wrote: > > Hello dear GRUB2 developers, > > > > I am a user of Ubuntu 9.10, which uses GRUB2 1.97. Unfortunately > GRUB > > needs a rather long time loading the modules. For 2 minutes or so it > > just displays "GRUB loading..." until the boot menu is shown and I > can > > start Ubuntu. > > > > The bug has already been reported at Launchpad: > > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/420933 > > > > I tried to find out what causes the problem. I have the following > disk > > layout: > > > > A "Windows HD" with the following partitions > > /dev/sda1 > > /dev/sda2 > > /dev/sda3 > > /dev/sda4 > > /dev/sda5 > > > > A "Ubuntu HD": > > /dev/sdb2 (Extended Partition) > > /dev/sdb5 (swap) > > /dev/sdb6 (small partition, holds some misc data) > > /dev/sdb7 (Ubuntu 9.10) > > /dev/sdb8 (Backup) > > > > So when I add > >set debug="disk" > > at grub.cfg I can see grub accessing the disk. It cycles through all > > the partitions, then reads data from sdb7, cycles again through the > > partitions, reads again from sdb7, and so on... > > > > I can't really tell whats causing this, I used the Ubuntu 9.04 > package > > of grub2 before and that had not this problem. The package dates > back > > to to the grub2 version from the 24th July of 2008. > > > > Maybe it is possible to do some caching in GRUB2? So for example, if > >search -u someuuid > > is done, the result is saved, and if we do that again, we can lookup > > in the cache which drive has that uuid? The same for the FS type. If > > we once did detect ext2 on hd1,7 we should cache that, so we don't > > need to detect that again. > > > > I will try to add more grub_dprintf calls, so that I can better see > > what is going on. > > > > Sincerly > > Simon W. > > > We're aware of this problem and have patch which I'll merge as soon as > I'm back home Vladimir any news? The people on the LP bug now seem to more revert to Legacy instead of following the advice to boot from the disk where their /boot/grub is on. -- 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] Add -nostdinc to TARGET_CFLAGS
Am Sonntag, den 15.11.2009, 13:32 +0100 schrieb Robert Millan: > On Sun, Nov 15, 2009 at 12:50:39PM +0100, Felix Zielcke wrote: > > > > $ srcdir=$PWD builddir=$PWD gcc -isystem=$srcdir/include > > > > -I$srcdir/include -I$builddir -I$builddir/include test.c -o test && ls > > > > test > > > > test > > > > $ srcdir=$PWD builddir=$PWD gcc -nostdinc -isystem $(gcc > > > > -print-file-name=include) -I$srcdir/include -I$builddir > > > > -I$builddir/include test.c > > > > test.c:2:20: error: stdint.h: No such file or directory > > > > > > We used -isystem as a way of excluding system headers but not gcc headers. > > > With the -print-file-name trick this seems to be no longer necessary, > > > right? > > > > > > So why not "-nostdinc -I$(gcc -print-file-name=include)" instead? > > > > I think we should use -isystem for the gcc internal header files not -I, > > but I just tested experimental branch with -I instead of -isystem and > > also compiles cleanly (except the usual grub.texi warnings) > > Seems fine. Thanks for investigating this. You're welcome. I commited this now except that I used now $TARGET_CC. Makes more sense inside TARGET_CPPFLAGS. -- 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] Add -nostdinc to TARGET_CFLAGS
Am Sonntag, den 15.11.2009, 12:35 +0100 schrieb Robert Millan:
> On Sun, Nov 15, 2009 at 12:17:50PM +0100, Felix Zielcke wrote:
> >
> > The advantage is that this does exatly what we want for the target.
> > Remove /usr/include from the include search directories but still keep
> > the gcc internal one for e.g. stdarg.h
> > As far as I understand the gcc manual, isystem adds this directory to
> > the search path and treats all headers there in as system headers.
> > And with the = between -isystem and $(srcdir) it actually uses
> > ${sysroot}{$srcdir} but we don't use any --sysroot or -isysroot.
> > The arguments we currently have there just look wrong with my understand
> > of the gcc manual
>
> Ah, I see..
>
> > $ cat test.c
> > #include
> > #include
> >
> > int main (void)
> > {
> > return 0;
> > }
> >
> > $ srcdir=$PWD builddir=$PWD gcc -isystem=$srcdir/include -I$srcdir/include
> > -I$builddir -I$builddir/include test.c -o test && ls test
> > test
> > $ srcdir=$PWD builddir=$PWD gcc -nostdinc -isystem $(gcc
> > -print-file-name=include) -I$srcdir/include -I$builddir -I$builddir/include
> > test.c
> > test.c:2:20: error: stdint.h: No such file or directory
>
> We used -isystem as a way of excluding system headers but not gcc headers.
> With the -print-file-name trick this seems to be no longer necessary, right?
>
> So why not "-nostdinc -I$(gcc -print-file-name=include)" instead?
I think we should use -isystem for the gcc internal header files not -I,
but I just tested experimental branch with -I instead of -isystem and
also compiles cleanly (except the usual grub.texi warnings)
As said on IRC already:
http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
--
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] Add -nostdinc to TARGET_CFLAGS
Am Sonntag, den 15.11.2009, 12:12 +0100 schrieb Robert Millan: > On Sun, Nov 15, 2009 at 12:04:58PM +0100, Robert Millan wrote: > > On Sat, Nov 14, 2009 at 10:16:45PM +0100, Felix Zielcke wrote: > > > Am Mittwoch, den 04.11.2009, 11:48 +0100 schrieb Felix Zielcke: > > > > > > > > Thanks to the hint from rubisher I looked now at Linux Makefiles. > > > > They use this: > > > > > > > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) > > > > -print-file-name=include) > > > > > > > > # ls $(gcc-4.4 -print-file-name=include)/stdarg.h > > > > /usr/lib/gcc/x86_64-linux-gnu/4.4.2/include/stdarg.h > > > > > > > > > > Robert? > > > IMO this makes at least more sense then what we have now > > > and I just tested this now with and without a seperate build directory > > > with experimental branch and it works > > > TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -nostdinc -isystem $(shell $(CC) > > > -print-file-name=include) -I$(srcdir)/include -I$(builddir) > > > -I$(builddir)/include -Wall -W > > > > What's the advantage? > > Ah, I remember. There was a problem with stddef.h right? > > So you propose something like this: > > -TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -isystem=$(srcdir)/include > -I$(srcdir)/include -I$(builddir) -I$(builddir)/include \ > +TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -isystem=$(shell $(CC) > -print-file-name=include) -I$(srcdir)/include -I$(builddir) > -I$(builddir)/include \ > > ? See my previous mail, actually this: -TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -isystem=$(srcdir)/include -I$(srcdir)/include -I$(builddir) -I$(builddir)/include \ +TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -nostdinc -isystem $(shell $(CC) -print-file-name=include) -I$(srcdir)/include -I$(builddir) -I$(builddir)/include \ The = in -isystem doestn't make much sense to me. And with above -nostdinc really works for us. -- 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] Add -nostdinc to TARGET_CFLAGS
Am Sonntag, den 15.11.2009, 12:04 +0100 schrieb Robert Millan:
> On Sat, Nov 14, 2009 at 10:16:45PM +0100, Felix Zielcke wrote:
> > Am Mittwoch, den 04.11.2009, 11:48 +0100 schrieb Felix Zielcke:
> > >
> > > Thanks to the hint from rubisher I looked now at Linux Makefiles.
> > > They use this:
> > >
> > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC)
> > > -print-file-name=include)
> > >
> > > # ls $(gcc-4.4 -print-file-name=include)/stdarg.h
> > > /usr/lib/gcc/x86_64-linux-gnu/4.4.2/include/stdarg.h
> > >
> >
> > Robert?
> > IMO this makes at least more sense then what we have now
> > and I just tested this now with and without a seperate build directory
> > with experimental branch and it works
> > TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -nostdinc -isystem $(shell $(CC)
> > -print-file-name=include) -I$(srcdir)/include -I$(builddir)
> > -I$(builddir)/include -Wall -W
>
> What's the advantage?
>
The advantage is that this does exatly what we want for the target.
Remove /usr/include from the include search directories but still keep
the gcc internal one for e.g. stdarg.h
As far as I understand the gcc manual, isystem adds this directory to
the search path and treats all headers there in as system headers.
And with the = between -isystem and $(srcdir) it actually uses
${sysroot}{$srcdir} but we don't use any --sysroot or -isysroot.
The arguments we currently have there just look wrong with my understand
of the gcc manual
$ cat test.c
#include
#include
int main (void)
{
return 0;
}
$ srcdir=$PWD builddir=$PWD gcc -isystem=$srcdir/include -I$srcdir/include
-I$builddir -I$builddir/include test.c -o test && ls test
test
$ srcdir=$PWD builddir=$PWD gcc -nostdinc -isystem $(gcc
-print-file-name=include) -I$srcdir/include -I$builddir -I$builddir/include
test.c
test.c:2:20: error: stdint.h: No such file or directory
--
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] Add -nostdinc to TARGET_CFLAGS
Am Mittwoch, den 04.11.2009, 11:48 +0100 schrieb Felix Zielcke: > Am Donnerstag, den 29.10.2009, 11:36 +0100 schrieb Robert Millan: > > On Thu, Oct 29, 2009 at 11:14:33AM +0100, Robert Millan wrote: > > > > > > It appears that -nostdinc also excludes GCC internal header directory (for > > > e.g. stdarg.h), which I didn't expect. > > > > > > Does someone know a clean way to resolve this? A quick check at GCC > > > command-line options didn't reveal a way to explicitly include that > > > directory afterwards without knowing its path. > > > > > > I.e. something similar to `gcc -print-file-name=libgcc.a` > > > > Maybe with -isysroot=`pwd`/dummy instead of -nostdinc. > > > > It's an ugly kludge, but the alternatives look even worse. > > > > Does someone have a better idea? > > > > Thanks to the hint from rubisher I looked now at Linux Makefiles. > They use this: > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) > > # ls $(gcc-4.4 -print-file-name=include)/stdarg.h > /usr/lib/gcc/x86_64-linux-gnu/4.4.2/include/stdarg.h > Robert? IMO this makes at least more sense then what we have now and I just tested this now with and without a seperate build directory with experimental branch and it works TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -nostdinc -isystem $(shell $(CC) -print-file-name=include) -I$(srcdir)/include -I$(builddir) -I$(builddir)/include -Wall -W -- 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] Re: Bug in read_handler_list (autoloading) ???
Am Samstag, den 14.11.2009, 16:35 +0100 schrieb Robert Millan: > On Fri, Nov 13, 2009 at 11:43:52PM +0100, Vladimir 'phcoder' Serbinenko wrote: > > Felix Zielcke wrote: > > > Am Donnerstag, den 12.11.2009, 21:46 +0530 schrieb BVK: > > > > > >> Valgrind log is attached. It also reported invalid free for the same > > >> place. > > >> > > >> BTW, valgrind is run as > > >> > > >> sudo valgrind -v --log-file=/tmp/valgrind.log ./grub-emu > > >> > > > > > > Here's a grub-emu tested patch to fix this > > > > > > > > > > > Why are all handlers are removed on normal.mod unload? If user e.g. > > relies on special terminal he may lose terminal completely. I would say > > it's better not to touch already loaded modules. I temporarily unmerged > > it from experimental. We can remerge it once issues are fixed > > Did you unmerge Felix' fix, or the original prefix move fix? I didn't commit my fix. He reverted your original merge of this. > My goal was to make command and file-system auto-completion not break when > $prefix is changed. Handlers are not the important change in my initial > patch, and if it's problematic it can be discarded IMO. > -- 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: Booting TrueCrypt Windows Hard Drive
Am Samstag, den 14.11.2009, 13:22 +0100 schrieb Johannes Bauer: > Felix Zielcke schrieb: > > > On launchpad someone made a bugreport where removing the search and > > drivemap commands from the generated Win 7 menu entry by os-prober > > breaks booting it. > > So I removed drivemap command for Vista and 7. > > It wouldn't make much sense if the search line would break it. > > Well, without the drivemap command, it doesn't boot up at all... > > > Did you try without drivemap? > > Yup. TrueCrypt immediately complains: > > TrueCrypt Boot Loader > Loader Damaged! Use Rescue Disk: [blabla] > > > You could also try to directly chainload MBR with (hd1) > > Well, that's the same as "chainloader (hd0,1)/boot/truecrypt.mbr", isn't > it? I tried it and they yielded the same result. I meant with set root=(hd1) or set root=(hd0) and with/without drivemap. As I said there's a difference if you do set root=(hd1) chainloader (hd0)+1 or set root=(hd0) ; chainloader +1 > > Note that there's a difference if you use set root=(hd1,1) chainloader > > +1 or just chainloader (hd1,1)+1 > > The "chainloader (hd1,1)+1" which was what I originally tried does not > work at all since (hd1,1) is encrypted at that point and thus grub does > not know recognize the file format and won't boot - forcing the > chainload with "--force" causes the system to lock up at boot. > MBR would be (hd1) or (hd0) not (hd1,1) But maybe it's really like Vladimir thinks and Truecrypt loader and windows bootloader are different in this case. -- 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: Booting TrueCrypt Windows Hard Drive
Am Freitag, den 13.11.2009, 18:28 +0100 schrieb Johannes Bauer:
> Dear list,
>
> I've read a whole lot about problems booting Windows through Grub - but
> found no solution at all. By playing around with the options, I found a
> solution which *almost* works:
>
> My main (Linux) drive is /dev/sda. / and /boot are on /sda1, i.e. (hd0,1).
> My crap (Windows) drive is /dev/sdb. There is only one partition
> /dev/sdb1. The whole drive has been encrypted with TrueCrypt.
>
> I've copied the MBR of /dev/sdb to /boot/truecrypt.mbr. Then I used the
> following grub entry:
>
> menuentry "Sigh" {
> insmod drivemap
> set root=(hd1,1)
> drivemap (hd0) (hd1)
> drivemap (hd1) (hd0)
> chainloader (hd0,1)/boot/truecrypt.mbr
> boot
> }
>
> This gets further than all other tutorials I've read before - it makes
> Truecrypt actually ask for my password. After I've entered it
> successfully, the Windows logo comes up and it appears to be booting.
> However, after about 20 seocnds, it just resets hard. The next time I
> boot Windows (7, BTW) that way, I get a message saying that it crashed
> during bootup and if I want to use some kind of boot rescue restore
> magic. When I say yes, a textmode progressbar comes up. When it reaches
> 100%, the computer again resets hard.
>
> I have a feeling that I'm almost there but am missing something - can
> somebody please help me?
>
> Kind regards,
> Johannes
On launchpad someone made a bugreport where removing the search and
drivemap commands from the generated Win 7 menu entry by os-prober
breaks booting it.
So I removed drivemap command for Vista and 7.
It wouldn't make much sense if the search line would break it.
Did you try without drivemap?
You could also try to directly chainload MBR with (hd1)
Note that there's a difference if you use set root=(hd1,1) chainloader
+1 or just chainloader (hd1,1)+1
So you could also play around a bit with them.
The root device gets into %dl register and so the bootcode can make use
of that one.
If you specify the device inside chainloader command only GRUB itself
knows that one.
--
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: gettext branch
Am Sonntag, den 01.11.2009, 23:47 + schrieb Carles Pina i Estany: > Hi, > > On Nov/01/2009, Carles Pina i Estany wrote: > > > On Nov/01/2009, Carles Pina i Estany wrote: > > > > > bzr.savannah.gnu.org/grub/people/cpina/gettext2 > > > (notice the 2 at the end!) > > > > without the 2, Robert moved it correctly. > > > > So the address of the gettext branch is. > > bzr.savannah.gnu.org/grub/people/cpina/gettext2 > > bzr.savannah.gnu.org/grub/people/cpina/gettext > > Without 2, as I said before. > Hi Carles, please push your bzr branch again on savannah. It got lost because we had to create all bzr branches again due to corruption in the trunk. -- 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: Roadmap for LUA support in GRUB
Am Freitag, den 13.11.2009, 00:08 -0800 schrieb Roman Shaposhnik: > On Thu, Nov 12, 2009 at 2:38 AM, Robert Millan wrote: > > First of all, there's no license problem. We usually write our own code, > > but > > when we have specific reasons to import it from another project, any license > > that is compatible with GPL (v3 and later) would be considered suitable. > > Aha! So the Lua license really is a red herring here.. My bad I used the wrong word, I should have said s/license/copyright/ But anyway > > However, we only import code from external projects when there's an > > important > > reason to do so. For example, we imported LZMA code because we needed the > > best compression around, and we didn't want to reinvent the wheel. In the > > specific case of LUA, this compromise didn't make sense to us since we > > already > > had a scripting engine. > > ...the real reason seems to be that you don't really believe in Lua as a > primary > scripting language for GRUB, correct? Why do you think Lua as a *primary* language/format/whatever for grub.cfg would be right? With sh grub.cfg isn't that different from any other normal config file or even GRUB Legacy's menu.lst Learning Lua might be not so difficult for average experienced Linux users. But things are moving. Not every average Linux user has now some experience. -- 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
[PATCH] Re: Bug in read_handler_list (autoloading) ???
Am Donnerstag, den 12.11.2009, 21:46 +0530 schrieb BVK:
> Valgrind log is attached. It also reported invalid free for the same place.
>
> BTW, valgrind is run as
>
> sudo valgrind -v --log-file=/tmp/valgrind.log ./grub-emu
Here's a grub-emu tested patch to fix this
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
2009-11-12 Felix Zielcke
* normal/handler.c (read_handler_list): Use grub_handler_unregister
to properly remove the handlers. Skip `rescue' and `console'
handlers defined in kernel.
=== modified file 'normal/handler.c'
--- normal/handler.c 2009-11-09 14:55:27 +
+++ normal/handler.c 2009-11-12 20:31:00 +
@@ -176,14 +176,21 @@ read_handler_list (void)
if (file)
{
char *buf = NULL;
-
+ grub_handler_class_t hcnext, hc = grub_handler_class_list;
+ grub_handler_t hl;
/* Override previous handler.lst. */
- while (grub_handler_class_list)
+ for (; hc ; hc = hcnext)
{
- grub_handler_class_t tmp;
- tmp = grub_handler_class_list->next;
- grub_free (grub_handler_class_list);
- grub_handler_class_list = tmp;
+ hcnext = hc->next;
+ hl = hc->handler_list;
+ while (hl)
+ {
+ grub_handler_t tmp = hl->next;
+ if (grub_strcmp (hl->name, "rescue") != 0
+ && grub_strcmp (hl->name, "console") != 0)
+ grub_handler_unregister (hc,hl);
+ hl = tmp;
+ }
}
for (;; grub_free (buf))
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Unification of grub-mkrescue
Am Donnerstag, den 12.11.2009, 13:12 +0100 schrieb Robert Millan: > On Thu, Nov 12, 2009 at 11:42:47AM +0100, Robert Millan wrote: > > > and support for floppy > > > images. > > > > I didn't consider this critical, but I'm fine with adding it back if > > someone finds a way to do it cleanly. > > Sorry, I confused this with something else. It's actually trivial; I > will > do this before commit. > Thanks. Even in my opinion this isn't that critical. Todays computers probable rarely have a floppy drive. But if you have one and a spare floppy it's pretty useful. Oh why do I _now_ get this idea only and not before. *sigh* (See #grub why ;)) -- 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: grub2 (1.97.1) on RAID0
Am Donnerstag, den 12.11.2009, 12:40 +0100 schrieb André Fettouhi:
> That sucks big time!
>
> i...@dupondje.be skrev:
> > To bad :)
> > Its not possible to use dmraid with Grub2 yet.
> >
> > I had to switch bad to grub1 because its not possible to get it working.
> > Hopefully some developper wants to implement this :)
> >
> > Sincerely,
> > Jean-Louis
> >
If you have some /dev/mapper/nvida_ pdc_ or isw_ device you can try
attached patch.
But it's a dirty way to implement it and not really tested.
I haven't checked it with recent releases but at the time I wrote it it
worked with my nvidia dmraid device.
isw_ devices seems to have different formats only one of them is
supported.
And pdc_ worked for Pavel but for someone else on IRC it didn't.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
diff --git a/util/getroot.c b/util/getroot.c
index 120ab13..f1bfd4c 100644
--- a/util/getroot.c
+++ b/util/getroot.c
@@ -396,13 +396,38 @@ grub_guess_root_device (const char *dir)
return os_dev;
}
+int
+grub_util_is_dmraid (const char *os_dev)
+{
+ if (! strncmp (os_dev, "/dev/mapper/nvidia_", 19))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/isw_", 16))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/hpt37x_", 19))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/hpt45x_", 19))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/via_", 16))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/lsi_", 16))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/pdc_", 16))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/jmicron_", 20))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/asr_", 16))
+return 1;
+ else if (! strncmp (os_dev, "/dev/mapper/sil_", 16))
+return 1;
+ return 0;
+}
int
grub_util_get_dev_abstraction (const char *os_dev UNUSED)
{
#ifdef __linux__
/* Check for LVM. */
- if (!strncmp (os_dev, "/dev/mapper/", 12))
+ if (!strncmp (os_dev, "/dev/mapper/", 12) && ! grub_util_is_dmraid (os_dev))
return GRUB_DEV_ABSTRACTION_LVM;
/* Check for RAID. */
diff --git a/util/hostdisk.c b/util/hostdisk.c
index a06ecca..0d94ccd 100644
--- a/util/hostdisk.c
+++ b/util/hostdisk.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -819,6 +820,27 @@ convert_system_partition_to_system_disk (const char *os_dev)
p[4] = '\0';
return path;
}
+ /* If this is a Nvidia fake raid. */
+ if (strncmp ("mapper/nvidia_", p, 14) == 0 && p[22] >= '0' && p[22] <= '9')
+ {
+ p[sizeof ("mapper/nvidia_abcdefgh") - 1] = '\0';
+ return path;
+ }
+ if (strncmp ("mapper/pdc_", p, 11) == 0 && p[20] >= '0' && p[20] <= '9')
+ {
+ p[sizeof ("mapper/pdc_abcdefghi") - 1] = '\0';
+ return path;
+ }
+ if (strncmp ("mapper/isw_", p, 11) == 0 && p[29] >= '0' && p[29] <= '9')
+ {
+ p[sizeof ("mapper/isw_abcdefghij_Volume0") - 1] = '\0';
+ return path;
+ }
+ if (strncmp ("mapper/isw_", p, 11) == 0 && p[27] >= '0' && p[27] <= '9')
+ {
+ p[sizeof ("mapper/isw_abcdefghij_ARRAY") - 1] = '\0';
+ return path;
+ }
}
return path;
@@ -869,6 +891,10 @@ device_is_wholedisk (const char *os_dev)
if (os_dev[len - 1] < '0' || os_dev[len - 1] > '9')
return 1;
+ if (strncmp ("/dev/mapper/isw_", os_dev, 16) == 0 && os_dev[34] == '\0')
+return 1;
+ if (strncmp ("/dev/mapper/isw_", os_dev, 16) == 0 && os_dev[32] == '\0')
+return 1;
return 0;
}
#endif
@@ -935,7 +961,7 @@ grub_util_biosdisk_get_grub_dev (const char *os_dev)
does not count the extended partition and missing primary
partitions. Use same method as on Linux here. */
{
-char *name;
+char *name, *os_dev_uuid;
grub_disk_t disk;
int fd;
struct hd_geometry hdg;
@@ -985,7 +1011,44 @@ grub_util_biosdisk_get_grub_dev (const char *os_dev)
return 0;
}
+auto int find_partition_by_uuid (const char *name);
+int find_partition_by_uuid (const char *name)
+{
+ grub_device_t dev;
+
+ if (name[0] == 'f' && name[1] == 'd'
+ && name[2] >= '0' && name[2] <= '9')
+ return 0;
+
+ dev = grub_device_open (name);
+ if (dev)
+ {
+ grub_fs_t fs;
+
+ fs = grub_fs_probe (dev);
+
+ if (fs && fs->uuid)
+ {
+ char *uuid, *p;
+
+ (
Re: [PATH] grub-mkrelpath
Am Sonntag, den 01.11.2009, 16:39 +0100 schrieb Felix Zielcke:
> New version avaible at
> sftp://bzr.savannah.gnu.org/srv/bzr/grub/people/fzielcke/mkrelpath
Ah Vladimir you aren't anymore on IRC.
So that I don't forget to ask you, I pushed this now:
2009-11-11 Felix Zielcke
* util/grub-probe.c (probe): Abort with an error if file can't be
opened via GRUB facilities.
2009-11-11 Felix Zielcke
* util/i386/pc/grub-setup.c (setup): Make core.img path relative
to its root.
--
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] Unification of grub-mkrescue
Am Mittwoch, den 11.11.2009, 22:50 +0100 schrieb Robert Millan: > Attached is a unified version of grub-mkrescue. This grub-mkrescue not > just provides both i386-pc and i386-coreboot support from the same source, > but also from the same runtime. > > Provided that both i386-pc and i386-coreboot ports are installed [1], > grub-mkrescue will generate a CDROM image that is bootable on both > platforms at the same time. > > Please give it some review, I'll be committing this to util/grub-mkrescue.in > shortly. > > [1] Currently a bit problematic due to file conflicts; this fixes one > of them (the other is grub-install). Does that meant the old i386-pc script gets completely dropped? I don't like it that it doestn't have --overlay and support for floppy images. -- 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: Roadmap for LUA support in GRUB
Am Mittwoch, den 11.11.2009, 10:13 -0800 schrieb Roman Shaposhnik: > Hi! > > On Wed, Nov 11, 2009 at 2:41 AM, Felix Zielcke wrote: > > Am Dienstag, den 10.11.2009, 19:38 -0800 schrieb Roman Shaposhnik: > >> Browsing the archives of grub-devel reveals that Lua support was moved to > >> grub-extras which makes me ask these two questions: > >> 1. Was the decision to move Lua based exclusively on the licensing > >> concerns? > > > > I don't think it was exclusively only decided because of the license, > > but this is the top reason for it. > > I'd appreciated knowing non-licensing reasons as well. Uhm actually I should have written `I don't know if it was*' and I forgot that Robert even sent a mail to this list about it: http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00424.html > On the licensing front, though, what was an actual issue there? > After all, Lua has a respectable FOSS license and I'm sure there's tons of > MIT-licensed software in Debian. What made Lua different? The difference is that GRUB is a GNU project and not some other random open source package. FSF wants to have the copyright of all code which is in GNU so that they have the right to enforce the licences of all GNU projects in courts. > > > lua.mod IIRC was 99K big and it was always included into the floppy > > rescue images. > > 99K doesn't seem to be a lot compared to other auxiliary modules I find > in /boot/grub on my Ubuntu. > To some extent, that's exactly the reason of my frustration -- saving 99K > on a partition full of all sorts of stuff hardly justifies withholding a > useful > feature. Don't take it the wrong way, though, this frustration is totally > misplaced on grub-devel, but to some extent had Lua module been part > of the core GRUB v2 I'm pretty sure distribution maintainers wouldn't have > thrown it out. > Well another solution would be if you can convince lua developers to assign copyright to the FSF for all the code we need to have in GRUB in order to support it. But before you go this route please talk with Robert if he's willing to reintrage it after assigned copyright. Not that you waste your time. -- 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: Roadmap for LUA support in GRUB
Am Dienstag, den 10.11.2009, 19:38 -0800 schrieb Roman Shaposhnik: > Browsing the archives of grub-devel reveals that Lua support was moved to > grub-extras which makes me ask these two questions: > 1. Was the decision to move Lua based exclusively on the licensing > concerns? I don't think it was exclusively only decided because of the license, but this is the top reason for it. License alone is the only reason why grub-extras has been created. But Robert or maybe Vladimir may be able to tell you more. > 2. Is there any hope of ever seeing GRUB v2 + Lua in major distributions > once they start adopting GRUB v2 as a default boot loader? Convince the major distributions that integrating lua in their builds is a good reason. In Debian we still dropped lua even though we already include grub-extras into our build system since it was created. In our opinion lua can be useful for a small amount of persons but is just a waste for the majority. lua.mod IIRC was 99K big and it was always included into the floppy rescue images. -- 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: warn_unused_result attribute (Re: mingw32 compile fixes (Re: [GITGRUB] New menu interface (implementation)))
Am Montag, den 09.11.2009, 21:04 +0100 schrieb Robert Millan: > On Tue, Nov 10, 2009 at 12:46:06AM +0800, Bean wrote: > > Some system such as ubuntu karmic define write using > > warn_unused_result attribute, which cause a warning when return > value > > of write is not used. As grub compile with -Werror, this turn into > > error, to work around it, use something like this: > > > > ssize_t tmp = write(bcat, buf, 2048); > > (void) tmp; > > Isn't "(void) write (bcat, buf, 2048)" enough? Why not just check the return code and print a warning (or maybe even error) for tmp != 2048? -- 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: Bazaar as main repository
Am Montag, den 09.11.2009, 16:49 +0100 schrieb Michal Suchanek: > > is there a tool similar to git-svn that would import bzr repository > into git? You can use the bzr fast-export , git fast-import method for a one time conversion. If I understood Vladimir on IRC right, incremental mirroring should also be possible with it. There also seems to be some git-bzr stuff: http://github.com/pieter/git-bzr/network -- 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: [PATH] grub-mkrelpath
Am Mittwoch, den 04.11.2009, 15:59 +0100 schrieb rubisher: > btw I just find a small typo in your branch: Thanks fixed. I should have taken another look at that part when I imported in bzr. -- 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: [PATH] grub-mkrelpath
Am Mittwoch, den 04.11.2009, 10:55 +0100 schrieb rubisher: > > Right trunk contains my -I($srcdir)/include fix. > > merged now. > Sorry I don't agree with your fix: As you might have thought already from the following sentence, I already suspected that it's not the proper way. By the way this topic really belongs to the -nostdinc Thread from Robert. This is not at all specific to my grub-mkrelpath. At least this fixed building with a seperate build directory. > > > > But I still have the feeling using -isystem is wrong at all or at least > > the =. > Well as far as I understand, yes for cross-compiling that would make stuff > easier? > > A quick look at linux kernel build, it shows that also use -isystem but > not yet with '=' option so may be my previous patch would be more relevant. > > I let you appreciate. IMO we should use the same approach as Linux kernel does. Using -isystem just for the gcc include headers. I don't think gcc should treat our own headers as system headers. > Tx, > J. > > PS: any idea where (in which part of this proj) should I have a look to > learn why ofs doesn't reach to find disks and their structures?) > No clue. Better ask such questions in a seperate mail, not hidden in a thread which has nothing to do with this. The chances are much higer that then who can answer the qestion will read it. -- 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] Add -nostdinc to TARGET_CFLAGS
Am Donnerstag, den 29.10.2009, 11:36 +0100 schrieb Robert Millan: > On Thu, Oct 29, 2009 at 11:14:33AM +0100, Robert Millan wrote: > > > > It appears that -nostdinc also excludes GCC internal header directory (for > > e.g. stdarg.h), which I didn't expect. > > > > Does someone know a clean way to resolve this? A quick check at GCC > > command-line options didn't reveal a way to explicitly include that > > directory afterwards without knowing its path. > > > > I.e. something similar to `gcc -print-file-name=libgcc.a` > > Maybe with -isysroot=`pwd`/dummy instead of -nostdinc. > > It's an ugly kludge, but the alternatives look even worse. > > Does someone have a better idea? > Thanks to the hint from rubisher I looked now at Linux Makefiles. They use this: NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) # ls $(gcc-4.4 -print-file-name=include)/stdarg.h /usr/lib/gcc/x86_64-linux-gnu/4.4.2/include/stdarg.h -- 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,HURD] Fix GNU/Hurd menu entry generation
Am Dienstag, den 03.11.2009, 15:01 +0100 schrieb Samuel Thibault: > Yves Blusseau, le Tue 03 Nov 2009 14:36:09 +0100, a écrit : > > is it normal that hurd entry match ANY OS because you left the wildcard > > in the hurd case: > > Ugh, no, I was misguided by the hurd tag indeed, here is a patch. > > Samuel Commited. -- 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: [PATH] grub-mkrelpath
Am Dienstag, den 03.11.2009, 14:51 +0100 schrieb rubisher: > On Tue, 03 Nov 2009 11:33:42 +0100, Felix Zielcke > wrote: > > Am Dienstag, den 03.11.2009, 11:21 +0100 schrieb rubisher: > >> Hello Felix, > >> > >> On Mon, 02 Nov 2009 09:54:43 +0100, Felix Zielcke > >> wrote: > >> > Am Sonntag, den 01.11.2009, 23:04 +0100 schrieb Robert Millan: > >> >> On Sun, Nov 01, 2009 at 04:39:42PM +0100, Felix Zielcke wrote: > >> >> > > >> >> > I added now a comment that this shouldn't ever happen. > >> >> > > >> >> > New version avaible at > >> >> > bzr+ssh://bzr.savannah.gnu.org/grub/people/fzielcke/mkrelpath > >> >> > >> [snip] > >> > >> I am trying to build your mkrelpath branch on my ppc with debian > gcc-4.4 > >> latest unstable release 4.4.2-1 and failed to build as far as I > >> understand > >> because isystem syntax is not correct; following diff help me to > complete > >> the build: > > > > Which is the same as in trunk. > right no issue to compile trunk 2676 but as following way (svn 2676): Right trunk contains my -I($srcdir)/include fix. merged now. But I still have the feeling using -isystem is wrong at all or at least the =. -- 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: [PATH] grub-mkrelpath
Am Dienstag, den 03.11.2009, 11:21 +0100 schrieb rubisher: > Hello Felix, > > On Mon, 02 Nov 2009 09:54:43 +0100, Felix Zielcke > wrote: > > Am Sonntag, den 01.11.2009, 23:04 +0100 schrieb Robert Millan: > >> On Sun, Nov 01, 2009 at 04:39:42PM +0100, Felix Zielcke wrote: > >> > > >> > I added now a comment that this shouldn't ever happen. > >> > > >> > New version avaible at > >> > bzr+ssh://bzr.savannah.gnu.org/grub/people/fzielcke/mkrelpath > >> > [snip] > > I am trying to build your mkrelpath branch on my ppc with debian gcc-4.4 > latest unstable release 4.4.2-1 and failed to build as far as I understand > because isystem syntax is not correct; following diff help me to complete > the build: Which is the same as in trunk. > === <> === > (i.e. I have to rm '=' between isystem and its arg) > > I don't know if it's specific to ppc arch, sorry. > Seems so, because on amd64 it works fine. The docs say: -isystem dir Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. If dir begins with =, then the = will be replaced by the sysroot prefix; see --sysroot and -isysroot. So it should be valid. Maybe with a space between -isystem and = it works for you too. But now that I read that I'm not so sure we actually should use = -- 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,HURD] Fix root device passing
Am Montag, den 02.11.2009, 20:06 +0100 schrieb Felix Zielcke:
> Am Montag, den 02.11.2009, 19:53 +0100 schrieb Samuel Thibault:
> > Colin Watson, le Mon 02 Nov 2009 18:50:43 +, a écrit :
> > > 'multiboot ${kernel} root=device:${GRUB_DEVICE#/dev/}' would be simpler
> > > and quicker.
> >
> > And will not work on some systems.
> >
> > Samuel
>
> Why ones?
Uhm which ones of course.
> I just looked in POSIX.1-2008 and it defines it.
> Both bash and dash supports it.
> Note that 10_hurd only gets installed if the host kernel is HURD.
> Is there any HURD based distribution avaible besides Debian?
>
>
--
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,HURD] Fix root device passing
Am Montag, den 02.11.2009, 19:53 +0100 schrieb Samuel Thibault:
> Colin Watson, le Mon 02 Nov 2009 18:50:43 +, a écrit :
> > 'multiboot ${kernel} root=device:${GRUB_DEVICE#/dev/}' would be simpler
> > and quicker.
>
> And will not work on some systems.
>
> Samuel
Why ones?
I just looked in POSIX.1-2008 and it defines it.
Both bash and dash supports it.
Note that 10_hurd only gets installed if the host kernel is HURD.
Is there any HURD based distribution avaible besides Debian?
--
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: [PATH] grub-mkrelpath
Am Montag, den 02.11.2009, 14:45 +0100 schrieb Robert Millan: > > I wasn't sure if I should do it at the same time or not. > > The just grub-mkrelpath way has the advantage that if something in > the > > function is still broken (which I don't think) then just > grub-mkrelpath > > is broken not also grub-probe. > > Don't worry, if something is broken it's better to know early about > it. We > have experimental branch for safety. I just pushed the grub-probe change. Works also for me. and I also changed the `reading %s via GRUB facilities' info message to use the grub_path instead of the OS path. IMO it's more useful then showing twice the same path. -- 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: [PATH] grub-mkrelpath
Am Sonntag, den 01.11.2009, 23:04 +0100 schrieb Robert Millan: > On Sun, Nov 01, 2009 at 04:39:42PM +0100, Felix Zielcke wrote: > > > > I added now a comment that this shouldn't ever happen. > > > > New version avaible at > > bzr+ssh://bzr.savannah.gnu.org/grub/people/fzielcke/mkrelpath > > Vladimir, could you review and consider for inclusion in experimental? Or > if you're busy, let me know and I'll do it. > > Btw, with this the "#if 0" in util/grub-probe.c can be removed. Felix, if > you like you can adjust that in the same patchset, or otherwise we can just > do it later. I wasn't sure if I should do it at the same time or not. The just grub-mkrelpath way has the advantage that if something in the function is still broken (which I don't think) then just grub-mkrelpath is broken not also grub-probe. -- 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: bzr trunk failed to build from separate build directory
Am Sonntag, den 01.11.2009, 22:58 +0530 schrieb BVK: > hi > > Bazaar branch, http://bzr.savannah.gnu.org/r/grub/trunk/grub doesn't > seem to build from separate build directory? When I tried building it > from trunk, it goes fine. > > gcc -Iboot/i386/pc -I../trunk/boot/i386/pc -isystem=../trunk/include > -I. -I./include -Wall -W -DASM_FILE=1 -nostdinc -fno-builtin -m32 -MD > -c -o boot_img-boot_i386_pc_boot.o ../trunk/boot/i386/pc/boot.S > ../trunk/boot/i386/pc/boot.S:20:25: error: grub/symbol.h: No such file > or directory > ../trunk/boot/i386/pc/boot.S:21:23: error: grub/boot.h: No such file > or directory > make: *** [boot_img-boot_i386_pc_boot.o] Error 1 > > Am I doing it wrong? Can anybody confirm this? You left the IRC channel too soon. Solution is to add `-I$(srcdir)/include' to TARGET_CPPFLAGS in Makefile or Makefile.in and call configure again -- 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: [PATH] grub-mkrelpath
Am Samstag, den 29.08.2009, 09:51 +0200 schrieb Felix Zielcke:
> Am Samstag, den 29.08.2009, 01:55 +0200 schrieb Robert Millan:
> > On Fri, Aug 28, 2009 at 07:58:39PM +0200, Felix Zielcke wrote:
> > > +#else /* ! HAVE_REALPATH */
> > > + grub_util_warn ("grub-mkrelpath might not work on your OS correctly.");
> > > + /* make relative path absolute. */
> > > + if (*path != '/')
> > > +{
> > > + len = 1024;
> > > + buf2 = xmalloc (len);
> > > + do
> > > + {
> > > + buf2 = getcwd (buf2, len);
> > > + if (buf2 == NULL)
> > > + {
> > > + if (errno != ERANGE)
> > > + grub_util_error ("can not get current working directory");
> > > + else
> > > + len *= 2;
> > > + buf2 = xrealloc (buf2, len);
> > > + }
> > > + } while (buf2 == NULL);
> > > + buf = xmalloc (strlen (path) + strlen (buf2) + 1);
> > > + strcpy (buf, buf2);
> > > + strcat (buf, "/");
> > > + strcat (buf, path);
> > > +}
> > > + else
> > > + buf = strdup (path);
> > > +#endif /* ! HAVE_REALPATH */
> >
> > Please can you leave this part out? realpath() is POSIX, so it should be
> > present in all systems we support, and if it isn't, we should be using a
> > complete implementation from Gnulib instead, but we don't need to worry
> > about this untill/unless someone reports it as a problem.
>
> Ok, but should I then check in configure.ac that realpath is required or
> something else?
> Or should I just assume that realpath is always avaible?
For now I assume that realpath is avaible.
> > > + p = strrchr (buf, '/');
> > > + if (p == NULL)
> > > + grub_util_error ("FIXME: no / in buf.
> > > (make_system_path_relative_to_its_root)");
> >
> > Does this ever happen?
>
> As Vladimir said, it shouldn't ever happen, but I thought it would be
> better to check for this explicitly instead of core dumping in that
> case.
I added now a comment that this shouldn't ever happen.
New version avaible at
bzr+ssh://bzr.savannah.gnu.org/grub/people/fzielcke/mkrelpath
--
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] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 18:02 + schrieb rubisher: > and at the grub sh prompt, ls doesn't report any disk? > > Even thought: # more /boot/grub/device.map > (hd0) /dev/sda > (hd1) /dev/sdb device.map is only used for the utilities. real GRUB never uses it. > Could it be for the reason you explained above? Sorry but I don't know anything at all about Openfirmware. -- 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: Experimental branch of GRUB
Am Samstag, den 31.10.2009, 19:33 +0100 schrieb Vladimir 'phcoder' Serbinenko: > Felix Zielcke wrote: > > Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: > > > >> An experimental branch of GNU GRUB is now available: > >> > >> > > [...] > > > >> I'm appointing Vladimir Serbinenko as the developer in charge of this > >> branch. > >> Patches may be merged in it at his discretion. > >> > > > > Vladimir whats your policy for merging trunk into experimental? > > Do you want to track it on your own to keep them in sync? > > > > > > > As nyu said everything which is ok for mainline is ok for experimental > and so the only issue are conflicts but in practice any sane way to > resolve them is ok. So I feel like no discussion should be necessary > about this > Well my question was mainly `Do you want to merge trunk into it or can anyone of us do it?' But seems like so :) -- 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: GRUB2 and DMRAID
Am Samstag, den 31.10.2009, 16:11 +0100 schrieb Jean-Louis Dupond: > Is there already a possibility to get DMRAID working with GRUB2? > Even when the /boot device is on a DMRAID partition. > > Seems like we have already a dmraid_nvidia module, but that doesn't work? That module is only useful with ata.mod, which isn't the default. With default biosdisk.mod the BIOS handles the RAID for us. All the GRUB modules have nothing to do with handling the OS specific things like device names. > It would be very nice to get grub2 & dmraid working nicely together. > As we are now stuck to grub1 for that. On Debian BTS and Launchpad there's a bug about this. And maybe even Savannah. The main problem is that our way to map Linux devices to GRUB devices doestn't work with multipath and dmraid devices. There's a first patch I made for nvidia_ pdc_ and some isw_ devices, but that's the wrong approach. -- 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: Experimental branch of GRUB
Am Samstag, den 24.10.2009, 15:06 +0200 schrieb Robert Millan: > > An experimental branch of GNU GRUB is now available: > [...] > > I'm appointing Vladimir Serbinenko as the developer in charge of this branch. > Patches may be merged in it at his discretion. Vladimir whats your policy for merging trunk into experimental? Do you want to track it on your own to keep them in sync? -- 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] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 12:30 +0100 schrieb Robert Millan: > On Sat, Oct 31, 2009 at 11:34:22AM +0100, Felix Zielcke wrote: > > Am Samstag, den 31.10.2009, 11:10 +0100 schrieb Robert Millan: > > > > > > Felix, did you have some code to do make_path_relative_to_its_root() > > > in C? > > > Then we can re-enable the check in grub-probe, fixing this problem. > > > > Yes, the only missing thing is that you wanted to have the function > > imported from gnulib for the systems which don't have realpath() > > But realpath() is posix AFAIK. Or you mean the realpath(name, NULL) GNU > extension? > realpath(name,NULL) is POSIX too now. The only problem I know about is that we support mingw32, i.e. plain windows not cygwin. If we say we don't support this anymore then I don't think we need to import the gnulib function. -- 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] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 11:10 +0100 schrieb Robert Millan: > > Felix, did you have some code to do make_path_relative_to_its_root() > in C? > Then we can re-enable the check in grub-probe, fixing this problem. Yes, the only missing thing is that you wanted to have the function imported from gnulib for the systems which don't have realpath() Would be easier if we didn't support mingw already, but then I can also look into including asprintf() from there. -- 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] grub incorrectly identifies ext3 as fat
Am Samstag, den 31.10.2009, 02:44 -0400 schrieb Andrew Clausen: > Hi, > > 2009/10/30 Robert Millan : > >> What about probing in the boot-loader? > > > > It's too late then. grub-install needs to know which filesystem module has > > to be included in core.img. > > What if the core.img contains modules for 2 or more file systems? > That only happens if you use grub-install with --modules or you directly create it with grub-mkimage. By default there's just one module and there only needs to be one. The one to access /boot/grub. It doestn't make sense to include more then one fs module into core.img With grub.efi the situation seems to be different though. But IMO it's a bug there. -- 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] grub incorrectly identifies ext3 as fat
Am Freitag, den 30.10.2009, 19:57 +0100 schrieb Robert Millan: > On Thu, Oct 29, 2009 at 02:58:09PM +, Andrew Clausen wrote: > > Hi all, > > > > grub (both the boot loader, and grub-probe) incorrectly identifies my > > ext3 partition as containing a fat file system. This means it can't > > boot without manual tweaking. The problem is caused by stale fat > > signatures... this is probably a common problem, as mke2fs often > > doesn't wipe old signatures. > > > > I wrote a patch. In order for a file system to be considered > > detected, dir() must not only succeed, it also must find at least one > > file or directory. This is pretty effective at ruling out misdetecting > > a filesystem based on a stale signature that wasn't wiped by mkfs. > > We already had code for this, see: > > 2009-09-05 Robert Millan > > * util/grub-probe.c (probe): Comment out buggy codepath, which > was unexpectedly enabled by Colin Watson's 2009-09-02 fix. This > should be re-enabled after 1.97. The problem with this (well not the problem why this was reverted) is that would just abort with an error if grub-probe detects the wrong filesystem. Ok would still be better then as currently embeding the wrong fs module to core.img -- 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: Problem building Grub2 on OSX
Am Donnerstag, den 29.10.2009, 22:19 + schrieb André Lopes: > > > After this i've tried to "svn update"(r2672) the sources but in the > make execution: > > gcc -Ikern -I./kern -nostdinc -I. -I./include -I./include -Wall -W > -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes > -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1 -falign-loops=1 > -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow > -DAPPLE_CC=1 -fnested-functions -m32 -fno-stack-protector > -mno-stack-arg-probe -Werror -fno-builtin -m32 -MD -c -o > kernel_mod-kern_main.o kern/main.c > In file included from kern/main.c:21: > ./include/grub/misc.h:23:20: error: stdarg.h: No such file or > directory > In file included from kern/main.c:21: > ./include/grub/misc.h:178: error: syntax error before ‘va_list’ > cc1: warnings being treated as errors > ./include/grub/misc.h:178: warning: function declaration isn’t a > prototype > ./include/grub/misc.h:180: error: syntax error before ‘va_list’ > ./include/grub/misc.h:180: warning: function declaration isn’t a > prototype > make: *** [kernel_mod-kern_main.o] Error 1 > > Any hints, on this problem? The svn tag release_1_97 compiles just > fine with the include of stdarg.h. > Just revert r2670 -- 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] try to reread partition table in 10_linux
Am Donnerstag, den 29.10.2009, 00:00 +0100 schrieb Robert Millan:
> On Wed, Oct 28, 2009 at 11:33:51PM +0100, Felix Zielcke wrote:
> > +if which sfdisk /dev/null ; then
> > + GRUB_DEVICE_DISK=`echo ${GRUB_DEVICE} | sed -e "s/[0-9]*$//"`
> > + sfdisk -R ${GRUB_DEVICE_DISK} 2>/dev/null
> > +fi
>
> s/[0-9]*$// doesn't catch all partition path layouts. More heuristic
> is needed for that (we have this in util/hostdisk.c), but duplicating it
> doesn't sound like a good idea.
Oh right I forgot about e.g. the hardware RAID controllers.
Hm if grub-probe would accept a GRUB device, we could use 2 grub-probe
calls to do that.
i.e. something like
tmp_drive=`grub-probe -t drive -d ${GRUB_DEVICE} | sed -e 's/,[a-z0-9]//g'`
GRUB_DEVICE_DISK=`grub-probe -t device ${tmp_drive}`
> Can this be avoided altogether? E.g. by telling Linux the partition path
> instead, or by using another interface.
I don't think we can:
$ LANG=C sudo sfdisk -R /dev/hda2
BLKRRPART: Invalid argument
I doubt the kernel provides more then one way to reread the partition
table.
Hm but maybe libparted or something else has a wrapper for this.
--
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
[PATCH] try to reread partition table in 10_linux
/dev/disk/by-uuid seems to be only created when the partition table gets
reread after a new filesystem has been created.
So here's a patch which does it with sfdisk.
I wasn't sure if some devices like e.g. /dev/mapper/* should be ignored.
mdraid devices can have partitions so they should be tried too.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
2009-10-28 Felix Zielcke
* util/grub.d/10_linux.in: Try to reread partition table with
sfdisk before we check if UUIDs can be used.
Index: util/grub.d/10_linux.in
===
--- util/grub.d/10_linux.in (revision 2668)
+++ util/grub.d/10_linux.in (working copy)
@@ -35,6 +35,13 @@ case ${GRUB_DEVICE} in
;;
esac
+# Try to reread partition table. In case a fresh filesystem has been created
+# /dev/disk/by-uuid doestn't yet exist.
+if which sfdisk /dev/null ; then
+ GRUB_DEVICE_DISK=`echo ${GRUB_DEVICE} | sed -e "s/[0-9]*$//"`
+ sfdisk -R ${GRUB_DEVICE_DISK} 2>/dev/null
+fi
+
if [ "x${GRUB_DEVICE_UUID}" = "x" ] || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \
|| ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" ; then
LINUX_ROOT_DEVICE=${GRUB_DEVICE}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-1.97
Am Mittwoch, den 28.10.2009, 17:39 +0100 schrieb Felix Zielcke: > Am Mittwoch, den 28.10.2009, 11:02 -0500 schrieb Bruce Dubbs: > > Since there is only one Makefile, I could take a shot at creating a > > patch to > > address this problem. Would you be interested in such a patch? > > That's wrong that there is just one Makefile. Well it's true that there > is just one file named like that, but the main Makefiles are the > conf/*.mk files generated from conf/*.rmk by genmk.rb. > > There wasn't yet much talk about improving our build system. > Bean just made it less complex in his lib branch (IIRC he called it > something like that) > But except of this nobody had much interest/time to improve or even > directly replace our build system by something better. > Okuji already objected against automake because according to him it > doestn't satisfy the needs for our build system. Uhm correction: I totally forgot about Vladimirs one Makefile implementation. Sorry Vladimir. But IIRC even about this there wasn't much talk about. -- 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: grub-1.97
Am Mittwoch, den 28.10.2009, 11:02 -0500 schrieb Bruce Dubbs: > Since there is only one Makefile, I could take a shot at creating a > patch to > address this problem. Would you be interested in such a patch? That's wrong that there is just one Makefile. Well it's true that there is just one file named like that, but the main Makefiles are the conf/*.mk files generated from conf/*.rmk by genmk.rb. There wasn't yet much talk about improving our build system. Bean just made it less complex in his lib branch (IIRC he called it something like that) But except of this nobody had much interest/time to improve or even directly replace our build system by something better. Okuji already objected against automake because according to him it doestn't satisfy the needs for our build system. -- 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: powerpc/sparc problems
Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke: > David are you still there? > And also anyone who has access to a powerpc machine (and experience)? > > In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols > can't be found in the grub-ieee1275 build on powerpc and also sparc. Ok the internal gcc symbols for sparc have been fixed now. But now there's another problem on sparc: ok boot Boot device: disk File and args: GRUB Illegal Instruction ok -- 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: os-prober incorrectly generates stanza - wrong root= device.
Am Dienstag, den 27.10.2009, 23:23 -0400 schrieb Chris Jones:
> While detecting other kernels, update-grub generates the following:
>
> menuentry "Debian GNU/Linux, kernel 2.6.24-etchnhalf.1-686 (on /dev/sda12)" {
>
> insmod ext2
>
> set root=(hd0,12)
>
> search --no-floppy --fs-uuid --set
> 042b6b67-5464-426e-a60a-21b71dfbcb74
> linux /boot/vmlinuz-2.6.24-etchnhalf.1-686 root=/dev/hda5 ro
>
> initrd /boot/initrd.img-2.6.24-etchnhalf.1-686
>
> }
>
> menuentry "Debian GNU/Linux, kernel 2.6.24-etchnhalf.1-686 (single-user mode)
> (on /dev/sda12)" {
> insmod ext2
>
> set root=(hd0,12)
>
> search --no-floppy --fs-uuid --set
> 042b6b67-5464-426e-a60a-21b71dfbcb74
> linux /boot/vmlinuz-2.6.24-etchnhalf.1-686 root=/dev/hda5 ro single
>
> initrd /boot/initrd.img-2.6.24-etchnhalf.1-686
>
> }
>
>
> /dev/sda12 is the correct partition, which is correctly reported in the
> menuentry and set root= statements, but not on the linux statement.
>
> The result, when trying to boot these entries, is that another system
> which has its /root & /root/boot on /dev/sda5 is booted instead.
>
> This happens with grub 1.97 as shipped by ubuntu 9.10.
>
> Not sure this qualifies as a bug, or just incorrect setup my end.
>
os-prober is a seperate package. It has nothing to do with us, except
that we call it to generate menuentries, if it's avaible.
It takes the root= value for the Linux kernel out of lilo.conf, menu.lst
or grub.cfg depending what you have on that partition installed.
So you have to change the bootloader configuration of your Debian etch.
--
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: Fwd: Problems with linux and framebuffer
Am Montag, den 26.10.2009, 23:32 +0200 schrieb Ciprian Dorin, Craciun: > I've tried initially to send this email to the mailing list > without beeing subscribed. Now I've subscribed and send the email > again. > > Ciprian. > > P.S.: Is there any mailing list for Grub users? > There is help-g...@gnu.org but it's pretty low traffic and at least I'm not subscribed there. For support questions about grub2 our IRC channel is better: #grub on irc.freenode.net > -- Forwarded message -- > From: Ciprian Dorin, Craciun > Date: Mon, Oct 26, 2009 at 11:01 PM > Subject: Problems with linux and framebuffer > To: grub-devel@gnu.org > > >Hello all! > >I've just installed Grub 1.97 on my laptop, and tried it... (I've > installed it manualy by calling grub-mkimage and grub-setup.) > >The problem is related with not beeing able to boot a Linux kernel > with framebuffer... (I've already tried the gfx dance...) :) (See the > attached config where I've commented the lines in discussion.) > >Can anyone send me a working grub.cfg example? grub-mkconfig should generate a gfxterm config if you have the fonts compiled. If you used grub-mkfont yourself you can use GRUB_FONT_PATH=/boot/myfont.pf2 in /etc/default/grub or /usr/local/default/grub depending what --prefix option was used to ./configure For `set gfxpayload=1024x768x32' or the deprecated `vga=0x317' to work you need at least `insmod vbe' -- 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
