Re: Installing GRUB 2 on a CompactFlash card
Quoting Colin D Bennett <[EMAIL PROTECTED]>: If I create one partition on the CF card, for GRUB, I assume I should set up my grub.cfg to refer to it as (hd0,1) since this will only be used on the TARGET SYSTEM, right? I suggest that you use the current GRUB from CVS and use UUID to refer to any drives. update-grub will generate the new style grub.cfg, but be sure to back up your current grub.cfg in case it gets overwritten. Then on my development workstation I will do: grub-install /dev/sdc But will this affect my development workstation's "/boot" ? I don't think current GRUB will allow you to do that, but if cross-device installs were supported, it would indeed overwrite /boot/grub I want to install only to my CompactFlash card; is this possible without messing with my dev machine's filesystem? Yes, I did it several times. If I have /dev/sdc1 (the CF card's partition) mounted at /media/grubtest, can I just do grub-install --root-directory=/media/grubtest /dev/sdc Yes, that should work. In case you are not sure if the system boot was affected, I suggest that you reinstall grub on your hard drive the way it was installed before attempting a reboot. Also make the rescue image with grub-mkrescue, write it to a CD and keep it handy in case you need to recover anything. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Installing GRUB 2 on a CompactFlash card
I want to install GRUB 2 on a CompactFlash card, which I will boot on my Mini-ITX VIA C3 system for testing, by attaching the CF card to an IDE-CF adapter. Before I run grub-install, I wanted to get a confirmation that I'm doing the right thing, so I don't end up wiping out my development system's boot partition or something. Here's my setup: Development workstation: Running Linux. Hard drives on /dev/hdXX and /dev/sdXX. The CompactFlash card will appear as /dev/sdc or something. (let's assume it's /dev/sdc) Target system: IDE controller - connected to IDE-CompactFlash adapter. If I create one partition on the CF card, for GRUB, I assume I should set up my grub.cfg to refer to it as (hd0,1) since this will only be used on the TARGET SYSTEM, right? Then on my development workstation I will do: grub-install /dev/sdc But will this affect my development workstation's "/boot" ? I want to install only to my CompactFlash card; is this possible without messing with my dev machine's filesystem? If I have /dev/sdc1 (the CF card's partition) mounted at /media/grubtest, can I just do grub-install --root-directory=/media/grubtest /dev/sdc Thanks! Colin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Reimplementing the legacy "map" command
Hi again everybody. After some hacking with the GRUB internals, I've completed a reimplementation of the legacy "map" command that allowed the BIOS drives to have their numbers reassigned, in order to boot OSes whose boot code requires their installation to be located in the first HD (BIOS drive 0x80). This implementation gets next to the status of the command in GRUB Legacy, with the main changes being: * Command: now called "drivemap", attending to suggestions in this list * UI: the less complete part of the job. The syntax is now as follows: drivemap (hd1) 0x80 # Makes (hd1) appear as the first BIOS drive i.e. the second argument is now any BIOS drive number instead of another device. This change is in part due to my lack of time, but also because others here pointed that it would be useful to allow arbitrary mappings. If required, old syntax could be reimplemented in short time. * Backend: the command is now a module, but there is also code in the several files like the machine-specific loader.S, the loader header file and the makefiles. * Backend: a preboot hook system has been added to the loader backend, allowing modules to register functions to be run just before the grub_X_real_boot function is called. The drivemap module uses this new functionality to get its install_int13_handler function to be called before booting the target OS without creating chaos in GRUB itself. * Functionality: the new module is independent of chainloader, so its functions can be applied with any target loader. What effects will this have, I don't know. This patch is just a preliminary version that has been tested only in QEMU and Bochs, not on real hardware because I'm cut off from x86 computers from the time being (I'm running on a PPC mac now). I will be back to town (and to my olde amd64 box) this weekend, but I wanted to submit this so others could scrutinize it for obvious mistakes, and maybe test it. I've tried to respect the style rules I've seen, but please note that this is my first patch. Cheers! Habbit ? commands/i386/pc/drivemap.c Index: conf/i386-pc.mk === RCS file: /sources/grub/grub2/conf/i386-pc.mk,v retrieving revision 1.132 diff -u -r1.132 i386-pc.mk --- conf/i386-pc.mk 30 May 2008 04:20:47 - 1.132 +++ conf/i386-pc.mk 5 Jun 2008 20:08:20 - @@ -842,7 +842,7 @@ vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \ videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod \ ata.mod vga.mod memdisk.mod jpeg.mod png.mod pci.mod lspci.mod \ - aout.mod _bsd.mod bsd.mod + aout.mod _bsd.mod bsd.mod drivemap.mod # For biosdisk.mod. biosdisk_mod_SOURCES = disk/i386/pc/biosdisk.c @@ -2970,4 +2970,60 @@ bsd_mod_CFLAGS = $(COMMON_CFLAGS) bsd_mod_LDFLAGS = $(COMMON_LDFLAGS) +# For drivemap.mod. +drivemap_mod_SOURCES = commands/i386/pc/drivemap.c +CLEANFILES += drivemap.mod mod-drivemap.o mod-drivemap.c pre-drivemap.o drivemap_mod-commands_i386_pc_drivemap.o und-drivemap.lst +ifneq ($(drivemap_mod_EXPORTS),no) +CLEANFILES += def-drivemap.lst +DEFSYMFILES += def-drivemap.lst +endif +MOSTLYCLEANFILES += drivemap_mod-commands_i386_pc_drivemap.d +UNDSYMFILES += und-drivemap.lst + +drivemap.mod: pre-drivemap.o mod-drivemap.o + -rm -f $@ + $(TARGET_CC) $(drivemap_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ $^ + $(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -R .note -R .comment $@ + +pre-drivemap.o: $(drivemap_mod_DEPENDENCIES) drivemap_mod-commands_i386_pc_drivemap.o + -rm -f $@ + $(TARGET_CC) $(drivemap_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ drivemap_mod-commands_i386_pc_drivemap.o + +mod-drivemap.o: mod-drivemap.c + $(TARGET_CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(drivemap_mod_CFLAGS) -c -o $@ $< + +mod-drivemap.c: moddep.lst genmodsrc.sh + sh $(srcdir)/genmodsrc.sh 'drivemap' $< > $@ || (rm -f $@; exit 1) + +ifneq ($(drivemap_mod_EXPORTS),no) +def-drivemap.lst: pre-drivemap.o + $(NM) -g --defined-only -P -p $< | sed 's/^\([^ ]*\).*/\1 drivemap/' > $@ +endif + +und-drivemap.lst: pre-drivemap.o + echo 'drivemap' > $@ + $(NM) -u -P -p $< | cut -f1 -d' ' >> $@ + +drivemap_mod-commands_i386_pc_drivemap.o: commands/i386/pc/drivemap.c $(commands/i386/pc/drivemap.c_DEPENDENCIES) + $(TARGET_CC) -Icommands/i386/pc -I$(srcdir)/commands/i386/pc $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(drivemap_mod_CFLAGS) -MD -c -o $@ $< +-include drivemap_mod-commands_i386_pc_drivemap.d + +CLEANFILES += cmd-drivemap_mod-commands_i386_pc_drivemap.lst fs-drivemap_mod-commands_i386_pc_drivemap.lst partmap-drivemap_mod-commands_i386_pc_drivemap.lst +COMMANDFILES += cmd-drivemap_mod-commands_i386_pc_drivemap.lst +FSFILES += fs-drivemap_mod-commands_i386_pc_drivemap.lst +PARTMAPFILES += partmap-drivemap_mod-commands_i386_pc_drivemap.lst + +cmd-drivemap_mod-commands_i386_pc_drivemap.lst: c
Re: Floating point usage
Robert Millan wrote: > Why would i386-linuxbios and i386-ieee1275 need libgcc but i386-pc don't? > IIRC the tendency is that CISC platforms tend not to need libgcc for floating > point but RISC ones do. Did I make a mistake on these two ports? > Those platforms require libgcc even for double precision integer divisions. It's a bit nasty. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] missleading function name
On Thu, 2008-06-05 at 23:11 +0200, Robert Millan wrote: > On Wed, Jun 04, 2008 at 10:08:28PM -0400, Pavel Roskin wrote: > > On Thu, 2008-06-05 at 01:30 +0200, Robert Millan wrote: > > > IMHO the name of this function is highly misleading. It makes one think > > > it just checks something, but it actually modifies our variables. I think > > > "adjust" would fit better than "check". > > > > But nothing can be better that a good old-fashioned connect before the > > function. > > What do you mean? I mean "comment", sorry. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] biosdisk / open_device() messing up offsets
On Wed, Jun 04, 2008 at 09:47:17PM -0400, Pavel Roskin wrote: > On Thu, 2008-06-05 at 01:35 +0200, Robert Millan wrote: > > It seems that open_device() in biosdisk is messing up offsets when > > accessing partitions. For example if you try: > > > > grub> hexdump (hd0,1) > > > > in grub-emu, you'll get a message saying lseek failed. The problem is that > > it substracts to the sector offset, so all accesses get to wrong data and > > accessing sector 0 results in underflow. > > > > I would think those lines (see patch) are plainly wrong, but they appear to > > be very old, and it is strange that this wasn't noticed earlier. Maybe we > > have changed behaviour around partition/disk offsets, causing this breakage > > without noticing? > > The question whether sector is relative to the partition or to the whole > disk. From what I see in disk/memdisk.c or it disk/i386/pc/biosdisk.c, > the sector is relative to the whole disk. There is no compensation for > partition offsets. That's low-level code that doesn't know about > partitions, and util/biosdisk.c correctly tries to emulate that. > > I guess grub-emu gets it wrong somewhere. grub-emu itself does nothing about this AFAIK, it just relies on util/biosdisk.c to do the right thing. -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] missleading function name
On Wed, Jun 04, 2008 at 10:08:28PM -0400, Pavel Roskin wrote: > On Thu, 2008-06-05 at 01:30 +0200, Robert Millan wrote: > > IMHO the name of this function is highly misleading. It makes one think > > it just checks something, but it actually modifies our variables. I think > > "adjust" would fit better than "check". > > But nothing can be better that a good old-fashioned connect before the > function. What do you mean? > It looks like it does several things: > > 1) it makes sectors disk relative from partition relative (I guess > that's what grub-emu forgets) Ah, that explains it. Maybe the code in util/biosdisk.c comes from a time in which kern/disk.c didn't do this. -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
On Thu, Jun 05, 2008 at 10:01:38PM +0200, Vincent Pelletier wrote: > And there is an except to this except: If -lgcc is specified it will be used, > and it is for the following archs, as far as I can see: > - powerpc-ieee1275 > - i386-linuxbios > - i386-ieee1275 Why would i386-linuxbios and i386-ieee1275 need libgcc but i386-pc don't? IIRC the tendency is that CISC platforms tend not to need libgcc for floating point but RISC ones do. Did I make a mistake on these two ports? -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
Pavel Roskin wrote: Hello! I tried to compile the current grub on Fedora 9 for PowerPC, but it failed due to floating point usage in ls. Sorry, I don't have the exact message handy. Anyway, there are several references to "float" and "double" in the code, and I think it's wrong. GRUB should be able to work on systems with no floating point support and on systems where the floating point device needs to be activated. Even Linux kernel avoids using floating point. If everyone is fine, I'll try to remove all floating point stuff from the code. Its only for printing units in human readable format. So its only small arithmetics to get it going nicely with integers. While you are there, can you modify it to use more proper units... MiB , KiB,... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
Le Thursday 05 June 2008 17:12:26 Jan Kleinsorge, vous avez écrit : > Given that GRUB is linked against it. Which is likely as it is a necessity > when compiling with gcc. ...except if -nostdlib is given to gcc, which is the case in grub2. For the bootloader part at least, grub-emu is another question. And there is an except to this except: If -lgcc is specified it will be used, and it is for the following archs, as far as I can see: - powerpc-ieee1275 - i386-linuxbios - i386-ieee1275 So half the supported archs don't need libgcc, I think it's enough to try avoiding that dependency. -- Vincent Pelletier signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
On Thu, 05 Jun 2008 17:23:00 +0200 Stefan Reinauer <[EMAIL PROTECTED]> wrote: > Jan Kleinsorge wrote: > > Pavel Roskin wrote: > > > >> Hello! > >> > >> I tried to compile the current grub on Fedora 9 for PowerPC, but it > >> failed due to floating point usage in ls. Sorry, I don't have the > >> exact message handy. > >> > >> Anyway, there are several references to "float" and "double" in the > >> code, and I think it's wrong. GRUB should be able to work on > >> systems with no floating point support and on systems where the > >> floating point device needs to be activated. Even Linux kernel > >> avoids using floating point. > >> > >> If everyone is fine, I'll try to remove all floating point stuff > >> from the code. > >> > >> > > Hi Pavel, > > > > there is no need for hard-float support on the target machine. The > > libgcc provides all the software-emulation routines. Given that > > GRUB is linked against it. Which is likely as it is a necessity > > when compiling with gcc. Maybe your compilation is simply broken > > because of that one missing. Could you please post the error > > message? > Nonetheless, using Floating Point operations in bootloaders and > firmware is highly discouraged. If Floating Point is required for a > bootloader (except, maybe, possibly, at all, for encryption) the > bootloader is definitely broken, either in implementation or in > design. > > Also keep in mind, most operating systems expect the FPU to be in > power on state. > > Stefan The bootloader is "broken" if it uses floating point arithmetic? I think that while GRUB should not REQUIRE an FPU, it could use software floating point if there was a good reason to do so (and it would not be broken as long is it was done portably). Though I only have minimal knowledge of encryption algorithms, I don't think that floating point math is often used. I think that avoiding floating point math as Pavel Roskin suggested is good, though I don't agree that Stefan's assertion that any use of floating point math is necessarily "broken" -- it might be better to say that we'd prefer not to pull in softfloat libraries (necessary since many targets have no FPU); therefore it is desirable to avoid floating point math. Colin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
Jan Kleinsorge wrote: > Pavel Roskin wrote: > >> Hello! >> >> I tried to compile the current grub on Fedora 9 for PowerPC, but it >> failed due to floating point usage in ls. Sorry, I don't have the exact >> message handy. >> >> Anyway, there are several references to "float" and "double" in the >> code, and I think it's wrong. GRUB should be able to work on systems >> with no floating point support and on systems where the floating point >> device needs to be activated. Even Linux kernel avoids using floating >> point. >> >> If everyone is fine, I'll try to remove all floating point stuff from >> the code. >> >> > Hi Pavel, > > there is no need for hard-float support on the target machine. The > libgcc provides all the software-emulation routines. Given that GRUB is > linked against it. Which is likely as it is a necessity when compiling > with gcc. Maybe your compilation is simply broken because of that one > missing. Could you please post the error message? Nonetheless, using Floating Point operations in bootloaders and firmware is highly discouraged. If Floating Point is required for a bootloader (except, maybe, possibly, at all, for encryption) the bootloader is definitely broken, either in implementation or in design. Also keep in mind, most operating systems expect the FPU to be in power on state. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Floating point usage
Pavel Roskin wrote: > Hello! > > I tried to compile the current grub on Fedora 9 for PowerPC, but it > failed due to floating point usage in ls. Sorry, I don't have the exact > message handy. > > Anyway, there are several references to "float" and "double" in the > code, and I think it's wrong. GRUB should be able to work on systems > with no floating point support and on systems where the floating point > device needs to be activated. Even Linux kernel avoids using floating > point. > > If everyone is fine, I'll try to remove all floating point stuff from > the code. > Hi Pavel, there is no need for hard-float support on the target machine. The libgcc provides all the software-emulation routines. Given that GRUB is linked against it. Which is likely as it is a necessity when compiling with gcc. Maybe your compilation is simply broken because of that one missing. Could you please post the error message? Jan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
