Discuss

discuss@lists.centos.org

8 participants
34745 discussions

/boot partition running out of space randomly. Please help!
by Sean Son 15 Feb '19

15 Feb '19

Hello all First off, I am running Oracle Linux 7.6 on a Hyper-V 2016 VM for a customer. I know this is not an Oracle Linux mailling list, but because Oracle Linux and CentOS are so similar, to an extent, I figured why not ask on here because someone MIGHT know the answer.. Here is the issue. I have a 600MB /boot partition allocated on a UEFI system. The /boot/efi partition is on a separate EFI partition. Recently, I noticed that this system has been crashing every few minutes and when I checked the disk space, I noticed that the /boot partition has zero free space available. I removed all of the old kernels and left the running kernel in place, in hopes that will free up some space. It freed up about 50MB or so, but then the system would crash again. After I would reboot the VM to bring the system back up, I ran a df -h /boot, and the results were reporting ZERO disk space again for the /boot partition.. It makes absolutely no sense how a partition which is generally static UNLESS you move something into it, is running out of space after space has been manually freed up in the partition! What boggles me even more is that when I do an ls -lh /boot, the file systems do not add up to 600M (well 594M) at all. See below: df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 2.8G 0 2.8G 0% /dev tmpfs 2.8G 0 2.8G 0% /dev/shm tmpfs 2.8G 8.5M 2.8G 1% /run tmpfs 2.8G 0 2.8G 0% /sys/fs/cgroup /dev/mapper/VolGroup00-LogVolRoot 30G 19G 12G 63% / /dev/sda2 594M 594M 0 100% /boot /dev/sda1 238M 9.7M 229M 5% /boot/efi /dev/mapper/VolGroup00-LogVolHome 3.3G 415M 2.9G 13% /home tmpfs 565M 0 565M 0% /run/user/54321 tmpfs 565M 0 565M 0% /run/user/1000 ]$ ls -lh /boot total 92M -rw-r--r-- 1 root root 179K Dec 12 22:52 config-4.14.35-1844.0.7.el7uek.x86_64 drwx------ 3 root root 16K Dec 31 1969 efi drwx------. 2 root root 21 Feb 8 15:55 grub2 -rw-------. 1 root root 54M Aug 28 12:31 initramfs-0-rescue-0287c4db206d4a9abe14f750b9091a01.img -rw------- 1 root root 22M Dec 21 17:24 initramfs-4.14.35-1844.0.7.el7uek.x86_64.img -rw-r--r-- 1 root root 329K Dec 12 22:52 symvers-4.14.35-1844.0.7.el7uek.x86_64.gz -rw-r--r-- 1 root root 3.6M Dec 12 22:52 System.map-4.14.35-1844.0.7.el7uek.x86_64 -rwxr-xr-x. 1 root root 6.1M Aug 28 12:31 vmlinuz-0-rescue-0287c4db206d4a9abe14f750b9091a01 -rwxr-xr-x 1 root root 7.2M Dec 12 22:52 vmlinuz-4.14.35-1844.0.7.el7uek.x86_64 I have no idea what is going on here and why the space keeps filling up and the VM crashing! ANY and all help will be greatly appreciated! Thanks! I am running the following kernel: 4.14.35-1844.0.7.el7uek.x86_64 Thanks! Sean S.

4 4

DNSSEC Questions
by Paul R. Ganci 15 Feb '19

15 Feb '19

Last weekend I had my DNSSEC keys expire. I discovered that they had expired the hard way... namely randomly websites could not be found and email did not get delivered. It seems that the keys were only valid for what I estimate was about 30 days. It is a real PITA to have update the keys, restart named and then update Godaddy with new digests. The first part of the problem is fairly manageable in the sense I already have a script that partially can do the job of updating the DNS server. However from what I can tell the only way I can update the DNSSEC of my 8 domains is via the Godaddy control panel GUI. So a couple of questions. 1.) Is anyone aware of anyway to update Godaddy DNSSEC data via a Centos 7 bash shell? I will contact Godaddy but I suspect I am SOL but thought I would ask here thinking somebody else may have already run into this issue. 2.) Assuming the answer to DNSSEC is no, can I at least have the keys last longer than they do by default. I am presently creating the keys via: > dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE zone > dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE zone It is very unclear to me given the dnssec-keygen man page how to set the date so that I could get 90 days or even more per key. The descriptions I found about constructing rolling keys was even more cryptic to me. For example, how do you use these switches: -A date/offset Sets the date on which the key is to be activated. After that date, the key will be included in the zone and used to sign it. If not set, and if the -G option has not been used, the default is "now". -D date/offset Sets the date on which the key is to be deleted. After that date, the key will no longer be included in the zone. (It may remain in the key repository, however.) -I date/offset Sets the date on which the key is to be retired. After that date, the key will still be included in the zone, but it will not be used to sign it. -P date/offset Sets the date on which a key is to be published to the zone. After that date, the key will be included in the zone but will not be used to sign it. If not set, and if the -G option has not been used, the default is "now". -R date/offset Sets the date on which the key is to be revoked. After that date, the key will be flagged as revoked. It will be included in the zone and will be used to sign it. Is it as simple as setting the -I and -R switches to something like +90d At least if I can get the DNS server to update via a cron job even if the 1st item will always have to be done manually that would be help. Thanks for your help. -- Paul (ganci(a)nurdog.com) Cell: (303)257-5208

3 5

question about upgrade qemu and libvirtd
by rong zhao 15 Feb '19

15 Feb '19

Hi Team, I am not sure if I should put my question here, I have googled long time, no explicit information found. Background: We need to support KVM encryption and decided to use LUKS. Refer to:https://libvirt.org/formatsecret.html#VolumeUsageType libvirtd and KVM should be able to support LUKS format disk directly. Unfortunately, seems that we need to use libvirt2.2+ and qemu 2.6+, because our current qemu-kvm version does not support luks format: And our hypervisor's OS is CentOS 7.2 with libvirt 2.0 and qemu-kvm 1.5.3 Question: Is there any safe way to upgrade to libvirt 2.2 and qemu 2.6? Safe way means: do not need to reboot hyper or VM, do not impact VM types support . Any suggestion is welcome. Thanks.

3 2

Centos bug 15570 - Not just a VBOX bug, can also reproduce on direct hardware install
by Steve Gomez 14 Feb '19

14 Feb '19

Ran into this rather frustrating bug when working with VBOX on a Windows 10 host. It should come as no surprise that I would hit this bug when installing CentOS, and also with RHEL 7 Server with GUI (since you get the same kernel). Based on information from your bug list, I was fortunately able to workaround the trouble with: wget https://people.centos.org/toracat/kernel/7/plus/bug15570new/kernel-3.10.0-9… wget https://people.centos.org/toracat/kernel/7/plus/bug15570new/kernel-devel-3.… yum -y localinstall kernel-3.10.0-957.1.3.bug15570.plus.el7.x86_64.rpm yum -y localinstall kernel-devel-3.10.0-957.1.3.bug15570.plus.el7.x86_64.rpm However, the bug lists seem to refer only to issues with VirtualBox. I have experienced the same symptom when installing on a "hardware" system (no hypervisor). The same commands above also provide a workaround here, but thought the flag should be raised for CentOS and RHEL that it doesn't seem to be just VBOX. Perhaps the priority of this issue should be raised further up the pole since I can't imagine it being a good experience for someone who doesn't know how to dig through a problem like this. The average bear would install something else and move on. In any case, thank you for the patch information. Look forward to a "real" fix soon. Other than that I'm really liking CentOS 7. SG

2 2

possible issue in Anaconda WRT processing %posttrans scriptlets?
by Brian Reichert 14 Feb '19

14 Feb '19

This sounds really weird, bear with me. I've put together a custom install CD derived from CentOS-7-x86_64-Minimal-1810.iso. I've added my RPMs in the mix, and have my dependencies lined up. The installation of the RPMs fail, from packaging.log: ... 15:42:35,741 INFO packaging: libwbclient-4.8.3-4.el7.x86_64 (320/432) 15:42:35,741 INFO packaging: samba-client-libs-4.8.3-4.el7.x86_64 (321/432) 15:42:35,742 INFO packaging: samba-libs-4.8.3-4.el7.x86_64 (322/432) 15:42:35,743 INFO packaging: samba-common-tools-4.8.3-4.el7.x86_64 (323/432) 15:42:35,743 INFO packaging: uid-admin-1-1.noarch (324/432) 15:42:35,743 INFO packaging: creating admin smbpasswd ... 15:42:35,743 INFO packaging: pdbedit: error while loading shared libraries: libwbclient.so.0: cannot open shared object file: No such file or directory 15:42:35,745 INFO packaging: error: %pre(uid-admin-1-1.noarch) scriptlet failed, exit status 127 15:42:35,745 INFO packaging: ==== end rpm scriptlet logs ==== To rewind this: - in my uid-admin RPM's %pre scriptlet, I invoke /usr/bin/pdbedit. - /usr/bin/pdbedit is provided by samba-common-tools. - samba-common-tools requires libwbclient. and we can see they have all gotten installed in the correct order. When I get to an alternate console, I did a search under /mnt/sysimage for libwbclient.so.0, and all I can find is this: /mnt/sysimage/usr/lib64/samba/wbclient/libwbclient.so.0 I can see that libwbclient's %posttrans scriptlet should have installed this shared library: # It has to be posttrans here to make sure all files of a previous version # without alternatives support are removed /usr/sbin/update-alternatives \ --install \ /usr/lib64/libwbclient.so.0.14 \ libwbclient.so.0.14-64 \ /usr/lib64/samba/wbclient/libwbclient.so.0.14 \ 10 /sbin/ldconfig Yet clearly, that didn't happen, and there's no dialog to the contrary. I was able to extract that scriptlet, and run it in the chrooted environment successfully. Is there something about anaconda-yum under CentOS 7 that does something counterintuitive WRT %posttrans scriptlets? -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large

1 0

dont run cron.d- when cron.daily-scripts are running
by Leon Fauster 14 Feb '19

14 Feb '19

EL6 context: cronie-1.4.4-16.el6_8.2.x86_64 cronie-anacron-1.4.4-16.el6_8.2.x86_64 crontabs-1.10-33.el6.noarch I have some cron.d entries that execute scripts in minute intervals and I'm wondering how could an "official" way look like, to have a condition to not run cron.d entries when cron.daily scripts are running. Sure, I can hack something around file timestamps or so but that feels not so streamlined ... I'd really appreciate any ideas ... -- LF

3 4

Support for Argon2 for password hashing
by Robert Moskowitz 13 Feb '19

13 Feb '19

Is there any information on adding support for Argon2? I have been working on my new mailserver and this came up in moving from the default MD5 hash to more 'modern' hashes like SHA256 and SHA512. Then I was pointed to the work behind Argon2, and I see that it is moving through the IRTF cfrg workgroup: draft-irtf-cfrg-argon2-04.txt It is a 'purpose built' hash for passwords, with recommendations that new implementations use it. Of course can't use it if crypt does not support it.... thanks

3 3

freeIPA from CR repo - conflicts
by lejeczek 13 Feb '19

13 Feb '19

hi guys do you see the same by any chance? .... --> Processing Dependency: ipa-server-common = 4.6.4-10.el7.centos.2 for package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch --> Processing Dependency: ipa-common = 4.6.4-10.el7.centos.2 for package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch --> Finished Dependency Resolution Error: Package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-server-common = 4.6.4-10.el7.centos.2 Installed: ipa-server-common-4.6.4-10.el7.centos.noarch (@cr) ipa-server-common = 4.6.4-10.el7.centos Error: Package: ipa-server-4.6.4-10.el7.centos.x86_64 (@cr) Requires: python2-ipaserver = 4.6.4-10.el7.centos Removing: python2-ipaserver-4.6.4-10.el7.centos.noarch (@cr) python2-ipaserver = 4.6.4-10.el7.centos Updated By: python2-ipaserver-4.6.4-10.el7.centos.2.noarch (updates) python2-ipaserver = 4.6.4-10.el7.centos.2 Error: Package: python2-ipaclient-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-common = 4.6.4-10.el7.centos.2 Installed: ipa-common-4.6.4-10.el7.centos.noarch (@cr) ipa-common = 4.6.4-10.el7.centos Error: Package: python2-ipaclient-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-client-common = 4.6.4-10.el7.centos.2 Installed: ipa-client-common-4.6.4-10.el7.centos.noarch (@cr) ipa-client-common = 4.6.4-10.el7.centos Error: Package: python2-ipalib-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-common = 4.6.4-10.el7.centos.2 Installed: ipa-common-4.6.4-10.el7.centos.noarch (@cr) ipa-common = 4.6.4-10.el7.centos Error: Package: ipa-client-4.6.4-10.el7.centos.x86_64 (@cr) Requires: python2-ipaclient = 4.6.4-10.el7.centos Removing: python2-ipaclient-4.6.4-10.el7.centos.noarch (@cr) python2-ipaclient = 4.6.4-10.el7.centos Updated By: python2-ipaclient-4.6.4-10.el7.centos.2.noarch (updates) python2-ipaclient = 4.6.4-10.el7.centos.2 Error: Package: python2-ipaserver-4.6.4-10.el7.centos.2.noarch (updates) Requires: ipa-common = 4.6.4-10.el7.centos.2 Installed: ipa-common-4.6.4-10.el7.centos.noarch (@cr) ipa-common = 4.6.4-10.el7.centos You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

1 0

Cups Ink Levels
by Mark LaPierre 13 Feb '19

13 Feb '19

Hey all, In this week's Open Source Highlights I read: "Check ink level: If you have an Epson, Canon, HP, or Sony printer, you can see its ink level with a simple application. Look for the "ink" package in your distribution repositories." I checked my package manager but I didn't find any "ink" package. Does such a package exist for Centos? Is so, what it the package called? -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****

2 1

persistent generic device for tape changer
by Helmut Drodofsky 12 Feb '19

12 Feb '19

Hello, mtx and therefor amanda use generic device /dev/sg<x> for tape changer. These devices change on reboot. How to make them persistent? /dev/sch0 and /dev/sch1 seem to be persistent. /dev/tape/by-id/ shows links from WWID to generic device An UDEV rule could help? I have not found any example. -- Viele Grüße Helmut Drodofsky Internet XS Service GmbH Heßbrühlstraße 15 70565 Stuttgart Geschäftsführung Helmut Drodofsky HRB 21091 Stuttgart USt.ID: DE190582774 Fon: 0711 781941 0 <tel:+497117819410> Fax: 0711 781941 79 Mail: info(a)internet-xs.de www.internet-xs.de

3 5

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