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 #511587,
regarding grub: update-grub fails on Xen DomU with no whole block device
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.)
--
511587: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511587
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: grub
Version: 0.97-47lenny1
Severity: important
I have a number of Xen DomUs running Debian Etch. These have been created
using xen-tools, and do not have a whole block device assigned to them.
As an example, I have /dev/sda1 as root and /dev/sda2 as swap, but no
/dev/sda :
lenny-domu:~# ls /dev/sda*
/dev/sda1 /dev/sda2
And the relevant lines from the Xen cfg in the Dom0:
disk = [
'phy:/dev/xenimages/lenny-root,sda1,w',
'phy:/dev/xenimages/lenny-swap,sda2,w',
]
I have the DomUs booting using pygrub, so I install grub and the relevant
linux-image packages. This means I can manage the kernel packages on the
DomU itself, which is particularly useful when the Dom0 is not a Debian
system.
Under Debian Etch, this arrangement works perfectly. However, when I
did an dist-upgrade to Lenny, the kernel-image upgrade breaks :
Unpacking linux-image-2.6.26-1-xen-686 (from
.../linux-image-2.6.26-1-xen-686_2.6.26-12_i386.deb) ...
Setting up linux-image-2.6.26-1-xen-686 (2.6.26-12) ...
update-initramfs: Generating /boot/initrd.img-2.6.26-1-xen-686
Searching for GRUB installation directory ... found: /boot/grub
warning: grub-probe can't find drive for /dev/sda1.
grub-probe: error: Cannot find a GRUB drive for /dev/sda1. Check your
device.map.
And the updated grub file never gets written, leaving the system in an
inconsistent
state. /boot/grub/device.map does exist, but is empty (0 bytes).
In addition, I also have to edit the postrm file to comment out the
update-grub command in order to cleanly remove the package.
I appreciate the disk layout is a little "odd", but this is the
default setup from
xen-tools, and worked fine under Etch. As a test, I copied the
/usr/sbin/update-grub
script from an Etch system (version 0.97-27etch1), and it worked OK.
Please let me know if you need any further information.
-Mark
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-xen-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- 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 ---
