On Sat, Jun 2, 2012 at 11:51 PM, Dave Reisner <d@falconindy.com> wrote:

On Sat, Jun 02, 2012 at 11:45:26PM +0200, Tom Gundersen wrote:

...

The upgrade requires user intervention:

# rm /var/{lock,run} ; pacman -Syu

As you pointed out, this assumes that the machine was booted at least once on "recent" initscripts. If they're still directories, I suppose this gets a bit more fun -- subdirs, files, sockets, whatever will need to be moved into /run first.

I just did "rm -rf /var/{lock,run}" on my systemd machine (where these were proper folders with lots of stuff in them). This should be safe as long as you shutdown as much as you can beforehand and reboot afterwards.

...

A request: it would be really ideal if we could roll a new installer release as soon as this is out, so people don't have to deal with these sorts of things on their first upgrade after install. Would that be possible?

There's a lot of reasons we need a new core installer. Note that the netinstall isn't affected by this.

In that case, it might be worthwhile to remove the core installer from our webpage (at least for the time being), and write in big bold letters that everyone should use the netinstall. -t

One more sentence added: On Sun, Jun 3, 2012 at 4:58 PM, Tom Gundersen <teg@jklm.no> wrote:

----- 8< ------------------------------------------

filesystem upgrade - manual intervention required

As of filesystem-2012.3-1 the folders /var/run and /var/lock will be replaced by symlinks to /run and /run/lock, respectively.

On most systems this is already the case, as initscripts create the symlinks on boot. However, these symlinks are not owned by any package, which is what we are fixing with this upgrade.

If the symlinks are already in place on your system (which should be the case for most people), then you can simply perform

# pacman -Syu --ignore filesystem && pacman -S filesystem --force

In general, it is strongly advised to avoid the --force switch as it is not safe. However, in this particular case it is safe, and suggested to avoid having to manually delete the /var/run or /var/lock symlinks.

Otherwise, if /var/run or /var/lock are directories (e.g. if you are using systemd and never booted with initscripts) you need to delete the directories before performing the update. As these directories are used at runtime, it is recommended to shutdown any background tasks before performing

# rm -rf /var/run /var/lock && pacman -Syu && reboot

----- 8< ------------------------------------------

On Wed, Jun 06, 2012 at 11:31:52PM +1000, Gaetan Bisson wrote:

[2012-06-03 16:58:24 +0200] Tom Gundersen:

...

# pacman -Syu --ignore filesystem && pacman -S filesystem --force

On a VM created today with systemd, enabling [testing] yields:

# pacman -S filesystem --force resolving dependencies... looking for inter-conflicts...

Targets (1): filesystem-2012.6-2

Total Installed Size: 0.30 MiB Net Upgrade Size: 0.23 MiB

Proceed with installation? [Y/n] y (1/1) checking package integrity [#####################################] 100% (1/1) loading package files [#####################################] 100% (1/1) checking available disk space [#####################################] 100% (1/1) upgrading filesystem [#####################################] 100% warning: directory permissions differ on sys/ filesystem: 755 package: 555 error: extract: not overwriting dir with file var/run error: problem occurred while upgrading filesystem error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.

But that's not all; then:

# pacman -Q filesystem filesystem 2012.6-2 # ls -la /var | grep run lrwxrwxrwx 1 root root 11 Jun 6 10:13 lock -> ../run/lock drwxr-xr-x 4 root root 72 Jun 6 11:47 run

So pacman did not touch /var/run but "validated" the upgrade anyhow. What am I doing wrong?

-- Gaetan

I think this happens when /var/run has files in it. pacman should probably be aborting here before it gets to sync_commit.