right - _finally_ i've encountered a requirement to upgrade a 2nd
system that has lvm2 and (in this 2nd case 2.6.18-486) a linux kernel
image, and have encountered the *exact* same problem as is in bugs
636123 and 638896. this time, however, i was anticipating that
something might go wrong, so was watching out for it.

the error that is causing the problem is when the linux kernel has
been installed, but then when lvm is upgraded from lvm1 to lvm2.
lvm-common is *removed*, including removing /sbin/vgchange, but that's
not all.

here's what happens when the postinst mkinitramfs is called:

mkdir: cannot create directory /tmp/mkinitramfs_tF5045/lib/udev: File exists
cpio: ./sbin/vgchange: No such file or directory

now, in this particular test case, the postinst mkinitramfs appears to
have been triggered twice, so the file /boot/initrd-2.6.32-5-686
exists and is not of zero size.

in the case of the system(s) under bugs 636123 and 638896, the initrd
file wasn't created - at all.

this definitely warrants further investigation.

l.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPweEDzBcz9ipGPhU_t=AT+Rc1rV4khNHrX-FaxTCJ=yhiW9iA@mail.gmail.com">http://lists.debian.org/CAPweEDzBcz9ipGPhU_t=AT+Rc1rV4khNHrX-FaxTCJ=yhiW9iA@mail.gmail.com

right - _finally_ i've encountered a requirement to upgrade a 2nd
system that has lvm2 and (in this 2nd case 2.6.18-486) a linux kernel
image, and have encountered the *exact* same problem as is in bugs
636123 and 638896. this time, however, i was anticipating that
something might go wrong, so was watching out for it.

the error that is causing the problem is when the linux kernel has
been installed, but then when lvm is upgraded from lvm1 to lvm2.
lvm-common is *removed*, including removing /sbin/vgchange, but that's
not all.

here's what happens when the postinst mkinitramfs is called:

mkdir: cannot create directory /tmp/mkinitramfs_tF5045/lib/udev: File exists
cpio: ./sbin/vgchange: No such file or directory

now, in this particular test case, the postinst mkinitramfs appears to
have been triggered twice, so the file /boot/initrd-2.6.32-5-686
exists and is not of zero size.

in the case of the system(s) under bugs 636123 and 638896, the initrd
file wasn't created - at all.

this definitely warrants further investigation.

l.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPweEDzBcz9ipGPhU_t=AT+Rc1rV4khNHrX-FaxTCJ=yhiW9iA@mail.gmail.com">http://lists.debian.org/CAPweEDzBcz9ipGPhU_t=AT+Rc1rV4khNHrX-FaxTCJ=yhiW9iA@mail.gmail.com

On Wed, 2011-10-05 at 04:44 +0100, Luke Kenneth Casson Leighton wrote:
> right - _finally_ i've encountered a requirement to upgrade a 2nd
> system that has lvm2 and (in this 2nd case 2.6.18-486) a linux kernel
> image, and have encountered the *exact* same problem as is in bugs
> 636123 and 638896. this time, however, i was anticipating that
> something might go wrong, so was watching out for it.

It is documented that you should completely upgrade from one stable
release to the next, before upgrading further:
<http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.en.html#system-status>, <http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#system-status>.

We do not attempt to support or test upgrades that skip a stable
release; if they work at all then consider yourself lucky.

> the error that is causing the problem is when the linux kernel has
> been installed, but then when lvm is upgraded from lvm1 to lvm2.
> lvm-common is *removed*, including removing /sbin/vgchange, but that's
> not all.

Expected because lvm2 conflicts with lvm-common.

> here's what happens when the postinst mkinitramfs is called:
>
> mkdir: cannot create directory /tmp/mkinitramfs_tF5045/lib/udev: File exists
> cpio: ./sbin/vgchange: No such file or directory
>
> now, in this particular test case, the postinst mkinitramfs appears to
> have been triggered twice, so the file /boot/initrd-2.6.32-5-686
> exists and is not of zero size.
>
> in the case of the system(s) under bugs 636123 and 638896, the initrd
> file wasn't created - at all.

So it's not the exact same problem, is it?

> this definitely warrants further investigation.

Can you try to reproduce this in an etch-lenny-squeeze upgrade?

Ben.

--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.

On Wed, 2011-10-05 at 04:44 +0100, Luke Kenneth Casson Leighton wrote:
> right - _finally_ i've encountered a requirement to upgrade a 2nd
> system that has lvm2 and (in this 2nd case 2.6.18-486) a linux kernel
> image, and have encountered the *exact* same problem as is in bugs
> 636123 and 638896. this time, however, i was anticipating that
> something might go wrong, so was watching out for it.

It is documented that you should completely upgrade from one stable
release to the next, before upgrading further:
<http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.en.html#system-status>, <http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#system-status>.

We do not attempt to support or test upgrades that skip a stable
release; if they work at all then consider yourself lucky.

> the error that is causing the problem is when the linux kernel has
> been installed, but then when lvm is upgraded from lvm1 to lvm2.
> lvm-common is *removed*, including removing /sbin/vgchange, but that's
> not all.

Expected because lvm2 conflicts with lvm-common.

> here's what happens when the postinst mkinitramfs is called:
>
> mkdir: cannot create directory /tmp/mkinitramfs_tF5045/lib/udev: File exists
> cpio: ./sbin/vgchange: No such file or directory
>
> now, in this particular test case, the postinst mkinitramfs appears to
> have been triggered twice, so the file /boot/initrd-2.6.32-5-686
> exists and is not of zero size.
>
> in the case of the system(s) under bugs 636123 and 638896, the initrd
> file wasn't created - at all.

So it's not the exact same problem, is it?

> this definitely warrants further investigation.

Can you try to reproduce this in an etch-lenny-squeeze upgrade?

Ben.

--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.