November 2019 - openSUSE Users - openSUSE Mailing Lists

[opensuse] setfacl problem
by Carlos E. R. 26 Nov '19

26 Nov '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi cer@Telcontar:/data/storage_b/cer> setfacl -m u:wwwrun:rx tmp/ cer@Telcontar:/data/storage_b/cer> setfacl -m u:users:rx tmp/ setfacl: Option -m: Invalid argument near character 3 cer@Telcontar:/data/storage_b/cer> l tmp/ total 4266952 drwxr-xr-x+ 3 cer cer 69 Nov 27 2011 ./ ... Why does one command work and not the other? I jus edited the group name, and both do exist. cer@Telcontar:/data/storage_b/cer> getfacl tmp # file: tmp # owner: cer # group: cer user::rwx user:wwwrun:r-x group::r-x mask::r-x other::r-x cer@Telcontar:/data/storage_b/cer> - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXd0piRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVklQAoJD/CSo0Yeug2W6Vbbzj cZC7f95tAJ0eqFr4Xo/SjMnpV0/WxMoNUvyPlw== =YzLT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

Re: [opensuse] Re: repomd.xml will expire soon
by Marcus Meissner 25 Nov '19

25 Nov '19

Hi, On Mon, Nov 25, 2019 at 06:47:05AM +0300, Andrei Borzenkov wrote: > > 24 нояб. 2019 г., в 22:37, Marcus Meissner <meissner(a)suse.de> написал(а): > > > > Hi, > > > > The repo key should auto extend itself. (Well the obs will do it.) > > > > We will monitor if this happens. > > > > Is it possible to configure OBS to do it earlier, to avoid zypper warnings? FWIW, the key is now extended until 2022. The repo will get the new key on its next republish. What repository was it actually? The original reporter did not say? Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] repomd.xml will expire soon
by Wolfgang Mueller 24 Nov '19

24 Nov '19

Invoking 'zypper patch' yielded--among others--the following response: > Retrieving repository 'Untested Updates' metadata----------------[\] > The gpg key signing file 'repomd.xml' will expire in 14 days. > Repository: Untested Updates > Key Name: openSUSE:Maintenance OBS Project <openSUSE:Maintenance@build.opensuse.org> > Key Fingerprint: 7C097045 B0D351D3 69AC453A 598D0E63 B3FD7E48 > Key Created: Fri Sep 29 19:30:59 2017 > Key Expires: Sun Dec 8 18:30:59 2019 (expires in 14 days) > Rpm Name: gpg-pubkey-b3fd7e48-59ce8353 > Retrieving repository 'Untested Updates' metadata.............[done] Is there any need to renew or prolongate the file repomd.xml? Or is it--as I suppose--dispensable? Thanks in advance, Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 8

[opensuse] Fwd: Re: [clamav-users] clamav-0.102.1 error - Update
by Frans de Boer 24 Nov '19

24 Nov '19

LS, Just want to give some inside because of the outdated software in openSUSE 15.1. Just fear that 15.2 will not be much better as to up-to-date software. I hope there will be a hybrid someday between the cutting edge (sort off) Tumbleweed and the stable distributions based on very old software. Frans >>> I get the next report (all systems): >>> /configure: line 30094: auto=yes: command not found >>> >>> Also, check_clamav failed on 2 different systems (openSUSE 15.1). It >>> did not failed on openSUSE Tumbleweed. >>> >>> --- Frans. >>> > http://www.clamav.net/contact.html#ml On all my systems using openSUSE Tumbleweed, all tests work as expected. Alas, under openSUSE 15.1 - with it's mostly antiquated software -, which is their newest "recent" stable distribution, does the test "check_clamav" fails. This applies both to clamav-0.102.0 and .1. The clamav-0.101.x series have no such problem. Regards, Frans. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 16

[opensuse] dracut --kernel-cmdline option not effective?
by Istvan Gabor 23 Nov '19

23 Nov '19

Hello: I would like to make an initrd image in openSUSE Leap 15.1 that has root=LABEL=... and resume=LABEL=... kernel command line options instead of root=UUID= and resume=UUID= . When I run mkinitrd it runs as: # mkinitrd Creating initrd: /boot/initrd-4.12.14-lp151.28.13-default dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp151.28.13-default 4.12.14-lp151.28.13-default ... dracut: *** Store current command line parameters *** dracut: Stored kernel commandline: dracut: resume=UUID=ca1f9a2d-468f-4718-b993-d7041556be8c dracut: root=UUID=c6a2aa57-1ff2-4ebd-a1fb-e56cf4b3a4b9 rootfstype=ext4 rootflags=rw,relatime,data=ordered dracut: *** Creating image file '/boot/initrd-4.12.14-lp151.28.13-default' *** dracut: *** Creating initramfs image file '/boot/initrd-4.12.14-lp151.28.13-default' done *** According to dracut man page I can customize kernel command line options with --kernel-cmdline option to dracut. Based on the above I ran dracut as: # /usr/bin/dracut --kernel-cmdline "root=LABEL=L151-KDE3-ext resume=LABEL=swap-OSL" --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp151.28.13-default 4.12.14-lp151.28.13-default dracut: Executing: /usr/bin/dracut --kernel-cmdline "root=LABEL=L151-KDE3-ext resume=LABEL=swap-OSL" --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp151.28.13-default 4.12.14-lp151.28.13-default ... dracut: *** Store current command line parameters *** dracut: Stored kernel commandline: dracut: root=LABEL=L151-KDE3-ext resume=LABEL=swap-OSL dracut: resume=UUID=ca1f9a2d-468f-4718-b993-d7041556be8c dracut: root=UUID=c6a2aa57-1ff2-4ebd-a1fb-e56cf4b3a4b9 rootfstype=ext4 rootflags=rw,relatime,data=ordered dracut: *** Creating image file '/boot/initrd-4.12.14-lp151.28.13-default' *** dracut: *** Creating initramfs image file '/boot/initrd-4.12.14-lp151.28.13-default' done *** It seems that dracut recognizes and applies --kernel-cmdline option values but then overwrites them by the system default values, at least that is how I interpret dracut output messages. What do I do wrong and how could I set only root=LABEL=L151-KDE3-ext and resume=LABEL=swap-OSL kernel command line options in the initrd image? Thanks, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 4

[opensuse] Security/Privacy Minded - 'Unblockable' web trackers emerge.
by David C. Rankin 23 Nov '19

23 Nov '19

Worth all being aware of -- courtesy of El Reg. Bad news: 'Unblockable' web trackers emerge. Good news: Firefox with uBlock Origin can stop it. Chrome, not so much https://www.theregister.co.uk/2019/11/21/ublock_origin_firefox_unblockable_… And the world called Kaczynski crazy....?? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

7 11

[opensuse] Minimal autoyast file not working on Tumbleweed
by Jim Fehlig 23 Nov '19

23 Nov '19

Hi, I'm trying to cook up a minimal autoyast file that I can use while adding openSUSE support to the CentOS CI for the various projects in the (lib)virt ecosystem [0][1]. The attached file works fine for everything except Tumbleweed, where I get the following error None or wrong base product has been defined in the AutoYaST configuration file. Please check the products entry in the software section. Following base products are available: openSUSE-MicroOS (openSUSE MicroOS) openSUSE (openSUSE Tumbleweed) But I can see that 'base', 'minimal_base', and 'yast2_basis' are included in the large list of patterns available to a Tumbleweed installation. Has something changed that would prevent installing Tumbleweed with this small list of patterns? Is there a better autoyast <software> configuration for a minimal system that works across Leap and Tumbleweed? [0] https://ci.centos.org/view/libvirt/ [1] https://libvirt.org/git/?p=libvirt-jenkins-ci.git

2 1

[opensuse] 42.3 -> 15.0 /usr/include/asm-x86 -> /usr/include/arch-x86/asm ??
by David C. Rankin 23 Nov '19

23 Nov '19

Devs, What caused the location of header files to change from /usr/include/asm-x86 to /usr/include/arch-x86/asm ?? What this a gcc change of a discretionary move? I believe gcc uses /usr/include/asm by default, so why do we put it somewhere else and why did it change? It's not a huge deal, but I'm curios about the change. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] Fail To Boot After Update to kernel-default-4.12.14-lp150.12.82.1 ??
by David C. Rankin 22 Nov '19

22 Nov '19

All, Devs, On a virtualbox install, zypper up to kernel-default-4.12.14-lp150.12.82.1 on 15.0 left the VM unable to boot - it hangs part way though the boot. Downgrade to kernel-default-4.12.14-lp150.12.79.1 works just fine. Attempts to rebuild the init with: # dracut -fM --kver 4.12.14-lp150.12.82-default completes successfully but does not solve the problem. I have removed (zypper rm'ed) kernel-default-4.12.14-lp150.12.82.1 and the system boots fine on the kernel-default-4.12.14-lp150.12.79.1 kernel. What to check as to why update to the new kernel failed? There is no persistent journal to check. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

6 16

[opensuse] Leap 15.1 on Lenovo P53
by Philippe Andersson 22 Nov '19

22 Nov '19

Disclaimer | Use of IBA e-communication<https://iba-worldwide.com/disclaimer> The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation.

2 2