ok, so here is my fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
UUID=a0168b9f-31b4-4378-bbc9-438998b0d9b0 / ext3
errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=1620924a-1d73-47b0-91d3-f7c74083f526 none swap sw
0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
as you can see there is nothing about /tmp in the fstab.
so *I* did nothing to my computer (except upgrade)
Maybe the bug is not a piuparts bug, but piuparts use to work and not it does
not.
So there is a bug somewhere.
man 5 rcS
RAMTMP Make /tmp/ available as a ram file system (tmpfs). Set to 'yes'
to enable, to 'no' to disable. It defaults to yes for new installations
(wheezy and
later); no for upgrades from earlier releases, which do
not contain RAMTMP in /etc/default/rcS. The size of the tmpfs can be
controlled using
TMPFS_SIZE and TMP_SIZE in /etc/default/tmpfs. However,
/etc/default/tmpfs is deprecated and to override the defaults an entry should
be created in
/etc/fstab, for example:
tmpfs /tmp tmpfs nodev,nosuid,size=20%,mode=1777 0 0
Packages can not expect directories in /tmp to exist after boot.
so for wheezy RAMTMP=yes, on my system I checked and RAMTMP=yes.
so it seems that the default configuration of weezy will cause troubles to
piuparts.
Can you reopen the bug until a real fix exist, or a decision about the right
configuration of thoses /tmp is over. [1]
thanks
Frederic
[1] http://wiki.debian.org/ReleaseGoals/RunDirectory
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
