Bugzilla Bug 212165

Platform is using an intel S5000PAL motherboard with a 2GB disk on module as
the master on the primary IDE channel (first partition is FAT32 and contains
necessary grub files), grub is installed this way:
grub> root (hd0,0)
grub> embed /boot/grub/stage1_5 (hd0)
grub> install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
/boot/grub/menu.lst
grub> quit

Grub is installed this way because (hd0,0) is FAT32 without long name support
and stage 1.5 default name is fat_stage1_5 (modified to the short name
"stage1_5" in order to be handled by the filesystem)

Before the grub GPT patch, the platform was behaving correctly. After GPT
patch, grub does not display anything and the platform reboots suddenly (over
and over since hd0 is the first boot drive).

I say that grub does not display anything but I need to test with a serial line
config to be 100% sure. I'm almost sure that grub doesn't even have the time to
read the configuration file so I guess it won't help. I'll try anyway on spare
time.

The only difference between both config is using grub ebuild 0.97-r4 instead of
0.97-r3. I've tested twice both config with repeating rebuild/install steps and
just emerging the needed grub version first.

Still haven't done the serial line test, in the meantime, here is the output of
'emerge --info':

Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0,
2.6.23-gentoo-r8-20080212 i686)
=================================================================
System uname: 2.6.23-gentoo-r8-20080212 i686 Intel(R) Xeon(TM) CPU 3.20GHz
Timestamp of tree: Fri, 29 Feb 2008 05:00:01 +0000
app-shells/bash:     3.2_p17-r1
dev-lang/python:     2.4.4-r6
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.61-r1
sys-devel/automake:  1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo
/etc/udev/rules.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans
userfetch"
GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://portage/gentoo-portage"
USE="minimal symlink x86" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x
ca0106 cmipci emu10k1   emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel
intel8x0 intel8x0m        maestro3 trident usb-audio via82xx via82xx-modem
ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug
file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate
route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias
authn_anon authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs
dav_lock deflate dir disk_cache env expires ext_filter file_cache filter
headers include info log_config logio mem_cache mime mime_magic negotiation
rewrite setenvif speling status unique_id userdir usertrack vhost_alias"
ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux"
LCD_DEVICES="cfontz ncurses" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus
cyrix dummy fbdev glint i128 i740 i810 imstt        mach64 mga neomagic nsc nv
r128 radeon rendition s3 s3virge savage       siliconmotion sis sisusb tdfx tga
trident tseng v4l vesa vga via vmware         voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

Ok, that's bizarre. Does your grub config use the parttype or hide/unhide
commands - I know there are bugs in those, that i'm going to be patching in r5.

The GPT changes are basically:
foreach(partition) {
 if(GPT signature) {
  goto GPT-scan;
 }
 if(valid) {
  valid-partition = $THIS;
  goto boot;
 }
}
goto failure;
GPT-scan:
 foreach(GPT partition) {
  if(valid) {
   valid-partition = $THIS;
   goto boot;
  }
 }
boot:
 use valid-partition to boot;
failure:
 we fucked up.

Instead of doing the whole build/install process with grub-0.97-r4, I have done
this:
- platform with old build/install (grub 0.97-r3): OK
- replaced stage1 and stage1_5 by the ones from r4 (by using grub r4 shell): OK
- replaced stage2 by the one from r4 (copy to the boot partition): KO

But this time, instead of having the reboot behavior, The platform acts as
described in bug #211584.
So perhaps the reboot behavior is just another side effect of using "unhide".
I'll wait for the r5 release and will test again with the whole build/install 
procedure.
But for sure, I didn't spot something which makes the difference between
"endless reboot" and "Error 22: No such partition".

Ooops! I'm mister stupid.
During the previous tests, I've forgot to copy stage1 and stage1_5 before the
grub shell part.
I'm currently restarting the tests from scratch...

Ok, I've reproduced the "endless reboot" and identified the faulty grub
component.

To summarize my tests:
stage1[r3], fat_stage1_5[r3], stage2[r3]: OK
stage1[r3], fat_stage1_5[r3], stage2[r4]: bug #211584
stage1[r4], fat_stage1_5[r3], stage2[r3]: OK
stage1[r4], fat_stage1_5[r4], stage2[r3]: endless reboot
stage1[r4], fat_stage1_5[r4], stage2[r4]: endless reboot

So, from my point of view, the grub stage from grub-0.97-r4 which induces the
"endless reboot" bug is the FAT stage 1.5.

Instead of using the manual embed+install, please try using 'setup (hd0)'.

Also, could you try to make your first partition ext2 instead and see if the
bug persists?

Robin, you've put me on the right track by telling me to use the "setup"
command.
When I've migrated to grub-0.97-r4, I didn't notice that the fat_stage1_5 size
had been increased by one sector.
So when calling the "install" command, I was still using "(hd0)1+15" instead of
"(hd0)1+16".
So this is not a bug but a misuse of grub. Sorry for the hassle.

A cool thing would be to modify the default name of the fat_stage1_5 so it
would fit in a FAT partition with no long name support (this way the "setup"
command will work).
I'll send you a patch for this if you find the "feature" useful and if I have
some more spare time.