Bug#771092: libuuid1: moreinfo
Hello Ivo De Decker! On Thu, Dec 11, 2014 at 09:12:44PM +0100, Ivo De Decker wrote: Hi, On Tue, Dec 09, 2014 at 11:55:25AM +0100, Andreas Henriksson wrote: I have absolutely no idea how the buildds work, but I imagine it's overall somewhat similar to how pbuilder handles chroots. ie. throw away chroots for builds, a pristine chroot as a base. On IRC, Ansgar noted that the buildds copy the host passwd/group into the chroot, which explains why it failed on a version that should have been fixed before. Thanks for the confirmation! This should then go away as soon as the host is updated to Jessie, so I should be able to ignore it... Will try to follow up with an upload ASAP with the 2 rc bug fixes and the l10n updates. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771092: libuuid1: moreinfo
Hi, On Tue, Dec 09, 2014 at 11:55:25AM +0100, Andreas Henriksson wrote: I have absolutely no idea how the buildds work, but I imagine it's overall somewhat similar to how pbuilder handles chroots. ie. throw away chroots for builds, a pristine chroot as a base. On IRC, Ansgar noted that the buildds copy the host passwd/group into the chroot, which explains why it failed on a version that should have been fixed before. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771092: libuuid1: moreinfo
Hello again Niels! On Tue, Dec 09, 2014 at 06:32:18AM +0100, Niels Thykier wrote: [...] The buildd chroot upgrade seems to run the migration code and then somehow throw away all the resulting user/group modifications, so that on next package upgrade the migration runs again (and again, ...). This seems like plausible explanation given we tend to use throw-away chroots or lvm-snapshots. So if this problem only appears on buildds (or in other throw-ways environments), I guess you are just missing a Depends after all. We can have the buildds upgraded post Jessie, before you remove the migration code. I cannot recommend it now, as gcc has a new version in unstable that could cause issues for other packages (that could pick up a dependency on the newer gcc). [...] I have absolutely no idea how the buildds work, but I imagine it's overall somewhat similar to how pbuilder handles chroots. ie. throw away chroots for builds, a pristine chroot as a base. With pbuilder you simply pbuilder --update to update the pristine chroot without throwing away the changes. This second part is not working correctly on the buildds, as they keep the upgraded package but throws away the usermod/groupmod changes done in the maintainer scripts. This means the throwaway chroot comes with a pre-installed version of src:util-linux packages which should have already done the migration of the user, but hasn't Are you saying that the buildds somehow copies the user/group database from the host (which is not yet running jessie?)? That would be weird I could add a pre-condition check in postinst to detect if we are upgrading *from* a version which should already have migrated but somehow haven't and bail out. I guess that would be an effective way to halt all buildds and I bet the release team wouldn't appreciate that right now... On the other hand I bet it would be an effective way of getting attention and feedback on the issue. :P Not sure how to proceed from here. Do we even know if this issue is isolated to only the Debian buildds? If so, I guess we could argue that the chroots provided are corrupt and buildd admins gets to fix up the mess when we open up Stretch. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771092: libuuid1: moreinfo
Hello Niels Thykier. Thanks for following up on this bug report... On Mon, Dec 08, 2014 at 08:36:36AM +0100, Niels Thykier wrote: On Thu, 27 Nov 2014 12:32:08 +0100 Andreas Henriksson andr...@fatal.se wrote: Control: tags 771092 + moreinfo Just adding the passwd dependency would hide the real problem here. Someone needs to look into why the migration code is being run again and again (as it apparently does on a sparc buildd atleast)! This code is going to be dropped in Jessie+1 where it's expected that everyone has migrated. If there are cases where migration isn't working we need to fix those now. Regards, Andreas Henriksson Hi, The postinst looks like (modulo wrapping): # upgrade existing libuuid user/group. if getent group libuuid /dev/null ! getent group uuidd /dev/null ; then groupmod --new-name uuidd libuuid fi if getent passwd libuuid /dev/null ! getent passwd uuidd /dev/null ; then [...] fi In both cases, the condition for the ifs seems to be false. In the failing build logs the condition is true and it explodes because of groupmod not yet existing, so your issue seems unrelated to what I'm looking for information on. The buildd chroot upgrade seems to run the migration code and then somehow throw away all the resulting user/group modifications, so that on next package upgrade the migration runs again (and again, ...). But: $ getent group libuuid /dev/null echo group libuuid present; \ getent group uuidd /dev/null echo group uuidd present group uuidd present $ getent group libuuid /dev/null ! getent group uuidd /dev/null $ getent passwd libuuid /dev/null ; echo User libuuid present ; \ getent passwd uuidd /dev/null echo User uuidd present User libuuid present User uuidd present $ getent passwd libuuid /dev/null ! getent passwd uuidd \ /dev/null echo true I only have /group/ uuidd, but I have both users present!? I'm not sure how that happened, but it is only a minor issue. The migration code checks that both the old user/group exists and new user/group not exists, so if both exists it's not a problem. Ofcourse it's not nice to leave old cruft around... I'd suggest we track this in a separate bug report. Please follow up on how both users looks. Does anything else then name and uid set them apart? If you remove the new username and reinstall the package does the user get migrated? My guess would be that the group got migrated on upgrade, then you already had a user with the new username so no user migration was done (and you where thus left with both the old and new usernames in place). Inside the user migration, there is a remark that usermod will fail if the process is running. Does that hold for groupmod as well? This remark comes from ubuntu users running into that problem. If the same where true for groupmod, the (launchpad) bug report for it would probably have said groupmod instead of usermod as groupmod is run first. So my guess is no. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771092: libuuid1: moreinfo
On 2014-12-08 15:27, Andreas Henriksson wrote: Hello Niels Thykier. Thanks for following up on this bug report... On Mon, Dec 08, 2014 at 08:36:36AM +0100, Niels Thykier wrote: [...] In both cases, the condition for the ifs seems to be false. In the failing build logs the condition is true and it explodes because of groupmod not yet existing, so your issue seems unrelated to what I'm looking for information on. Fair enough. I was trying to make the case that the script not indempotent in its clean up and it may have caused the issue. But certainly, I see your point. The buildd chroot upgrade seems to run the migration code and then somehow throw away all the resulting user/group modifications, so that on next package upgrade the migration runs again (and again, ...). This seems like plausible explanation given we tend to use throw-away chroots or lvm-snapshots. So if this problem only appears on buildds (or in other throw-ways environments), I guess you are just missing a Depends after all. We can have the buildds upgraded post Jessie, before you remove the migration code. I cannot recommend it now, as gcc has a new version in unstable that could cause issues for other packages (that could pick up a dependency on the newer gcc). But: $ getent group libuuid /dev/null echo group libuuid present; \ getent group uuidd /dev/null echo group uuidd present group uuidd present $ getent group libuuid /dev/null ! getent group uuidd /dev/null $ getent passwd libuuid /dev/null ; echo User libuuid present ; \ getent passwd uuidd /dev/null echo User uuidd present User libuuid present User uuidd present $ getent passwd libuuid /dev/null ! getent passwd uuidd \ /dev/null echo true I only have /group/ uuidd, but I have both users present!? I'm not sure how that happened, but it is only a minor issue. The migration code checks that both the old user/group exists and new user/group not exists, so if both exists it's not a problem. Ofcourse it's not nice to leave old cruft around... [...] Okay, thanks for clarifying. Given you believe it is only a minor cruft issue, it is not a priority for me for Jessie (unless it is last call for getting it fixed). :) I am certainly ready to look into this for Stretch (or, Jessie, if needed). Inside the user migration, there is a remark that usermod will fail if the process is running. Does that hold for groupmod as well? This remark comes from ubuntu users running into that problem. If the same where true for groupmod, the (launchpad) bug report for it would probably have said groupmod instead of usermod as groupmod is run first. So my guess is no. Regards, Andreas Henriksson Ack, thanks. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771092: libuuid1: moreinfo
On Thu, 27 Nov 2014 12:32:08 +0100 Andreas Henriksson andr...@fatal.se wrote: Control: tags 771092 + moreinfo Just adding the passwd dependency would hide the real problem here. Someone needs to look into why the migration code is being run again and again (as it apparently does on a sparc buildd atleast)! This code is going to be dropped in Jessie+1 where it's expected that everyone has migrated. If there are cases where migration isn't working we need to fix those now. Regards, Andreas Henriksson Hi, The postinst looks like (modulo wrapping): # upgrade existing libuuid user/group. if getent group libuuid /dev/null ! getent group uuidd /dev/null ; then groupmod --new-name uuidd libuuid fi if getent passwd libuuid /dev/null ! getent passwd uuidd /dev/null ; then [...] fi In both cases, the condition for the ifs seems to be false. But: $ getent group libuuid /dev/null echo group libuuid present; \ getent group uuidd /dev/null echo group uuidd present group uuidd present $ getent group libuuid /dev/null ! getent group uuidd /dev/null $ getent passwd libuuid /dev/null ; echo User libuuid present ; \ getent passwd uuidd /dev/null echo User uuidd present User libuuid present User uuidd present $ getent passwd libuuid /dev/null ! getent passwd uuidd \ /dev/null echo true I only have /group/ uuidd, but I have both users present!? Inside the user migration, there is a remark that usermod will fail if the process is running. Does that hold for groupmod as well? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771092: libuuid1: moreinfo
Control: tags 771092 + moreinfo Just adding the passwd dependency would hide the real problem here. Someone needs to look into why the migration code is being run again and again (as it apparently does on a sparc buildd atleast)! This code is going to be dropped in Jessie+1 where it's expected that everyone has migrated. If there are cases where migration isn't working we need to fix those now. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
