On Wed, Apr 18, 2007 at 01:48:40PM +0200, Ola Lundqvist wrote: > > Sorry, I don't see how this is possible at all, and no one else has reported > > seeing this problem on upgrade. The slapd package depends on adduser, and > > the current slapd postinst unconditionally calls:
> Can it be so that the old postinst script was used for some strange reason? Only if there were a bug in dpkg; the "point of no return" in an upgrade is immediately after the new version is unpacked and the old version's postrm is called with "upgrade <new-version>" as arguments, so if that failed the conffile should have been rolled back by dpkg and if it succeeded the old maintainer scripts should have been completely removed from the system. > It is the best thing I can consider. Or maybe prerm or preinst? Again, this shouldn't have gone anywhere near a failure to start slapd, because that doesn't happen until the postinst. > > There are no invocations of invoke-rc.d slapd prior to this anywhere in the > > upgrade process, the daemon restart is the last thing done in the postinst; > > and nothing but the init script uses the openldap user/group, which is > > referenced only from /etc/default/slapd. So without a log of the *earliest* > > stages of this upgrade, I don't see that there's any hope of figuring out > > what happened to cause this problem for you. > I see. Too bad that I do not think I have that left. Ok, then I guess this failure is doomed to go unexplained. > > > 3) The upgrade continue, and now the user is created it chowns > > > a number of files and do convert from old data to the new. > > > 4) But the start of slapd do not work well and the upgrade > > > of the package terminates. > > Well, again here we would need to know what didn't "work well". > In this case I have figured out that I needed the -4 option as I do > not have IPv6 support in this virtual server. That is probably the > reason for it. Hmm, ok. That means the kernel doesn't allow an IPv6-style bind in the virtual server, right? I don't see any good way to handle that specifically on upgrade. > > No, I disagree. The slapd maintainer scripts are deliberately very > > conservative with what they do with all user data. Inconveniencing users > > with a requirement to manually fix up the data directory is better (not > > good, but better) than trashing the user's directory by mistake. > Ok. In this case I suggest to improve the log message with an suggestion > on how to proceed. Yah, no disagreement there; no time on my part to look into it currently though. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
