Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
Unfortunately, on my machine, this fails for some reason (currently unknown to me):
Installing: filesystem-12.3-3.1 ...............................................................................................[error] Installation of filesystem-12.3-3.1 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory error: filesystem-12.3-3.1.x86_64: install failed error: filesystem-12.3-2.1.x86_64: erase skipped
Trying to do this move manually results in: # mv /var/lock /var/lock.migrated mv: cannot move ‘/var/lock’ to ‘/var/lock.migrated’: Device or resource busy
lsof +D /var/lock yields no results.
apparmor has been ruled out (disabled)
Any other good ideas on what can be tested? Whatever it is, it will have to enter the package too of course :)
Best regards, Dominique
Am 15.10.2012 18:53, schrieb Dimstar / Dominique Leuenberger:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
Unfortunately, on my machine, this fails for some reason (currently unknown to me):
Installing: filesystem-12.3-3.1 ...............................................................................................[error] Installation of filesystem-12.3-3.1 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory error: filesystem-12.3-3.1.x86_64: install failed error: filesystem-12.3-2.1.x86_64: erase skipped
Trying to do this move manually results in: # mv /var/lock /var/lock.migrated mv: cannot move ‘/var/lock’ to ‘/var/lock.migrated’: Device or resource busy
On my Factory box with filesystem-12.3-2.1, a tmpfs is mounted on /var/lock -- and I guess you cannot rename busy mountpoints...
Any other good ideas on what can be tested? Whatever it is, it will have to enter the package too of course :)
The question os: What is the filesystem package trying to do?
On Mon, 2012-10-15 at 19:20 +0200, Stefan Seyfried wrote:
On my Factory box with filesystem-12.3-2.1, a tmpfs is mounted on /var/lock -- and I guess you cannot rename busy mountpoints...
Not the case at mine.. and actually, the script would try to umount -l it first anyway.. so that part is covered
The full script is (in lua): os.remove ("/usr/include/X11") os.remove ("/usr/lib/X11") os.execute ("mountpoint -q /var/lock && umount -l /var/lock") os.rename ("/var/lock","/var/lock.migrated") os.execute ("mountpoint -q /var/run && umount -l /var/run") os.rename ("/var/run","/var/run.migrated")
Any other good ideas on what can be tested? Whatever it is, it will have to enter the package too of course :)
The question os: What is the filesystem package trying to do?
from the changelog: - replace /var/run and /var/lock directories with symlinks to /run and /run/lock (respectively)
Best regards, Dominique
Le lundi 15 octobre 2012 à 19:20 +0200, Stefan Seyfried a écrit :
Am 15.10.2012 18:53, schrieb Dimstar / Dominique Leuenberger:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
Unfortunately, on my machine, this fails for some reason (currently unknown to me):
Installing: filesystem-12.3-3.1 ...............................................................................................[error] Installation of filesystem-12.3-3.1 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory error: filesystem-12.3-3.1.x86_64: install failed error: filesystem-12.3-2.1.x86_64: erase skipped
Trying to do this move manually results in: # mv /var/lock /var/lock.migrated mv: cannot move ‘/var/lock’ to ‘/var/lock.migrated’: Device or resource busy
On my Factory box with filesystem-12.3-2.1, a tmpfs is mounted on /var/lock -- and I guess you cannot rename busy mountpoints...
which is why I used "umount -l /var/lock" before the rename. It allows access to the underlying directory (and renaming it) even if there are process still accessing the mount point.
And in my tests, it was working it (same for /var/run). Unfortunately, it looks like "something" not visible with lsof / fuser is using /var/lock, which is preventing mv to work properly and I have no idea what it might be.
On Mon, 2012-10-15 at 18:53 +0200, Dimstar / Dominique Leuenberger wrote:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
For reference, this has been reported as bug: https://bugzilla.novell.com/show_bug.cgi?id=785133
Dominique
On 15.10.2012 19:59, Dimstar / Dominique Leuenberger wrote:
On Mon, 2012-10-15 at 18:53 +0200, Dimstar / Dominique Leuenberger wrote:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
For reference, this has been reported as bug: https://bugzilla.novell.com/show_bug.cgi?id=785133
I removed the offending code from the openSUSE:Factory package
Greetings, Stephan
On 17/10/12 12:53, Stephan Kulow wrote:
On 15.10.2012 19:59, Dimstar / Dominique Leuenberger wrote:
On Mon, 2012-10-15 at 18:53 +0200, Dimstar / Dominique Leuenberger wrote:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
For reference, this has been reported as bug: https://bugzilla.novell.com/show_bug.cgi?id=785133
I removed the offending code from the openSUSE:Factory package
Greetings, Stephan
Loading repository data... Reading installed packages... Computing distribution upgrade...
The following package is going to be upgraded: filesystem
1 package to upgrade. Overall download size: 67.1 KiB. No additional space will be used or freed after the operation. Continue? [y/n/?] (y): Retrieving package filesystem-12.3-5.1.x86_64 (1/1), 67.1 KiB ( 0 B unpacked) Retrieving: filesystem-12.3-5.1.x86_64.rpm ..............................................................................................................................................................................................................................[done] Installing: filesystem-12.3-5.1 ........................................................................................................................................................................................................................................[error] Installation of filesystem-12.3-5.1 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory error: filesystem-12.3-5.1.x86_64: install failed error: filesystem-12.3-2.1.x86_64: erase skipped
Abort, retry, ignore? [a/r/i] (a): Regards Sid.
On 17/10/12 12:53, Stephan Kulow wrote:
On 15.10.2012 19:59, Dimstar / Dominique Leuenberger wrote:
On Mon, 2012-10-15 at 18:53 +0200, Dimstar / Dominique Leuenberger wrote:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
For reference, this has been reported as bug: https://bugzilla.novell.com/show_bug.cgi?id=785133
I removed the offending code from the openSUSE:Factory package
Greetings, Stephan
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error. Regards Sid.
Am 21.10.2012 14:38, schrieb Sid Boyce:
On 17/10/12 12:53, Stephan Kulow wrote:
On 15.10.2012 19:59, Dimstar / Dominique Leuenberger wrote:
On Mon, 2012-10-15 at 18:53 +0200, Dimstar / Dominique Leuenberger wrote:
Hi all,
the latest filesystem package received some script magic, trying to rename /var/lock to /var/lock.migrated and finally adding some symlinking to /run/lock, which is the new location for the lock folder.
For reference, this has been reported as bug: https://bugzilla.novell.com/show_bug.cgi?id=785133
I removed the offending code from the openSUSE:Factory package
Greetings, Stephan
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
Greetings, Stephan
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
thanks,
* Jiri Slaby jslaby@suse.cz [10-23-12 12:22]:
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
And leaves 12.3 systems effectively *borked* since yast/zypper are not functional. zypper reports missing libidn.so.11.
And VB guest doesn't allow larger than 640x480 display.
On 23/10/12 17:22, Jiri Slaby wrote:
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
thanks,
The previous answers seemed quite evasive so I didn't ask this in case it was an embarrassing question. Regards Sid.
Am 23.10.2012 18:22, schrieb Jiri Slaby:
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
Check the beginning of the thread, the solution is not simple. Frederic is looking for a solution in the initrd to move /var/run - my aim was just to avoid zypper up breaking the system. But I can revert the whole change too - I just hoped Frederic would do it himself ;(
Greetings, Stephan
Le mercredi 24 octobre 2012 à 18:08 +0200, Stephan Kulow a écrit :
Am 23.10.2012 18:22, schrieb Jiri Slaby:
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
Check the beginning of the thread, the solution is not simple. Frederic is looking for a solution in the initrd to move /var/run - my aim was just to avoid zypper up breaking the system. But I can revert the whole change too - I just hoped Frederic would do it himself ;(
I wanted to avoid relying on an initrd solution, but if we can't find a good way to handle this switch at the rpm/scripts level, I guess we'll go this route.
I've got some suggestions to locate what is causing the issue, so I suggest we continue this discussion on bugzilla
Am 24.10.2012 18:21, schrieb Frederic Crozat:
Le mercredi 24 octobre 2012 à 18:08 +0200, Stephan Kulow a écrit :
Am 23.10.2012 18:22, schrieb Jiri Slaby:
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
Check the beginning of the thread, the solution is not simple. Frederic is looking for a solution in the initrd to move /var/run - my aim was just to avoid zypper up breaking the system. But I can revert the whole change too - I just hoped Frederic would do it himself ;(
I wanted to avoid relying on an initrd solution, but if we can't find a good way to handle this switch at the rpm/scripts level, I guess we'll go this route.
Right now even the live cds fail to build because of filesystem:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
Greetings, Stephan
Le mercredi 24 octobre 2012 à 18:30 +0200, Stephan Kulow a écrit :
Am 24.10.2012 18:21, schrieb Frederic Crozat:
Le mercredi 24 octobre 2012 à 18:08 +0200, Stephan Kulow a écrit :
Am 23.10.2012 18:22, schrieb Jiri Slaby:
On 10/22/2012 11:40 AM, Stephan Kulow wrote:
Am 21.10.2012 14:38, schrieb Sid Boyce:
Meaning exactly what? filesystem-12.3-5.1 yields exactly the same error.
No, it does not. It might be the same message, but filesystem 5.1 won't remove your /var/run directory and destroy your running system.
So I suppose another fix will happen there, as it is impossible to install that package, right?
Check the beginning of the thread, the solution is not simple. Frederic is looking for a solution in the initrd to move /var/run - my aim was just to avoid zypper up breaking the system. But I can revert the whole change too - I just hoped Frederic would do it himself ;(
I wanted to avoid relying on an initrd solution, but if we can't find a good way to handle this switch at the rpm/scripts level, I guess we'll go this route.
Right now even the live cds fail to build because of filesystem:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
So, either something else is packaging /var/run as a directory or a script is creating this directory before filesystem package is installed.
On Wednesday 2012-10-24 18:42, Frederic Crozat wrote:
I wanted to avoid relying on an initrd solution, but if we can't find a good way to handle this switch at the rpm/scripts level, I guess we'll go this route.
Right now even the live cds fail to build because of filesystem:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
So, either something else is packaging /var/run as a directory or a script is creating this directory before filesystem package is installed.
(12.3-0 is a local build of Base:System/filesystem)
v-sfac:/tmp # rpm -Uhv filesystem-12.3-0.x86_64.rpm --oldpackage Forbereder... ################################# [100%] Updating / installing... 1:filesystem-12.3-0 ################################# [ 50%] Cleaning up / removing... 2:filesystem-12.3-2.1 ################################# [100%]
So I don't see anything - but then again, this is only a minimal VM.
It looks as if 12.3-5.1 did not have anything in %pre.
RPM failed with "rename failed", since it moves every object from itsname to mktemp(itsname.XXXXXX) before writing the new file that is just being decoded from the cpio stream. Naturally, calling rename(2) on a mount is not permitted, so a rename failure is to be expected iff %pre had not made a clean house first.
Am 25.10.2012 03:48, schrieb Jan Engelhardt:
It looks as if 12.3-5.1 did not have anything in %pre.
RPM failed with "rename failed", since it moves every object from itsname to mktemp(itsname.XXXXXX) before writing the new file that is just being decoded from the cpio stream. Naturally, calling rename(2) on a mount is not permitted, so a rename failure is to be expected iff %pre had not made a clean house first.
The problem is moving from /var/run as directory to /var/run as symlink. rpm just can't do that.
Greetings, Stephan
Hey,
On 25.10.2012 16:30, Stephan Kulow wrote:
The problem is moving from /var/run as directory to /var/run as symlink. rpm just can't do that.
No really true. If you can modify the updated package you should be able to use the pretrans trigger.
%pretrans mv dir dir.rpmsave ln -s dir.rpmsave dir
Henne
Am 25.10.2012 16:44, schrieb Henne Vogelsang:
Hey,
On 25.10.2012 16:30, Stephan Kulow wrote:
The problem is moving from /var/run as directory to /var/run as symlink. rpm just can't do that.
No really true. If you can modify the updated package you should be able to use the pretrans trigger.
%pretrans mv dir dir.rpmsave ln -s dir.rpmsave dir
ok, I should be a bit more specific: you can't move from /var/run the live mount point to /var/run the symlink with rpm.
Greetings, Stephan
On Thu, Oct 25, 2012 at 04:44:21PM +0200, Henne Vogelsang wrote:
Hey,
On 25.10.2012 16:30, Stephan Kulow wrote:
The problem is moving from /var/run as directory to /var/run as symlink. rpm just can't do that.
No really true. If you can modify the updated package you should be able to use the pretrans trigger.
%pretrans mv dir dir.rpmsave ln -s dir.rpmsave dir
Argh, not again. Folks, pretrans triggers *must* be lua scripts, otherwise you can never install a new system.
Also, pretrans triggers are called *before* checking for file conflicts, so they should be as lightweight as possible. Running a 'mv' command is not lightweight. (And 'mv' is also not availible in a fresh installation.)
The correct way to do this is to symlink in the other direction in lua and cleanup in %pre or %post.
Cheers, Michael.
Le jeudi 25 octobre 2012 à 17:07 +0200, Michael Schroeder a écrit :
On Thu, Oct 25, 2012 at 04:44:21PM +0200, Henne Vogelsang wrote:
Hey,
On 25.10.2012 16:30, Stephan Kulow wrote:
The problem is moving from /var/run as directory to /var/run as symlink. rpm just can't do that.
No really true. If you can modify the updated package you should be able to use the pretrans trigger.
%pretrans mv dir dir.rpmsave ln -s dir.rpmsave dir
Argh, not again. Folks, pretrans triggers *must* be lua scripts, otherwise you can never install a new system.
Also, pretrans triggers are called *before* checking for file conflicts, so they should be as lightweight as possible. Running a 'mv' command is not lightweight. (And 'mv' is also not availible in a fresh installation.)
The correct way to do this is to symlink in the other direction in lua and cleanup in %pre or %post.
Which is how my initial script was written, thanks to you ;)
But we are still left with a "non rpm" issue with /var/lock..
On Thu, 25 Oct 2012 16:30:44 +0200 Stephan Kulow wrote:
The problem is moving from /var/run as directory to /var/run as symlink. rpm just can't do that.
I don't have this problem.
% file /var/run /var/lock /var/run: symbolic link to `/run' /var/lock: symbolic link to `/run/lock'
% rpm -qf /var/run /var/lock filesystem-12.3-5.1.x86_64 filesystem-12.3-5.1.x86_64
I'm running continuously updated Factory since 11.2.
Am 24.10.2012 18:42, schrieb Frederic Crozat:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
So, either something else is packaging /var/run as a directory or a script is creating this directory before filesystem package is installed.
I checked and there is /var/run/zypp.pid in that directory - so libzypp needs to be changed before you can do the magic in filesystem. I better revert more of filesystem ;(
Greetings, Stephan
Le samedi 27 octobre 2012 à 08:26 +0200, Stephan Kulow a écrit :
Am 24.10.2012 18:42, schrieb Frederic Crozat:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
So, either something else is packaging /var/run as a directory or a script is creating this directory before filesystem package is installed.
I checked and there is /var/run/zypp.pid in that directory - so libzypp needs to be changed before you can do the magic in filesystem. I better revert more of filesystem ;(
This is still strange, because people didn't had issue with /var/run being moved but with /var/lock.
Anyway, with Milestone 1 approaching, we should probably revert to /var/run and /var/lock as directories (I'll put back the needed commits in systemd to make sure /var/run and /var/lock are still bind mounted, until we really fix filesystem).
On 29/10/12 11:49, Frederic Crozat wrote:
Le samedi 27 octobre 2012 à 08:26 +0200, Stephan Kulow a écrit :
Am 24.10.2012 18:42, schrieb Frederic Crozat:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
So, either something else is packaging /var/run as a directory or a script is creating this directory before filesystem package is installed.
I checked and there is /var/run/zypp.pid in that directory - so libzypp needs to be changed before you can do the magic in filesystem. I better revert more of filesystem ;(
This is still strange, because people didn't had issue with /var/run being moved but with /var/lock.
Anyway, with Milestone 1 approaching, we should probably revert to /var/run and /var/lock as directories (I'll put back the needed commits in systemd to make sure /var/run and /var/lock are still bind mounted, until we really fix filesystem).
filesystem-12.3-6.1.x86_64 resolves the issue. Regards Sid.
Le lundi 29 octobre 2012 à 12:08 +0000, Sid Boyce a écrit :
On 29/10/12 11:49, Frederic Crozat wrote:
Le samedi 27 octobre 2012 à 08:26 +0200, Stephan Kulow a écrit :
Am 24.10.2012 18:42, schrieb Frederic Crozat:
[ 1375s] Installation of filesystem-12.3-5.1 failed: [ 1375s] (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory
So, either something else is packaging /var/run as a directory or a script is creating this directory before filesystem package is installed.
I checked and there is /var/run/zypp.pid in that directory - so libzypp needs to be changed before you can do the magic in filesystem. I better revert more of filesystem ;(
This is still strange, because people didn't had issue with /var/run being moved but with /var/lock.
Anyway, with Milestone 1 approaching, we should probably revert to /var/run and /var/lock as directories (I'll put back the needed commits in systemd to make sure /var/run and /var/lock are still bind mounted, until we really fix filesystem).
filesystem-12.3-6.1.x86_64 resolves the issue.
Well, it has the /var/run part reverted. However, I'm not sure if the /var/lock part has been reverted too.
On Monday 2012-10-29 13:41, Frederic Crozat wrote:
filesystem-12.3-6.1.x86_64 resolves the issue.
Well, it has the /var/run part reverted. However, I'm not sure if the /var/lock part has been reverted too.
Is there a way the problem can actually be reproduced?
* Sid Boyce sboyce@blueyonder.co.uk [10-29-12 08:09]:
On 29/10/12 11:49, Frederic Crozat wrote:
...
This is still strange, because people didn't had issue with /var/run being moved but with /var/lock.
Anyway, with Milestone 1 approaching, we should probably revert to /var/run and /var/lock as directories (I'll put back the needed commits in systemd to make sure /var/run and /var/lock are still bind mounted, until we really fix filesystem).
filesystem-12.3-6.1.x86_64 resolves the issue.
*Is* working for me. Installed this am and survived two reboots and a zypper dup.
On 29.10.2012 15:55, Patrick Shanahan wrote:
- Sid Boyce sboyce@blueyonder.co.uk [10-29-12 08:09]:
On 29/10/12 11:49, Frederic Crozat wrote:
...
This is still strange, because people didn't had issue with /var/run being moved but with /var/lock.
Anyway, with Milestone 1 approaching, we should probably revert to /var/run and /var/lock as directories (I'll put back the needed commits in systemd to make sure /var/run and /var/lock are still bind mounted, until we really fix filesystem).
filesystem-12.3-6.1.x86_64 resolves the issue.
*Is* working for me. Installed this am and survived two reboots and a zypper dup.
But /var/run and /var/lock are symlinks now?
Greetings, Stephan
* Stephan Kulow coolo@suse.de [10-31-12 08:59]:
On 29.10.2012 15:55, Patrick Shanahan wrote:
- Sid Boyce sboyce@blueyonder.co.uk [10-29-12 08:09]:
On 29/10/12 11:49, Frederic Crozat wrote:
...
This is still strange, because people didn't had issue with /var/run being moved but with /var/lock.
Anyway, with Milestone 1 approaching, we should probably revert to /var/run and /var/lock as directories (I'll put back the needed commits in systemd to make sure /var/run and /var/lock are still bind mounted, until we really fix filesystem).
filesystem-12.3-6.1.x86_64 resolves the issue.
*Is* working for me. Installed this am and survived two reboots and a zypper dup.
But /var/run and /var/lock are symlinks now?
No, they are *not!*
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/24/2012 06:08 PM, Stephan Kulow wrote:
Check the beginning of the thread, the solution is not simple. Frederic is looking for a solution in the initrd to move /var/run - my aim was just to avoid zypper up breaking the system. But I can revert the whole change too - I just hoped Frederic would do it himself ;(
I'm not saying it's easy, I just wanted to make sure, something else will happen to get rid of that problem. Because it sounded like you changed something and it should be fine back then. And apparently it wasn't.
Now, it's pretty clear to me. Thanks.
- -- js suse labs
-
Dimstar / Dominique Leuenberger -
Frederic Crozat -
Henne Vogelsang -
Jan Engelhardt -
Jiri Slaby -
Kyrill Detinov -
Michael Schroeder -
Patrick Shanahan -
Sid Boyce -
Stefan Seyfried -
Stephan Kulow