Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
On Fr, 2015-01-02 at 08:48 +0100, Marc Haber wrote: On Tue, Dec 30, 2014 at 06:59:19PM +0100, Stephan Sürken wrote: That said ;), the final problem that (in the end) broke things with _your_ setup imho was the lack of space in /var, as usermod supports moving across filesystems just fine. Yes, but I don't think that a user must expect multiple gigabytes (~ 6 in my case) to be moved to /var during a package update. Sure, I was not arguing against that ;). The fix now always prefers the home of the actually existing mini-buildd user, even over a previously set debconf value. As an extra, this also handles manual (not via debconf) changes to the mini-buildd user gracefully. Such a move/copy on upgrade could now only happen in case the debconf value is explicitly changed. Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
On Tue, Dec 30, 2014 at 06:59:19PM +0100, Stephan Sürken wrote: That said ;), the final problem that (in the end) broke things with _your_ setup imho was the lack of space in /var, as usermod supports moving across filesystems just fine. Yes, but I don't think that a user must expect multiple gigabytes (~ 6 in my case) to be moved to /var during a package update. Atm, you may test the fix with the latest stable snapshot from here http://mini-buildd.installiert.net/ or alternatively rebuild via git branch 1.0.x. I need to re-build my minibuildd installation from the backup first since my attempt to restore to the pre-update snapshot wrecked the LV. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
Hi Marc, On So, 2014-12-28 at 14:49 +0100, Marc Haber wrote: Package: mini-buildd Version: 1.0.5 Severity: important (...) In my opinion, mini-buildd should not try to move its home directory on a package upgrade. It's fine to use the new /var/lib location for new installs, but an upgrade script cannot foresee possible pitfalls in moving the home directory (and, frankly, yours doesn't even try to check). yes, what you describe is actually intended behaviour ;); more precisely that code should only actually do something when the administrator explicitly changes the path via debconf. I am currently guessing that the debconf value did not exist yet in 0.9.5, and the postinstall does not handle this situation gracefully, but using the default path. Will have a look this afternoon... Thx, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
Hi, On Di, 2014-12-30 at 11:48 +0100, Stephan Sürken wrote: Hi Marc, (...) Will have a look this afternoon... first, jftr, version 0.9.5 is ancient, has only been in experimental, and is not supported; only upgrades 0.8.x-1.0.x are really supported. However, it should of course work anyway, and furthermore package-wise and for this problem, 0.9.5 is very much like 0.8.x; so this can indeed be a problem for things I actually support. So this is actually a problem that can arise when upgrading from 0.8.x. That said ;), the final problem that (in the end) broke things with _your_ setup imho was the lack of space in /var, as usermod supports moving across filesystems just fine. mini-buildd does have the ability to set the home dir via debconf, so I need some automation going on there to make this work automatically. The actual bug here imho is assuming to use the new default path -- in case none has been set yet -- even so a user already exists. It should always use the path of an existing user, prior to anything else. Atm, you may test the fix with the latest stable snapshot from here http://mini-buildd.installiert.net/ or alternatively rebuild via git branch 1.0.x. Hth! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
Package: mini-buildd Version: 1.0.5 Severity: important Hi, I finally tried updating mini-buildd 0.9.5 to the current unstable version on my build machine. The postinst obviously tried calling usermod to change the home directory, which tried renaming /home/mini-buildd to /var/lib/mini-buildd. That didn't work, most probably because my /home is on a different file system than /var: Setting up mini-buildd (1.0.5) ... Adding group `mini-buildd' (GID 118) ... Done. usermod: cannot rename directory /home/mini-buildd to /var/lib/mini-buildd dpkg: error processing package mini-buildd (--configure): subprocess installed post-installation script returned error exit status 12 Errors were encountered while processing: mini-buildd E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up mini-buildd (1.0.5) ... addgroup: The group `mini-buildd' already exists as a system group. Exiting. usermod: no changes usermod: no changes The user `mini-buildd' is already a member of `sbuild'. Setting admin password...mini-buildd FAILED: [Errno 13] Permission denied: '/var/lib/mini-buildd' dpkg: error processing package mini-buildd (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mini-buildd Press Return to continue. Trying to do a manual copy didn't work as well since my /var was not big enough for the 6 GB /home/mini-buildd. In my opinion, mini-buildd should not try to move its home directory on a package upgrade. It's fine to use the new /var/lib location for new installs, but an upgrade script cannot foresee possible pitfalls in moving the home directory (and, frankly, yours doesn't even try to check). Greetings Marc -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.17.6-zgsrv20080 (SMP w/6 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mini-buildd depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.55 ii debootstrap 1.0.66 ii devscripts 2.14.11 ii dpkg-dev1.17.23 ii gnupg 1.4.18-6 ii libjs-jquery1.7.2+dfsg-3.2 ii libjs-sphinxdoc 1.2.3+dfsg-1 ii lintian 2.5.30+deb8u3 ii mini-buildd-common 1.0.5 ii python-cherrypy33.5.0-2 ii python-daemon 1.5.5-1 ii python-django 1.7.1-1 ii python-django-extensions1.3.10-1 ii python-django-registration 1.0+dfsg-2 ii python-mini-buildd 1.0.5 ii python-pyftpdlib1.2.0-1 pn python:any none ii reprepro4.16.0-1 ii sbuild 0.65.0-1 ii schroot 1.6.10-1+b1 ii sudo1.8.11p2-1.1 Versions of packages mini-buildd recommends: ii python-apt 0.9.3.11 Versions of packages mini-buildd suggests: pn binfmt-supportnone ii debootstrap 1.0.66 pn haveged none ii lvm2 2.02.111-2 pn qemu-user-static none -- Configuration Files: /etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: u'/etc/sudoers.d/mini-buildd-sudoers' -- debconf information: mini-buildd/purge_warning: * mini-buildd/home: /var/lib/mini-buildd * mini-buildd/options: --verbose * mini-buildd/note: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
