Re: [arch-general] [arch-dev-public] [signoff] device-mapper 1.02.29-1 & lvm2 2.02.43-1
Eric Bélanger wrote:
Hi,
device-mapper 1.02.29-1 and lvm2 2.02.43-1 are now in testing for both arches. It's a minor upstream update. The most important change is: "Starting with LVM2 release 2.02.43, the device-mapper files are now included with the LVM2 releases (in ../lvm2)." I've modified the PKGBUILD accordingly.
Please test and signoff. I would like 2 signoff for i686 because I don't use lvm2 on my i686 system so I could only do minor testing. As I believe few devs use this, signoffs from users are welcomed.
Eric
I'm a user, not a dev, running on i686. I couldn't find a definition of a 'signoff', but I updated abs, built the 2 new packages, they compiled fine, i installed them, rebooted my system and everything came up fine (dm_crypt+lvm based system). I also tested the basic commands (pvdisplay,lvdisplay) and even did an lvextend and resize2fs on a volume. everything still works fine. (didn't try making new/deleting LV/PV's etc though) Does this count as a "signoff" ? PS: Users cannot send to arch-dev-public@archlinux.org, so fwiw I cc'd arch-general. Dieter
Dieter Plaetinck schrieb:
I'm a user, not a dev, running on i686. I couldn't find a definition of a 'signoff', but I updated abs, built the 2 new packages, they compiled fine, i installed them, rebooted my system and everything came up fine (dm_crypt+lvm based system). I also tested the basic commands (pvdisplay,lvdisplay) and even did an lvextend and resize2fs on a volume. everything still works fine. (didn't try making new/deleting LV/PV's etc though) Does this count as a "signoff" ?
The point of the signoff is not that you can build the package, but that the package provided in the repositories is working. If you can build the package, you still won't know if (for example) one of the executables inside the binary package is corrupted. Other than that, your tests are sufficient.
PS: Users cannot send to arch-dev-public@archlinux.org, so fwiw I cc'd arch-general.
Indeed they can't, you can always reply on arch-general if you feel the need to comment on a developer discussion.
Thomas Bächler wrote:
Dieter Plaetinck schrieb:
I'm a user, not a dev, running on i686. I couldn't find a definition of a 'signoff', but I updated abs, built the 2 new packages, they compiled fine, i installed them, rebooted my system and everything came up fine (dm_crypt+lvm based system). I also tested the basic commands (pvdisplay,lvdisplay) and even did an lvextend and resize2fs on a volume. everything still works fine. (didn't try making new/deleting LV/PV's etc though) Does this count as a "signoff" ?
The point of the signoff is not that you can build the package, but that the package provided in the repositories is working. If you can build the package, you still won't know if (for example) one of the executables inside the binary package is corrupted. Other than that, your tests are sufficient.
PS: Users cannot send to arch-dev-public@archlinux.org, so fwiw I cc'd arch-general.
Indeed they can't, you can always reply on arch-general if you feel the need to comment on a developer discussion.
I believe that all answers to this question have been given so hopefully you don't mind if I hijack this thread... Since we're in the middle of discussing LVM, I've got a request. Not too long ago, I had my root partition "/" on an LVM physical volume. It was actually pretty easy to set up and worked like a charm until I created a snapshot of one of my other PVs. As soon as I did so, I could no longer boot the system because the dm_snapshot kernel module was not loaded. I was told by several people that I needed to add a "hook" for it, but never did figure out how to do so. It seems to me that if we are going to support booting from logical volumes, we also need to make sure that users who do so are still able to boot if they decide to take a snapshot of any logical volumes, including booting from a snapshot of "/". I'll be glad to help test and even work on the hook if anyone gives me instructions detailing how to do so. Thanks! -Tim
Tim Gelter wrote:
Thomas Bächler wrote:
I'm a user, not a dev, running on i686. I couldn't find a definition of a 'signoff', but I updated abs, built the 2 new packages, they compiled fine, i installed them, rebooted my system and everything came up fine (dm_crypt+lvm based system). I also tested the basic commands (pvdisplay,lvdisplay) and even did an lvextend and resize2fs on a volume. everything still works fine. (didn't try making new/deleting LV/PV's etc though) Does this count as a "signoff" ? The point of the signoff is not that you can build the package, but that
Dieter Plaetinck schrieb: the package provided in the repositories is working. If you can build the package, you still won't know if (for example) one of the executables inside the binary package is corrupted. Other than that, your tests are sufficient.
PS: Users cannot send to arch-dev-public@archlinux.org, so fwiw I cc'd arch-general. Indeed they can't, you can always reply on arch-general if you feel the need to comment on a developer discussion.
I believe that all answers to this question have been given so hopefully you don't mind if I hijack this thread...
Since we're in the middle of discussing LVM, I've got a request. Not too long ago, I had my root partition "/" on an LVM physical volume. It was actually pretty easy to set up and worked like a charm until I created a snapshot of one of my other PVs. As soon as I did so, I could no longer boot the system because the dm_snapshot kernel module was not loaded. I was told by several people that I needed to add a "hook" for it, but never did figure out how to do so. It seems to me that if we are going to support booting from logical volumes, we also need to make sure that users who do so are still able to boot if they decide to take a snapshot of any logical volumes, including booting from a snapshot of "/". I'll be glad to help test and even work on the hook if anyone gives me instructions detailing how to do so. Thanks! -Tim
Put dm_snapshot in the MODULES array in /etc/mkinitcpio.conf and then rebuild the initial ramdisk using mkinitcpio -p kernel26 (assuming you are using the kernel26 package from core). Glenn
Tim Gelter wrote:
Thomas Bächler wrote:
I'm a user, not a dev, running on i686. I couldn't find a definition of a 'signoff', but I updated abs, built the 2 new packages, they compiled fine, i installed them, rebooted my system and everything came up fine (dm_crypt+lvm based system). I also tested the basic commands (pvdisplay,lvdisplay) and even did an lvextend and resize2fs on a volume. everything still works fine. (didn't try making new/deleting LV/PV's etc though) Does this count as a "signoff" ? The point of the signoff is not that you can build the package, but that
Dieter Plaetinck schrieb: the package provided in the repositories is working. If you can build the package, you still won't know if (for example) one of the executables inside the binary package is corrupted. Other than that, your tests are sufficient.
PS: Users cannot send to arch-dev-public@archlinux.org, so fwiw I cc'd arch-general. Indeed they can't, you can always reply on arch-general if you feel the need to comment on a developer discussion.
I believe that all answers to this question have been given so hopefully you don't mind if I hijack this thread...
Since we're in the middle of discussing LVM, I've got a request. Not too long ago, I had my root partition "/" on an LVM physical volume. It was actually pretty easy to set up and worked like a charm until I created a snapshot of one of my other PVs. As soon as I did so, I could no longer boot the system because the dm_snapshot kernel module was not loaded. I was told by several people that I needed to add a "hook" for it, but never did figure out how to do so. It seems to me that if we are going to support booting from logical volumes, we also need to make sure that users who do so are still able to boot if they decide to take a snapshot of any logical volumes, including booting from a snapshot of "/". I'll be glad to help test and even work on the hook if anyone gives me instructions detailing how to do so. Thanks! -Tim
Put dm_snapshot in the MODULES array in /etc/mkinitcpio.conf and then rebuild the initial ramdisk using mkinitcpio -p kernel26 (assuming you are using the kernel26 package from core).
Glenn Thanks for the recommendation Glenn. If I remember correctly, I did exactly as you suggest but it didn't solve the issue. I think it was a matter of loading the driver at the correct time during the boot sequence and that was the reason for the HOOK. I actually was given some vague instructions about what I needed to do from a dev in #archlinux but never got around to doing it because I got busy with work and home
RedShift wrote: life. I currently don't have the setup to verify what needs to be done which is why I posted to the list. I may of course be mistaken and won't be upset by any corrections I receive. :) Thanks again. -Tim
participants (4)
-
Dieter Plaetinck
-
RedShift
-
Thomas Bächler
-
Tim Gelter