Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
Hi Witold, On Sonntag, 12. Dezember 2010, Witold Baryluk wrote: Basically I had /var/cache/apt, linked to /home/root/apt, and /home was NFS mount. http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#sufficient-space (probably just now) states: Use a temporary /var/cache/apt/archives: You can use a temporary cache directory from another filesystem (USB storage device, temporary hard disk, filesystem already in use, ...) _Note_: Do not use an NFS mount as the network connection could be interrupted during the upgrade. I think that's sufficient and we can close your bug. Do you agree? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
Le 12/12/2010 à 01:50, Witold Baryluk a écrit : Package: upgrade-reports Severity: normal Tags: squeeze Hi. Basically I had /var/cache/apt, linked to /home/root/apt, and /home was NFS mount. I also discovered today that I have all users' TMP and TEMP env. var. pointing to /home/username/tmp which unfortunelty is also true for user root (i do not know how to add exception to pam_env.so and /etc/security/pam_env.conf for user root - it currently affects all users). So also interactive root session (used to upgrade) had TMP and TEMP pointing to /home/root/tmp, this directory obviously existed, but due to the problem on upgrade with nfs (probably portmap restart, or something like that), any access to TMP resulted in error (No such directory - which resulted in many packages upgrade/install errors), or uninteruptible lock (even worse). What is even stranger manually exporting TMP=/tmp TEMP=/tmp just before apt-get , due not changed this behaviour. This is of course my fault that root user had insecure and not robust enough TMP directory set. (but I unfortunelty do not know how to make it work and still have it configured for normal users). I do not know if also adding small warning somehow about this in upgrade notes can help someone. I know this is probably unusual configuration, but it is good to know all this strange situations where upgrade can fail and notify users about such possibility. PS. TMP/TEMP is setup into users home directory mainly due to the simpler quota managment. (and the fact that local /tmp had no quota and can easly fill up making some system services fail). Thanks. -- Witold Baryluk JID: witold.baryluk // jabster.pl signature.asc Description: Digital signature
Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
On Sun, Dec 12, 2010 at 01:50:58AM +0100, Witold Baryluk wrote: Unfotunetly in mean time, something broked (probably nscd, nss, or LDAP authentification), and NFS mount was still mounted, but files was practically unaccessible. For example ls /home just hangs. And it cannot even be interupted by Ctrl-C. Nobody could connect using ssh easly (i still managed somehow to login into root using ssh, and fix problems). I'm not sure how we can describe this issue so that users do not get bitten by it. Specially without knowing the root cause. Maybe asking users to upgrade some services (LDAP, nss, nscd) before going to the full upgrade would be an option. (I use NFS for apt, because my workstations have limited disk capacity, and I have many of them, so I often download everything on one machine, and then remove lock, and use it on others machine to save Internet bandwidth). I would suggest, as an alternative, to use 'apt-cacher-ng' instead. You install it in one system and then make the others use it as a proxy for apt downloads. That way you do not have to handle file locking issues. I can try reinstalling there back lenny using FAI, and perform upgrade again to see what is going on exactly, and record whole session. (Previously i somehow managed to fix problem, but do not have logs) Yes, I would appreciate that so we can take a look and try to see what's going on. Regards Javier signature.asc Description: Digital signature
Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
On Mon, Dec 13, 2010 at 11:22:26AM +0100, Javier Fernández-Sanguino Peña wrote: (I use NFS for apt, because my workstations have limited disk capacity, and I have many of them, so I often download everything on one machine, and then remove lock, and use it on others machine to save Internet bandwidth). I would suggest, as an alternative, to use 'apt-cacher-ng' instead. You install it in one system and then make the others use it as a proxy for apt downloads. That way you do not have to handle file locking issues. I do not think apt-cacher-ng address this issue: apt-cacher-ng addresses the limited bandwidth issue, but not the limited disk capacity issue. apt-get will download package through apt-cacher-ng but still stores them in /var/cache/apt. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
Le 12/12/2010 à 01:50, Witold Baryluk a écrit : Package: upgrade-reports Severity: normal Tags: squeeze Hi. Basically I had /var/cache/apt, linked to /home/root/apt, and /home was NFS mount. It is not a good idea to link /var/x to /home/y : * /var is (more or less) mandatory for booting, and get mounted early * /usr should not be needed to boot (and can be monted later) * /home is not needed at all to boot, and can come late Alain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
On Sun, Dec 12, 2010 at 11:15:27AM +0100, Alain Baeckeroot wrote: Le 12/12/2010 à 01:50, Witold Baryluk a écrit : Package: upgrade-reports Severity: normal Tags: squeeze Hi. Basically I had /var/cache/apt, linked to /home/root/apt, and /home was NFS mount. It is not a good idea to link /var/x to /home/y : * /var is (more or less) mandatory for booting, and get mounted early * /usr should not be needed to boot (and can be monted later) * /home is not needed at all to boot, and can come late Your advice does not seems relevant to this bug report. Certainly /var/cache/apt is not used at boot time. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606826: upgrade-reports: release notes should warn about vital NFS mounts during upgrade
Package: upgrade-reports Severity: normal Tags: squeeze Hi. Basically I had /var/cache/apt, linked to /home/root/apt, and /home was NFS mount. After downloding everything using apt-get dist-upgrade -d, i started upgrade. Unfotunetly in mean time, something broked (probably nscd, nss, or LDAP authentification), and NFS mount was still mounted, but files was practically unaccessible. For example ls /home just hangs. And it cannot even be interupted by Ctrl-C. Nobody could connect using ssh easly (i still managed somehow to login into root using ssh, and fix problems). It worked for me without problem when doing small upgrades in lenny, but apperantly it is a problem of some kind in big upgrade of all packages. (I use NFS for apt, because my workstations have limited disk capacity, and I have many of them, so I often download everything on one machine, and then remove lock, and use it on others machine to save Internet bandwidth). I had this issue on 2 machines i tried to upgrade. I can try reinstalling there back lenny using FAI, and perform upgrade again to see what is going on exactly, and record whole session. (Previously i somehow managed to fix problem, but do not have logs) Similar problem could appear if /usr/ is mounted on NFS i suppose. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.37-rc4-sredniczarny-11361-g11e8896 (SMP w/1 CPU core; PREEMPT) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
