[x86_64] Let's fix grub issues - help wanted

AndyRTR · 2006-07-17 09:22:45

We have some issues with our grub bootloader. Lilo is working well but need to be recalled for every kernel update. Grub2 is not ready for x86_64 and still under heavy developement. So we should get grub (legacy) working. Arch32 is not patching it at all. It looks like we need to do this now.

I myself have two systems: one with GeForce 6100 chipset (nforce4) booting from IDE hard disc very well. No issues there. The other system with Uli1695 chipset booting form IDE or SATA installs grub fine but cannot find the right partition when booting, even not in grub-shell. I cannot play to much with it as it is my main system.

Read more on the mailing lists: http://savannah.gnu.org/mail/?group=grub

You can base any testing package on this PKGBUILD

The Package has to be build on i686 (Arch32) as it will not compile on x86_64 natively.

So I've tried to collect all important patches and it's up to you to test them and report which will help!

CLFS http://cross-lfs.org/view/svn/x86_64/bo … build.html

1) http://cross-lfs.org/files/patches/svn/ … es-1.patch

Description: Contains various fixes and enhancements
    Graphics mode support
    Fixes for Raid Support
    XFS Filesystem Boot Freeze Fixes
    Removed 2GB Memory Limitation
    Freebsd support
    Fixes for initrd support
    Grub installation Fixes
    Linux 2.6 geometry Fixes
    Intel Mac Support
    Autoconf and aclocal updates

2) http://cross-lfs.org/files/patches/svn/ … ap-1.patch

Description: This patch fixes the following issues on x86_64
    1) malloc'd pages seem to lack the execute bit on x86_64;
    2) grub seems to use some stack pointer diversion to malloc'd pages;
    3) nested functions execute data on the stack;
    4) this causes a segfault (at least on my machine)

Frugalware http://darcs.frugalware.org/darcsweb/da … /base/grub
They patch for better network support, cd support and a graphical menu.

Gentoo
http://www.gentoo.org/cgi-bin/viewcvs.c … iew=markup
http://ftp.ucsb.edu/pub/mirrors/linux/g … .2.tar.bz2
The patchset includes fixes for: splash, PIC, bounced checks, unsigned adresses, i2o raid, nxstac, netboot-pic, reiser4, netboot-gcc4.

So user with grub issues - come on - test the patches and report if you got it working for you :!:

gs · 2006-07-17 13:43:49

Just to say that I'll have a go at this. I have two arch64 partitions and two arch32, so I can take risks comfortably.

Even if I do not have much success, I can report stuff back; and maybe this will help, too.

Geoff

gs · 2006-07-17 23:24:51

I have tried applying patch no.2 (nmap1.patch).

On my arch 32, it objected to MAP_32BIT as it got incorporated into the build.

MAP_PRIVATE | MAP_GROWSDOWN | MAP_ANONYMOUS | MAP_32BIT,

about half-way down the patch.

I tried deleting |MAP_32BIT. It built; but the binaries and scripts would not pull a grub-install process together in arch64.

Any suggestions?

Also, if anyone wants to make any trial pkg's, I can try them out.

Geoff

[/quote]

gs · 2006-07-18 14:05:57

I found this entry at Savannah on the possibilities of compiling in an amd64 environment. This may be worth exploring.

http://savannah.nongnu.org/support/?fun … _id=103863

Also, it may be worth getting intouch with LinPhone, who may -- by now -- have definitive answers.

Geoff

gs · 2006-07-18 23:11:05

I have tried the patch numbered (1).

grub-install /dev/hda fails at line 481 of grub-install, apparently when trying to set up stage1. I.e

/sbin/grub-install: line 481: /sbin/grub: No such file or directory
cmp: /tmp/grub-install.img.3073: No such file or directory
The file /boot/grub/stage1 not read correctly.

I am no expert at this, so I can not really do so much knowledgeable tinkering. I do wonder again, though, if the present workarounds of using lilo or grub-install invoked from an arch32 partition might not be good enough.

Any ideas when grub2 could be up to this present set of tasks?

Geoff

gs · 2006-07-19 01:22:47

I have had a go with 040_all_grub-0.96-nxstack.patch (in the gentoo bundle). The blurb says: "Fix NX segfaulting on amd64."

Same result as earlier, with stage1 apprently not being read successfully.

gs · 2006-07-19 01:30:27

There is another gentoo patch, entitled, 010_all_grub-0.96-bounced-checks.

The blurb says: "Disables testing of FFS and UFS2 images (which always fail). Upstream
maintainers say that these can be ignored anyways."

This might remove the failures I have reported. So my guess is to try this patch in combination with the last one.

HTH. I am going to get some sleep!

Geoff :idea:

gs · 2006-07-19 20:18:50

The above method failed in the same way.

I googled up the following link on a recent patch, which I will have a closer look at.

http://www.mail-archive.com/grub-devel@ … 01821.html

Geoff

AndyRTR · 2006-07-19 20:33:02

I haven't seen any distribution compiling it nativly 64bit without 32bit libs from a multilib system. But a few people menaged to get it compile. I even don't expect a 64bit compiled grub working better than a statically build on i686.

Maybe it's better to try the right patches for compiling it on i686 so it will work better for us. Anyway keep trying it out!

If we won't find soon a good solution I will declare lilo as our prefered bootloader and call grub "experimental" in the ISO boot screen message. Should be enough warning.

AndyRTR

AndyRTR · 2006-07-21 22:42:04

This pkg should solve the segfault when installing grub onto disc.

http://www.archlinux.org/~andyrtr/grub- … pkg.tar.gz

Please report if I got it fixed.

karsten · 2006-07-22 00:16:31

it works!

gs · 2006-07-23 10:09:16

Congrats!

For my Asus amd64 motherboard this works just fine.

grub reads my sata hard drive as hd0 (/dev/sda). Previously I have not bothered to modify my device.map, and there was no problem.

But this time, it does need the full correction. So arguably, the iso installation needs to contain a note about this possibility of having to modify /boot/device.map.

It may also be possible to write a script which does all this automagically, too.

This is my new map:

(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/hda
(hd2) /dev/hdb
(hd3) /dev/sdb

I reckon you need to check out how common this sort of issue is.

Thanks

Geoff

gs · 2006-07-23 13:56:20

Having thought this through, I reckon the grub installation interface, in the installation iso would need to display the device.map listing and the same message to adjust and reinstall if device.map is not accurate.

Geoff

AndyRTR · 2006-07-23 15:12:30

@gs:judd is mainating the installer. if you wanna see something new in there open a featurew request in flyspray ;-)

I will checkin the fixed grub package. Then I will make new isos for a (hopefully) short testing period.

@gs, here are some small fixes you can locally test if they fix your issues:

Submitted By: Jim Gifford <jim>
Date: 07-14-2006
Initial Package Version: 0.97
Upstream Status: Unknown
Origin: Grub Bug Report - http://savannah.gnu.org/bugs/?func=detailitem&item_id=11312
Description: This patch fixes the following issues on x86_64
    1) malloc'd pages seem to lack the execute bit on x86_64;
    2) grub seems to use some stack pointer diversion to malloc'd pages;
    3) nested functions execute data on the stack;
    4) this causes a segfault (at least on my machine)

diff -Naur grub-0.97.orig/grub/asmstub.c grub-0.97/grub/asmstub.c
--- grub-0.97.orig/grub/asmstub.c    2005-02-16 12:45:14.000000000 -0800
+++ grub-0.97/grub/asmstub.c    2006-07-14 12:38:08.305902933 -0700
@@ -43,6 +43,8 @@
 #include <termios>
 #include <signal>
 
+#include <sys>
+
 #ifdef __linux__
 # include <sys>        /* ioctl */
 # if !defined(__GLIBC__) || 
@@ -142,14 +144,25 @@
     }
 
   assert (grub_scratch_mem == 0);
-  scratch = malloc (0x100000 + EXTENDED_MEMSIZE + 15);
+  scratch = mmap(NULL,
+                 0x100000 + EXTENDED_MEMSIZE + 15,
+                 PROT_EXEC | PROT_READ | PROT_WRITE,
+                 MAP_PRIVATE | MAP_GROWSDOWN | MAP_ANONYMOUS | MAP_32BIT,
+                 -1,
+                 0);
+
   assert (scratch);
   grub_scratch_mem = (char *) ((((int) scratch) >> 4) << 4);
 
   /* FIXME: simulate the memory holes using mprot, if available. */
 
   assert (disks == 0);
-  disks = malloc (NUM_DISKS * sizeof (*disks));
+  disks = mmap(NULL,
+               NUM_DISKS * sizeof (*disks),
+               PROT_EXEC | PROT_READ | PROT_WRITE,
+               MAP_PRIVATE | MAP_GROWSDOWN | MAP_ANONYMOUS | MAP_32BIT,
+               -1,
+               0);
   assert (disks);
   /* Initialize DISKS.  */
   for (i = 0; i < NUM_DISKS; i++)
@@ -215,9 +228,9 @@
   /* Release memory. */
   restore_device_map (device_map);
   device_map = 0;
-  free (disks);
+  munmap(disks, NUM_DISKS * sizeof (*disks));
   disks = 0;
-  free (scratch);
+  munmap(scratch, 0x100000 + EXTENDED_MEMSIZE + 15);
   grub_scratch_mem = 0;
 
   if (serial_device)

or this one, a part from http://ftp.jg555.com/grub-0.97-disk_geometry-2.patch

diff -Naur grub-0.97.orig/grub/asmstub.c grub-0.97/grub/asmstub.c
--- grub-0.97.orig/grub/asmstub.c    2005-02-16 12:45:14.000000000 -0800
+++ grub-0.97/grub/asmstub.c    2006-07-14 12:38:08.305902933 -0700
@@ -43,6 +43,8 @@
 #include <termios>
 #include <signal>
 
+#include <sys>
+
 #ifdef __linux__
 # include <sys>        /* ioctl */
 # if !defined(__GLIBC__) || 
@@ -142,14 +144,25 @@
     }
 
   assert (grub_scratch_mem == 0);
-  scratch = malloc (0x100000 + EXTENDED_MEMSIZE + 15);
+  scratch = mmap(NULL,
+                 0x100000 + EXTENDED_MEMSIZE + 15,
+                 PROT_EXEC | PROT_READ | PROT_WRITE,
+                 MAP_PRIVATE | MAP_GROWSDOWN | MAP_ANONYMOUS | MAP_32BIT,
+                 -1,
+                 0);
+
   assert (scratch);
   grub_scratch_mem = (char *) ((((int) scratch) >> 4) << 4);
 
   /* FIXME: simulate the memory holes using mprot, if available. */
 
   assert (disks == 0);
-  disks = malloc (NUM_DISKS * sizeof (*disks));
+  disks = mmap(NULL,
+               NUM_DISKS * sizeof (*disks),
+               PROT_EXEC | PROT_READ | PROT_WRITE,
+               MAP_PRIVATE | MAP_GROWSDOWN | MAP_ANONYMOUS | MAP_32BIT,
+               -1,
+               0);
   assert (disks);
   /* Initialize DISKS.  */
   for (i = 0; i < NUM_DISKS; i++)
@@ -215,9 +228,9 @@
   /* Release memory. */
   restore_device_map (device_map);
   device_map = 0;
-  free (disks);
+  munmap(disks, NUM_DISKS * sizeof (*disks));
   disks = 0;
-  free (scratch);
+  munmap(scratch, 0x100000 + EXTENDED_MEMSIZE + 15);
   grub_scratch_mem = 0;
 
   if (serial_device)
diff -Naur grub-0.97.orig/lib/device.c grub-0.97/lib/device.c
--- grub-0.97.orig/lib/device.c    2005-03-27 15:14:25.000000000 -0800
+++ grub-0.97/lib/device.c    2006-07-14 12:37:02.523614144 -0700
@@ -131,6 +131,152 @@
 #include <shared>
 #include <device>
 
+#if defined(__linux__)
+/* The 2.6 kernel has removed all of the geometry handling for IDE drives
+ * that did fixups for LBA, etc.  This means that the geometry we get
+ * with the ioctl has a good chance of being wrong.  So, we get to 
+ * also know about partition tables and try to read what the geometry
+ * is there. *grumble*   Very closely based on code from cfdisk
+ */
+static void get_kernel_geometry(int fd, long long *cyl, int *heads, int *sectors) {
+    struct hd_geometry hdg;
+    
+    if (ioctl (fd, HDIO_GETGEO, &hdg))
+        return;
+
+    *cyl = hdg.cylinders;
+    *heads = hdg.heads;
+    *sectors = hdg.sectors;
+}
+
+struct partition {
+        unsigned char boot_ind;         /* 0x80 - active */
+        unsigned char head;             /* starting head */
+        unsigned char sector;           /* starting sector */
+        unsigned char cyl;              /* starting cylinder */
+        unsigned char sys_ind;          /* What partition type */
+        unsigned char end_head;         /* end head */
+        unsigned char end_sector;       /* end sector */
+        unsigned char end_cyl;          /* end cylinder */
+        unsigned char start4[4];        /* starting sector counting from 0 */
+        unsigned char size4[4];         /* nr of sectors in partition */
+};
+
+#define ALIGNMENT 2
+typedef union {
+    struct {
+    unsigned char align[ALIGNMENT];
+    unsigned char b[SECTOR_SIZE];
+    } c;
+    struct {
+    unsigned char align[ALIGNMENT];
+    unsigned char buffer[0x1BE];
+    struct partition part[4];
+    unsigned char magicflag[2];
+    } p;
+} partition_table;
+
+#define PART_TABLE_FLAG0 0x55
+#define PART_TABLE_FLAG1 0xAA
+
+static void
+get_partition_table_geometry(partition_table *bufp, long long *cyl, int *heads, 
+                             int *sectors) {
+    struct partition *p;
+    int i,h,s,hh,ss;
+    int first = 1;
+    int bad = 0;
+
+    if (bufp->p.magicflag[0] != PART_TABLE_FLAG0 ||
+    bufp->p.magicflag[1] != PART_TABLE_FLAG1) {
+        /* Matthew Wilcox: slightly friendlier version of
+           fatal(_("Bad signature on partition table"), 3);
+        */
+            fprintf(stderr, "Unknown partition table signaturen");
+        return;
+    }
+
+    hh = ss = 0;
+    for (i=0; i<4>p.part[i]);
+    if (p->sys_ind != 0) {
+        h = p->end_head + 1;
+        s = (p->end_sector & 077);
+        if (first) {
+        hh = h;
+        ss = s;
+        first = 0;
+        } else if (hh != h || ss != s)
+        bad = 1;
+    }
+    }
+
+    if (!first && !bad) {
+    *heads = hh;
+    *sectors = ss;
+    }
+}
+
+static long long my_lseek (unsigned int fd, long long offset, 
+                           unsigned int origin)
+{
+#if defined(__linux__) && (!defined(__GLIBC__) || 
+        ((__GLIBC__ < 2) || ((__GLIBC__ == 2) && (__GLIBC_MINOR__ <1>> 32, offset & 0xffffffff, &result, SEEK_SET))
-      {
-    errnum = ERR_DEV_VALUES;
-    return 0;
-      }
-  }
-#else
-  {
-    off_t offset = (off_t) sector * (off_t) SECTOR_SIZE;
 
-    if (lseek (fd, offset, SEEK_SET) != offset)
-      {
-    errnum = ERR_DEV_VALUES;
-    return 0;
-      }
-  }
-#endif
+  if (my_lseek(fd, offset, SEEK_SET) != offset)
+    {
+      errnum = ERR_DEV_VALUES;
+      return 0;
+    }
   
   if (write (fd, buf, size * SECTOR_SIZE) != (size * SECTOR_SIZE))
     {
diff -Naur grub-0.97.orig/util/grub-install.in grub-0.97/util/grub-install.in
--- grub-0.97.orig/util/grub-install.in    2004-07-24 11:57:31.000000000 -0700
+++ grub-0.97/util/grub-install.in    2006-07-14 12:37:02.535613832 -0700
@@ -336,6 +336,10 @@
     # Create a safe temporary file.
     test -n "$mklog" && log_file=`$mklog`
 
+    # Before all invocations of the grub shell, call sync to make sure
+    # the raw device is in sync with any bufferring in filesystems.
+    sync
+ 
     $grub_shell --batch $no_floppy --device-map=$device_map <<EOF>$log_file
 quit
 EOF
@@ -450,6 +454,10 @@
 # Create a safe temporary file.
 test -n "$mklog" && log_file=`$mklog`
 
+# Before all invocations of the grub shell, call sync to make sure
+# the raw device is in sync with any bufferring in filesystems.
+sync
+
 # Now perform the installation.
 $grub_shell --batch $no_floppy --device-map=$device_map <<EOF>$log_file
 root $root_drive

gs · 2006-07-23 18:43:51

I have not been able to successfully build from these patches. But it may be possible to modify the second patch and get it to build, since there are error indications suggesting it is malformed.

But it seems to me that anyone who has their sata drive come in grub as hd0, when your booting from that sata drive (but come up as hd2 when youre booting from one of the ide drives) will be wise enough to check out and correct device.map.

After all, this vagueness and wantoness with grub-legacy is well known! Yes there is this additional bug of device.map having to be edited, but grub-legacy is not going to be around forever!

Geoff

Arch Linux

#1 2006-07-17 09:22:45

[x86_64] Let's fix grub issues - help wanted

#2 2006-07-17 13:43:49

Re: [x86_64] Let's fix grub issues - help wanted

#3 2006-07-17 23:24:51

Re: [x86_64] Let's fix grub issues - help wanted

#4 2006-07-18 14:05:57

Re: [x86_64] Let's fix grub issues - help wanted

#5 2006-07-18 23:11:05

Re: [x86_64] Let's fix grub issues - help wanted

#6 2006-07-19 01:22:47

Re: [x86_64] Let's fix grub issues - help wanted

#7 2006-07-19 01:30:27

Re: [x86_64] Let's fix grub issues - help wanted

#8 2006-07-19 20:18:50

Re: [x86_64] Let's fix grub issues - help wanted

#9 2006-07-19 20:33:02

Re: [x86_64] Let's fix grub issues - help wanted

#10 2006-07-21 22:42:04

Re: [x86_64] Let's fix grub issues - help wanted

#11 2006-07-22 00:16:31

Re: [x86_64] Let's fix grub issues - help wanted

#12 2006-07-23 10:09:16

Re: [x86_64] Let's fix grub issues - help wanted

#13 2006-07-23 13:56:20

Re: [x86_64] Let's fix grub issues - help wanted

#14 2006-07-23 15:12:30

Re: [x86_64] Let's fix grub issues - help wanted

#15 2006-07-23 18:43:51

Re: [x86_64] Let's fix grub issues - help wanted

Board footer