Aw: [opensuse-factory] New Tumbleweed snapshot 20200801 released! - update hangs on Plasma update tool
Hi Together,
Gesendet: Sonntag, 02. August 2020 um 18:00 Uhr; Von: "Dominique Leuenberger" <dimstar@suse.de> [...] Packages changed: autoyast2 (4.3.31 -> 4.3.32) filesystem
If I start the update on plasma update tool, it stops/hangs. If I start # zypper ref && zypper dup If I update via KDE/plasma update tool I received following message: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /home: cpio: chmod failed - No such file or directory error: filesystem-15.5-30.1.x86_64: install failed error: filesystem-15.5-29.2.x86_64: erase skipped # ls -l / | grep home lrwxrwxrwx 1 root root 11 Jun 4 21:50 home -> /home.server/ drwxr-xr-x 1 root root 52 Apr 4 10:39 home.local drwxr-xr-x 10 root root 4096 Aug 1 12:36 home.server # mount | grep home /dev/nvme0n1p2 on /home.local type btrfs (rw,relatime,ssd,space_cache,subvolid=263,subvol=/@/home) server:/home on /home.server type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.y.z.2,local_lock=none,addr=x.y.z.1) server:/home/users on /home.server/users type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.y.z.2,local_lock=none,addr=x.y.z.1) # cat /etc/fstab | grep home UUID=123 /home.local btrfs subvol=/@/home 0 0 server:/home /home.server nfs defaults 0 0 Seams to be an issue with the linked /home (which I use to be able to use the device in my network with mounted /home from Server and stand alone). Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2020-08-03 10:31, ub22@gmx.net wrote:
If I start the update on plasma update tool, it stops/hangs.
If I start # zypper ref && zypper dup
If I update via KDE/plasma update tool
I received following message:
Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /home: cpio: chmod failed - No such file or directory error: filesystem-15.5-30.1.x86_64: install failed error: filesystem-15.5-29.2.x86_64: erase skipped
# ls -l / | grep home lrwxrwxrwx 1 root root 11 Jun 4 21:50 home -> /home.server/
Isn't this the historic problem of rpm having been unable to deal with from-symlink and to-symlink changes.. (after all, it is trying to update/replace it with a drwx /home) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Aug 03, Jan Engelhardt wrote:
On Monday 2020-08-03 10:31, ub22@gmx.net wrote:
Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /home: cpio: chmod failed - No such file or directory error: filesystem-15.5-30.1.x86_64: install failed error: filesystem-15.5-29.2.x86_64: erase skipped
# ls -l / | grep home lrwxrwxrwx 1 root root 11 Jun 4 21:50 home -> /home.server/
Isn't this the historic problem of rpm having been unable to deal with from-symlink and to-symlink changes.. (after all, it is trying to update/replace it with a drwx /home)
Yes, RPM has problems replacing directories with symlinks. But in this case it's something else: home is a directory according to the RPM database, home is a directory in the updated filesystem.rpm, but on disk is something different. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 3. August 2020, 10:46:50 CEST schrieb Jan Engelhardt:
On Monday 2020-08-03 10:31, ub22@gmx.net wrote:
If I start the update on plasma update tool, it stops/hangs.
Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /home: cpio: chmod failed - No such file or directory error: filesystem-15.5-30.1.x86_64: install failed error: filesystem-15.5-29.2.x86_64: erase skipped
# ls -l / | grep home lrwxrwxrwx 1 root root 11 Jun 4 21:50 home -> /home.server/
Isn't this the historic problem of rpm having been unable to deal with from-symlink and to-symlink changes.. (after all, it is trying to update/replace it with a drwx /home)
..along with the from-dir to-file and vice versa. Considering, that we all get bitten by it from time to time, question is, why rpm refrains from solving this annoyance? Another question is, if packages should touch /home at all? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Aug 03, Hans-Peter Jansen wrote:
Am Montag, 3. August 2020, 10:46:50 CEST schrieb Jan Engelhardt:
Isn't this the historic problem of rpm having been unable to deal with from-symlink and to-symlink changes.. (after all, it is trying to update/replace it with a drwx /home)
..along with the from-dir to-file and vice versa.
Considering, that we all get bitten by it from time to time, question is, why rpm refrains from solving this annoyance?
Because it is not solveable. Assume you have: /usr/lib/app/<scripts> Now you want to move that to /usr/libexec/app and replace /usr/lib/app with an symlink. What do you do with the content of /usr/lib/app during that time? Especially, if this is coming from different packages, some files got removed in the new package, ...
Another question is, if packages should touch /home at all?
Either we create /home with correct permissions in filesystem.rpm, or we trust that all tools (useradd, adduser, systemd-sysusers, ...) do create /home correct. If they create /home at all and don't fail to create a user, since /home is missing. Somebody needs to initialy create /home with the correct permissions, and on a RPM based distribution this is RPM. So yes, one package needs to contain and such touch /home. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 3. August 2020, 11:28:15 CEST schrieb Thorsten Kukuk:
On Mon, Aug 03, Hans-Peter Jansen wrote:
Am Montag, 3. August 2020, 10:46:50 CEST schrieb Jan Engelhardt:
Isn't this the historic problem of rpm having been unable to deal with from-symlink and to-symlink changes.. (after all, it is trying to update/replace it with a drwx /home)
..along with the from-dir to-file and vice versa.
Considering, that we all get bitten by it from time to time, question is, why rpm refrains from solving this annoyance?
Because it is not solveable. Assume you have: /usr/lib/app/<scripts>
Now you want to move that to /usr/libexec/app and replace /usr/lib/app with an symlink. What do you do with the content of /usr/lib/app during that time? Especially, if this is coming from different packages, some files got removed in the new package, ...
It even fails with silly situations, where all files/folders are contained in a package, e.g. python's egg-info might be a file or a folder, but rpm didn't manage, if they change their type (at least about a year ago, when this failed for me again). BTW, you're right with /home. Sorry. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 03 Aug 2020, 11:16:24 +0200, Hans-Peter Jansen wrote:
Am Montag, 3. August 2020, 10:46:50 CEST schrieb Jan Engelhardt:
On Monday 2020-08-03 10:31, ub22@gmx.net wrote:
If I start the update on plasma update tool, it stops/hangs.
Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /home: cpio: chmod failed - No such file or directory error: filesystem-15.5-30.1.x86_64: install failed error: filesystem-15.5-29.2.x86_64: erase skipped
# ls -l / | grep home lrwxrwxrwx 1 root root 11 Jun 4 21:50 home -> /home.server/
Isn't this the historic problem of rpm having been unable to deal with from-symlink and to-symlink changes.. (after all, it is trying to update/replace it with a drwx /home)
..along with the from-dir to-file and vice versa.
Considering, that we all get bitten by it from time to time, question is, why rpm refrains from solving this annoyance?
Another question is, if packages should touch /home at all?
I'd rather ask why people don't add a proper entry to their /etc/fstab? This way, everything would be OK from rpm's point of view: /home.server /home none bind 0 0 Cheers. l8er manfred
Hi,
Gesendet: Montag, 03. August 2020 um 11:42 Uhr; Von: "Manfred Hollstein" I'd rather ask why people don't add a proper entry to their /etc/fstab? This way, everything would be OK from rpm's point of view:
/home.server /home none bind 0 0
OK, I was not aware about this entry (so I'm only an experianced user not an Linux professional ;-) ). But now I added this in the entry and the same with my '/root/bin' now. Are this all pathes which are not allowing symlinks to other pathes. Or will be generelly not allowed to do a symlink to a path? We will see if this really fix this Issue. Only to be sure, will the mounting in /etc/fstab will be done sequential starting at line 1 till the end? Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Ulf, On Mon, 03 Aug 2020, 16:42:34 +0200, ub22@gmx.net wrote:
Hi,
Gesendet: Montag, 03. August 2020 um 11:42 Uhr; Von: "Manfred Hollstein" I'd rather ask why people don't add a proper entry to their /etc/fstab? This way, everything would be OK from rpm's point of view:
/home.server /home none bind 0 0
OK, I was not aware about this entry (so I'm only an experianced user not an Linux professional ;-) ).
But now I added this in the entry and the same with my '/root/bin' now. Are this all pathes which are not allowing symlinks to other pathes. Or will be generelly not allowed to do a symlink to a path?
As a start, look at the output from running the following command: rpm -ql filesystem | while read dir; do [ -d $dir ] && echo $dir; done This will print all directories which are owned by the filesystem package and thusly a candidate for similar trouble, when you're replacing any of them with a symbolic link. There are probably more directories owned by other packages...
We will see if this really fix this Issue.
Only to be sure, will the mounting in /etc/fstab will be done sequential starting at line 1 till the end?
Quoting from "man fstab": The order of records in fstab is important because fsck(8), mount(8), and umount(8) sequentially iterate through fstab doing their thing.
Regards Ulf
HTH, cheers. l8er manfred
ub22@gmx.net wrote:
# ls -l / | grep home lrwxrwxrwx 1 root root 11 Jun 4 21:50 home -> /home.server/ drwxr-xr-x 1 root root 52 Apr 4 10:39 home.local drwxr-xr-x 10 root root 4096 Aug 1 12:36 home.server # mount | grep home /dev/nvme0n1p2 on /home.local type btrfs (rw,relatime,ssd,space_cache,subvolid=263,subvol=/@/home) server:/home on /home.server type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.y.z.2,local_lock=none,addr=x.y.z.1) server:/home/users on /home.server/users type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.y.z.2,local_lock=none,addr=x.y.z.1) # cat /etc/fstab | grep home UUID=123 /home.local btrfs subvol=/@/home 0 0 server:/home /home.server nfs defaults 0 0
Seams to be an issue with the linked /home (which I use to be able to use the device in my network with mounted /home from Server and stand alone). If you need a symlink home -> /home.server/ I would suggest to use a bind mount instead of a symlink. Two reasons:
* Many programs use files in $HOME and many of them could not deal consistently with symlinks. For instance they write pathes like /home.server/user/some-file1 and /home/user/some-file2 in config files. * Bind mounts will not result in errors like you described. Offline updates (from CDROM, ISO) may still be an issue. I haven't tested, if the Installer uses the bind mounts from /etc/fstab. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 3 Aug 2020 11:51:27 +0200, Bjoern Voigt <bjoernv@arcor.de> wrote:
ub22@gmx.net wrote:
Seams to be an issue with the linked /home (which I use to be able to use the device in my network with mounted /home from Server and stand alone).
If you need a symlink home -> /home.server/ I would suggest to use a bind mount instead of a symlink. Two reasons:
Why did I not think of this for the /tmp - tmpfs issue? Is it plausible to have /tmp = tmpfs with a service that depends on /tmp that mounts /tmp/whatever to /opt/product/workspace on boot? If I can setup such a scheme in a reliable way, I think that I can workaround the problems I mentioned with legacy products wanting to write files to /tmp (and persist there) This would not be possible if tmpfs does not allow bind to harddisk locations Am I being too terse?
* Many programs use files in $HOME and many of them could not deal consistently with symlinks. For instance they write pathes like /home.server/user/some-file1 and /home/user/some-file2 in config files. * Bind mounts will not result in errors like you described. Offline updates (from CDROM, ISO) may still be an issue. I haven't tested, if the Installer uses the bind mounts from /etc/fstab.
Björn
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On Mon, Aug 3, 2020 at 6:08 AM H.Merijn Brand <linux@tux.freedom.nl> wrote:
Is it plausible to have /tmp = tmpfs with a service that depends on /tmp that mounts /tmp/whatever to /opt/product/workspace on boot?
Just use bind mounts if this a regular user app or systemd unit setting TemporaryFileSystem= if this is a service.
If I can setup such a scheme in a reliable way, I think that I can workaround the problems I mentioned with legacy products wanting to write files to /tmp (and persist there)
I assume that this legacy products cannot be fixed...because it they could be..you better do that and operate under the expected constraints: "programs should not assume that files in /tmp persist between invocations" (currently the system is forgiving and will persist until next reboot (unless it is a system service with privatetmp on) but again nothing should depend on this implementation-specific detail) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 3 Aug 2020 10:15:17 -0400, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
On Mon, Aug 3, 2020 at 6:08 AM H.Merijn Brand <linux@tux.freedom.nl> wrote:
Is it plausible to have /tmp = tmpfs with a service that depends on /tmp that mounts /tmp/whatever to /opt/product/workspace on boot?
Just use bind mounts if this a regular user app or systemd unit setting TemporaryFileSystem= if this is a service.
If I can setup such a scheme in a reliable way, I think that I can workaround the problems I mentioned with legacy products wanting to write files to /tmp (and persist there)
I assume that this legacy products cannot be fixed...because it they could be..you better do that and operate under the expected constraints: "programs should not assume that files in /tmp persist between invocations" (currently the system is forgiving and will persist until next reboot (unless it is a system service with privatetmp on) but again nothing should depend on this implementation-specific detail)
It is even worse for one product: it supports $TMPDIR (yeah) but not for all files used (WTF?). Another issue I need sudo for is that it requires a hard-coded path in /usr. I need to make a symbolic link there to escape of that idiot stupidity. As the company of that product does not exist anymore (at least not in terms of maint or support) there is no chance of getting that fixed I will investigate bind mounts! -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On Mon, Aug 3, 2020 at 10:31 AM H.Merijn Brand <linux@tux.freedom.nl> wrote:
It is even worse for one product: it supports $TMPDIR (yeah) but not for all files used (WTF?).
Another issue I need sudo for is that it requires a hard-coded path in /usr. I need to make a symbolic link there to escape of that idiot stupidity.
As the company of that product does not exist anymore (at least not in terms of maint or support) there is no chance of getting that fixed
I will investigate bind mounts!
Issues are not uncommon at all.. and the very reason these changes are pursued in the first place.. you could also ran the application wrapped into systemd-run if it is not a system service. Look into the bright side, at least it is not of the nastiest kind that expects and will consume in the next startup files from /tmp. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2020-08-03 16:31, H.Merijn Brand wrote:
It is even worse for one product: it supports $TMPDIR (yeah) but not for all files used (WTF?). Another issue I need sudo for is that it requires a hard-coded path in /usr. I need to make a symbolic link there to escape of that idiot stupidity.
As the company of that product does not exist anymore (at least not in terms of maint or support) there is no chance of getting that fixed
Humour me. I like patching, even binaries :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Bjoern Voigt -
Cristian Rodríguez -
H.Merijn Brand -
Hans-Peter Jansen -
Jan Engelhardt -
Manfred Hollstein -
Thorsten Kukuk -
ub22＠gmx.net