Bug#782264: grub-install fails in nested LVM
Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
LVM"):
> Thanks for your anwser. I understand.
Thanks.
> And I intend to become a contributor (currently working on it).
Thanks, and good luck.
There are of course many ways to be a contributor to Debian that don't
involve formally joining the project and gaining some kind of approved
status. We have a lot of bugs that could do with investigation and
perhaps need patches writing and testing, for example :-).
Regards,
Ian.
Bug#782264: grub-install fails in nested LVM
Le jeudi 24 mars 2016 à 00:23:40+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
> LVM"):
> > Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > > You do not even have a right to a reply from a human.
> >
> > I'm not sure to agree with that.
>
> There are too many bugs and too few humans to deal with them. We are
> not able to reply to every bug. At least, if we prioritised writing a
> reply (even if only a vacuous one) to every bug, there would be other
> more important work that would go undone.
>
> If you'd like to make a human connection with the project, it is best
> if you do that as a contributor. Debian has many millions of users,
> and we can't make a personal connection with each one.
Thanks for your anwser. I understand.
And I intend to become a contributor (currently working on it).
Cheers,
--
PEB
Bug#782264: grub-install fails in nested LVM
Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
LVM"):
> Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > You do not even have a right to a reply from a human.
>
> I'm not sure to agree with that.
There are too many bugs and too few humans to deal with them. We are
not able to reply to every bug. At least, if we prioritised writing a
reply (even if only a vacuous one) to every bug, there would be other
more important work that would go undone.
If you'd like to make a human connection with the project, it is best
if you do that as a contributor. Debian has many millions of users,
and we can't make a personal connection with each one.
Thanks,
Ian.
Bug#782264: grub-install fails in nested LVM
Hey,
First, I'd like to apologize for the way I asked for a fix or any solution
in that issue. I realize that it was inappropriate.
Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
> LVM"):
> > Anyway, I was more concerned by the non-ack of my report.
>
> You received an ack of your report from the bug tracking system.
>
> But it seems that you are concerned that this bug is not getting
> enough human attention. That is quite possibly true. Debian as a
> whole has too much work to do with too few people. Maintainers have
> to choose which packages and which bug reports are going to receive
> their attention.
That's true, but I got used to see at least a human ack on bug reports, that
does not imply any commitment to solve the issue, but that is a way to say
that not only an automatized system received the report.
Maybe I should not get used to that human interaction, but I beleive that it
is exactly what makes a community, and that's what I thought I saw in the
social contract.
> Maintainers will try to work on those tasks which they think will give
> the biggest gain for the lowest effort. Or - as volunteers - which
> they think are most fun.
That's fair.
> To try to escalate the priority of a bug you are interested in, by
> sending content-free pings, is rude. Debian contributors should
> ignore a submitter who behaves in that way.
My apologies if that's what I made anybody think. My point was not to
escalate the priority of this bug but really to see a human being at the
other end.
> As a user, or a bug submitter, you do not have a right to a fix.
That's true, and I clearly shouldn't have been that though in my second and
third mail for this bug. Again, I'd like to apologize.
> You do not even have a right to a reply from a human.
I'm not sure to agree with that.
As far as I understood, -- and let me be clear, I *know* that I know less
about Debian than you do --, Debian, by its social contract, intends, as a
community, to focus on users needs and on the fact that nothing is made to
be hidden. In my opinion, there is no community if there is no human
interaction.
As someone becomes maintainer of a package, I'm keen on beleiving that he
chose to, and that he agrees to provide user support regarding the package
(not the software). In a public project, that relies on a community concept,
it appears to me as a very bad move to say "the automatized response is
enough", or to say "I do not have to make user support".
I have no right, but I beleive that there is commitment from a maintainer to
provide support (not fixes, just say that I'm not speaking in the wind). If
I'm wrong, -- and I guess that's your point --, then I'm sorry that I
misbeleived about Debian concept and philosophy.
> If you are dissatisfied with the progress of the work to investigate
> and fix a bug, then the Debian maintainainers will generally welcome
> your constructive help. In this case that probably means: Feel Free
> To (Investigate And) Submit A Patch.
>
> If neither you nor your friends have the skills to work on the bug
> yourselves, and you would like to ensure you have a right to a reply
> to your emails and bug reports, I suggest you employ someone (an
> individual or a company), on a commercial basis, to provide you with
> the support you require.
I'm not dissatisfied with the progress of the work, I was dissatisfied with
the silence around my report, which seemed like "burying" the issue.
As you can see, I made a lot of investigations, especially to make sure that
the bug was really in the Debian package, but I did not succeed in finding
the exact issue, since I'm not able to reproduce the same behaviour with
bare grub2 software. I guess the issue is hidden in Debian patches, but I've
no proof of that, and not enough skills in that part of packaging to
bissect.
That was in my opinion a good move to ask someone who knows for some help.
The support could have been a simple ack, but at least, I'd have reached a
human.
Anyway, sorry, I shouldn't have been aggressive. I'll try again to find the
exact issue when I'll have some time to.
Cheers,
--
PEB
Bug#782264: grub-install fails in nested LVM
Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
LVM"):
> Anyway, I was more concerned by the non-ack of my report.
You received an ack of your report from the bug tracking system.
But it seems that you are concerned that this bug is not getting
enough human attention. That is quite possibly true. Debian as a
whole has too much work to do with too few people. Maintainers have
to choose which packages and which bug reports are going to receive
their attention.
Maintainers will try to work on those tasks which they think will give
the biggest gain for the lowest effort. Or - as volunteers - which
they think are most fun.
To try to escalate the priority of a bug you are interested in, by
sending content-free pings, is rude. Debian contributors should
ignore a submitter who behaves in that way.
As a user, or a bug submitter, you do not have a right to a fix. You
do not even have a right to a reply from a human.
If you are dissatisfied with the progress of the work to investigate
and fix a bug, then the Debian maintainainers will generally welcome
your constructive help. In this case that probably means: Feel Free
To (Investigate And) Submit A Patch.
If neither you nor your friends have the skills to work on the bug
yourselves, and you would like to ensure you have a right to a reply
to your emails and bug reports, I suggest you employ someone (an
individual or a company), on a commercial basis, to provide you with
the support you require.
Thanks,
Ian.
Bug#782264: grub-install fails in nested LVM
Le mercredi 27 janvier 2016 à 18:13:29+, Martin Read a écrit : > On 26/01/16 15:52, Pierre-Elliott Bécue wrote: > >Bump. > > > >It's been more than 10 months and still nothing (even a simple ack). > > > >Could you consider adding a stable version of grub in a partial release of > >Jessie? > > A cursory inspection of the public browsing interface[1] to the relevant git > repo makes it clear that there is no newer *version*, despite 2.02 beta 2 > being two years old and there having been significant numbers of git commits > since then. > > [1] http://git.savannah.gnu.org/cgit/grub.git/ Right, 2.02 beta 3 is out now, maybe it's worth a try. Anyway, I was more concerned by the non-ack of my report. Cheers, -- PEB
Bug#782264: grub-install fails in nested LVM
On 26/01/16 15:52, Pierre-Elliott Bécue wrote: Bump. It's been more than 10 months and still nothing (even a simple ack). Could you consider adding a stable version of grub in a partial release of Jessie? A cursory inspection of the public browsing interface[1] to the relevant git repo makes it clear that there is no newer *version*, despite 2.02 beta 2 being two years old and there having been significant numbers of git commits since then. [1] http://git.savannah.gnu.org/cgit/grub.git/
Bug#782264: grub-install fails in nested LVM
Le 9 avril 2015 18:05:50 GMT+02:00, "Pierre-Elliott Bécue" a écrit : >Source: grub >Version: 2.02~beta2-22 >Severity: important > >Dear maintainer, > >I've met a bug in GRUB under a Proxmox environment, which I was able to >reproduce under a clean Debian system (my laptop, under jessie). > >With Proxmox, I needed to build a nested LVM storage for my VM, that >is, >in the host point of view : > >/dev/sdxx (physical) -> first volumegroup (vg1) -> A single logical >volume (lv1) >(the guest physical disk) -> a single partition (lv1p1) -> a second >volumegroup (vg2) >-> logical volumes containing guest data. (slash, var, swap) > >For the guest, the single logical volume (lv1) is seen as the physical >disk of the VM, named /dev/vda when the VM is started. > >Under wheezy, I was able to debootstrap wheezy on the disks, and to >chroot in them to make a grub-install on lv1. > >Under jessie, I get an error : >grub-install: error: disk >`lvmid/[VOLUMEGROUPID]/[LOGICALVOLUMEID]' >not found. > >I first thought it was a bug due to Proxmox VE. So I tried to build a >proof of concept on my Jessie laptop, using an external drive. The >problem is the same. > >I tried to git clone the grub repo and to compile it to try a >grub-install, and this one worked. So it seems that grub 2.02~beta2-22 >is broken. > >I'm not able to say if it comes from Debian patches or from the actual >upstream code, but it seems this problem is important enough to be >noticed. > >I'll be happy to provide you with more data if I can. > >Cheers, Bump. It's been more than 10 months and still nothing (even a simple ack). Could you consider adding a stable version of grub in a partial release of Jessie? Thanks. -- PEB
Bug#782264: grub-install fails in nested LVM
Le jeudi 09 avril 2015 à 18:05:50+0200, Pierre-Elliott Bécue a écrit : > Source: grub > Version: 2.02~beta2-22 > Severity: important > > Dear maintainer, > [bug in grub, with grub-install] Good evening, It has been almost seven month since this bug report. The fact that no update of grub has been done in a partial release of Jessie seems pretty bad to me. But furthermore, I'm really disappointed that no maintainer took any time to send me at least an ACK. Is there any plan for fixing this bug, and putting in jessie an non-beta version of GRUB? Thanks, and sorry if I seem rude, but this bug prevents me from upgrading part of my machines, and also made grub-install not properly usable on some already upgraded ones. Cheers. -- PEB
Bug#782264: grub-install fails in nested LVM
Hi,
I think this bug can be genericized to grub-install and update-grub no
longer working inside chroot with a LVM backing device. Actual nested LVM
isn't necessary to reproduce the problem.
You used to be able to give it a device node -- pointing to the LV -- and it
would grub-install or update-grub on that. So just copy the two
/dev/foo{,-p1} files into the chroot's /dev and you're done.
Now it seems to take that node you have it on the command-line and try to
canonicalize it, which fails.
When you do it without nested /proc, you get this:
% sudo chroot /mnt/ubuntu14-build grub-install --modules=part_msdos
/dev/new-root
Installing for i386-pc platform.
/proc/devices: fopen failed: No such file or directory
/proc/devices: fopen failed: No such file or directory
/proc/devices: fopen failed: No such file or directory
/proc/devices: fopen failed: No such file or directory
/proc/devices: fopen failed: No such file or directory
device node not found
Installation finished. No error reported.
This actually manages to stuff GRUB into the MBR, but there's no
/boot/grub/grub.cfg to actually boot; when you run update-grub, it fails
just like when you try grub-install with nested /proc:
% sudo chroot /mnt/ubuntu14-build mount none -t proc /proc
% sudo chroot /mnt/ubuntu14-build grub-install --modules=part_msdos
/dev/new-root
Installing for i386-pc platform.
grub-install: error: failed to get canonical path of
`/dev/mapper/vgayrabtu-ubuntu14--build--root-p1'.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782264: grub-install fails in nested LVM
Source: grub
Version: 2.02~beta2-22
Severity: important
Dear maintainer,
I've met a bug in GRUB under a Proxmox environment, which I was able to
reproduce under a clean Debian system (my laptop, under jessie).
With Proxmox, I needed to build a nested LVM storage for my VM, that is,
in the host point of view :
/dev/sdxx (physical) -> first volumegroup (vg1) -> A single logical volume (lv1)
(the guest physical disk) -> a single partition (lv1p1) -> a second volumegroup
(vg2)
-> logical volumes containing guest data. (slash, var, swap)
For the guest, the single logical volume (lv1) is seen as the physical
disk of the VM, named /dev/vda when the VM is started.
Under wheezy, I was able to debootstrap wheezy on the disks, and to
chroot in them to make a grub-install on lv1.
Under jessie, I get an error :
grub-install: error: disk
`lvmid/[VOLUMEGROUPID]/[LOGICALVOLUMEID]'
not found.
I first thought it was a bug due to Proxmox VE. So I tried to build a
proof of concept on my Jessie laptop, using an external drive. The
problem is the same.
I tried to git clone the grub repo and to compile it to try a
grub-install, and this one worked. So it seems that grub 2.02~beta2-22
is broken.
I'm not able to say if it comes from Debian patches or from the actual
upstream code, but it seems this problem is important enough to be
noticed.
I'll be happy to provide you with more data if I can.
Cheers,
--
PEB
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- Here is the logs of what I did. This is a verbatim print of my command line,
with non relevant intel removed.
─( 15:59:22 )─< /
>─[
0 ]─
root@nauhp # vgcreate testvg /dev/sdb
Physical volume "/dev/sdb" successfully created
Volume group "testvg" successfully created
─( 15:59:27 )─< /
>─[
0 ]─
root@nauhp # lvcreate -n testlv -l 100%FREE testvg
Logical volume "testlv" created
─( 15:59:45 )─< /
>─[
0 ]─
root@nauhp # lvscan
ACTIVE'/dev/testvg/testlv' [14,41 GiB] inherit
[IRRELEVANT LINE FILTERED]
[IRRELEVANT LINE FILTERED]
[IRRELEVANT LINE FILTERED]
─( 15:59:56 )─< /
>─[
0 ]─
root@nauhp # fdisk /dev/testvg/testlv
Bienvenue dans fdisk (util-linux 2.25.2).
Les modifications resteront en mémoire jusqu'à écriture.
Soyez prudent avant d'utiliser la commande d'écriture.
Le périphérique ne contient pas de table de partitions reconnue.
Created a new DOS disklabel with disk identifier 0xb6653e34.
Commande (m pour l'aide) : p
Disque /dev/testvg/testlv : 14,4 GiB, 15476981760 octets, 30228480 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xb6653e34
Commande (m pour l'aide) : n
Type de partition
p primaire (0 primaire, 0 étendue, 4 libre)
e étendue (conteneur pour partitions logiques)
Sélectionnez (p par défaut) :
Utilisation de la réponse p par défaut.
Numéro de partition (1-4, 1 par défaut) :
Premier secteur (2048-30228479, 2048 par défaut) :
Dernier secteur, +secteurs ou +taille{K,M,G,T,P} (2048-30228479, 30228479 par
défaut) :
Une nouvelle partition 1 de type « Linux » et de taille 14,4 GiB a été créée.
Commande (m pour l'aide) : w
La table de partitions a été altérée.
Appel d'ioctl() pour relire la table de partitions.
Échec de relecture de la table de partitions.: Argument invalide
Le noyau continue à utiliser l'ancienne table. La nouvelle sera utilisée lors
du prochain démarrage ou après avoir exécuté partprobe(8) ou kpartx(8).
─( 16:00:25 )─< /
>─[
0 ]─
root@nauhp # kpartx -av /dev/testvg/testlv
add map testvg-testlv1 (254:5): 0 30226432 linear /dev/testvg/testlv 2048
─( 16:00:34 )─< /
>─[
0 ]─
root@nauhp # ls -al /dev/mapper
total 0
drwxr-xr-x
