Your message dated Sat, 16 Aug 2025 15:55:37 -0400 (EDT)
with message-id <[email protected]>
and subject line Bug#1110934: Removed package(s) from unstable
has caused the Debian Bug report #502544,
regarding INT13 handler misbehaviour
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
502544: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502544
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: grub
Version: 0.97-47
Severity: normal
Tags: patch
Hello!
For a rather special application, I tried to use grub's "map" command
in a creative way, something like:
map (hd0) (hd1)
map (hd1) (hd2)
map (hd2) (hd3)
map (hd3) (hd4)
chainloader (hd1)+1
The idea was to "shift" the BIOS numbering of disks and then to jump
to the MBR code of the next disk. This worked partially, but only
partially... it ended with either "read error" when loading stage1.5,
or (if done twice) by a mixup of files from the 2nd and 3rd disk.
After a day of debugging I found out the cause of this misbehaviour:
The map command installs an INT13 handler that does the remapping of
device numbers. After calling the previous handler, it tries to
restore register %dl (drive number) to the original value, because
it's traditionally a called-saved register (and grub itself relies on
that). However, there are two functions (08h and 15h) that return
something in %dl/%dx, so in their case the restauration should not
happen. Therefore the code tries to catch these, but the conditions
are horribly wrong ;) (see patch below: wrong condition tests, and
also comparing %ax instead %ah), with the effect that %dl was never
restored. So grub started to read one sector from 0x80, the rest
coming from 0x81 (or, in the double case, from 0x82)...
I guess nobody noticed that until now, because the normal usage of
"map" is to swap (hd0) and (hd1) to boot DOS/Win from the second disk.
And those two insist on booting from device 0x80 (otherwise you
wouldn't need the swap...), so I guess it the device number is
hardcoded in their boot loaders.
Anyway, the patch below fixes the handler to restore %dl exactly in
the cases when it should be.
As upstream doesn't maintain "GRUB Legacy" anymore, I want to submit
this patch at least here. GRUB2 doesn't contain the map command
(yet?), nor the INT13 handler at all, so the fix doesn't apply there.
Roman
--- grub/stage2/asm.S~ 2004-03-11 13:00:30.000000000 +0100
+++ grub/stage2/asm.S 2008-10-17 16:13:04.000000000 +0200
@@ -713,10 +713,10 @@
movw %ax, 0xc(%bp)
/* check if should map the drive number */
movw 6(%bp), %ax
- cmpw $0x8, %ax
- jne 3f
- cmpw $0x15, %ax
- jne 3f
+ cmpb $0x8, %ah
+ je 3f
+ cmpb $0x15, %ah
+ je 3f
/* check if the mapping was performed */
movw 2(%bp), %ax
testw %ax, %ax
--- End Message ---
--- Begin Message ---
Apologies; this wasn't sent as part of the dak rm action. I'm doing
this by hand. Since this was manual, this opens the chance for me taking
action by mistake.
I got the list of bugs via UDD, and am closing via -close on BCC. I spot
checked about 10 of the bugs, and they're all src:grub. The COUNT
matches the tracker page, so I'm sending this.
If I have closed a bug that's not about bin:grub or src:grub, please do
re-open the bug.
paultag
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:
grub | 0.97-84 | source
grub-legacy | 0.97-84 | amd64, i386
------------------- Reason -------------------
ROM; dead upstream, replaced by grub2
----------------------------------------------
Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it). Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors until the next
dinstall run at the earliest.
Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.
We try to close bugs which have been reported against this package
automatically. But please check all old bugs, if they were closed
correctly or should have been re-assigned to another package.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected].
The full log for this bug can be viewed at https://bugs.debian.org/1110934
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Paul Tagliamonte (the ftpmaster behind the curtain)
--- End Message ---
