upgrading to 4.0.23-1 from some of the 4.0.22 version removed my /var/lib/mysql symlink to /usr/mysql. This was stated in the changelog that this shouldn't be the case but it sure did, causing the last major headache for me in 2004.
Hello The fix starts to work after installing 4.0.23 so you should be safe at the next upgrade. bye,
reopen 287978 ! severity 287978 grave thanks Hi, this bug means that on upgrading from woody to sarge, a symlinked database is lost, according to: | The fix starts to work after installing 4.0.23 so you should be safe at the | next upgrade. and madison reports mysql-server | 3.23.49-8.11 | stable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Is my understanding of the situation right? In that case, I consider this bug to be release critical, as it will hit our users on upgrade from woody to sarge. Cheers, Andi
I just upgraded from v3.23.49 to v4.0.24 only to find that I had apparently lost all my databases. Checking /var/lib/mysql revealed that it only contained the mysql and test DBs. After a short panic attack I located the original DBs under /opt/mysql and remembered that I had moved them there and symlinked /opt/mysql to /var/lib/mysql. It would appear that the upgrade removed the symlink and recreated only the original DBs. I've recreated the symlink and now only have one error remaining. The cron.daily/mysql-server run is generating an Access Denied, but I'm guessing that this is due to the upgrade not operating on the original mysql DB but rather the new one it created. This effectively crippled two production sites until the cause was located.
severity 287978 important reassign 287978 dpkg thanks hi andreas, i'm reassigning this to dpkg, as i believe that this is a documented problem with dpkg handling symlinks (i believe there are also other open bugs reporting this against dpkg). perhaps the dpkg maintainers would care to comment on what the best approach would be to handle this problem[1]? istr reading a report where it was stated there wasn't an easy way to fix this within dpkg. if that's the case, perhaps providing an empty .placeholder file in /var/lib/mysql would be an effective workaround? i've also lowered the severity of the bug to important, as it does not cause any data loss (loss of availability, yes, but not data), and only affects some users (those who have symlinked). sean
Hi Sean: During lunch break I examined my changelog entry for 4.0.23-1 which "fixed" the problem by removing /var/lib/mysql from the mysql-server.dirs i.e. /var/lib/dpkg/info/mysql-server.list file so that dpkg did no longer knew about the connection between the dir and package and thus does no longer remove it. So we can fix the woody-sarge upgrade just by uploading a new package to stable-proposed-updates and hoping that Joey makes a new Woody update before the Sarge release, right, or am I missing something? (not yet tested though) bye,
hey, yeah, i think that would do it. of course testing will be the ultimate judge, but that definitely sounds like the best approach so far. sean
Hello Scott I'm not yet convinced that I can agree with that. Please retitle it or change the severity or even tag it as wontfix but it had been assigned to dpkg for a reason. Or is there another bug report regarding this issue? One should at least be kept open for reference to both users and maintainers! It's common that admins replace directories with symlinks to relocate big chunks of data to a different partition without mounting a whole partition to this directory or using bind mounts which are not so known among admins. So dpkg should not simply delete a symlink to a directory that still contains files. bye,
Looking at this bug alone, it looks like a problem with mysql's maintainer scripts mucking around with this directory and symlink, rather than dpkg misbehaving. There is a bug reporting regarding the known bug (#182747), but this is particularly interesting... dpkg ordinarily tries very hard to keep symlinks-to-directories rather than replacing them with a directory again. The one known circumstance where there is a bug (noted above) is if the directory is removed from the package. If foo 1.0 ships "/foo" and foo 2.0 doesn't, dpkg will remove the /foo directory OR symlink. However if both foo 1.0 and 2.0 contain the directory in the package list, then if the admin has changed it to a symlink, the symlink should be preserved. If dpkg is removing the symlink and replacing it with a directory, there is another bug that is not a duplicate of #182747 -- however so far it hasn't shown up in any other package. If #182747 is actually what's going on here (mysql no longer includes /var/lib/mysql and dpkg so the admin's symlink) then by all means reassign and merge the two bugs. If not, we'll need to look a little closer at what's going on -- and try without your maintainer script cruft which I think is really causing the problem. Scott
Hello Scott In this case the update was from mysql-server-4.0 (4.0.22) to mysql-server-4.1 (4.1.11) so the first package got removed which is probably technically the same as an upgrade where the file is no longer in the package and thus this bug was triggered. What we noticed though was that a "real" directory would *not* have been removed if it contained data. This is the point where dpkg makes a difference between symlinks to directories and real directories. The tricks we did to our packages (i.e. removing and creating this symlink ourselves) was *only* to circumvent this problem on upgrades. bye,
reassign 287978 dpkg severity 287978 wishlist reassign 307730 dpkg severity 307730 wishlist merge 287978 307730 merge 182747 287978 thanks That makes sense. I can see what's going on here, and it is a duplicate of the bug yesterday. This is a good additional use case for it, too. Scott