Aw: Re: update hangs on Plasma update tool ([opensuse-factory] New Tumbleweed snapshot 20200801)
Hi Manfred, thanks for fast reply :-)
Gesendet: Montag, 03. August 2020 um 19:46 Uh;: Von: "Manfred Hollstein" <mhollstein@t-online.de> On Mon, 03 Aug 2020, 16:42:34 +0200, ub22@gmx.net wrote:
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
OK, thats the hard methode, but then only for "filesystem" rpm I changed it a little bit and search for SymLinks # rpm -ql filesystem | while read dir; do [ -h $dir ] && echo $dir; done /var/mail /var/run Seems that there are some default directories which are linked. Why this are working?
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...
Yes, but from my point of view, a System must be tolerant according to such case of (possible or not forbidden) issues.
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.
Uppss, not read / remind :-( Cheers 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, 20:44:23 +0200, ub22@gmx.net wrote:
Hi Manfred,
thanks for fast reply :-)
Gesendet: Montag, 03. August 2020 um 19:46 Uh;: Von: "Manfred Hollstein" <mhollstein@t-online.de> On Mon, 03 Aug 2020, 16:42:34 +0200, ub22@gmx.net wrote:
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
OK, thats the hard methode, but then only for "filesystem" rpm I changed it a little bit and search for SymLinks
# rpm -ql filesystem | while read dir; do [ -h $dir ] && echo $dir; done /var/mail /var/run
Seems that there are some default directories which are linked. Why this are working?
It works because these are symbolic links which ought to be symbolic links according to the package's source rpm/spec file. Think of an rpm as a defined set of files/directories/links, where each of them carry another defined set of information such as who owns it (user/group id), permissions, etc. When you run "rpm -V filesystem" and you've modified /home and /root/bin, you'll get warnings as the integrity of that package is no longer maintained. Please have a look at "man rpm" and search for "VERIFY OPTIONS" which will show what this integrity/consistency actually means.
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...
Yes, but from my point of view, a System must be tolerant according to such case of (possible or not forbidden) issues.
It surely can be discussed if /home actually should be owned by a package, but, as others have argued, it plays an established role in the Linux/UNIX FHS and therefore has to be created according to some proper rules. These rules say that it is a directory, owned by root:root with permission 755! When you want/need a different device to carry your /home directory, you can either bind-mount another directory (as I suggested in my initial reply), or bind a different block device to /home. This way rpm wouldn't complain about any inconsistency. So, if your HOME directories should live on a partition of your second disk /dev/sdb, you could use something like this: - Use fdisk or parted (or your preferred partition tool) to create such a partition with your preferred file system type; ideally you assign it a unique label such as HOME - Then you could mount your home directory using something like LABEL=HOME /home auto defaults 1 2 I guess, your /home.server is already mounted like this. So, you could just replace /home.server in the line of your /etc/fstab with /home. No need for a symbolic link at all ;) HTH, cheers. l8er manfred
Hi Manfred and other readers,
Gesendet: Montag, 03. August 2020 um 21:30 Uhr; Von: "Manfred Hollstein"
On Mon, 03 Aug 2020, 20:44:23 +0200, ub22@gmx.net wrote:
OK, thats the hard methode, but then only for "filesystem" rpm I changed it a little bit and search for SymLinks
# rpm -ql filesystem | while read dir; do [ -h $dir ] && echo $dir; done /var/mail /var/run
Seems that there are some default directories which are linked. Why this are working?
It works because these are symbolic links which ought to be symbolic links according to the package's source rpm/spec file. Think of an rpm as a defined set of files/directories/links, where each of them carry another defined set of information such as who owns it (user/group id), permissions, etc. When you run "rpm -V filesystem" and you've modified /home and /root/bin, you'll get warnings as the integrity of that package is no longer maintained. Please have a look at "man rpm" and search for "VERIFY OPTIONS" which will show what this integrity/consistency actually means.
OK, thanks for your detailed answer :-) Seems to be fine now, with mounting of /home and /root/bin
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...
Yes, but from my point of view, a System must be tolerant according to such case of (possible or not forbidden) issues.
It surely can be discussed if /home actually should be owned by a package, but, as others have argued, it plays an established role in the Linux/UNIX FHS and therefore has to be created according to some proper rules. These rules say that it is a directory, owned by root:root with permission 755! When you want/need a different device to carry your /home directory, you can either bind-mount another directory (as I suggested in my initial reply), or bind a different block device to /home. This way rpm wouldn't complain about any inconsistency. So, if your HOME directories should live on a partition of your second disk /dev/sdb, you could use something like this:
- Use fdisk or parted (or your preferred partition tool) to create such a partition with your preferred file system type; ideally you assign it a unique label such as HOME - Then you could mount your home directory using something like LABEL=HOME /home auto defaults 1 2
I guess, your /home.server is already mounted like this. So, you could just replace /home.server in the line of your /etc/fstab with /home. No need for a symbolic link at all ;)
Yes, you are right, now my new fstab: # cat /etc/fstab UUID=uuid-xyz / btrfs defaults 0 0 UUID=uuid-xyz /var btrfs subvol=/@/var 0 0 UUID=uuid-xyz /usr/local btrfs subvol=/@/usr/local 0 0 UUID=uuid-xyz /tmp btrfs subvol=/@/tmp 0 0 UUID=uuid-xyz /srv btrfs subvol=/@/srv 0 0 UUID=uuid-xyz /root btrfs subvol=/@/root 0 0 UUID=uuid-xyz /opt btrfs subvol=/@/opt 0 0 UUID=uuid-xyz /home.local btrfs subvol=/@/home 0 0 UUID=uuid-xyz /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 UUID=uuid-xyz /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 UUID=uuid-abc /boot/efi vfat defaults 0 2 UUID=uuid-xyz /.snapshots btrfs subvol=/@/.snapshots 0 0 UUID=uuid-123 swap swap defaults 0 0 ## Remote Mounts server:/home /home.server nfs defaults 0 0 /home.server /home none bind 0 0 /home/all/bin /root/bin none bind 0 0 So I hope this will work fine :-) cheers :-) Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (2)
-
Manfred Hollstein -
ub22＠gmx.net