Ubuntu
grub package

grub fails after upgrading and using grub shell to reinstall instead of grub-install

Bug #27969 reported by Debian Bug Importer
10
Affects Status Importance Assigned to Milestone
grub (Debian)
Won't Fix
Unknown
grub (Ubuntu)
Won't Fix
High
Unassigned

Bug Description

Automatically imported from Debian bug report #345931 http://bugs.debian.org/345931

Tags: dapper
Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 04 Jan 2006 13:58:23 +0100
From: John Hughes <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: grub 0.97 doesn't work on several machines

Package: grub
Version: 0.97-2
Severity: critical
Justification: breaks the whole system

After installing grub 0.97 and doing a simple setup the system is
unbootable.

The same behaviour was observed on an old Dell Dimension 4100 and a new
Dell Optiplex GX270.

This may be the same as bug 341535, but it's happening on machines other
than a IBM thinkpad and using ext2 filesystems noy xfs.

When the system random garbage gets printed on the screen.

Here's a typescript of the grub setup:

republic:~# grub

Probing devices to guess BIOS drives. This may take a long time.

GNU GRUB version 0.97 (640K lower / 3072K upper memory)
Minimal BASH-like line editing is supported. For
the first word, TAB lists possible command
completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> find /grub/menu.lst
 (hd0,0)
grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)

 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/menu
..lst"... succeeded
Done.
grub> quit
republic:~# exit

Script done on Wed 04 Jan 2006 01:49:59 PM CET

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages grub depends on:
ii libc6 2.3.5-7 GNU C Library: Shared libraries an
ii libncurses5 5.5-1 Shared libraries for terminal hand

grub recommends no packages.

-- no debconf information

Revision history for this message
In , John Hughes (john-calva) wrote :

Package: grub
Version: 0.97-2
Severity: critical
Justification: breaks the whole system

After installing grub 0.97 and doing a simple setup the system is
unbootable.

The same behaviour was observed on an old Dell Dimension 4100 and a new
Dell Optiplex GX270.

This may be the same as bug 341535, but it's happening on machines other
than a IBM thinkpad and using ext2 filesystems noy xfs.

When the system random garbage gets printed on the screen.

Here's a typescript of the grub setup:

republic:~# grub

Probing devices to guess BIOS drives. This may take a long time.

GNU GRUB version 0.97 (640K lower / 3072K upper memory)
Minimal BASH-like line editing is supported. For
the first word, TAB lists possible command
completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> find /grub/menu.lst
 (hd0,0)
grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)

 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/menu
..lst"... succeeded
Done.
grub> quit
republic:~# exit

Script done on Wed 04 Jan 2006 01:49:59 PM CET

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages grub depends on:
ii libc6 2.3.5-7 GNU C Library: Shared libraries an
ii libncurses5 5.5-1 Shared libraries for terminal hand

grub recommends no packages.

-- no debconf information

Revision history for this message
In , Jason Thomas (jason-debian) wrote : Re: Bug#345931: grub 0.97 doesn't work on several machines

Hi,

Please check your menu.lst for a splashimage line. If one or more exists
comment them out and try to boot again.

How where the menu.lst files created?

You could also try pressing 'c' for the command line interface, when the
random garbage is on the screen. But I've no idea if that will work.

I have seen this problem occurs when the splashimage directive points to
a nonexistant file.

On Wed, Jan 04, 2006 at 01:58:23PM +0100, John Hughes wrote:
> When the system random garbage gets printed on the screen.

Revision history for this message
Debian Bug Importer (debzilla) wrote : Re: grub 0.97 doesn't work on several machines

Message-ID: <email address hidden>
Date: Thu, 5 Jan 2006 08:35:02 +1100
From: Jason Thomas <email address hidden>
To: John Hughes <email address hidden>, <email address hidden>
Cc: Debian Bug Tracking System <email address hidden>
Subject: Re: Bug#345931: grub 0.97 doesn't work on several machines

Hi,

Please check your menu.lst for a splashimage line. If one or more exists
comment them out and try to boot again.

How where the menu.lst files created?

You could also try pressing 'c' for the command line interface, when the
random garbage is on the screen. But I've no idea if that will work.

I have seen this problem occurs when the splashimage directive points to
a nonexistant file.

On Wed, Jan 04, 2006 at 01:58:23PM +0100, John Hughes wrote:
> When the system random garbage gets printed on the screen.

Revision history for this message
In , John Hughes (john-calva) wrote : Re: Bug#345931: grub 0.97 doesn't work on several machines

Jason Thomas wrote:

>Hi,
>
>Please check your menu.lst for a splashimage line. If one or more exists
>comment them out and try to boot again.
>
>
No splashimage. (Onscreen garbage is text).

>How where the menu.lst files created?
>
>
By normal grub install, linux-image install/update process.

menu.lst attached to this message.

>You could also try pressing 'c' for the command line interface, when the
>random garbage is on the screen. But I've no idea if that will work.
>
>
Doesn't work.

>I have seen this problem occurs when the splashimage directive points to
>a nonexistant file.
>
>On Wed, Jan 04, 2006 at 01:58:23PM +0100, John Hughes wrote:
>
>
>>When the system random garbage gets printed on the screen.
>>
>>

Revision history for this message
Debian Bug Importer (debzilla) wrote : Re: grub 0.97 doesn't work on several machines
Download full text (4.3 KiB)

Message-ID: <email address hidden>
Date: Thu, 05 Jan 2006 09:55:42 +0100
From: John Hughes <email address hidden>
To: Jason Thomas <email address hidden>
CC: <email address hidden>,
   Debian Bug Tracking System <email address hidden>
Subject: Re: Bug#345931: grub 0.97 doesn't work on several machines

--------------040501020407060206050804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jason Thomas wrote:

>Hi,
>
>Please check your menu.lst for a splashimage line. If one or more exists
>comment them out and try to boot again.
>
>
No splashimage. (Onscreen garbage is text).

>How where the menu.lst files created?
>
>
By normal grub install, linux-image install/update process.

menu.lst attached to this message.

>You could also try pressing 'c' for the command line interface, when the
>random garbage is on the screen. But I've no idea if that will work.
>
>
Doesn't work.

>I have seen this problem occurs when the splashimage directive points to
>a nonexistant file.
>
>On Wed, Jan 04, 2006 at 01:58:23PM +0100, John Hughes wrote:
>
>
>>When the system random garbage gets printed on the screen.
>>
>>

--------------040501020407060206050804
Content-Type: text/plain;
 name="menu.lst"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="menu.lst"

# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
default 0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout 5

# Pretty colours
color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line) and entries protected by the
# command 'lock'
# e.g. password topsecret
# password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title Windows 95/98/NT/2000
# root (hd0,0)
# makeactive
# chainloader +1
#
# title Linux
# root (hd0,1)
# kernel /vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specifiv kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
# kopt=root=/dev/hda2 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)

## should update-grub create alternative a...

Read more...

Revision history for this message
In , karl shaul (shaulk-013) wrote : Not sure if this is the same bug.

  With 0.97-3 and a boot floppy, I get:

    Error 15: File not found

or something very similar. This happens with the kernel command.
Thing is that both blocklist and one other command, possibly find, can
see the kernel. The fs is ext2. No splash image. It was working with an
older version of grub. I don't remember what version that was, probably
some 0.95.

$ cat menu.lst
default 2
#default saved
timeout 15

title FAI-ANY 2.6.14-fai-kernels
kernel (fd0)/vmlinuz-2.6.14-fai-kernels root=/dev/nfs ip=::::::any FAI_FLAGS
=verbose,sshd,createvt,syslogd FAI_ACTION=sysinfo
savedefault

title FAI-BOOTP 2.6.14-fai-kernels
kernel (fd0)/vmlinuz-2.6.14-fai-kernels root=/dev/nfs ip=::::::bootp FAI_FLA
GS=verbose,sshd,createvt,syslogd FAI_ACTION=sysinfo
savedefault

title FAI-DHCP 2.6.14-fai-kernels
kernel (fd0)/vmlinuz-2.6.14-fai-kernels root=/dev/nfs ip=::::::dhcp FAI_FLAG
S=verbose,sshd,createvt,syslogd FAI_ACTION=sysinfo
savedefault

title FAI-FIXED-IP 2.6.14-fai-kernels
kernel (fd0)/vmlinuz-2.6.14-fai-kernels root=/dev/nfs nfsroot=192.168.1.1:
/var/fai/nfsroot FAI_FLAGS=verbose,sshd,createvt,syslogd FAI_ACTION=sysinfo
savedefault

title FAI-RARP 2.6.14-fai-kernels
kernel (fd0)/vmlinuz-2.6.14-fai-kernels root=/dev/nfs ip=::::::rarp FAI_FLAG
S=verbose,sshd,createvt,syslogd FAI_ACTION=sysinfo
savedefault

$

Revision history for this message
In , Matthijs Mohlmann (matthijs) wrote : grub: doesn't show anything when the system tries to boot

Package: grub
Version: 0.97-4
Followup-For: Bug #345931

Hi,

I can confirm the same behaviour. When I try to install grub into my MBR
then it doesn't fail at all. Then I tried to reboot and nothing appears
on the screen.

Attached my menu.lst

Regards,

Matthijs Mohlmann

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages grub depends on:
ii libc6 2.3.5-12 GNU C Library: Shared libraries an
ii libncurses5 5.5-1 Shared libraries for terminal hand

grub recommends no packages.

-- no debconf information

Revision history for this message
In , Matthijs Mohlmann (matthijs) wrote : Solved problem with grub not showing anything.

Package: grub
Version: 0.97-4
Followup-For: Bug #345931

Hi,

I investigated today a bit more into this problem. I just copied the stage1,
stage2 and xfs_stage1_5 files again to /boot/grub and then run grub again. This
solved the problem in my case.

Regards,

Matthijs Mohlmann

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages grub depends on:
ii libc6 2.3.5-12 GNU C Library: Shared libraries an
ii libncurses5 5.5-1 Shared libraries for terminal hand

grub recommends no packages.

-- no debconf information

Revision history for this message
In , Otavio Salvador (otavio) wrote : Is possible to reproduze using grub-install?

Hello,

I saw you used grub shell for installation but the recommended way to
install is using grub-install. Are you able to reproduze it using
grub-install?

I'm not able to reproduze your problem and then is dificult to me to
fix it.

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Frans Pop (aragorn) wrote : grub 0.97 doesn't work on several machines

retitle 345931 System fails to boot after updating boot sector from grub interactive shell
thanks

I have managed to reproduce this in vmware using the following procedure:
- new Sarge install (has grub 0.95+cvs20040624-17)
- change sources list to unstable and upgrade

After grub is upgraded (to 0.97-4), but without re-installing its boot sector,
the system reboots without problem.

Now there are two methods to reinstall the grub boot sector to the new
version.

1) Run the grub-install script
# grub-install /dev/sda1
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script 'grub-install'.

(hd0) /dev/sda
# reboot
=> system reboots without any problems

2) Run the grub shell interactively as in the original report
# grub
grub> find /boot/grub/menu.lst
 (hd0,0)
grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)

 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2
/grub/menu..lst"... succeeded
Done.
grub> quit

# reboot
=> Grub menu is not shown (screen remains blank); system fails to boot

Conclusions:
- grub-install does the right thing
- the setup command in the grub interactive shell checks if the stage files
  exist, but apparently its setup command fails to check if they are
  compatible with the current version of grub

I will keep the image I created this way in vmware for a while in case
additional information is wanted.

Cheers,
Frans Pop

Revision history for this message
In , Jason Thomas (jason-debian) wrote : Re: Bug#345931: grub 0.97 doesn't work on several machines

close 345931
thanks

Hi,

grub-install copies the various stage* files into /boot/grub. grub shell
does not.

If you do not copy the stage* files then they will be incompatible with
the boot sector that is installed.

grub-install is the recommeneded method to install.

On Mon, Feb 06, 2006 at 02:55:05PM +0100, Frans Pop wrote:
> retitle 345931 System fails to boot after updating boot sector from grub interactive shell
> thanks
>
> I have managed to reproduce this in vmware using the following procedure:
> - new Sarge install (has grub 0.95+cvs20040624-17)
> - change sources list to unstable and upgrade
>
> After grub is upgraded (to 0.97-4), but without re-installing its boot sector,
> the system reboots without problem.
>
> Now there are two methods to reinstall the grub boot sector to the new
> version.
>
> 1) Run the grub-install script
> # grub-install /dev/sda1
> Installation finished. No error reported.
> This is the contents of the device map /boot/grub/device.map.
> Check if this is correct or not. If any of the lines is incorrect,
> fix it and re-run the script 'grub-install'.
>
> (hd0) /dev/sda
> # reboot
> => system reboots without any problems
>
> 2) Run the grub shell interactively as in the original report
> # grub
> grub> find /boot/grub/menu.lst
> (hd0,0)
> grub> root (hd0,0)
> Filesystem type is ext2fs, partition type 0x83
> grub> setup (hd0)
>
> Checking if "/boot/grub/stage1" exists... no
> Checking if "/grub/stage1" exists... yes
> Checking if "/grub/stage2" exists... yes
> Checking if "/grub/e2fs_stage1_5" exists... yes
> Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded.
> succeeded
> Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2
> /grub/menu..lst"... succeeded
> Done.
> grub> quit
>
> # reboot
> => Grub menu is not shown (screen remains blank); system fails to boot
>
> Conclusions:
> - grub-install does the right thing
> - the setup command in the grub interactive shell checks if the stage files
> exist, but apparently its setup command fails to check if they are
> compatible with the current version of grub
>
> I will keep the image I created this way in vmware for a while in case
> additional information is wanted.
>
> Cheers,
> Frans Pop
>
>
> _______________________________________________
> Pkg-grub-devel mailing list
> <email address hidden>
> http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel

Revision history for this message
In , Steve Langasek (vorlon) wrote :

reopen 345931
severity 345931 serious
tags 345931 upstream
thanks

On Tue, Feb 07, 2006 at 09:01:01AM +1100, Jason Thomas wrote:
> close 345931
> thanks

> grub-install copies the various stage* files into /boot/grub. grub shell
> does not.

> If you do not copy the stage* files then they will be incompatible with
> the boot sector that is installed.

> grub-install is the recommeneded method to install.

Surely this is still a bug in the grub shell for failing to notice that it
had rendered the system unbootable?

I think this bug qualifies as "serious"; I think plenty of people are going
to be upset when the grub shell toasts their system without warning. If you
downgrade it, I'd appreciate if you would offer an explanation why you think
this is an ok bug to release with given its non-obvious consequences; but
please don't close it, as it does refer to a real bug.

I've already talked with Otavio about getting 0.97 into testing in spite of
this bug, since there are other bugs in testing that are at least as
significant.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

Revision history for this message
In , Otavio Salvador (otavio) wrote :

Steve Langasek <email address hidden> writes:

> On Tue, Feb 07, 2006 at 09:01:01AM +1100, Jason Thomas wrote:
>> close 345931
>> thanks
>
>> grub-install copies the various stage* files into /boot/grub. grub shell
>> does not.
>
>> If you do not copy the stage* files then they will be incompatible with
>> the boot sector that is installed.
>
>> grub-install is the recommeneded method to install.
>
> Surely this is still a bug in the grub shell for failing to notice that it
> had rendered the system unbootable?

I don't think so. If you're using grub's shell you need know what
you're doing since it isn't indeed to be used for enduser.

> I think this bug qualifies as "serious"; I think plenty of people are going
> to be upset when the grub shell toasts their system without warning. If you
> downgrade it, I'd appreciate if you would offer an explanation why you think
> this is an ok bug to release with given its non-obvious consequences; but
> please don't close it, as it does refer to a real bug.

This is a upstream issue and I doubt upstream will change it since
it's currently in legacy mode and all effort in grub2.

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Steve Langasek (vorlon) wrote :

On Mon, Feb 06, 2006 at 09:58:29PM -0200, Otavio Salvador wrote:
> Steve Langasek <email address hidden> writes:

> > On Tue, Feb 07, 2006 at 09:01:01AM +1100, Jason Thomas wrote:
> >> close 345931
> >> thanks

> >> grub-install copies the various stage* files into /boot/grub. grub shell
> >> does not.

> >> If you do not copy the stage* files then they will be incompatible with
> >> the boot sector that is installed.

> >> grub-install is the recommeneded method to install.

> > Surely this is still a bug in the grub shell for failing to notice that it
> > had rendered the system unbootable?

> I don't think so. If you're using grub's shell you need know what
> you're doing since it isn't indeed to be used for enduser.

Er, but I do know what I'm doing; I'm telling grub to reinstall a boot
block. What I *don't* know is that grub is going to silently fail to
ascertain that the stage files on disk aren't compatible with the commands
being run. Why does the grub shell even bother to look for the stage2
loader on disk, for instance, if it's not going to verify that it's usable?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

Jeff Bailey (jbailey)
Changed in grub:
assignee: jbailey → tfheen
Revision history for this message
In , Kristian Edlund (edlund) wrote :

The first installation report states that /grub/stage1 exists. Is that
indeed true?

Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote :

Why don't we move [/usr]/sbin/grub to /usr/lib ? Then we could even have a stub
that echoes "Use grub-install" in /usr/sbin/grub.

--
Robert Millan

My spam trap is <email address hidden>. Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.

Revision history for this message
In , Steve Langasek (vorlon) wrote :

On Mon, Aug 28, 2006 at 03:37:10PM +0200, Robert Millan wrote:

> Why don't we move [/usr]/sbin/grub to /usr/lib ? Then we could even have a
> stub that echoes "Use grub-install" in /usr/sbin/grub.

I have no idea; is this something I should have an opinion on? :) If you
don't mean for the binary to be invoked directly by an admin, then of course
/usr/lib is allowed/preferred under the FHS.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

Revision history for this message
In , telenieko (telenieko) wrote : If the problem is that the user doesn't know he won't be able to reboot...

Steve Langasek <email address hidden> writes:
> Surely this is still a bug in the grub shell for failing to notice that it
> had rendered the system unbootable?

Grub shell is supposed to be used by "experienced" users, and if the
big problem is that setup() doesn't copy those files to /boot/ there
are two lines of action:
a) On a call to setup() output a nice warning message that clearly
says that the files MUST be manually copied by the user encouragin the
use of grub-install
b) On a call to setup() take care of copying the files.

I'd vote for option a, with that warning in place the bug would be ok,
right? I've never touched inside grub but I can try to patch it if you
select A, and less maybe for B ;) [so, is option A ok for closing the
bug? at least the user knows that he/she won't boot again... hehe]

Cheers,
Marc.

--
The probability of failure of a (computer) system is exponentially
proportional to the physical distance between it and the one who could
fix it. -- Martin F. Krafft

--
The probability of failure of a (computer) system is exponentially
proportional to the physical distance between it and the one who could
fix it. -- Martin F. Krafft

Revision history for this message
In , Jason Thomas (jason-debian) wrote : Re: Bug#345931: If the problem is that the user doesn't know he won't be able to reboot...

option C, we create a way to extract the version information from every
grub file. So that the grub shell can check that its version matches
the stage files and if not generate an ERROR message.

On Wed, Sep 13, 2006 at 11:05:38AM +0200, Marc Fargas wrote:
> Steve Langasek <email address hidden> writes:
> >Surely this is still a bug in the grub shell for failing to notice that it
> >had rendered the system unbootable?
>
> Grub shell is supposed to be used by "experienced" users, and if the
> big problem is that setup() doesn't copy those files to /boot/ there
> are two lines of action:
> a) On a call to setup() output a nice warning message that clearly
> says that the files MUST be manually copied by the user encouragin the
> use of grub-install
> b) On a call to setup() take care of copying the files.
>
> I'd vote for option a, with that warning in place the bug would be ok,
> right? I've never touched inside grub but I can try to patch it if you
> select A, and less maybe for B ;) [so, is option A ok for closing the
> bug? at least the user knows that he/she won't boot again... hehe]
>
> Cheers,
> Marc.
>
> --
> The probability of failure of a (computer) system is exponentially
> proportional to the physical distance between it and the one who could
> fix it. -- Martin F. Krafft
>
>
> --
> The probability of failure of a (computer) system is exponentially
> proportional to the physical distance between it and the one who could
> fix it. -- Martin F. Krafft
>
>
> _______________________________________________
> Pkg-grub-devel mailing list
> <email address hidden>
> http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel

Revision history for this message
In , telenieko (telenieko) wrote :

I'm not sure about that. there's a chance that some people want thise
behaviour (I mean, do not touch the stage files) and raising an ERROR
would leave them with no option. If you want your stage files updated
use grub-install. If not use grub, setup() and pay attention to the
warning message.

A warning is much less intrusive than an error. If one likes that
behaviour and sees a warning will simply ignore it. If he/she gets an
error, it can't be ignored. I would only raise a warning by checking
the version on stage files or simply every time setup() is called.

Cheers,
Marc.

On 9/14/06, Jason Thomas <email address hidden> wrote:
> option C, we create a way to extract the version information from every
> grub file. So that the grub shell can check that its version matches
> the stage files and if not generate an ERROR message.
>
> On Wed, Sep 13, 2006 at 11:05:38AM +0200, Marc Fargas wrote:
> > Steve Langasek <email address hidden> writes:
> > >Surely this is still a bug in the grub shell for failing to notice that it
> > >had rendered the system unbootable?
> >
> > Grub shell is supposed to be used by "experienced" users, and if the
> > big problem is that setup() doesn't copy those files to /boot/ there
> > are two lines of action:
> > a) On a call to setup() output a nice warning message that clearly
> > says that the files MUST be manually copied by the user encouragin the
> > use of grub-install
> > b) On a call to setup() take care of copying the files.
> >
> > I'd vote for option a, with that warning in place the bug would be ok,
> > right? I've never touched inside grub but I can try to patch it if you
> > select A, and less maybe for B ;) [so, is option A ok for closing the
> > bug? at least the user knows that he/she won't boot again... hehe]
> >
> > Cheers,
> > Marc.
> >
> > --
> > The probability of failure of a (computer) system is exponentially
> > proportional to the physical distance between it and the one who could
> > fix it. -- Martin F. Krafft
> >
> >
> > --
> > The probability of failure of a (computer) system is exponentially
> > proportional to the physical distance between it and the one who could
> > fix it. -- Martin F. Krafft
> >
> >
> > _______________________________________________
> > Pkg-grub-devel mailing list
> > <email address hidden>
> > http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel
>

--
The probability of failure of a (computer) system is exponentially
proportional to the physical distance between it and the one who could
fix it. -- Martin F. Krafft

Revision history for this message
In , dorileo (ldorileo) wrote :

Hi Jason

On Wednesday 13 September 2006 18:26, Jason Thomas wrote:
> option C, we create a way to extract the version information from every
> grub file. So that the grub shell can check that its version matches
> the stage files and if not generate an ERROR message.

I tryied to understand how to do this ~2 months ago but didnt have time to go
deep on it. How do you think it should be done?

I saw a patch[1] sent by Mats Erik Andersson and it seems to be ok(needs just
little changes), I`m going to try it better.

[1]
http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2006-September/001998.html

--
Dorileo

>
> On Wed, Sep 13, 2006 at 11:05:38AM +0200, Marc Fargas wrote:
> > Steve Langasek <email address hidden> writes:
> > >Surely this is still a bug in the grub shell for failing to notice that
> > > it had rendered the system unbootable?
> >
> > Grub shell is supposed to be used by "experienced" users, and if the
> > big problem is that setup() doesn't copy those files to /boot/ there
> > are two lines of action:
> > a) On a call to setup() output a nice warning message that clearly
> > says that the files MUST be manually copied by the user encouragin the
> > use of grub-install
> > b) On a call to setup() take care of copying the files.
> >
> > I'd vote for option a, with that warning in place the bug would be ok,
> > right? I've never touched inside grub but I can try to patch it if you
> > select A, and less maybe for B ;) [so, is option A ok for closing the
> > bug? at least the user knows that he/she won't boot again... hehe]
> >
> > Cheers,
> > Marc.
> >
> > --
> > The probability of failure of a (computer) system is exponentially
> > proportional to the physical distance between it and the one who could
> > fix it. -- Martin F. Krafft
> >
> >
> > --
> > The probability of failure of a (computer) system is exponentially
> > proportional to the physical distance between it and the one who could
> > fix it. -- Martin F. Krafft
> >
> >
> > _______________________________________________
> > Pkg-grub-devel mailing list
> > <email address hidden>
> > http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel
>
> _______________________________________________
> Pkg-grub-devel mailing list
> <email address hidden>
> http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel

Revision history for this message
In , Kapil Hari Paranjape (kapil) wrote : Quote from documentation

Hello,

On reading of this problem in using the grub "shell" setup command
instead of "grub-install" I looked through the documentation since I
was sure that it had asked me to copy the files.

Sure enough, under the node "Installation" in the grub info there is
the following paragraph:

           GRUB comes with boot images, which are normally put in
           the directory `/usr/lib/grub/i386-pc'. If you do not use
           grub-install, then you need to copy the files `stage1',
           `stage2', and `*stage1_5' to the directory `/boot/grub',
           ...

Unfortunately, this is from the info file which is in the package
"grub-doc". On the other hand the grub "shell" command has little to
hint about what needs to be done.

 grub> help setup

 setup: setup [--prefix=DIR] [--stage2=STAGE2_FILE] [--force-lba] INSTALL_DEVICE [IMAGE_DEVICE]
     Set up the installation of GRUB automatically. This command uses
     the more flexible command "install" in the backend and installs
     GRUB into the device INSTALL_DEVICE. If IMAGE_DEVICE is
     specified, then find the GRUB images in the device IMAGE_DEVICE,
     otherwise use the current "root device", which can be set by the
     command "root". If you know that your BIOS should support LBA but
     GRUB doesn't work in LBA mode, specify the option `--force-lba'.
     If you install GRUB under the grub shell and you cannot unmount
     the partition where GRUB images reside, specify the option
     `--stage2' to tell GRUB the file name under your OS.

Perhaps we could add some suitable text here which would resolve this
bug. For example, we could append the following:

     WARNING: In order for this to work GRUB needs to find the images
     "stage1" and "stage2" (or "stage1_5") corresponding to its
     current version in the locations specified by INSTALL_DEVICE
     (or IMAGE_DEVICE if specified or STAGE2_FILE if specified).

Regards,

Kapil.
--

Revision history for this message
In , Kapil Hari Paranjape (kapil) wrote : Re: If the problem is that the user doesn't know he won't be able to reboot...

tags 345931 + patch
thanks

In my previous response, I missed this post to this bug list.

On Wed, 13 Sep 2006, Marc Fargas wrote:
> Steve Langasek <email address hidden> writes:
> >Surely this is still a bug in the grub shell for failing to notice that it
> >had rendered the system unbootable?
>
> Grub shell is supposed to be used by "experienced" users, and if the
> big problem is that setup() doesn't copy those files to /boot/ there
> are two lines of action:
> a) On a call to setup() output a nice warning message that clearly
> says that the files MUST be manually copied by the user encouragin the
> use of grub-install
> b) On a call to setup() take care of copying the files.
>
> I'd vote for option a, with that warning in place the bug would be ok,
> right? I've never touched inside grub but I can try to patch it if you
> select A, and less maybe for B ;) [so, is option A ok for closing the
> bug? at least the user knows that he/she won't boot again... hehe]

I concur and enclose a patch which is the output of:

 interdiff -z grub_0.97-15.diff.gz grub_0.97-15.0pre1.diff.gz

(This also includes the small patch for #385980 suggested by Joey Hess.)

On Thu, 14 Sep 2006, Jason Thomas wrote:
> option C, we create a way to extract the version information from every
> grub file. So that the grub shell can check that its version matches
> the stage files and if not generate an ERROR message.

Note that stage1 is a boot sector and so contains precious little
space for such version information. Implementing this option seems
quite difficult to me.

Regards,

Kapil.
--

Revision history for this message
In , Otavio Salvador (otavio) wrote : Re: Bug#345931: If the problem is that the user doesn't know he won't be able to reboot...

Kapil Hari Paranjape <email address hidden> writes:

>> option C, we create a way to extract the version information from every
>> grub file. So that the grub shell can check that its version matches
>> the stage files and if not generate an ERROR message.
>
> Note that stage1 is a boot sector and so contains precious little
> space for such version information. Implementing this option seems
> quite difficult to me.

I'm not sure but I think we might try to include the version string at
stage1 and match it when loading stage1.5 or even stage2. Would work,
no?

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Kapil Hari Paranjape (kapil) wrote : Re: Bug#345931: If the problem is that the user doesn't know ...

Hello,

On Sat, 23 Sep 2006, Otavio Salvador wrote:
> Kapil Hari Paranjape <email address hidden> writes:
>
> >> option C, we create a way to extract the version information from every
> >> grub file. So that the grub shell can check that its version matches
> >> the stage files and if not generate an ERROR message.
> >
> > Note that stage1 is a boot sector and so contains precious little
> > space for such version information. Implementing this option seems
> > quite difficult to me.
>
> I'm not sure but I think we might try to include the version string at
> stage1 and match it when loading stage1.5 or even stage2. Would work,
> no?

I think that the problem that arose was that grub-shell "setup_func"
of one version (say 0.97) would check for "stage1" and "stage2" without
checking that they belonged to the same version. So the matching
needs to done at installation time and not at run-time. (Though the
latter may be a good thing (TM) to do as well.)

Now there is certainly enough space in "stage2" or "stage1.5" for the
version number so we could check those but that still leaves the
problem of "stage1". (In fact "strings" shows that the version string
already appears in the binaries stage{2,1.5}).

Solution 1: We try to make room in "stage1" for the version number
and check all version numbers before installing. This may be
difficult given that "stage1" is only a boot-sector long and space is
"tight".

Solution 2: (Since "stage1" does not change a lot) we can usually
expect that "stage1" of an older version will be able to load the
current version of "stage2" or "stage1.5"; so we only check the
version numbers of the latter. However, this has some "future risks"
built in---when "stage1" is actually changed what do we do?

The solution that the patch implements is to just print a big fat warning to
the user that it is better to use "grub-install" unless they are sure
that they have the correct versions installed.

Considering the idea of a "feature freeze" for "grub" and a move to
try and consolidate "grub2" instead, I think this solution is simpler
to use than Solution 1 and 2.

Thanks and regards,

Kapil.
--

Revision history for this message
In , Jason Thomas (jason-debian) wrote :

If stage2 and stage1.5 are correct then most likely stage1 is correct as
well. So would say just checking there version matches grub-shell would
be enough.

On Mon, Sep 25, 2006 at 09:01:02AM +0530, Kapil Hari Paranjape wrote:
> Solution 2: (Since "stage1" does not change a lot) we can usually
> expect that "stage1" of an older version will be able to load the
> current version of "stage2" or "stage1.5"; so we only check the
> version numbers of the latter. However, this has some "future risks"
> built in---when "stage1" is actually changed what do we do?

> _______________________________________________
> Pkg-grub-devel mailing list
> <email address hidden>
> http://lists.alioth.debian.org/mailman/listinfo/pkg-grub-devel

Revision history for this message
In , Otavio Salvador (otavio) wrote :

Kapil Hari Paranjape <email address hidden> writes:

> Considering the idea of a "feature freeze" for "grub" and a move to
> try and consolidate "grub2" instead, I think this solution is simpler
> to use than Solution 1 and 2.

I tend to agree with you.

Besides it keep clear that grub shell shouldn't be use if you doesn't
know what you're doing.

Do you think the current patch is ready for "wide use"?

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Otavio Salvador (otavio) wrote :

Jason Thomas <email address hidden> writes:

> If stage2 and stage1.5 are correct then most likely stage1 is correct as
> well. So would say just checking there version matches grub-shell would
> be enough.

Yes, it should be enough. My personal worry is how difficult will be
to add it.

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote : Re: A patch solving #345931
Download full text (3.2 KiB)

On Mon, Sep 11, 2006 at 06:26:37PM +0200, Mats Erik Andersson wrote:
> Venerable Maintainers of Grub,
>
> I offer you a patch that should close bug report
> #345931.
>
> The patch has been built on top of grub-0.97-13 with
> success and it repaired with honours mbr-installs of
>
> grub-0.97-1ubuntu1 on kubuntu 6.0.6
> and
> grub-0.95+cvs20040624-17sarge1 on Debian
> Sarge.

Does your patch work with grub from debian sid?

Does GRUB 2 also exhibit this problem?

> As you will see the coding is independent of any
> Debian patches and contains a few lines of code for
> the source file
>
> grub-0.97/stage2/builtins.c
>
> and thus would easily integrate in the upstream
> version 0.97. I leave to you to decide whether the
> author ought to be informed, since I am still a
> novice in these matters.
>
> Best regards
>
> Mats Erik Andersson
> <email address hidden>
Content-Description: 526972506-drive_correction.diff
> diff -Naur grub-0.97.orig/stage2/builtins.c grub-0.97/stage2/builtins.c
> --- grub-0.97.orig/stage2/builtins.c 2006-09-11 16:08:32.261227280 +0200
> +++ grub-0.97/stage2/builtins.c 2006-09-11 16:15:54.035067448 +0200
> @@ -1953,13 +1953,30 @@
> *((unsigned char *) (stage1_buffer + STAGE1_FORCE_LBA)) = is_force_lba;
>
> /* If DEST_DRIVE is a hard disk, enable the workaround, which is
> - for buggy BIOSes which don't pass boot drive correctly. Instead,
> - they pass 0x00 or 0x01 even when booted from 0x80. */
> + * for buggy BIOSes which don't pass boot drive correctly. Instead,
> + * they pass 0x00 or 0x01 even when booted from 0x80. */
> if (dest_drive & BIOS_FLAG_FIXED_DISK)
> - /* Replace the jmp (2 bytes) with double nop's. */
> - *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> - = 0x9090;
> -
> + {
> + if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK)) == 0xeb )
> + /* For version 0.97:
> + * Replace the jmp (2 bytes) with double nop's. */
> + *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> + = 0x9090;
> + else if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK)) == 0x80 )
> + {
> + /* For versions 0.94-96:
> + * Set the boot drive mask. This is a workaround for buggy BIOSes which
> + * don't pass boot drive correctly. Instead, they pass 0x00 even when
> + * booted from 0x80.
> + * Rem: the old STAGE1_BOOT_DRIVE_MASK equals STAGE1_BOOT_DRIVE_CHECK + 2 */
> + *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK + 2 ))
> + = (dest_drive & BIOS_FLAG_FIXED_DISK);
> + }
> + else
> + /* The boot sector is older than version 0.94.
> + * Changing to a "nop" could make 0.92 and 0.93 acceptable. */
> + goto fail;
> + }
> /* Read the first sector of Stage 2. */
> disk_read_hook = disk_read_savesect_func;
> if (grub_read (stage2_first_buffer, SECTOR_SIZE) != SECTOR_SIZE)

--
Robert Millan

My spam trap is <email address hidden>. Note: this address is only intended for
spam harvesters. Writing...

Read more...

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote :
Download full text (3.9 KiB)

Also please send your input to bug report addresses (e.g.
<email address hidden>). Otherwise it gets lost here.

On Mon, Sep 25, 2006 at 04:17:15PM +0200, Robert Millan wrote:
> On Mon, Sep 11, 2006 at 06:26:37PM +0200, Mats Erik Andersson wrote:
> > Venerable Maintainers of Grub,
> >
> > I offer you a patch that should close bug report
> > #345931.
> >
> > The patch has been built on top of grub-0.97-13 with
> > success and it repaired with honours mbr-installs of
> >
> > grub-0.97-1ubuntu1 on kubuntu 6.0.6
> > and
> > grub-0.95+cvs20040624-17sarge1 on Debian
> > Sarge.
>
> Does your patch work with grub from debian sid?
>
> Does GRUB 2 also exhibit this problem?
>
>
> > As you will see the coding is independent of any
> > Debian patches and contains a few lines of code for
> > the source file
> >
> > grub-0.97/stage2/builtins.c
> >
> > and thus would easily integrate in the upstream
> > version 0.97. I leave to you to decide whether the
> > author ought to be informed, since I am still a
> > novice in these matters.
> >
> > Best regards
> >
> > Mats Erik Andersson
> > <email address hidden>
> Content-Description: 526972506-drive_correction.diff
> > diff -Naur grub-0.97.orig/stage2/builtins.c grub-0.97/stage2/builtins.c
> > --- grub-0.97.orig/stage2/builtins.c 2006-09-11 16:08:32.261227280 +0200
> > +++ grub-0.97/stage2/builtins.c 2006-09-11 16:15:54.035067448 +0200
> > @@ -1953,13 +1953,30 @@
> > *((unsigned char *) (stage1_buffer + STAGE1_FORCE_LBA)) = is_force_lba;
> >
> > /* If DEST_DRIVE is a hard disk, enable the workaround, which is
> > - for buggy BIOSes which don't pass boot drive correctly. Instead,
> > - they pass 0x00 or 0x01 even when booted from 0x80. */
> > + * for buggy BIOSes which don't pass boot drive correctly. Instead,
> > + * they pass 0x00 or 0x01 even when booted from 0x80. */
> > if (dest_drive & BIOS_FLAG_FIXED_DISK)
> > - /* Replace the jmp (2 bytes) with double nop's. */
> > - *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > - = 0x9090;
> > -
> > + {
> > + if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK)) == 0xeb )
> > + /* For version 0.97:
> > + * Replace the jmp (2 bytes) with double nop's. */
> > + *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > + = 0x9090;
> > + else if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK)) == 0x80 )
> > + {
> > + /* For versions 0.94-96:
> > + * Set the boot drive mask. This is a workaround for buggy BIOSes which
> > + * don't pass boot drive correctly. Instead, they pass 0x00 even when
> > + * booted from 0x80.
> > + * Rem: the old STAGE1_BOOT_DRIVE_MASK equals STAGE1_BOOT_DRIVE_CHECK + 2 */
> > + *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK + 2 ))
> > + = (dest_drive & BIOS_FLAG_FIXED_DISK);
> > + }
> > + else
> > + /* The boot sector is older than version 0.94.
> > + * Changing to a "nop" could make 0.92 and 0.93 acceptabl...

Read more...

Revision history for this message
In , Kapil Hari Paranjape (kapil) wrote : Re: Bug#345931: If the problem is that the user doesn't know ...

On Mon, 25 Sep 2006, Otavio Salvador wrote:
> Kapil Hari Paranjape <email address hidden> writes:
>
> > Considering the idea of a "feature freeze" for "grub" and a move to
> > try and consolidate "grub2" instead, I think this solution is simpler
> > to use than Solution 1 and 2.
>
> I tend to agree with you.
>
> Besides it keep clear that grub shell shouldn't be use if you doesn't
> know what you're doing.
>
> Do you think the current patch is ready for "wide use"?

Its my patch so I'm bound to like it :)

More objectively:

1. It only introduces some printf's so it does not seem to be
   something that can cause a build or security problem.

2. You may want to pass the actual warning messages by some
   of the other developers/bug reporters. You also need to
   check with them that this is a good enough fix.

3. I checked that this message *does not* appear when one uses
   the scripts. So the message will not come up to confuse the
   common user.

Overall, modulo (2) it looks as if the patch does fix things.

I also feel that implementing the version check is a bit complex since:

(a) the builtin.c has to know the actual location of the version
    string in the binary.

(b) builtin.c would need to be able to read ELF information to
    actually find this string.

(c) I have never actually implemented such a version check or know
    of some source where such a check is implemented.

Point (c) is of course the most important one :)

Thanks and regards,

Kapil.
--

Revision history for this message
In , dorileo (ldorileo) wrote : Re: Bug#345931: A patch solving #345931
Download full text (3.6 KiB)

Hi Robert

On Monday 25 September 2006 10:17, Robert Millan wrote:
> On Mon, Sep 11, 2006 at 06:26:37PM +0200, Mats Erik Andersson wrote:
> > Venerable Maintainers of Grub,
> >
> > I offer you a patch that should close bug report
> > #345931.
> >
> > The patch has been built on top of grub-0.97-13 with
> > success and it repaired with honours mbr-installs of
> >
> > grub-0.97-1ubuntu1 on kubuntu 6.0.6
> > and
> > grub-0.95+cvs20040624-17sarge1 on Debian
> > Sarge.
>
> Does your patch work with grub from debian sid?
>
> Does GRUB 2 also exhibit this problem?

I don`t think so, I`m trying this patch and I think It`s a totally grub legacy
related problem. I just have few considerations on the proposed patch.

>
> > As you will see the coding is independent of any
> > Debian patches and contains a few lines of code for
> > the source file
> >
> > grub-0.97/stage2/builtins.c
> >
> > and thus would easily integrate in the upstream
> > version 0.97. I leave to you to decide whether the
> > author ought to be informed, since I am still a
> > novice in these matters.
> >
> > Best regards
> >
> > Mats Erik Andersson
> > <email address hidden>
>
> Content-Description: 526972506-drive_correction.diff
>
> > diff -Naur grub-0.97.orig/stage2/builtins.c grub-0.97/stage2/builtins.c
> > --- grub-0.97.orig/stage2/builtins.c 2006-09-11 16:08:32.261227280 +0200
> > +++ grub-0.97/stage2/builtins.c 2006-09-11 16:15:54.035067448 +0200
> > @@ -1953,13 +1953,30 @@
> > *((unsigned char *) (stage1_buffer + STAGE1_FORCE_LBA)) =
> > is_force_lba;
> >
> > /* If DEST_DRIVE is a hard disk, enable the workaround, which is
> > - for buggy BIOSes which don't pass boot drive correctly. Instead,
> > - they pass 0x00 or 0x01 even when booted from 0x80. */
> > + * for buggy BIOSes which don't pass boot drive correctly. Instead,
> > + * they pass 0x00 or 0x01 even when booted from 0x80. */
> > if (dest_drive & BIOS_FLAG_FIXED_DISK)
> > - /* Replace the jmp (2 bytes) with double nop's. */
> > - *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > - = 0x9090;
> > -
> > + {
> > + if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > == 0xeb ) + /* For version 0.97:
> > + * Replace the jmp (2 bytes) with double nop's. */
> > + *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > + = 0x9090;

What have changed here?

> > + else if ( *((unsigned char *) (stage1_buffer +
> > STAGE1_BOOT_DRIVE_CHECK)) == 0x80 ) + {
> > + /* For versions 0.94-96:
> > + * Set the boot drive mask. This is a workaround for buggy BIOSes
> > which + * don't pass boot drive correctly. Instead, they pass
> > 0x00 even when + * booted from 0x80.
> > + * Rem: the old STAGE1_BOOT_DRIVE_MASK equals
> > STAGE1_BOOT_DRIVE_CHECK + 2 */ + *((unsigned char *)
> > (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK + 2 )) + =
> > (dest_drive & BIOS_FLAG_FIXED_DISK);
> > + }
> > + else
> > + /* The boot sector is older than version 0.94.
> > + * ...

Read more...

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote :
Download full text (3.2 KiB)

On Tue, Sep 26, 2006 at 09:52:28AM -0400, Leandro Dorileo wrote:
> Hi Robert
>
> On Monday 25 September 2006 10:17, Robert Millan wrote:
> > On Mon, Sep 11, 2006 at 06:26:37PM +0200, Mats Erik Andersson wrote:
> > > Venerable Maintainers of Grub,
> > >
> > > I offer you a patch that should close bug report
> > > #345931.
> > >
> > > The patch has been built on top of grub-0.97-13 with
> > > success and it repaired with honours mbr-installs of
> > >
> > > grub-0.97-1ubuntu1 on kubuntu 6.0.6
> > > and
> > > grub-0.95+cvs20040624-17sarge1 on Debian
> > > Sarge.
> >
> > Does your patch work with grub from debian sid?
> >
> > Does GRUB 2 also exhibit this problem?
>
> I don`t think so, I`m trying this patch and I think It`s a totally grub legacy
> related problem. I just have few considerations on the proposed patch.

You mean that GRUB 2 works fine on the same hardware?

> > > if (dest_drive & BIOS_FLAG_FIXED_DISK)
> > > - /* Replace the jmp (2 bytes) with double nop's. */
> > > - *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > > - = 0x9090;
> > > -
> > > + {
> > > + if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > > == 0xeb ) + /* For version 0.97:
> > > + * Replace the jmp (2 bytes) with double nop's. */
> > > + *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> > > + = 0x9090;
>
> What have changed here?

Only indentation. But we don't need to bother about this for Debian-specific
changes. OTOH, see below..

> > > + else if ( *((unsigned char *) (stage1_buffer +
> > > STAGE1_BOOT_DRIVE_CHECK)) == 0x80 ) + {
> > > + /* For versions 0.94-96:
> > > + * Set the boot drive mask. This is a workaround for buggy BIOSes
> > > which + * don't pass boot drive correctly. Instead, they pass
> > > 0x00 even when + * booted from 0x80.
> > > + * Rem: the old STAGE1_BOOT_DRIVE_MASK equals
> > > STAGE1_BOOT_DRIVE_CHECK + 2 */ + *((unsigned char *)
> > > (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK + 2 )) + =
> > > (dest_drive & BIOS_FLAG_FIXED_DISK);
> > > + }
> > > + else
> > > + /* The boot sector is older than version 0.94.
> > > + * Changing to a "nop" could make 0.92 and 0.93 acceptable. */
> > > + goto fail;
>
> What about we set here the errnum with ERR_BAD_VERSION? or perhaps define a
> new error with a new message - something like: you should run grub-install or
> you will be unbootable - for this situation?

I think this kind of discussion really belongs in upstream. That doesn't mean
we can't include the patch in debian if it fixes a problem, but all of this
should definitely be brought to <email address hidden>.

> > > + }
> > > /* Read the first sector of Stage 2. */
> > > disk_read_hook = disk_read_savesect_func;
> > > if (grub_read (stage2_first_buffer, SECTOR_SIZE) != SECTOR_SIZE)
>
> I`ll try this patch a bit more in the end of the week.

If you can confirm it works, then could you please resend it to <email address hidden>
(assuming you're the author) ?

--
Robert Millan

My spam trap is honeypot@aybab...

Read more...

Revision history for this message
In , Mats Erik Andersson (ynglingatal) wrote : A patch closing #345931, verified against debian testing

   Dear Maintainers and others,

 the attached patch-file closes to my understanding
 the urgent bug 345931. I write this very message in
 respons to a question of Robert Millan last Monday.
 The patch
           boot_drive_correction.diff

 is simply a beautyfied version of the one submitted
 the first time.

 Yesterday I fetched from Debian Sid grub 0.97-16.1,
 built it and observed that, as expected according
 to #345931, it destroyed and made useless the MBR
 of my grub 0.95+cvs20040624-17sarge1. But by an
 application of my patch the altered version of
 of grub 0.97 (the patch does not touch any code
 alterations of debian) correctly is able to
reactivate
 the the bootloader installed by grub 0.95.

 Let me stress that the patch simply make shore that
 the relevant technique used for boot-drive-workaround
 of grub 0.94-0.97 is respected by grub 0.97. The
 revision 0.97 originally disregards this backwards
 compatibility. At the end of the patch, there is
 an indication of how compatability may be extended
 to versions 0.92-0.93, should the maintainers so
 desire.

 Lastly, Robert Millan asks for relevance visavi
 Grub2. A quick check reveals that grub 1.94 does
 indeed utilize exactly the same workaround for
 harddisk booting as grub 0.97 does. The position
 at which this workaround is checked and applied is

    grub-1.94/util/i386/pc/grub-setup.c line 250.

 That position is the place to apply a patch with
 code accomodations to the new settings.

 HOWEVER, it is not clear to me if the Maintainers
 desire compatibility of Grub2 backwards to Grub
Legacy
 in the sense that the former should be able to
 reactivate a bootloader installed by the latter.
 The maintainers need to decide on this on their own.
 I have not delved into the complete code of Grub2.

      Regards
                    Mats Erik Andersson
                    <email address hidden>

Revision history for this message
In , Otavio Salvador (otavio) wrote : Re: Bug#345931: A patch closing #345931, verified against debian testing
Download full text (4.7 KiB)

Mats Erik Andersson <email address hidden> writes:

> Yesterday I fetched from Debian Sid grub 0.97-16.1,
> built it and observed that, as expected according
> to #345931, it destroyed and made useless the MBR
> of my grub 0.95+cvs20040624-17sarge1. But by an
> application of my patch the altered version of
> of grub 0.97 (the patch does not touch any code
> alterations of debian) correctly is able to
> reactivate the the bootloader installed by grub 0.95.

I agree that compatibility here is important.

> Let me stress that the patch simply make shore that
> the relevant technique used for boot-drive-workaround
> of grub 0.94-0.97 is respected by grub 0.97. The
> revision 0.97 originally disregards this backwards
> compatibility. At the end of the patch, there is
> an indication of how compatability may be extended
> to versions 0.92-0.93, should the maintainers so
> desire.

Ok.

> Lastly, Robert Millan asks for relevance visavi
> Grub2. A quick check reveals that grub 1.94 does
> indeed utilize exactly the same workaround for
> harddisk booting as grub 0.97 does. The position
> at which this workaround is checked and applied is
>
> grub-1.94/util/i386/pc/grub-setup.c line 250.
>
> That position is the place to apply a patch with
> code accomodations to the new settings.
>
> HOWEVER, it is not clear to me if the Maintainers
> desire compatibility of Grub2 backwards to Grub
> Legacy in the sense that the former should be able to
> reactivate a bootloader installed by the latter.
> The maintainers need to decide on this on their own.
> I have not delved into the complete code of Grub2.

I think you should contact upstream and check if they wants to have
compatibility and then provide a patch to them.

Let's now review your current patch:

> diff -Naur grub-0.97-16.1.old/stage2/builtins.c grub-0.97-16.1/stage2/builtins.c
> --- grub-0.97-16.1.old/stage2/builtins.c 2006-09-27 22:48:46.068364160 +0200
> +++ grub-0.97-16.1/stage2/builtins.c 2006-09-28 00:15:47.535580488 +0200
> @@ -2229,13 +2229,31 @@
> *((unsigned char *) (stage1_buffer + STAGE1_FORCE_LBA)) = is_force_lba;
>
> /* If DEST_DRIVE is a hard disk, enable the workaround, which is
> - for buggy BIOSes which don't pass boot drive correctly. Instead,
> - they pass 0x00 or 0x01 even when booted from 0x80. */
> + * for buggy BIOSes which don't pass boot drive correctly. Instead,
> + * they pass 0x00 or 0x01 even when booted from 0x80. */

I agree that your proposed style is better but we would like to reduce
code divergence so please, revert this one since this is just code
style fixing.

> if (dest_drive & BIOS_FLAG_FIXED_DISK)
> - /* Replace the jmp (2 bytes) with double nop's. */
> - *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> - = 0x9090;
> -
> + {
> + if ( *((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK)) == 0xeb )
> + /* For present version 0.97:
> + * Replace the jmp (2 bytes) with double nop's. */
> + *((unsigned short *) (stage1_buffer + STAGE1_BOOT_DRIVE_CHECK))
> + = 0x9090;
> + else if ( *((unsigned char *) (stage1_buffer +...

Read more...

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote :

On Thu, Sep 28, 2006 at 10:51:55AM -0300, Otavio Salvador wrote:
>
> This code also looks great for upstream subimition. I would like if
> you could send it to <email address hidden> and talk to them. If you can get
> it there would be easier to us just grub a CVS snapshot for packaging
> proposes.
>
> After fixing the issues that I pointed out would be good to send it
> upstream and check why _they_ broke the compatibility. Should exist a
> reason for it.

Are you sure it is upstream who broke compatibility? Maybe it is us who did
that (e.g. by appliing savedefault patches).

Anyway, is this compatibility between different versions of MBR and stage files?
I don't think having version disparity between MBR and stage was meant to be
supported.

--
Robert Millan

My spam trap is <email address hidden>. Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.

Revision history for this message
In , Otavio Salvador (otavio) wrote :

Robert Millan <email address hidden> writes:

> On Thu, Sep 28, 2006 at 10:51:55AM -0300, Otavio Salvador wrote:
>>
>> This code also looks great for upstream subimition. I would like if
>> you could send it to <email address hidden> and talk to them. If you can get
>> it there would be easier to us just grub a CVS snapshot for packaging
>> proposes.
>>
>> After fixing the issues that I pointed out would be good to send it
>> upstream and check why _they_ broke the compatibility. Should exist a
>> reason for it.
>
> Are you sure it is upstream who broke compatibility? Maybe it is us who did
> that (e.g. by appliing savedefault patches).

Humm, maybe... well taken :-D.. I need to check to verify it.

> Anyway, is this compatibility between different versions of MBR and stage files?
> I don't think having version disparity between MBR and stage was meant to be
> supported.

Right but if it's not too hard and complex might be good.

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Mats Erik Andersson (ynglingatal) wrote : Copy: An upstream patch to close bug #345931 in Debian
Download full text (6.3 KiB)

  To be on the safe side I duplicate below the message
sent to <email address hidden>, just recently.

  I might add that I did cross check that my patch
is not touching anything that is not present in the
upstreams tar-ball. In addition, the patched setup
function acts on whatever Stage1 is to be deposited in
the mbr, after the boot partition was searched for
originals, or lacking thereof, the new one was
imported from the performing grub-version's library.

  I do hope my message to bug-grub wasn't premature,
though!

      Best regards
                        Mats Erik Andersson

--- Mats Erik Andersson <email address hidden> skrev:

> Dear Maintainers and Bugtrackers,
>
> I would like to submit a patch to grub 0.97 that
> closes the urgent and long standing bug #345931
> recorded with Debian users. I will at some length
> try
> motivate an upstream acceptance. My arguments are of
> some implications even for Grub2, so please read
> this
> with an open mind.
>
> In a change 2005-02-15, the underlying principle
> for
> a workaround to recover from inferior drive-flags
> for
> harddisks in some BIOSes, was drastically changed.
> This
> meant that a three-byte instruction in Stage1 of
> grub
> 0.96 and a new two-byte instruction of grub 0.97
> became
> instrumental as to how the workaround are applied in
> the respective versions. The outcome was that grub
> 0.97
> completely breaks the code in Stage1 from grub 0.96
> when grub 0.97 is used to restore the installed boot
> files deposited by grub 0.96. This provoked #345931
> with the elaps of time.
> I personally find the above incompatibility to be
> a serious mistake, should it be allowed to prevail.
> Admittedly, the more recent workaround may well be
> superior, but it should not be allowed to disrupt
> perfectly fitting installments of grub 0.94-0.96.
> My proposed patch simply equips the setup-function
> of the grub-shell with the ability to test which
> workaround was used in the Stage1-sector present
> on the chosen harddisk partition, and then it takes
> the corresponding measures needed to correctly
> restore Stage1.
> At the very end of the patch I have deliberately
> coded and commented in a way to allow the proper
> actions to be implemented also for providing
> backward
> compatibility all the way back to grub 0.92, should
> the maintainers desire to effectuate also this.
> For the time being, the code deliberately fails
> for grub 0.93 and older. Please tell me to implement
> the extension or do it yourself. I must say again
> that I find it imperative to keep versions 0.96 and
> 0.97 compatible, since grub 0.95/96 are present on
> very many systems and will be for some time to come.
> A policy to implement compatibility visavi grub
> 0.92/3
> is negotiable and left to the maintainers to decide
> upon.
>
> Now over to Grub2. Robert Millan encouraged me to
> determine whether my patch is of relevance to Grub2.
> An investigation of the code in grub 1.94 reveals
> that
> the new code base uses the same mechanism as has
> been
> applied in grub 0.97 for this particular workaround.
> Thus it is well possible that the principle behind
> my patch - after insertion of new...

Read more...

Revision history for this message
In , Kapil Hari Paranjape (kapil) wrote : Re: Bug#345931: A patch closing #345931, verified against debian testing

Hello,

On Thu, 28 Sep 2006, Otavio Salvador wrote:
> Robert Millan <email address hidden> writes:
> > Anyway, is this compatibility between different versions of MBR and stage files?
> > I don't think having version disparity between MBR and stage was meant to be
> > supported.
>
> Right but if it's not too hard and complex might be good.

I think that it may be a good idea to plug-in a warning message
as well when this incompatibility is found (during the installation
phase only).

That way, the user is encouraged to use the newer stage1 but can
continue to the older stage1 at their own risk.

I think the warning patch and the proposed patch to the stage1
installation are disjoint so both can be put in concurrently.

Regards,

Kapil.
--

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote :

On Thu, Sep 28, 2006 at 04:58:52PM -0300, Otavio Salvador wrote:
> Robert Millan <email address hidden> writes:
>
> > On Thu, Sep 28, 2006 at 10:51:55AM -0300, Otavio Salvador wrote:
> >>
> >> This code also looks great for upstream subimition. I would like if
> >> you could send it to <email address hidden> and talk to them. If you can get
> >> it there would be easier to us just grub a CVS snapshot for packaging
> >> proposes.
> >>
> >> After fixing the issues that I pointed out would be good to send it
> >> upstream and check why _they_ broke the compatibility. Should exist a
> >> reason for it.
> >
> > Are you sure it is upstream who broke compatibility? Maybe it is us who did
> > that (e.g. by appliing savedefault patches).
>
> Humm, maybe... well taken :-D.. I need to check to verify it.
>
> > Anyway, is this compatibility between different versions of MBR and stage files?
> > I don't think having version disparity between MBR and stage was meant to be
> > supported.
>
> Right but if it's not too hard and complex might be good.

People should be using grub-install; if we still want compatibility I think it's
an upstream decision.

Mats, could you send your patch to <email address hidden>?

--
Robert Millan

My spam trap is <email address hidden>. Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.

Revision history for this message
In , Otavio Salvador (otavio) wrote :

Robert Millan <email address hidden> writes:

>> Right but if it's not too hard and complex might be good.
>
> People should be using grub-install; if we still want compatibility I think it's
> an upstream decision.
>
> Mats, could you send your patch to <email address hidden>?

I agree with Rebert here.

--
        O T A V I O S A L V A D O R
---------------------------------------------
 E-mail: <email address hidden> UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Revision history for this message
In , Robert Millan (rmh-aybabtu-com) wrote : wishlist

retitle 345931 please maintain backwards compatibility for unsynced versions of MBR / stage files
tags 345931 upstream wontfix
severity 345931 wishlist
thanks

--
Robert Millan

My spam trap is <email address hidden>. Note: this address is only intended for
spam harvesters. Writing to it will get you added to my black list.

Revision history for this message
Kurt J. Bosch (kujub-deactivatedaccount) wrote : Re: grub 0.97 doesn't work on several machines

Could this be the same bug as
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/79578 ?

Revision history for this message
Kurt J. Bosch (kujub-deactivatedaccount) wrote :

I anser my own question after reading more on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345931 :

No, it is not.

Tollef Fog Heen (tfheen)
Changed in grub:
assignee: tfheen → nobody
Bug Watch Updater (bug-watch-updater)
Changed in grub:
status: Confirmed → Won't Fix
Revision history for this message
David Tomaschik (matir) wrote :

Since grub upstream and Debian both seem to think that it's not a problem, and this bug was only generated by the Debian importer, is there any reason this should be kept open any longer?

Revision history for this message
zzzxxx (michalski-deactivatedaccount-deactivatedaccount) wrote :

replicatable on my friends Dell Optiplex GX270

Revision history for this message
zzzxxx (michalski-deactivatedaccount-deactivatedaccount) wrote :

(im new to bug commenting/reporting, should I mark this as conformed now?)

Revision history for this message
David Wynn (wynn-david) wrote :

grub 0.97-2 must have been a dapper or edgy version. (Perhaps an update to dapper?) Based on packages.ubuntu.com, dapper uses 0.97-1, while gutsy uses 0.97-29, and of course later releases use later versions of grub. (Edgy and feisty are no longer supported)

I'm just trying to get a handle on the scope of this issue. Is this issue peculiar to Dapper (which is still supported on the desktop through June 2009 and on server through June 2011)? Or does this affect later versions of grub, and thus later releases also?

Revision history for this message
Santana (rigosantana3-gmx) wrote :

The report is complete and ready for dev team

Changed in grub:
status: New → Confirmed
David Wynn (wynn-david)
tags: added: dapper
Revision history for this message
David Wynn (wynn-david) wrote :

If this is still a lingering issue, the grub team should review the original debian bug. It looks like some patch code has been added into the upstream bug report. If I read the accompanying explanation correctly, this affects both grub and grub2. For now, this has been indicated as peculiar to code that was active round about the time of dapper.

If anyone can confirm that this bug is still active in recent versions of ubuntu / grub, please update this bug with recent information regarding the version of ubuntu that you're testing. For the courageous, if you want to try the bug patch listed in the Debian bug, please report back on your test results.

Revision history for this message
Phillip Susi (psusi) wrote :

Following debian and marking this as wontfix.

Changed in grub (Ubuntu):
status: Confirmed → Won't Fix
summary: - grub 0.97 doesn't work on several machines
+ grub fails after upgrading and using grub shell to reinstall instead of
+ grub-install
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.