Discuss

discuss@lists.centos.org

34753 discussions

C7 minimal (1511) firewalld is not installed: logical?
by Patrick Bervoets 02 Mar '16

02 Mar '16

I just installed a host with CentOS-7-x86_64-Minimal-1511.iso It seems that firewalld is not included in the minimal set. I wonder why? If I recall correctly CentOS-7-x86_64-Minimal-1503-01.iso did include it. And, this could be a very stupid question, am I running without a firewall or just without a way to control my firewall? Thanks Patrick

2 2

RasPi 3.x and RH-based Distro (Slightly OT)
by Benjamin Smith 02 Mar '16

02 Mar '16

With the release of the Rasberry Pi 3.x, I think we have a platform I could jump on board with. Performance has just been lacking until now! But I really don't want to jump the "RH ship" - I'd rather stick with an environment I am comfortable in. Can anybody comment here on the best way to run RHEL/Fedora/CentOS on a RasPi, or if there's even a useful port? Thanks Ben S

6 7

CentOS-announce Digest, Vol 133, Issue 1
by centos-announce-request＠centos.org 02 Mar '16

02 Mar '16

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2016:0298 CentOS 6 findutils FASTTRACK BugFix Update (Johnny Hughes) 2. CESA-2016:0301 Important CentOS 6 openssl Security Update (Johnny Hughes) 3. CESA-2016:0301 Important CentOS 7 openssl Security Update (Johnny Hughes) 4. CESA-2016:0302 Important CentOS 5 openssl Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Mar 2016 13:06:38 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2016:0298 CentOS 6 findutils FASTTRACK BugFix Update Message-ID: <20160301130638.GA3583(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2016:0298 Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-0298.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: ed1a7580800b4cb68fd882f39eafe9c4a0d8b2ec9ff6d25358f2f10d9cc35555 findutils-4.4.2-9.el6.i686.rpm x86_64: fbbb4d9e91b0a7cac328167d09a3591d9ee50e990d86da45bee99f8020a03db3 findutils-4.4.2-9.el6.x86_64.rpm Source: 8f0afaba4a8461e71ea4001750df754ff6406e5a68e5276c8aae4a36a6a9632c findutils-4.4.2-9.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Tue, 1 Mar 2016 16:09:29 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:0301 Important CentOS 6 openssl Security Update Message-ID: <20160301160929.GA26137(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:0301 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0301.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 31cacdfe88b5e4b420bd2dd1fe6b491b35a2a57c7e3b4ef5b960573b095fc519 openssl-1.0.1e-42.el6_7.4.i686.rpm a57701c0598a7c91de1eac55fa5b6ffe2bc096c07f757723d6de65dd092dbc66 openssl-devel-1.0.1e-42.el6_7.4.i686.rpm 3e62aef02b5a465d587a3c3dfec494b27d55ec2a5dac0a13e6ac842188728d66 openssl-perl-1.0.1e-42.el6_7.4.i686.rpm 621cd98e6d221febb477906443a1692afd64ffcc79cb843a146ee4583e7224f7 openssl-static-1.0.1e-42.el6_7.4.i686.rpm x86_64: 31cacdfe88b5e4b420bd2dd1fe6b491b35a2a57c7e3b4ef5b960573b095fc519 openssl-1.0.1e-42.el6_7.4.i686.rpm e5fc87d5031ea23db0eb2be92743a557d8574caa583fad6a1cd16a757ed436f3 openssl-1.0.1e-42.el6_7.4.x86_64.rpm a57701c0598a7c91de1eac55fa5b6ffe2bc096c07f757723d6de65dd092dbc66 openssl-devel-1.0.1e-42.el6_7.4.i686.rpm 17b6a4dbe2f844d3944fa7c4cafe9ccf4d54a8dc23d26201a513fc86bd08d256 openssl-devel-1.0.1e-42.el6_7.4.x86_64.rpm 4b9ec40e680ad72d6134283f3ab6179d2c4c8a34433aed4f42c5117bfeb300a5 openssl-perl-1.0.1e-42.el6_7.4.x86_64.rpm aaaf4d42ef5f48f424ed9d6d04744e906a15d3ae66097bcd3ec60be226879cd6 openssl-static-1.0.1e-42.el6_7.4.x86_64.rpm Source: 152d1ec6f40854680bbad1524f2b7766c8f583de6b1a136b635ec9b257d4b088 openssl-1.0.1e-42.el6_7.4.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 3 Date: Tue, 1 Mar 2016 16:41:22 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:0301 Important CentOS 7 openssl Security Update Message-ID: <20160301164122.GA26845(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:0301 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0301.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: b2aaed03ed2d01d2a6482ed97a95aec0545ffc4c00ad46c7cafc10c9554e1b58 openssl-1.0.1e-51.el7_2.4.x86_64.rpm b1aa349c2ea3a99cc65d031850d415b7feb7924f0a121593c12b439934440eb4 openssl-devel-1.0.1e-51.el7_2.4.i686.rpm 3e194452a2616702ee91e791b163b739d012da52957f6e91927de9d554e4e203 openssl-devel-1.0.1e-51.el7_2.4.x86_64.rpm 2e193ea886626e3e8b151f905920503e2e505cc2bdfef31a8d38a581c99e210f openssl-libs-1.0.1e-51.el7_2.4.i686.rpm 249cc7d68c0d8d48a26b50066ed29da2d70c7a573d23dc566ee7c99f5c5f71c9 openssl-libs-1.0.1e-51.el7_2.4.x86_64.rpm 61cfe9edcb1d521b2978fee1acda2a9cba73f2c371bc9217b44bd527569938c5 openssl-perl-1.0.1e-51.el7_2.4.x86_64.rpm a5d2395db7a0c87d069e3fc80e55deacffeea5acc5162058075a746871954ce7 openssl-static-1.0.1e-51.el7_2.4.i686.rpm e48dd73a4f9bc7d3b6617842414a1b50fc086c720795451ca4795ecd08ba3b22 openssl-static-1.0.1e-51.el7_2.4.x86_64.rpm Source: 26fa86503898fa5fcf91188aa6f56172ea1896e4d4943bd407aa54d21d330618 openssl-1.0.1e-51.el7_2.4.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 4 Date: Tue, 1 Mar 2016 16:57:33 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:0302 Important CentOS 5 openssl Security Update Message-ID: <20160301165733.GA16183(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:0302 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-0302.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 045550a5b7552b7a9cd5ea7a1f866de367e3bf677d240925d633a1b7938cd07a openssl-0.9.8e-39.el5_11.i386.rpm 8c73a864ce991ba4e6c950cc6ca642c09a7753fc5aa793a0a23e683ba5df99e9 openssl-0.9.8e-39.el5_11.i686.rpm 230b07861835e3a65052e45b617a73cbbd3057c6db38d315dbed7b3d01f1fba6 openssl-devel-0.9.8e-39.el5_11.i386.rpm c63d611b4519928413ed611a020d7e7113ccbf6890b264b4b8399f9af7bf6140 openssl-perl-0.9.8e-39.el5_11.i386.rpm x86_64: 8c73a864ce991ba4e6c950cc6ca642c09a7753fc5aa793a0a23e683ba5df99e9 openssl-0.9.8e-39.el5_11.i686.rpm d7e159cfd9e991adf152df48cb97751c8a26601b1f3f3a70a3e137efb05e0c35 openssl-0.9.8e-39.el5_11.x86_64.rpm 230b07861835e3a65052e45b617a73cbbd3057c6db38d315dbed7b3d01f1fba6 openssl-devel-0.9.8e-39.el5_11.i386.rpm f6bc29a1ab08303174206210af09b37ec53f0c0d643f18bf98427b20f2cb4a67 openssl-devel-0.9.8e-39.el5_11.x86_64.rpm 7953dcc480ff7815f39943f62fc848b3ce7ecb66217d2829332d95be4400c13d openssl-perl-0.9.8e-39.el5_11.x86_64.rpm Source: e0dab71e400c340b8eed7770c582ce6f3768888a61b4c492411d20e81ae1a9a6 openssl-0.9.8e-39.el5_11.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: JohnnyCentOS ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 133, Issue 1 ***********************************************

1 0

Any experiences with newer WD Red drives?
by Emmanuel Noobadmin 02 Mar '16

02 Mar '16

Might be slightly OT as it isn't necessarily a CentOS related issue. I've been using WD Reds as mdraid components which worked pretty well for non-IOPS intensive workloads. However, the latest C7 server I built, ran into problems with them on on a Intel C236 board (SuperMicro X11SSH) with tons of "ata bus error write fpdma queued". Googling on it threw up old suggestions to limit SATA link speed to 1.5Gbps using libata.force boot options and/or noncq. Lowering the link speed helped to reduce the frequency of the errors (from not getting a smartctl output to getting a complete listing within 2 tries). Tried two Reds produced in Jan 2016, two HGST, two SSDs on the same combination of cable/bay/SATA port as well as different combos. SSD maxed out at 450Mbps dd write test so doesn't appear to be lousy cables or board problem. Basically only the Reds were having problems. Strange thing is a netinstall of CentOS 7.0 "minimal" worked with one of the Reds before starting to cough. Now that I think about it, could be due to an update to 7.2 after installing. Needed to get the server out the door ASAP so didn't have time to try C6 once I confirmed it was the drive and promptly replaced it with another HGST. Since I'm likely to use Reds again, it is a bit of a concern. So wondering if I just happen to get an unlucky batch, or is there some incompatibility between the Reds and the Intel C236 chipset, or between Red / C236 / Centos 7 combo or the unlikely chance WD has decided to do something with the firmware to make them work on on NAS and not workstation/server chipsets to make people buy better stuff. Anybody has recent experiences with them recently on the same chipset with C7?

6 10

ssh issues with centos 6
by William Warren 01 Mar '16

01 Mar '16

I have a new centos 6 install. Randomly i get out of memory messages and my ssh file transfer dies. I have tried this in filezilla as well as winscp. I have disabled motd in ssh and i also had entropy problems so i enacted rngd -r /dev/urandom -o /dev/random but did not stop the out of memory errors. I am seeing the below in the logs. It only occurs during ssh file transfers. Feb 28 17:18:19 web1 t of memory [13604]

3 2

making a new initrd
by Philip Manuel 01 Mar '16

01 Mar '16

Hi, I built a new kernel for C7 that contains the required driver for a new motherboard we have here. I'd like to take this initramfs and rebuild it/modify it so that it is suitable for pxe booting. I have tried dracut -v --force --add "anaconda" initramfs.img # results in an image that is too large for tftp Or dracut --nofscks --nomdadmconf --nolvmconf --xz --no-early-microcode -m "anaconda" --force initramfs.img # kernel panics What steps should I be taking to create an initrd image suitable for pxe boot ? Thanks

1 0

Pi 2 Alternatives
by Chris Olson 01 Mar '16

01 Mar '16

We have a requirement for a new application that will be used fixed, portable, and mobile. The hardware requirements drive the need for networking as well as some general purpose and special purpose interfaces. The software requirements are quite simple in comparison to many of our much larger systems with similar hardware requirements. We are not significantly restricted in choice of storage peripherals or other devices that may be needed. We believe that a small, single board computer will meet all requirements as long as it can run Linux. We have identified the need for approximately six prototyping units to support the initial production of about 200 to 300 operational systems. Our development and deployment time frame does not drive the need for an extremely rapid product decision, and there are pre-planned upgrade cycles over the next five years. An internal group has achieved a significant head of steam in support of using the Pi 2 Model B. The support enthusiasm may be partly technical and partly the hype associated with jumping into the Pi community. The number of suppliers does appear to support our supply chain and sustainment requirements, however the Linux available for the Pi 2 does not appear to be optimal. It would be better if there were choices that include a standard Linux distribution such as CentOS. This certainly seems like one of those situations where a trade of single board computer products is appropriate and achievable. There are products similar to the Pi 2 capable of running a more standard Linux distribution that we might consider. Does anyone have an experience-based single board computer recommendation? Thanks in advance for any product recommendations.

4 3

Hung kernel task on CentOS 7.2, fprintd and libvirtd
by Warren Young 01 Mar '16

01 Mar '16

A CentOS 7 box here recently started being very slow to give the Password prompt when using sudo. (25 seconds!) I eventually tracked this down to the following complaint in the kernel message log: > Feb 26 12:55:05 badboy kernel: INFO: task fprintd:1932 blocked for more than 120 seconds. > Feb 26 12:55:05 badboy kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Feb 26 12:55:05 badboy kernel: fprintd D ffff88021f7300f8 0 1932 1 0x00000080 > Feb 26 12:55:05 badboy kernel: ffff88022354bdc0 0000000000000086 ffff8800c54e8000 ffff88022354bfd8 > Feb 26 12:55:05 badboy kernel: ffff88022354bfd8 ffff88022354bfd8 ffff8800c54e8000 ffff88021f7300f0 > Feb 26 12:55:05 badboy kernel: ffff88021f7300f4 ffff8800c54e8000 00000000ffffffff ffff88021f7300f8 > Feb 26 12:55:05 badboy kernel: Call Trace: > Feb 26 12:55:05 badboy kernel: [<ffffffff8163b9e9>] schedule_preempt_disabled+0x29/0x70 > Feb 26 12:55:05 badboy kernel: [<ffffffff816396e5>] __mutex_lock_slowpath+0xc5/0x1c0 > Feb 26 12:55:05 badboy kernel: [<ffffffff81638b4f>] mutex_lock+0x1f/0x2f > Feb 26 12:55:05 badboy kernel: [<ffffffff81449729>] read_descriptors+0x39/0x110 > Feb 26 12:55:05 badboy kernel: [<ffffffff8125c28b>] ? read+0x6b/0x1f0 > Feb 26 12:55:05 badboy kernel: [<ffffffff8125c2fb>] read+0xdb/0x1f0 > Feb 26 12:55:05 badboy kernel: [<ffffffff811de43c>] vfs_read+0x9c/0x170 > Feb 26 12:55:05 badboy kernel: [<ffffffff811def8f>] SyS_read+0x7f/0xe0 > Feb 26 12:55:05 badboy kernel: [<ffffffff81645909>] system_call_fastpath+0x16/0x1b Since fprintd is the fingerprint reader daemon and this server doesn’t have such a peripheral, I removed the service. Now sudo is fast again. [*] Although that solves my immediate problem, while debugging all of this I noticed substantially the same error message also appearing for libvirtd: > Feb 26 12:57:05 badboy kernel: INFO: task libvirtd:1514 blocked for more than 120 seconds. > Feb 26 12:57:05 badboy kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Feb 26 12:57:05 badboy kernel: libvirtd D ffff88021f7300f8 0 1514 1 0x00000080 > Feb 26 12:57:05 badboy kernel: ffff8800c08ffde0 0000000000000086 ffff8800c550e780 ffff8800c08fffd8 > Feb 26 12:57:05 badboy kernel: ffff8800c08fffd8 ffff8800c08fffd8 ffff8800c550e780 ffff88021f7300f0 > Feb 26 12:57:05 badboy kernel: ffff88021f7300f4 ffff8800c550e780 00000000ffffffff ffff88021f7300f8 > Feb 26 12:57:05 badboy kernel: Call Trace: > Feb 26 12:57:05 badboy kernel: [<ffffffff8163b9e9>] schedule_preempt_disabled+0x29/0x70 > Feb 26 12:57:05 badboy kernel: [<ffffffff816396e5>] __mutex_lock_slowpath+0xc5/0x1c0 > Feb 26 12:57:05 badboy kernel: [<ffffffff81638b4f>] mutex_lock+0x1f/0x2f > Feb 26 12:57:05 badboy kernel: [<ffffffff81449100>] manufacturer_show+0x20/0x50 > Feb 26 12:57:05 badboy kernel: [<ffffffff813f1c20>] dev_attr_show+0x20/0x60 > Feb 26 12:57:05 badboy kernel: [<ffffffff8125928a>] sysfs_read_file+0x9a/0x1a0 > Feb 26 12:57:05 badboy kernel: [<ffffffff811de43c>] vfs_read+0x9c/0x170 > Feb 26 12:57:05 badboy kernel: [<ffffffff811def8f>] SyS_read+0x7f/0xe0 > Feb 26 12:57:05 badboy kernel: [<ffffffff81645909>] system_call_fastpath+0x16/0x1b I don’t want to employ the same solution in this case — i.e. disable libvirtd — because while I don’t yet use KVM on that server, I actually had plans to do so soon. I could host those VMs elsewhere, but that feels like sweeping the problem under the rug. I want to fix this, but I’m now stuck. I’ve ruled out several possible causes already: 1. It isn’t DNS. DNS responds quickly. 2. It isn’t a flaky OS drive. Swapping the spinning rust drive out for an SSD was already on the wish list for this system, so I took the opportunity to reinstall the OS fresh on a brand new SSD. The same problem occurred shortly after booting CentOS 7.2 for the first time, and it continues to happen periodically. The only thing I’ve copied over from the old spinning drive so far is /home and /usr/local, and I can’t see how that could affect the kernel. Besides, the problem still occurs while booted into single-user mode. 3. It isn’t the RAID card. A RAID verify pass completed successfully, as did smartctl -t long tests on all of the individual drives. I even disabled the RAID card’s OPROM and blacklisted its driver at one point, just to see if the driver or RAID BIOS were the cause of the problem. I haven’t actually pulled the card yet, but that seems unlikely to solve anything, given that the array seems to be storing data reliably. 4. It isn’t the RAM. It just passed a memtest86+ run. That probably exonerates the CPU and north bridge, too. (I used v4.20 from the CentOS 7.2 install ISO.) 5. It isn’t stale packages. The OS reinstall proves that. It’s currently running the tip of CentOS 7.2 and still showing the same symptoms. 6. It isn’t high-uptime kernel space cruft, since it’s been rebooted a bunch of times during all of this, including several hard reboots. Rebooting is especially painful at the moment because the system hangs on shutdown waiting for libvirtd to respond. While I had fprintd installed, that was causing 3-minute hangs on boot, too. Very frustrating! [*] In case it isn’t clear how fprintd could affect sudo, it’s because fprintd installs a PAM module, and sudo uses PAM for authentication. If fprintd is stuck, the PAM call stalls until it gives up and moves on. I tracked this down with strace. The 25 seconds above is the timeout value passed to poll(2); that timeout is hit while sudo (via PAM) is trying to talk to dbus, since apparently fprintd communicates via dbus. Because the problem is in PAM and not sudo, it also affected su. It did not affect console or ssh user logins for some reason. I’m posting these details in case this diagnosis helps someone. While chasing this, I found a bunch of postings on the net from people who have run into such problems before, but none of the threads mentioned this particular failure mode. For all I know, I’m the first person it’s ever happened to, so this needs to be in the archives.

2 2

Discarding empty lines in rsyslog
by Anand Buddhdev 29 Feb '16

29 Feb '16

Dear CentOS folk, I've been try to solve one issue with rsyslog on CentOS 6, but can't figure it out. I've searched through rsyslog documentation, and used Google but not found anything that matches my issue. I'm sending output of a program to rsyslog using "logger -t progname". I've got the following config snippet in /etc/rsyslog.d: $FileCreateMode 0644 if $programname == 'progname' then /var/log/prog.log & ~ This works. However, the program sometimes produces blank lines its output, and they get logged by rsyslog as well. I want to make rsyslog ignore empty lines. I am trying the following, but it doesn't work: if $programname == 'progname' and $msg != '\n' then /var/log/prog.log Does anyone know how to get this to work in rsyslog? This is rsyslog 5 on CentOS 6. Regards, Anand

1 1

Odd selinux complaints on new, fully updated CentOS 7
by m.roth＠5-cent.us 29 Feb '16

29 Feb '16

Just installed 7.2, and I'm seeing this - is this a bug in the policy? ************************** SELinux is preventing systemd-readahe from add_name access on the directory .readahead.new. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow systemd-readahe to have add_name access on the .readahead.new directory Then you need to change the label on .readahead.new Do # semanage fcontext -a -t FILE_TYPE '.readahead.new' where FILE_TYPE is one of the following: device_t, init_var_run_t, readahead_var_lib_t, readahead_var_run_t, root_t, var_run_t. Then execute: restorecon -v '.readahead.new' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that systemd-readahe should be allowed add_name access on the .readahead.new directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-readahe /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:readahead_t:s0 Target Context system_u:object_r:mnt_t:s0 Target Objects .readahead.new [ dir ] Source systemd-readahe Source Path systemd-readahe Port <Unknown> Host <hostname> Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-60.el7_2.3.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name <hostname> Platform Linux <hostname> 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 Alert Count 4 First Seen 2016-02-29 10:06:27 EST Last Seen 2016-02-29 16:50:22 EST Local ID 0ba32e6a-e502-45be-a2dc-cda4c380a2bb Raw Audit Messages type=AVC msg=audit(1456782622.230:435): avc: denied { add_name } for pid=410 comm="systemd-readahe" name=".readahead.new" scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Hash: systemd-readahe,readahead_t,mnt_t,dir,add_name ***************************************** mark

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss