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

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

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 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

On Mon, 3 Aug 2020 11:51:27 +0200, Bjoern Voigt 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, 3 Aug 2020 10:15:17 -0400, Cristian Rodríguez wrote:

On Mon, Aug 3, 2020 at 6:08 AM H.Merijn Brand 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 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