Your message dated Sat, 31 Dec 2016 15:31:59 +0000
with message-id <20161231153159.gt20...@riva.ucam.org>
and subject line Re: Bug#735935: grub2: LVM trouble at boot with several PVs
has caused the Debian Bug report #735935,
regarding grub2: LVM trouble at boot with several PVs
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 ow...@bugs.debian.org
immediately.)
--
735935: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735935
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: grub-pc
Version: 2.02~beta2-3
Hi Colin,
I have the strangest issue which I am not even entirely confident is a
GRUB issue, but it started right after upgrading my system to GRUB 2.02
from experimental, and without other changes, and it's even reproducible
when running my system inside kvm off a thumbdrive, so I'm going to
provisionally blame it on the GRUB 2.02 beta build.
I'm running a pretty standard LVM setup -- there's other stuff on this
hard disk (like the preinstalled Windows), but one of the MS-DOS
partitions is an LVM PV, containing a VG named "leveret", containing two
LVs named "root" and "swap". /boot itself is located on the "root" LV.
Every time I start up, since the upgrade, the initramfs fails to find my
root hard disk via its /dev/disk/by-uuid path, and dumps me to a shell. If
I look inside /dev/mapper, I see a node for "leveret-swap" but not
"leveret-root". `lvm lvs` happily lists both nodes, though, and I can get
my system to boot if I do `lvm vgchange -an`, `lvm vgchange -ay` (at which
point both nodes appear, as well as the by-uuid symlink), and `exit`.
(Resume-from-hibernate even worked after doing this, right after the
upgrade.) There's nothing particularly suspicious-sounding in dmesg at any
point.
The machine is a Toshiba L635 laptop, a few years old, BIOS boot only,
running a somewhat out-of-date Debian testing, amd64. I'm running
linux-image-3.9-1-amd64 3.9.8-1 (from testing this past summer or so) and
lvm2 2.02.95-7. I'm happy to try to upgrade these, but since I haven't
upgraded anything else on the system for a few weeks, I figured I'd report
this and leave the system alone in case you had more questions about the
current setup.
Let me know if you need any more information from me or want me to try
anything. I'm at a bit of a loss how GRUB could have caused this, but I
don't have any other ideas what's going on.
Thanks,
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
--- End Message ---
--- Begin Message ---
On Thu, Apr 14, 2016 at 07:45:36PM -0300, Iván Baldo wrote:
> This bug should be closed, I think it appears as open?
Indeed. It was reopened with a request to fix it in wheezy, but that's
frankly rather unlikely at this point (I didn't notice the reopening at
the time, over two years ago ...), and at any rate shouldn't cause the
bug to appear as open. Re-closing with this message.
Thanks,
--
Colin Watson [cjwat...@debian.org]
--- End Message ---
