Search results for "Linux ./configure"

Re: [CentOS] C7, mdadm issues

by mark

Alessandro Baggi wrote: > Il 30/01/19 16:33, mark ha scritto: > >> Alessandro Baggi wrote: >> >>> Il 30/01/19 14:02, mark ha scritto: >>> >>>> On 01/30/19 03:45, Alessandro Baggi wrote: >>>> >>>>> Il 29/01/19 20:42, mark ha scritto: >>>>> >>>>>> Alessandro Baggi wrote: >>>>>> >>>>>>> Il 29/01/19 18:47, mark ha scritto: >>>>>>> >>>>>>>> Alessandro Baggi wrote: >>>>>>>> >>>>>>>>> Il 29/01/19 15:03, mark ha scritto: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I've no idea what happened, but the box I was working >>>>>>>>>> on last week has a *second* bad drive. Actually, I'm >>>>>>>>>> starting to wonder about that particulare hot-swap bay. >>>>>>>>>> >>>>>>>>>> Anyway, mdadm --detail shows /dev/sdb1 remove. I've >>>>>>>>>> added /dev/sdi1... >>>>>>>>>> but see both /dev/sdh1 and /dev/sdi1 as spare, and have >>>>>>>>>> yet to find a reliable way to make either one active. >>>>>>>>>> >>>>>>>>>> Actually, I would have expected the linux RAID to >>>>>>>>>> replace a failed one with a spare.... >>>>>> >>>>>>>>> can you report your raid configuration like raid level >>>>>>>>> and raid devices and the current status from /proc/mdstat? >>>>>>>>> >>>>>>>>> >>>>>>>> Well, nope. I got to the point of rebooting the system (xfs >>>>>>>> had the RAID volume, and wouldn't let go; I also commented >>>>>>>> out the RAID volume. >>>>>>>> >>>>>>>> It's RAID 5, /dev/sdb *also* appears to have died. If I do >>>>>>>> mdadm --assemble --force -v /dev/md0 /dev/sd[cefgdh]1 >>>>>>>> mdadm: >>>>>>>> looking for devices for /dev/md0 mdadm: /dev/sdc1 is >>>>>>>> identified as a member of /dev/md0, slot 0. mdadm: /dev/sdd1 >>>>>>>> is identified as a member of /dev/md0, slot -1. mdadm: >>>>>>>> /dev/sde1 is identified as a member of /dev/md0, slot >>>>>>>> 2. >>>>>>>> mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot >>>>>>>> 3. >>>>>>>> mdadm: /dev/sdg1 is identified as a member of /dev/md0, slot >>>>>>>> 4. >>>>>>>> mdadm: /dev/sdh1 is identified as a member of /dev/md0, slot >>>>>>>> -1. >>>>>>>> mdadm: no uptodate device for slot 1 of /dev/md0 >>>>>>>> mdadm: added /dev/sde1 to /dev/md0 as 2 >>>>>>>> mdadm: added /dev/sdf1 to /dev/md0 as 3 >>>>>>>> mdadm: added /dev/sdg1 to /dev/md0 as 4 >>>>>>>> mdadm: no uptodate device for slot 5 of /dev/md0 >>>>>>>> mdadm: added /dev/sdd1 to /dev/md0 as -1 >>>>>>>> mdadm: added /dev/sdh1 to /dev/md0 as -1 >>>>>>>> mdadm: added /dev/sdc1 to /dev/md0 as 0 >>>>>>>> mdadm: /dev/md0 assembled from 4 drives and 2 spares - not >>>>>>>> enough to start the array. >>>>>>>> >>>>>>>> --examine shows me /dev/sdd1 and /dev/sdh1, but that both >>>>>>>> are spares. >>>>>>> Hi Mark, >>>>>>> please post the result from >>>>>>> >>>>>>> cat /sys/block/md0/md/sync_action >>>>>> >>>>>> There is none. There is no /dev/md0. mdadm refusees, saying >>>>>> that it's lost too many drives. >>>>>> >>>>>> mark >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CentOS mailing list >>>>>> CentOS(a)centos.org >>>>>> https://lists.centos.org/mailman/listinfo/centos >>>>>> >>>>> >>>>> I suppose that your config is 5 drive and 1 spare with 1 drive >>>>> failed. It's strange that your spare was not used for resync. Then >>>>> you added a new drive but it does not start because it marks the >>>>> new disk as spare and you have a raid5 with 4 devices and 2 >>>>> spares. >>>>> >>>>> First I hope that you have a backup for all your data and don't >>>>> run some exotic command before backupping your data. If you can't >>>>> backup your data, it's a problem. >>>> >>>> This is at work. We have automated nightly backups, and I do >>>> offline backups of the backups every two weeks. >>>>> >>>>> Have you tried to remove the last added device sdi1 and restart >>>>> the raid and force to start a resync? >>>> >>>> The thing is, it had one? two? spares when /dev/sdb1 started dying, >>>> and it didn't use them. >>>>> >>>>> Have you tried to remove this 2 devices and re-add only the >>>>> device that will be usefull for resync? Maybe you can set 5 >>>>> devices for your raid and not 6, if it works (after resync) you >>>>> can add your spare device growing your raid set. >>>> >>>> I tried, and that's when I lost it (again), and it refuses to >>>> assemble/start the RAID "not enough devices". >>>>> >>>>> Reading on google many users use --zero-superblock before re-add >>>>> the device. >>>> >>>> I can take one out, and re-add, but I think I'm going to have to >>>> recreate the RAID again, and again restore from backup. >>>>> >>>>> Other user reassemble the raid using --assume-clean but I don't >>>>> know what effect it will produces >>> >>> Hope that someone give you a better help for this. >>> >>> >>> Update here if you got the solution. >>> >>> >> >> Not that I'm into American football, but I seem to have pulled off what >> I >> understand is called a hail-mary: *without* zeroing the superrblocks, I >> did a create with all six good drives, excluding /dev/sdb1, and >> explicitly told it one spare. >> >> And the array is there, complete with data, with *one* spare, five good >> drives, and it's currently rebuilding the spare. >> >> The last resort worked, though we'll see how long. >> > So you have recreated the array without faulty device? > Yep. mdadm --create --verbose /dev/md0 --level=5 --raid-devices=6 /dev/sd[cdefgh]1 It's currently at 2.2% recovered for the extra drive. mark

7 years, 2 months

Re: [CentOS] yum update / kernal update failed - remove or repair

by Gary Stainburn

I have managed to find out what happened in the yum update and it turns out it was a mess. It looks like the server ran out of memory in the middle and things then started to fail. Any advice on how to recover from this would be greatly appreciated The log below shows: [root@vps2 ~]# yum history info 22 Loaded plugins: fastestmirror, langpacks Repository mariadb is listed more than once in the configuration Transaction ID : 22 Begin time : Sun Jan 19 18:15:33 2020 Begin rpmdb : 795:6c5cd82e3ada047c7071fea1524f41fd13fab6a1 End time : 19:19:32 2020 (63 minutes) End rpmdb : 801:6d1b278ccbeef6f68ff494cb28eaed5c7be4124b User : root <root> Return-Code : Failure: 1 Command Line : update Transaction performed with: Installed rpm-4.11.3-40.el7.x86_64 @anaconda Installed yum-3.4.3-163.el7.centos.noarch @anaconda Installed yum-plugin-fastestmirror-1.1.31-52.el7.noarch @anaconda Packages Altered: Updated MariaDB-client-10.4.10-1.el7.centos.x86_64 @mariadb Update 10.4.11-1.el7.centos.x86_64 @mariadb Updated MariaDB-common-10.4.10-1.el7.centos.x86_64 @mariadb Update 10.4.11-1.el7.centos.x86_64 @mariadb Updated MariaDB-compat-10.4.10-1.el7.centos.x86_64 @mariadb Update 10.4.11-1.el7.centos.x86_64 @mariadb ** Updated MariaDB-server-10.4.10-1.el7.centos.x86_64 @mariadb Loading mirror speeds from cached hostfile * base: mirror.as29550.net * epel: www.mirrorservice.org * extras: www.mirrorservice.org * remi-php73: mirrors.ukfast.co.uk * remi-safe: mirrors.ukfast.co.uk * updates: www.mirrorservice.org ** Update 10.4.11-1.el7.centos.x86_64 @?mariadb ** Updated MariaDB-shared-10.4.10-1.el7.centos.x86_64 @mariadb Update 10.4.11-1.el7.centos.x86_64 @mariadb ** Updated ca-certificates-2018.2.22-70.0.el7_5.noarch @anaconda ** Update 2019.2.32-76.el7_7.noarch @?updates Updated certbot-0.39.0-1.el7.noarch @epel Update 1.0.0-1.el7.noarch @epel Updated clamav-0.101.4-1.el7.x86_64 @epel Update 0.101.5-1.el7.x86_64 @epel Updated clamav-data-0.101.4-1.el7.noarch @epel Update 0.101.5-1.el7.noarch @epel Updated clamav-devel-0.101.4-1.el7.x86_64 @epel Update 0.101.5-1.el7.x86_64 @epel Updated clamav-filesystem-0.101.4-1.el7.noarch @epel Update 0.101.5-1.el7.noarch @epel Updated clamav-lib-0.101.4-1.el7.x86_64 @epel Update 0.101.5-1.el7.x86_64 @epel Updated clamav-update-0.101.4-1.el7.x86_64 @epel Update 0.101.5-1.el7.x86_64 @epel Updated clamd-0.101.4-1.el7.x86_64 @epel Update 0.101.5-1.el7.x86_64 @epel Updated curl-7.29.0-54.el7.x86_64 @anaconda Update 7.29.0-54.el7_7.1.x86_64 @updates Updated fail2ban-0.9.7-1.el7.noarch @epel Update 0.10.4-1.el7.noarch @epel Updated fail2ban-firewalld-0.9.7-1.el7.noarch @epel Update 0.10.4-1.el7.noarch @epel Updated fail2ban-sendmail-0.9.7-1.el7.noarch @epel Update 0.10.4-1.el7.noarch @epel Updated fail2ban-server-0.9.7-1.el7.noarch @epel Update 0.10.4-1.el7.noarch @epel Updated fail2ban-systemd-0.9.7-1.el7.noarch @epel Update 0.10.4-1.el7.noarch @epel Updated fribidi-1.0.2-1.el7.x86_64 @anaconda Update 1.0.2-1.el7_7.1.x86_64 @updates Updated iproute-4.11.0-25.el7.x86_64 @anaconda Update 4.11.0-25.el7_7.2.x86_64 @updates Install kernel-3.10.0-1062.9.1.el7.x86_64 @updates Updated kernel-headers-3.10.0-1062.4.3.el7.x86_64 @updates Update 3.10.0-1062.9.1.el7.x86_64 @updates Updated kernel-tools-3.10.0-1062.4.3.el7.x86_64 @updates Update 3.10.0-1062.9.1.el7.x86_64 @updates Updated kernel-tools-libs-3.10.0-1062.4.3.el7.x86_64 @updates Update 3.10.0-1062.9.1.el7.x86_64 @updates Updated libblkid-2.23.2-61.el7.x86_64 @anaconda Update 2.23.2-61.el7_7.1.x86_64 @updates Updated libcurl-7.29.0-54.el7.x86_64 @anaconda Update 7.29.0-54.el7_7.1.x86_64 @updates Updated libgs-9.25-2.el7_7.2.x86_64 @updates Update 9.25-2.el7_7.3.x86_64 @updates Updated libmount-2.23.2-61.el7.x86_64 @anaconda Update 2.23.2-61.el7_7.1.x86_64 @updates Updated libsmartcols-2.23.2-61.el7.x86_64 @anaconda Update 2.23.2-61.el7_7.1.x86_64 @updates Updated libsss_idmap-1.16.4-21.el7.x86_64 @anaconda Update 1.16.4-21.el7_7.1.x86_64 @updates Updated libsss_nss_idmap-1.16.4-21.el7.x86_64 @anaconda Update 1.16.4-21.el7_7.1.x86_64 @updates Updated libuuid-2.23.2-61.el7.x86_64 @anaconda Update 2.23.2-61.el7_7.1.x86_64 @updates Updated libwebp7-1.0.2-1.el7.remi.x86_64 @remi-safe Update 1.0.3-1.el7.remi.x86_64 @remi-safe ** Updated microcode_ctl-2:2.1-53.3.el7_7.x86_64 @updates Update 2:2.1-53.7.el7_7.x86_64 @updates Updated nss-3.44.0-4.el7.x86_64 @anaconda Update 3.44.0-7.el7_7.x86_64 @updates Updated nss-softokn-3.44.0-5.el7.x86_64 @anaconda Update 3.44.0-8.el7_7.x86_64 @updates Updated nss-softokn-freebl-3.44.0-5.el7.x86_64 @anaconda Update 3.44.0-8.el7_7.x86_64 @updates Updated nss-sysinit-3.44.0-4.el7.x86_64 @anaconda Update 3.44.0-7.el7_7.x86_64 @updates Updated nss-tools-3.44.0-4.el7.x86_64 @anaconda Update 3.44.0-7.el7_7.x86_64 @updates Updated nss-util-3.44.0-3.el7.x86_64 @anaconda Update 3.44.0-4.el7_7.x86_64 @updates Updated numactl-libs-2.0.12-3.el7.x86_64 @anaconda Update 2.0.12-3.el7_7.1.x86_64 @updates Updated pgdg-redhat-repo-42.0-5.noarch @/pgdg-centos10-10-2.noarch Update 42.0-6.noarch @pgdg10 Updated php-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-cli-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-common-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-gd-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-json-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-ldap-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-mysqlnd-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-odbc-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-pdo-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 ** Updated php-pear-1:1.10.10-2.el7.remi.noarch @remi-php70 ** Update 1:1.10.10-4.el7.remi.noarch @?remi-php73 Updated php-pgsql-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-process-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-xml-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated php-xmlrpc-7.3.12-1.el7.remi.x86_64 @remi-php73 Update 7.3.13-1.el7.remi.x86_64 @remi-php73 Updated postgresql10-10.11-1PGDG.rhel7.x86_64 @pgdg10 Update 10.11-2PGDG.rhel7.x86_64 @pgdg10 Updated postgresql10-contrib-10.11-1PGDG.rhel7.x86_64 @pgdg10 Update 10.11-2PGDG.rhel7.x86_64 @pgdg10 Updated postgresql10-libs-10.11-1PGDG.rhel7.x86_64 @pgdg10 Update 10.11-2PGDG.rhel7.x86_64 @pgdg10 ** Updated postgresql10-server-10.11-1PGDG.rhel7.x86_64 @pgdg10 Update 10.11-2PGDG.rhel7.x86_64 @pgdg10 ** Updated proftpd-1.3.5e-7.el7.x86_64 @epel Update 1.3.5e-8.el7.x86_64 @epel Updated python-perf-3.10.0-1062.4.3.el7.x86_64 @updates Update 3.10.0-1062.9.1.el7.x86_64 @updates Updated python-requests-2.6.0-7.el7_7.noarch @updates Update 2.6.0-8.el7_7.noarch @updates Updated python2-acme-0.39.0-1.el7.noarch @epel Update 1.0.0-1.el7.noarch @epel Updated python2-certbot-0.39.0-1.el7.noarch @epel Update 1.0.0-1.el7.noarch @epel Updated python2-certbot-apache-0.39.0-1.el7.noarch @epel Update 1.0.0-1.el7.noarch @epel Updated selinux-policy-3.13.1-252.el7.1.noarch @updates Update 3.13.1-252.el7_7.6.noarch @updates Updated selinux-policy-targeted-3.13.1-252.el7.1.noarch @updates Update 3.13.1-252.el7_7.6.noarch @updates Updated sos-3.7-7.el7.centos.noarch @updates Update 3.7-10.el7.centos.noarch @updates ** Updated sssd-client-1.16.4-21.el7.x86_64 @anaconda Update 1.16.4-21.el7_7.1.x86_64 @updates Updated tcpdump-14:4.9.2-4.el7.x86_64 @anaconda Update 14:4.9.2-4.el7_7.1.x86_64 @updates Updated util-linux-2.23.2-61.el7.x86_64 @anaconda Update 2.23.2-61.el7_7.1.x86_64 @updates Scriptlet output: 1 error: Couldn't fork %post(libsss_idmap-1.16.4-21.el7_7.1.x86_64): Cannot allocate memory 2 error: Couldn't fork %post(libsss_nss_idmap-1.16.4-21.el7_7.1.x86_64): Cannot allocate memory 3 error: Couldn't fork %pre(ca-certificates-2019.2.32-76.el7_7.noarch): Cannot allocate memory 4 error: ca-certificates-2019.2.32-76.el7_7.noarch: install failed 5 error: Couldn't fork %post(certbot-1.0.0-1.el7.noarch): Cannot allocate memory 6 error: Couldn't fork %pre(MariaDB-server-10.4.11-1.el7.centos.x86_64): Cannot allocate memory 7 error: MariaDB-server-10.4.11-1.el7.centos.x86_64: install failed 8 error: Couldn't fork %post(sssd-client-1.16.4-21.el7_7.1.x86_64): Cannot allocate memory 9 error: Couldn't fork %post(kernel-tools-3.10.0-1062.9.1.el7.x86_64): Cannot allocate memory 10 error: Couldn't fork %pre(php-pear-1:1.10.10-4.el7.remi.noarch): Cannot allocate memory 11 error: php-pear-1:1.10.10-4.el7.remi.noarch: install failed 12 warning: /etc/clamd.d/scan.conf created as /etc/clamd.d/scan.conf.rpmnew 13 error: Couldn't fork %triggerin(microcode_ctl-2:2.1-53.7.el7_7.x86_64): Cannot allocate memory 14 error: php-pear-1:1.10.10-2.el7.remi.noarch: erase skipped 15 error: MariaDB-server-10.4.10-1.el7.centos.x86_64: erase skipped 16 error: Couldn't fork %preun(MariaDB-shared-10.4.10-1.el7.centos.x86_64): Cannot allocate memory 17 error: MariaDB-shared-10.4.10-1.el7.centos.x86_64: erase failed 18 error: Couldn't fork %postun(MariaDB-compat-10.4.10-1.el7.centos.x86_64): Cannot allocate memory 19 error: ca-certificates-2018.2.22-70.0.el7_5.noarch: erase skipped 20 error: Couldn't fork %preun(microcode_ctl-2:2.1-53.3.el7_7.x86_64): Cannot allocate memory 21 error: microcode_ctl-2:2.1-53.3.el7_7.x86_64: erase failed 22 error: Couldn't fork %preun(postgresql10-server-10.11-1PGDG.rhel7.x86_64): Cannot allocate memory 23 error: postgresql10-server-10.11-1PGDG.rhel7.x86_64: erase failed 24 error: Couldn't fork %postun(libmount-2.23.2-61.el7.x86_64): Cannot allocate memory 25 error: Couldn't fork %preun(sssd-client-1.16.4-21.el7.x86_64): Cannot allocate memory 26 error: sssd-client-1.16.4-21.el7.x86_64: erase failed 27 error: Couldn't fork %postun(libblkid-2.23.2-61.el7.x86_64): Cannot allocate memory 28 error: Couldn't fork %postun(postgresql10-10.11-1PGDG.rhel7.x86_64): Cannot allocate memory 29 error: Couldn't fork %postun(clamav-lib-0.101.4-1.el7.x86_64): Cannot allocate memory 30 error: Couldn't fork %postun(kernel-tools-3.10.0-1062.4.3.el7.x86_64): Cannot allocate memory 31 error: Couldn't fork %postun(libcurl-7.29.0-54.el7.x86_64): Cannot allocate memory 32 error: Couldn't fork %postun(nss-3.44.0-4.el7.x86_64): Cannot allocate memory 33 error: Couldn't fork %postun(nss-softokn-3.44.0-5.el7.x86_64): Cannot allocate memory 34 error: Couldn't fork %postun(nss-util-3.44.0-3.el7.x86_64): Cannot allocate memory 35 error: Couldn't fork %postun(postgresql10-libs-10.11-1PGDG.rhel7.x86_64): Cannot allocate memory 36 error: Couldn't fork %postun(libuuid-2.23.2-61.el7.x86_64): Cannot allocate memory 37 error: Couldn't fork %postun(libsss_idmap-1.16.4-21.el7.x86_64): Cannot allocate memory 38 error: Couldn't fork %postun(libsss_nss_idmap-1.16.4-21.el7.x86_64): Cannot allocate memory 39 error: Couldn't fork %postun(libsmartcols-2.23.2-61.el7.x86_64): Cannot allocate memory 40 error: Couldn't fork %postun(libwebp7-1.0.2-1.el7.remi.x86_64): Cannot allocate memory 41 error: Couldn't fork %postun(fribidi-1.0.2-1.el7.x86_64): Cannot allocate memory 42 error: Couldn't fork %preun(proftpd-1.3.5e-7.el7.x86_64): Cannot allocate memory 43 error: proftpd-1.3.5e-7.el7.x86_64: erase failed 44 error: Couldn't fork %postun(numactl-libs-2.0.12-3.el7.x86_64): Cannot allocate memory 45 error: Couldn't fork %posttrans(kernel-3.10.0-1062.9.1.el7.x86_64): Cannot allocate memory 46 error: Couldn't fork %posttrans(microcode_ctl-2:2.1-53.7.el7_7.x86_64): Cannot allocate memory history info [root@vps2 ~]#

6 years, 2 months

[CentOS] LVM problem after adding new (md) PV

by Tomasz Nowak

Hello, I have a weird problem after adding new PV do LMV volume group. It seems the error comes out only during boot time. Please read the story. I have couple of 1U machines. They all have two, four or more Fujitsu-Siemens SAS 2,5" disks, which are bounded in Raid1 pairs with Linux mdadm. First pair of disks has always two arrays (md0, md1). Small md0 is used for booting and the rest - md1 is used as PV for volume group (vg0). When I need to enlarge the volume, I just add 2 new disks, create a raid 1 array of their whole space I add it as another mdX to vg0. That has been working fine since yesterday. I received new disks branded by Toshiba (Toshiba bought Fujitsu-Simens hdd business) which were supposed to be added as disk no 3 and 4. As far as I remember I've done everything in the same way as before: - They come out as sdc and sdd, so I - fdisk /dev/sdc, created one primary parition of whole space, type fd - the same with /dev/sdd - mdadm --create /dev/md2 -R -l 1 -n 2 /dev/sdc1 /dev/sdd1 - array has been created and syncronized - pvcreate /dev/md2 - vgextend vg0 /dev/md2 and it looks fine: ---------------------------------------------------------------------- # cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sdb2[1] sda2[0] 140488320 blocks [2/2] [UU] md2 : active raid1 sdd1[1] sdc1[0] 292961216 blocks [2/2] [UU] md0 : active raid1 sdb1[1] sda1[0] 3148608 blocks [2/2] [UU] ---------------------------------------------------------------------- # pvdisplay --- Physical volume --- PV Name /dev/md1 VG Name vg0 PV Size 133.98 GB / not usable 11.62 MB Allocatable yes PE Size (KByte) 32768 Total PE 4287 Free PE 1695 Allocated PE 2592 PV UUID AufZRm-QbFC-xRj1-OxwW-Z2w2-qbkM-qzoEcP --- Physical volume --- PV Name /dev/md2 VG Name vg0 PV Size 279.39 GB / not usable 14.94 MB Allocatable yes PE Size (KByte) 32768 Total PE 8940 Free PE 8940 Allocated PE 0 PV UUID qeDW2q-nq5b-Yh5U-5sKY-7Rkd-1UXh-LAxL8j ---------------------------------------------------------------------- # vgdisplay --- Volume group --- VG Name vg0 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1010 VG Access read/write VG Status resizable MAX LV 0 Cur LV 8 Open LV 2 Max PV 0 Cur PV 2 Act PV 2 VG Size 413.34 GB PE Size 32.00 MB Total PE 13227 Alloc PE / Size 2592 / 81.00 GB Free PE / Size 10635 / 332.34 GB VG UUID 5cF1dk-1CMM-qiuf-CyNY-aCmw-8Hx8-4iO12I ---------------------------------------------------------------------- # lvdisplay --- Logical volume --- LV Name /dev/vg0/d0v VG Name vg0 LV UUID q7zmrV-EykH-jPzR-smYJ-eehh-3Gbx-ebu5wK LV Write Access read/write LV Status available # open 1 LV Size 3.00 GB Current LE 96 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 [...] this part may be skiped as it's very long an irrelevant. There are no errors here. ---------------------------------------------------------------------- And now please take a look what happens during boot: [...] scsi0 : ioc0: LSISAS1078 C2, FwRev=01180400h, Ports=1, MaxQ=276, IRQ=20 mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 0, sas_addr 0x500000e01f975022 Vendor: FUJITSU Model: MBB2147RC Rev: 0105 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 287277984 512-byte hdwr sectors (147086 MB) sda: Write Protect is off SCSI device sda: drive cache: write back SCSI device sda: 287277984 512-byte hdwr sectors (147086 MB) sda: Write Protect is off SCSI device sda: drive cache: write back sda: sda1 sda2 sd 0:0:0:0: Attached scsi disk sda mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 2, phy 1, sas_addr 0x500000e01f602f42 Vendor: FUJITSU Model: MBB2147RC Rev: 0105 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdb: 287277984 512-byte hdwr sectors (147086 MB) sdb: Write Protect is off SCSI device sdb: drive cache: write back SCSI device sdb: 287277984 512-byte hdwr sectors (147086 MB) sdb: Write Protect is off SCSI device sdb: drive cache: write back sdb: sdb1 sdb2 sd 0:0:1:0: Attached scsi disk sdb mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 3, phy 2, sas_addr 0x50000392b8028856 Vendor: TOSHIBA Model: MBF2300RC Rev: 0107 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdc: 585937500 512-byte hdwr sectors (300000 MB) sdc: Write Protect is off SCSI device sdc: drive cache: write back SCSI device sdc: 585937500 512-byte hdwr sectors (300000 MB) sdc: Write Protect is off SCSI device sdc: drive cache: write back sdc: sdc1 sd 0:0:2:0: Attached scsi disk sdc mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 4, phy 3, sas_addr 0x50000392b80236da Vendor: TOSHIBA Model: MBF2300RC Rev: 0107 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdd: 585937500 512-byte hdwr sectors (300000 MB) sdd: Write Protect is off SCSI device sdd: drive cache: write back SCSI device sdd: 585937500 512-byte hdwr sectors (300000 MB) sdd: Write Protect is off SCSI device sdd: drive cache: write back sdd: sdd1 sd 0:0:3:0: Attached scsi disk sdd Loading shpchp.ko module shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 Loading libata.ko module Loading ata_piix.ko module GSI 23 sharing vector 0x41 and IRQ 23 ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 18 (level, low) -> IRQ 23 ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ] scsi1 : ata_piix scsi2 : ata_piix ata1: SATA max UDMA/133 cmd 0x3138 ctl 0x314c bmdma 0x3110 irq 23 ata2: SATA max UDMA/133 cmd 0x3130 ctl 0x3148 bmdma 0x3118 irq 23 ata1: SATA link down (SStatus 0 SControl 300) ata2: SATA link down (SStatus 0 SControl 300) GSI 24 sharing vector 0x49 and IRQ 24 ACPI: PCI Interrupt 0000:00:1f.5[D] -> GSI 21 (level, low) -> IRQ 24 ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ] scsi3 : ata_piix scsi4 : ata_piix ata3: SATA max UDMA/133 cmd 0x3128 ctl 0x3144 bmdma 0x30f0 irq 24 ata4: SATA max UDMA/133 cmd 0x3120 ctl 0x3140 bmdma 0x30f8 irq 24 ata3: SATA link down (SStatus 4 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) Loading usb-storage.ko module Initializing USB Mass Storage driver... scsi5 : SCSI emulation for USB Mass Storage devices usbcore: registered new driver usb-storage Waiting for driver initialization. USB Mass Storage support registered. Vendor: TEAC Model: DV-28S-V Rev: 1.0B Type: CD-ROM ANSI SCSI revision: 00 Loading dm-mod.ko module device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.11.5-ioctl (2007-12-12) initialised: dm-devel(a)redhat.com Loading dm-log.ko module Loading dm-mirror.ko module Loading dm-zero.ko module Loading dm-snapshot.ko module Loading dm-mem-cache.ko module Loading dm-region_hash.ko module Loading dm-message.ko module Loading dm-raid45.ko module device-mapper: dm-raid45: initialized v0.2594l Waiting for driver initialization. Scanning and configuring dmraid supported devices md: Autodetecting RAID arrays. md: autorun ... md: considering sdd1 ... md: adding sdd1 ... md: adding sdc1 ... md: sdb2 has different UUID to sdd1 md: sdb1 has different UUID to sdd1 md: sda2 has different UUID to sdd1 md: sda1 has different UUID to sdd1 md: created md2 md: bind<sdc1> md: bind<sdd1> md: running: <sdd1><sdc1> raid1: raid set md2 active with 2 out of 2 mirrors md: considering sdb2 ... md: adding sdb2 ... md: sdb1 has different UUID to sdb2 md: adding sda2 ... md: sda1 has different UUID to sdb2 md: created md1 md: bind<sda2> md: bind<sdb2> md: running: <sdb2><sda2> raid1: raid set md1 active with 2 out of 2 mirrors md: considering sdb1 ... md: adding sdb1 ... md: adding sda1 ... md: created md0 md: bind<sda1> md: bind<sdb1> md: running: <sdb1><sda1> raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. ------------------------ and come the problem ----------------------- Scanning logical volumes Reading all physical volumes. This may take a while... Couldn't find device with uuid qeDW2q-nq5b-Yh5U-5sKY-7Rkd-1UXh-LAxL8j. Found volume group "vg0" using metadata type lvm2 Activating logical volumes Couldn't find device with uuid qeDW2q-nq5b-Yh5U-5sKY-7Rkd-1UXh-LAxL8j. 8 logical volume(s) in volume group "vg0" now active Creating root device. Mounting root filesystem. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Setting up other filesystems. Setting up new root fs no fstab.sys, mounting internal defaults Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys SELinux: Disabled at runtime. type=1404 audit(1298476404.427:2): selinux=0 auid=4294967295 ses=4294967295 INIT: version 2.86 booting Welcome to CentOS release 5.5 (Final) Press 'I' to enter interactive startup. Setting clock (utc): Wed Feb 23 16:53:25 CET 2011 [ OK ] Starting udev: [ OK ] Loading default keymap (us): [ OK ] Setting hostname xen13.local: [ OK ] Setting up Logical Volume Management: 8 logical volume(s) in volume group "vg0" now active [...] I have no idea were the problem is. I could paste vgck result here but its long, is it nessesary? I have yet another machine with the same setup and the same new Toshiba disks and it shows even some more errors: Scanning logical volumes Reading all physical volumes. This may take a while... Couldn't find device with uuid fNeN0H-zeD1-ems8-TfqW-2pyC-ZBdR-3ni250. Found volume group "vg0" using metadata type lvm2 Activating logical volumes Couldn't find device with uuid fNeN0H-zeD1-ems8-TfqW-2pyC-ZBdR-3ni250. Refusing activation of partial LV d1dc. Use --partial to override. 6 logical volume(s) in volume group "vg0" now active [...] but then later: [...] Setting up Logical Volume Management: 7 logical volume(s) in volume group "vg0" now active and after boot all 7 logical volumes work fine. Where could be the problem with these errors? -- Tomasz

15 years, 1 month

Re: [CentOS-devel] Is there any way to follow errata for Stream 8?

by Neal Gompa

On Fri, Aug 20, 2021 at 4:09 PM Josh Boyer <jwboyer(a)redhat.com> wrote: > > On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer <jwboyer(a)redhat.com> wrote: > > > > > > On Fri, Aug 20, 2021 at 1:37 PM Carl George <carl(a)redhat.com> wrote: > > > > > > > > On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > > > > > > > On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes <johnny(a)centos.org> wrote: > > > > > > > > > > > > On 8/19/21 11:21 PM, John R. Dennison wrote: > > > > > > > On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: > > > > > > >> Even emails like I see for for CentOS 7 would be ok. > > > > > > > > > > > > > > Considering that people have had nearly 2 years to get such notices out > > > > > > > for 8 and it's still not happened I wouldn't hold my breath if I were > > > > > > > you. > > > > > > > > > > > > > > > > > > > I would provide the information if i could, it is not easy to do because > > > > > > of modularity. > > > > > > > > > > > > The thing that builds el8 modules is called MBS .. if you look at MBS > > > > > > operations, one of the things that gets generated as part of the > > > > > > filename. Here is an example: > > > > > > > > > > > > https://koji.mbox.centos.org/koji/buildinfo?buildID=18783 > > > > > > > > > > > > Part of the file name is dynamic, created by MBS at build time. For > > > > > > example, one of the Source RPM filenames generated is: > > > > > > > > > > > > runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm > > > > > > > > > > > > That is not it's filename in RHEL8. In RHEL 8 .. the filename is: > > > > > > > > > > > > runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm > > > > > > > > > > > > There is no easy way to figure out the file names that match up between > > > > > > the two systems. I took me 15 minutes to figure out that one filename, > > > > > > this does not scale. > > > > > > > > > > Everything prior to ".module" should be unique, identifiable, and > > > > > identical between RHEL and CentOS. MBS whacks %dist to add MBS > > > > > > > > Not exactly. Sometimes RHEL maintainers add digits after %dist, which > > > > results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's > > > > not impossible to parse, but it's much more complicated that just > > > > ignoring everything after ".module". > > > > > > > > > information at the end. So there is some mapping. Additionally, when > > > > > the RPMs are imported from RHEL into CentOS, the original NVR is > > > > > present as a tag. Ignoring transmodrifier remapping modulemd commits > > > > > between RHEL and CentOS, you have enough baseline references to be > > > > > able to connect the dots because the RHEL dist-git shorthash is > > > > > present in the import tag, which would exist in the imported modulemd > > > > > before transmodification. > > > > > > > > > > That process could be automated, but I was never particularly > > > > > motivated to do it because of the historical attitude around providing > > > > > errata for CentOS users like Fedora users get. > > > > > > > > I'm not aware of any policy against allowing this in the project. If > > > > there is I hope board members will speak up and clarify that. I > > > > suspect it's more of a resource thing than anything. > > > > > > I think lack of awareness of a publicly documented policy against > > > allowing this in the project is likely true, but also irrelevant. We > > > don't have a policy against allowing a FreeBSD kernel or using > > > Ubuntu's version of gcc, yet we wouldn't do those. In the absence of > > > meticulously detailed bylaws, we have historical precedent setting > > > defacto policy. I don't expect this to change. > > > > > > That being said, an update metadata mechanism for CentOS Stream is > > > certainly hampered by resource constraints both in terms of tooling > > > and in terms of the impact on the people developing the OS through the > > > CentOS Stream project. For a continuously developed and continuously > > > delivered OS, we expect a large amount of churn on a day to day basis. > > > Updates are a regular occurence, and they're important either because > > > of fixes or because of new features. Changes are documented in MRs, > > > RPM changelogs, and referenced bugs for those interested. > > > > > > > It's always been possible to have updateinfo generated as build > > submissions go through. That's literally how it's done in Fedora with > > Bodhi. > > > > It's not that much of a stretch to say "deploy Bodhi, make voting > > advisory or turn it off, and have builds submitted through it with the > > right information and auto-release based on gating checks". That > > structured data can be pulled in and used for Red Hat update > > advisories internally too, which simplifies the pipeline to validate > > and release updates. Or if you have a beef against Bodhi, then why not > > use the tooling Scientific Linux created to make updateinfo? Troy and > > Pat are very familiar with it, and it's publicly available: > > https://pagure.io/python-Updateinfo > > > > Okay, let's say we can't do it for CentOS Stream 8 because of resource > > constraints. Well then, what about CentOS Stream 9, where the RHEL > > developers themselves are submitting the builds? There's no logical > > resourcing problem there. Deploy Bodhi for update submissions and tie > > You have clearly never worked on making a change to a RHEL package :). > I will promise you that there are already a significant number of > steps that developers must do to even get to the point where they can > file an MR. Putting more process and tooling and hurdles in their way > before the code even gets into RHEL is absolutely a resource problem > and I am not going to sign them up to do that. If anything, we're > trying to simplify even though many will tell you it doesn't look like > that. > > I know you meant that with good intention, but it's easy to read it as > "there's no resourcing problem because someone else has to do the > work." > I certainly have made changes to RHEL packages. My name exists in changelogs and commits in enough packages in RHEL and CentOS Stream that I think that would be an unfair characterization. :) I'm aware of most of the steps for making package changes in RHEL, and I already am aware that packagers for RHEL have to go through the effort of declaring what an update is, what it's for, and whether it requires relogin/reboot to fully apply. These are the core properties that are defined in updateinfo. Defining them to push a build in CentOS Stream is something that I don't think is an unreasonable ask. It's the same thing we ask community folks in Fedora to do, after all. > > the gating into the auto-release criteria. The Fedora CI folks were > > already doing that for Fedora Rawhide, so it's no stretch to have it > > for CentOS Stream too. > > > > The idea is not new: I've talked to the CentOS project folks about it > > many times in the past. They get *extremely* uncomfortable and tell me > > that they can't do it for various reasons even though they want to. > > It's one of the biggest complaints everyone has about the project. > > It's made worse by the fact that none of the ecosystem tooling for > > updates works in any useful manner without updateinfo. RPM changelogs > > are no substitute because no automation works with that. You know that > > as well as everyone else here. > > Producing that information isn't only about tooling, and the fact that > people would immediately rely on it for automation makes it difficult > to suggest anyone else doing it on the side is a viable solution. If > it's wrong, that has bad consequences. I'd certainly be against it > under the project umbrella if it wasn't part of the official delivery > anyway. > > I still question the utility of it though. It's a continuous delivery > model. You have to update. Want to know if you have all available > bug fixes? Update. If your bug isn't fixed, it doesn't change the > fact that you have all *available* bug fixes. There are no batches or > releases. It's called Stream for a reason. > That doesn't mean I shouldn't have the ability to configure dnf-automatic to apply all updates automatically that don't require relogin and reboot and then have it email me to notify me for updates that *do* require that so I can schedule time to actually go and apply it. -- 真実はいつも一つ！/ Always, there's only one truth!

4 years, 7 months

Re: [CentOS-devel] Is there any way to follow errata for Stream 8?

by Brian Stinson

On 8/20/21 4:31 PM, Neal Gompa wrote: > On Fri, Aug 20, 2021 at 4:19 PM Brian Stinson <bstinson(a)redhat.com> wrote: >> >> >> >> On 8/20/21 2:35 PM, Neal Gompa wrote: >>> On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer <jwboyer(a)redhat.com> wrote: >>>> >>>> On Fri, Aug 20, 2021 at 1:37 PM Carl George <carl(a)redhat.com> wrote: >>>>> >>>>> On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa <ngompa13(a)gmail.com> wrote: >>>>>> >>>>>> On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes <johnny(a)centos.org> wrote: >>>>>>> >>>>>>> On 8/19/21 11:21 PM, John R. Dennison wrote: >>>>>>>> On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: >>>>>>>>> Even emails like I see for for CentOS 7 would be ok. >>>>>>>> >>>>>>>> Considering that people have had nearly 2 years to get such notices out >>>>>>>> for 8 and it's still not happened I wouldn't hold my breath if I were >>>>>>>> you. >>>>>>>> >>>>>>> >>>>>>> I would provide the information if i could, it is not easy to do because >>>>>>> of modularity. >>>>>>> >>>>>>> The thing that builds el8 modules is called MBS .. if you look at MBS >>>>>>> operations, one of the things that gets generated as part of the >>>>>>> filename. Here is an example: >>>>>>> >>>>>>> https://koji.mbox.centos.org/koji/buildinfo?buildID=18783 >>>>>>> >>>>>>> Part of the file name is dynamic, created by MBS at build time. For >>>>>>> example, one of the Source RPM filenames generated is: >>>>>>> >>>>>>> runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm >>>>>>> >>>>>>> That is not it's filename in RHEL8. In RHEL 8 .. the filename is: >>>>>>> >>>>>>> runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm >>>>>>> >>>>>>> There is no easy way to figure out the file names that match up between >>>>>>> the two systems. I took me 15 minutes to figure out that one filename, >>>>>>> this does not scale. >>>>>> >>>>>> Everything prior to ".module" should be unique, identifiable, and >>>>>> identical between RHEL and CentOS. MBS whacks %dist to add MBS >>>>> >>>>> Not exactly. Sometimes RHEL maintainers add digits after %dist, which >>>>> results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's >>>>> not impossible to parse, but it's much more complicated that just >>>>> ignoring everything after ".module". >>>>> >>>>>> information at the end. So there is some mapping. Additionally, when >>>>>> the RPMs are imported from RHEL into CentOS, the original NVR is >>>>>> present as a tag. Ignoring transmodrifier remapping modulemd commits >>>>>> between RHEL and CentOS, you have enough baseline references to be >>>>>> able to connect the dots because the RHEL dist-git shorthash is >>>>>> present in the import tag, which would exist in the imported modulemd >>>>>> before transmodification. >>>>>> >>>>>> That process could be automated, but I was never particularly >>>>>> motivated to do it because of the historical attitude around providing >>>>>> errata for CentOS users like Fedora users get. >>>>> >>>>> I'm not aware of any policy against allowing this in the project. If >>>>> there is I hope board members will speak up and clarify that. I >>>>> suspect it's more of a resource thing than anything. >>>> >>>> I think lack of awareness of a publicly documented policy against >>>> allowing this in the project is likely true, but also irrelevant. We >>>> don't have a policy against allowing a FreeBSD kernel or using >>>> Ubuntu's version of gcc, yet we wouldn't do those. In the absence of >>>> meticulously detailed bylaws, we have historical precedent setting >>>> defacto policy. I don't expect this to change. >>>> >>>> That being said, an update metadata mechanism for CentOS Stream is >>>> certainly hampered by resource constraints both in terms of tooling >>>> and in terms of the impact on the people developing the OS through the >>>> CentOS Stream project. For a continuously developed and continuously >>>> delivered OS, we expect a large amount of churn on a day to day basis. >>>> Updates are a regular occurence, and they're important either because >>>> of fixes or because of new features. Changes are documented in MRs, >>>> RPM changelogs, and referenced bugs for those interested. >>>> >>> >>> It's always been possible to have updateinfo generated as build >>> submissions go through. That's literally how it's done in Fedora with >>> Bodhi. >>> >>> It's not that much of a stretch to say "deploy Bodhi, make voting >>> advisory or turn it off, and have builds submitted through it with the >>> right information and auto-release based on gating checks". That >>> structured data can be pulled in and used for Red Hat update >>> advisories internally too, which simplifies the pipeline to validate >>> and release updates. Or if you have a beef against Bodhi, then why not >>> use the tooling Scientific Linux created to make updateinfo? Troy and >>> Pat are very familiar with it, and it's publicly available: >>> https://pagure.io/python-Updateinfo >>> >>> Okay, let's say we can't do it for CentOS Stream 8 because of resource >>> constraints. Well then, what about CentOS Stream 9, where the RHEL >>> developers themselves are submitting the builds? There's no logical >>> resourcing problem there. Deploy Bodhi for update submissions and tie >>> the gating into the auto-release criteria. The Fedora CI folks were >>> already doing that for Fedora Rawhide, so it's no stretch to have it >>> for CentOS Stream too. >> >> It's not Bodhi vs. another tool in this case. The reason we don't deploy >> an update manager in Stream is that we want to avoid an artificial gate >> before the RHEL process begins. In practice, CentOS Stream builds are >> promoted through the workflow in lockstep with their RHEL counterparts. >> This means CentOS Stream builds are subject to the fate of the RHEL >> gating results and other bits of paperwork and process that maintainers >> must go through to release a build into RHEL proper. If any of that RHEL >> process leads to a NAK we want to NAK a build in Stream too and we'd be >> overriding any pre-prepared updates in a hypothetical Stream update >> manager anyways. >> > > Maybe I said this wrong, but I think that this use-case is something > that Bodhi supports fine. Configuring Bodhi to respond to RHEL gating > and only push when RHEL pushes is something that Bodhi could do by > listening to whatever pushes RHEL builds. Having the RHEL NAK block a > CentOS Stream build seems reasonable, just as the other way would too. > You should be able to enforce that they land in tandem. Not reusing > Bodhi for this seems like a bad idea, especially after all the effort > to implement this capability in there for Fedora CI on Rawhide builds. > > > The thing that pushes RHEL builds is already the thing that influences when Stream builds move along in the workflow. Let's break this down by use-case, though: "I want to comment on a build before it makes it into RHEL" => Use the open bugzilla or comment on the open merge request "I want to try out a build before it makes it on the mirrors" => Pull from the buildsystem or from the development composes "I want to test a package before a build is made" => We're working on expanding pre-merge and post-merge CI. Note: this is a much better place to influence and provide feedback before a build makes it into the process than an update/errata Running an update manager in Stream would be extra work, when we want to encourage the use-cases to be addressed elsewhere anyways. --Brian

4 years, 7 months

Re: [CentOS] (EXT) CentOS Digest, Vol 162, Issue 29

by Selvam, Joshua

Send CentOS mailing list submissions to centos(a)centos.org -----Original Message----- From: CentOS <centos-bounces(a)centos.org> On Behalf Of centos-request(a)centos.org Sent: Tuesday, July 31, 2018 5:30 PM To: centos(a)centos.org Subject: (EXT) CentOS Digest, Vol 162, Issue 29 Send CentOS mailing list submissions to centos(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos or, via email, send a message with subject or body 'help' to centos-request(a)centos.org You can reach the person managing the list at centos-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS digest..." Today's Topics: 1. Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Yannis Milios) 2. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Simon Matter) 3. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Yannis Milios) 4. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (mark) 5. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Yannis Milios) 6. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (mark) 7. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Yannis Milios) 8. Re: Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Simon Matter) 9. Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] (Yannis Milios) 10. Increase Disk Space with LVM (Felix K?lzow) ---------------------------------------------------------------------- Message: 1 Date: Mon, 30 Jul 2018 16:26:43 +0100 From: Yannis Milios <yannis.milios(a)gmail.com> To: centos(a)centos.org Subject: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <CAFiF2OpdpWuVLyZq7_4n1MxtMr2ypJkgKhLt+03ayapexgNuqA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hello, I'm having a strange problem booting a new centos7 installation. Below some background on this. [I have attached the tech details at the bottom of this message] I started a new CentOS7 installation on a VM, so far all good, o/s boots fine. Then I decided to increase VM disk size (initially was 10G) to 13G. Powered off the VM, increased the vhd via the hypervisor, booted from CentOS livecd, selected "recover my centos installation". Then I used the following sequence of commands to make the new vhd size "visible" to the o/s ... - ran fdisk /dev/sda and deleted partition 2. (This is the LVM partition where the o/s is stored. The first partition is /boot [xfs] partition *non lvm*.) - created a new partition with same starting sector as before deleting it, but a different ending sector (to reflect to the increased space). - set partition type to 8e (lvm), saved settings and exit. - ran pvresize and lvresize to make new space visible to the o/s.All good, I can see the space increase on 'lvdisplay centos/root'. - ran 'mount /dev/mapper/centos-root /mnt/root' to temporarily mount the o/s partition. - ran 'xfs_growfs /mnt/root' to resize the o/s fs to the new size. It was successful and I could actually chroot to the o/s and verify new disk size. - rebooted and tried to boot from hdd this time. Grub menu shows up and loads default kernel (3.10.0-862.9.1.el7.x86_64). - after initial kernel boot up process, booting continues to initrd and then it's where the problem starts... - looks like dracut has issues locating/enabling /dev/mapper/centos-root (lv) and as a result it cannot boot to the 'real' root fs (/). - while in dracut shell, I execute the following command sequence: 1. lvm lvchange -ay /dev/centos/root 2. lvm lvchange -ay /dev/centos/swap 3. ln -s /dev/mapper/centos-root /dev/root 4. exit ...and the o/s boots fine...so looks like the pv,vg,lv is detected properly while in initrd, but somehow dracut has difficulties enabling the root,swap LVs ? - While in o/s, I rebuild initrd by using: 'dracut -f -v -a lvm' Note, I have to use '-a lvm' as for some reason, if don't, the lvm utils (lvm,lvm_scan) are not being included to the initrd, not sure why this happens. After rebooting, same thing happens, I have to manually boot the system via dracut shell. I'm a bit stuck at this point, any clues what I'm doing wrong in here ? As I previously said, this is a new installation, so I could simply reinstall the whole thing, but I would rather try to find out some answer to why is this happening ... :-) [curiosity] Some additional details: ================== I've attached /run/initramfs/rdsosreport.txt file [generated while in inird] here: https://privatebin.net/?fdc4052c0c402884#gdB/QYR3IeR55SxUbjfrkZPQfJ7jMxiUxq… o/s ver=CentOS Linux release 7.5.1804 (Core) [root@localhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 13G 0 disk ??sda1 8:1 0 500M 0 part /boot ??sda2 8:2 0 12.5G 0 part ??centos-root 253:0 0 11.5G 0 lvm / ??centos-swap 253:1 0 1G 0 lvm [SWAP] [root@localhost ~]# cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rd.shell rhgb" GRUB_DISABLE_RECOVERY="true" ------------------------------ Message: 2 Date: Mon, 30 Jul 2018 17:53:56 +0200 From: "Simon Matter" <simon.matter(a)invoca.ch> To: "CentOS mailing list" <centos(a)centos.org> Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <09679ddf131cfabaaa9a38ee3a874541.squirrel(a)webmail.bi.invoca.ch> Content-Type: text/plain;charset=utf-8 Hi, > Hello, > > I'm having a strange problem booting a new centos7 installation. Below > some background on this. [I have attached the tech details at the > bottom of this message] > > I started a new CentOS7 installation on a VM, so far all good, o/s > boots fine. Then I decided to increase VM disk size (initially was 10G) to 13G. > Powered off the VM, increased the vhd via the hypervisor, booted from > CentOS livecd, selected "recover my centos installation". Then I used > the following sequence of commands to make the new vhd size "visible" > to the o/s ... > > - ran fdisk /dev/sda and deleted partition 2. (This is the LVM > partition where the o/s is stored. The first partition is /boot [xfs] > partition *non > lvm*.) > - created a new partition with same starting sector as before deleting > it, but a different ending sector (to reflect to the increased space). > - set partition type to 8e (lvm), saved settings and exit. At this point I usually reboot and do the following steps while the system is running. I don't say how you do it is wrong, it's just easier/faster to do things while the system is online if downtime matters. I don't really know what causes your issues. The reason may be that I have more and more problems understanding the whole boot process and all the variants we used to have over more than two decades... But, what happens if you let the kernel post install scripts do the work or setting up the initrd things? If you reinstall the latest kernel, does it change anything? Regards, Simon > - ran pvresize and lvresize to make new space visible to the o/s.All > good, I can see the space increase on 'lvdisplay centos/root'. > - ran 'mount /dev/mapper/centos-root /mnt/root' to temporarily mount > the o/s partition. > - ran 'xfs_growfs /mnt/root' to resize the o/s fs to the new size. It > was successful and I could actually chroot to the o/s and verify new > disk size. > - rebooted and tried to boot from hdd this time. Grub menu shows up > and loads default kernel (3.10.0-862.9.1.el7.x86_64). > - after initial kernel boot up process, booting continues to initrd > and then it's where the problem starts... > - looks like dracut has issues locating/enabling > /dev/mapper/centos-root > (lv) and as a result it cannot boot to the 'real' root fs (/). > - while in dracut shell, I execute the following command sequence: > 1. lvm lvchange -ay /dev/centos/root > 2. lvm lvchange -ay /dev/centos/swap > 3. ln -s /dev/mapper/centos-root /dev/root > 4. exit > ...and the o/s boots fine...so looks like the pv,vg,lv is detected > properly while in initrd, but somehow dracut has difficulties enabling > the root,swap LVs ? > > - While in o/s, I rebuild initrd by using: 'dracut -f -v -a lvm' > Note, I have to use '-a lvm' as for some reason, if don't, the lvm > utils > (lvm,lvm_scan) are not being included to the initrd, not sure why this > happens. > After rebooting, same thing happens, I have to manually boot the > system via dracut shell. > > I'm a bit stuck at this point, any clues what I'm doing wrong in here ? > > As I previously said, this is a new installation, so I could simply > reinstall the whole thing, but I would rather try to find out some > answer to why is this happening ... :-) [curiosity] > > Some additional details: > ================== > I've attached /run/initramfs/rdsosreport.txt file [generated while in > inird] here: > https://privatebin.net/?fdc4052c0c402884#gdB/QYR3IeR55SxUbjfrkZPQfJ7jM > xiUxq5DWhTVbWc= > > o/s ver=CentOS Linux release 7.5.1804 (Core) > > [root@localhost ~]# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 13G 0 disk > ??sda1 8:1 0 500M 0 part /boot > ??sda2 8:2 0 12.5G 0 part > ??centos-root 253:0 0 11.5G 0 lvm / > ??centos-swap 253:1 0 1G 0 lvm [SWAP] > > [root@localhost ~]# cat /etc/default/grub > GRUB_TIMEOUT=5 > GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" > GRUB_DEFAULT=saved > GRUB_DISABLE_SUBMENU=true > GRUB_TERMINAL_OUTPUT="console" > GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap > rd.shell rhgb" > GRUB_DISABLE_RECOVERY="true" > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > https://lists.centos.org/mailman/listinfo/centos > ------------------------------ Message: 3 Date: Mon, 30 Jul 2018 17:32:53 +0100 From: Yannis Milios <yannis.milios(a)gmail.com> To: centos(a)centos.org Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <CAFiF2Or=a_2b+e+jj9AeUufnZg4N+rHvS8KJHF+LoBDJ+QcRNg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > > But, what happens if you let the kernel post install scripts do the > work or setting up the initrd things? Initially, I just rebooted from LiveCD and left Grub,kernel and dracut do their job with the defaults, but unfortunately, boot process stops at initrd (dracut) stage with the following error: [ 197.768159] localhost.localdomain dracut-initqueue[252]: Warning: Could > not boot. > [ 197.821409] localhost.localdomain systemd[1]: Received SIGRTMIN+20 > from PID 254 (plymouthd). > [ 197.822328] localhost.localdomain dracut-initqueue[252]: Warning: > /dev/centos/root does not exist > [ 197.823044] localhost.localdomain dracut-initqueue[252]: Warning: > /dev/centos/swap does not exist > [ 197.846807] localhost.localdomain systemd[1]: Starting Dracut > Emergency Shell... > [ 197.870983] localhost.localdomain systemd[1]: Received SIGRTMIN+21 > from PID 254 (plymouthd). Then, I'm dropped to dracut shell, where I boot the system by using the lvm commands as described to my first post. Once in O/S, I re-create initrd by using 'dracut -f -v -a lvm' command and reboot again the system. But still I get the same error during boot ... If you reinstall the latest kernel, does > it change anything? > This is actually the latest kernel (3.10.0-862.9.1.el7.x86_64) but I tried to boot with the second (older) kernel (vmlinuz-3.10.0-327.36.3.el7.x86_64), where I got exactly the same error during boot. Clearly, this is not a kernel issue, perhaps not even a dracut (initrd) issue, since everything was working fine, before resizing the PV/LV. I suspect that something went wrong during that step, but what? As I can successfully boot the system manually via dracut, normally everything should be ok? no? What can prevent dracut from activating the 2 LVs (centos/root and centos/swap) during initial boot phase ? Thanks, Yannis ------------------------------ Message: 4 Date: Mon, 30 Jul 2018 15:13:08 -0400 From: "mark" <m.roth(a)5-cent.us> To: "CentOS mailing list" <centos(a)centos.org> Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <e9796451bea645de4bc4fbe210591182.squirrel(a)host290.hostmonster.com> Content-Type: text/plain;charset=utf-8 Yannis Milios wrote: >> But, what happens if you let the kernel post install scripts do the >> work or setting up the initrd things? > > Initially, I just rebooted from LiveCD and left Grub,kernel and dracut > do their job with the defaults, but unfortunately, boot process stops > at initrd (dracut) stage with the following error: > > [ 197.768159] localhost.localdomain dracut-initqueue[252]: Warning: > Could > >> not boot. [ 197.821409] localhost.localdomain systemd[1]: Received >> SIGRTMIN+20 from >> PID 254 (plymouthd). >> [ 197.822328] localhost.localdomain dracut-initqueue[252]: Warning: >> /dev/centos/root does not exist >> [ 197.823044] localhost.localdomain dracut-initqueue[252]: Warning: >> /dev/centos/swap does not exist >> [ 197.846807] localhost.localdomain systemd[1]: Starting Dracut >> Emergency Shell... >> [ 197.870983] localhost.localdomain systemd[1]: Received SIGRTMIN+21 >> from PID 254 (plymouthd). >> > > > Then, I'm dropped to dracut shell, where I boot the system by using > the lvm commands as described to my first post. Once in O/S, I > re-create initrd by using 'dracut -f -v -a lvm' command and reboot > again the system. But still I get the same error during boot ... > > If you reinstall the latest kernel, does > >> it change anything? >> > > This is actually the latest kernel (3.10.0-862.9.1.el7.x86_64) but I > tried to boot with the second (older) kernel > (vmlinuz-3.10.0-327.36.3.el7.x86_64), where I got exactly the same > error during boot. > > Clearly, this is not a kernel issue, perhaps not even a dracut > (initrd) issue, since everything was working fine, before resizing the > PV/LV. I suspect that something went wrong during that step, but what? > As I can successfully boot the system manually via dracut, normally > everything should be ok? no? > > What can prevent dracut from activating the 2 LVs (centos/root and > centos/swap) during initial boot phase ? > Suggestion: once it's up, rebuild the initramfs. mark ------------------------------ Message: 5 Date: Mon, 30 Jul 2018 22:14:44 +0100 From: Yannis Milios <yannis.milios(a)gmail.com> To: CentOS mailing list <centos(a)centos.org> Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <CAFiF2OrJUiNh35M6PBxe=CQrtF1dRYb14b5H4pewTX-EsSm-TA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Suggestion: once it's up, rebuild the initramfs. > > I tried that already, but still the same problem. Aparently dracut does not want to activate the LVs required to boot to the root filesystem, for some reason ... Yannis -- Sent from Gmail Mobile ------------------------------ Message: 6 Date: Mon, 30 Jul 2018 17:16:51 -0400 From: "mark" <m.roth(a)5-cent.us> To: "CentOS mailing list" <centos(a)centos.org> Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <ce2b2fbed114eda6c7159b25098d48d1.squirrel(a)host290.hostmonster.com> Content-Type: text/plain;charset=utf-8 Yannis Milios wrote: > Suggestion: once it's up, rebuild the initramfs. >> > I tried that already, but still the same problem. > Aparently dracut does not want to activate the LVs required to boot to the > root filesystem, for some reason ... > At this point, I'd start wondering about the grub2 defaults, and the kernel command line. mark ------------------------------ Message: 7 Date: Mon, 30 Jul 2018 23:06:15 +0100 From: Yannis Milios <yannis.milios(a)gmail.com> To: CentOS mailing list <centos(a)centos.org> Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <CAFiF2Or5Ave-rhSCMmcD-h7X-sbhGsAGRG6psc0=jxdma7rN5g(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Monday, July 30, 2018, mark <m.roth(a)5-cent.us> > > At this point, I'd start wondering about the grub2 defaults, and the > kernel command line. > > This is Grub config.. [root@localhost ~]# cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rd.shell rhgb" GRUB_DISABLE_RECOVERY="true" -- Sent from Gmail Mobile ------------------------------ Message: 8 Date: Tue, 31 Jul 2018 08:22:12 +0200 From: "Simon Matter" <simon.matter(a)invoca.ch> To: "CentOS mailing list" <centos(a)centos.org> Subject: Re: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <970e648731344f68e1a1837a94b71d41.squirrel(a)webmail.bi.invoca.ch> Content-Type: text/plain;charset=utf-8 > Yannis Milios wrote: >>> But, what happens if you let the kernel post install scripts do the >>> work or setting up the initrd things? >> >> Initially, I just rebooted from LiveCD and left Grub,kernel and dracut >> do >> their job with the defaults, but unfortunately, boot process stops at >> initrd (dracut) stage with the following error: >> >> [ 197.768159] localhost.localdomain dracut-initqueue[252]: Warning: >> Could >> >>> not boot. [ 197.821409] localhost.localdomain systemd[1]: Received >>> SIGRTMIN+20 from >>> PID 254 (plymouthd). >>> [ 197.822328] localhost.localdomain dracut-initqueue[252]: Warning: >>> /dev/centos/root does not exist >>> [ 197.823044] localhost.localdomain dracut-initqueue[252]: Warning: >>> /dev/centos/swap does not exist >>> [ 197.846807] localhost.localdomain systemd[1]: Starting Dracut >>> Emergency >>> Shell... >>> [ 197.870983] localhost.localdomain systemd[1]: Received SIGRTMIN+21 >>> from PID 254 (plymouthd). >>> >> >> >> Then, I'm dropped to dracut shell, where I boot the system by using the >> lvm commands as described to my first post. Once in O/S, I re-create >> initrd >> by using 'dracut -f -v -a lvm' command and reboot again the system. But >> still I get the same error during boot ... >> >> If you reinstall the latest kernel, does >> >>> it change anything? >>> >> >> This is actually the latest kernel (3.10.0-862.9.1.el7.x86_64) but I >> tried to boot with the second (older) kernel >> (vmlinuz-3.10.0-327.36.3.el7.x86_64), where I got exactly the same error >> during boot. >> >> Clearly, this is not a kernel issue, perhaps not even a dracut (initrd) >> issue, since everything was working fine, before resizing the PV/LV. I >> suspect that something went wrong during that step, but what? As I can >> successfully boot the system manually via dracut, normally everything >> should be ok? no? >> >> What can prevent dracut from activating the 2 LVs (centos/root and >> centos/swap) during initial boot phase ? >> > Suggestion: once it's up, rebuild the initramfs. And when you did so, did you remove the "rd.shell" from GRUB_CMDLINE_LINUX before? Regards, Simon ------------------------------ Message: 9 Date: Tue, 31 Jul 2018 08:40:52 +0100 From: Yannis Milios <yannis.milios(a)gmail.com> To: CentOS mailing list <centos(a)centos.org> Subject: [CentOS] Issues booting centos7 [dracut is failing to enable centos/root, centos/swap LVs] Message-ID: <CAFiF2Or3nxaJcY44mWjosiTbwb==w2hU95iMpMC4=sTY7Wvn2A(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" And when you did so, did you remove the "rd.shell" from GRUB_CMDLINE_LINUX > before? > > Yes, basically that option was not there by default, I added it during the troubleshootig steps. Normally, rd.lvm.lv=centos/root and rd.lvm.lv=centos/swap are the kernel parameters which are parsed to dracut for enablig the two LVs, but somehow dracut does not. I've copied the log from dracut in here, can this be helpful to locate the problem? https://privatebin.net/?fdc4052c0c402884#gdB/QYR3IeR55SxUbjfrkZPQfJ7jMxiUxq… -- Sent from Gmail Mobile ------------------------------ Message: 10 Date: Tue, 31 Jul 2018 13:31:15 +0200 From: Felix K?lzow <felix.koelzow(a)gmx.de> To: centos(a)centos.org Subject: [CentOS] Increase Disk Space with LVM Message-ID: <1dd31e6b-ee9e-4a00-1bf2-22c0c2f0e699(a)gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Dear CentOS-Community, we have a server with four hard drives that are configured as raid10 (/dev/sda). Now, /home and /root are almost full. Therefore, we decided to buy four additional hard drives that should configured also as raid 10 (/dev/sdb). I want to use LVM to extend disk space for root and home. My (successful) test procedure in a virtual environment looks like this: 1. devide /dev/sdb into /dev/sdb1 for root and /dev/sdb2 for home using parted 2. Convert disk to physical volume: pvcreate /dev/sdb1 3. add physical volume to volume group (called centos): vgextend centos /dev/sdb1 4. Allocate physical volume to a logical volume:lvextend -l +100$FREE /dev/centos/root 5. resize2fs /dev/centos/root or xfs_grows /dev/centos/root depending on file system used 6. repeat steps 2-6 for /home and sdb2 The mentioned instruction I've got from this page: https://askubuntu.com/questions/458476/adding-disks-with-lvm#459176 Now my question: Is this procedure really safe or is something missing or are there some steps which I overlooked actually? Kind Regards Felix K?lzow ------------------------------ Subject: Digest Footer _______________________________________________ CentOS mailing list CentOS(a)centos.org https://lists.centos.org/mailman/listinfo/centos ------------------------------ End of CentOS Digest, Vol 162, Issue 29 ***************************************

7 years, 8 months

Re: [CentOS] SELinux and access across 'similar types'

by Bennett Haselton

On 1/6/2012 7:13 AM, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/06/2012 09:57 AM, Bennett Haselton wrote: >> On 1/6/2012 5:55 AM, RILINDO FOSTER wrote: >>> On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote: >>> >>>> Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit: >>>> >>>>> On 1/6/2012 4:11 AM, Philippe Naudin wrote: >>>>>> Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit: >>>>>> >>>>>>> On 1/6/2012 2:24 AM, Philippe Naudin wrote: >>>>>>>> Apache running as "init_t" is a call for troubles. >>>>>>> Is it? OK, any idea what caused that and how to fix it? >>>>>> No, sorry. Your httpd comes from CentOS ? >>>>> Yes >>>>>> Afaik, you should not have any process running in context >>>>>> init_t except init itself. If "ps awuxZ | grep [i]nit_t" >>>>>> returns more than only init and httpd, your problem is >>>>>> likely to be more complicated than a broken configuration >>>>>> of apache. >>>>> I've got a few... >>>>> >>>>> [root@g6950-21025 ~]# ps auwxZ | grep init_t >>>>> system_u:system_r:init_t root 1 0.6 0.0 >>>>> 10368 712 ? Ss 04:17 0:00 init [3] >>>>> >>>>> system_u:system_r:init_t root 537 0.2 0.1 >>>>> 13728 1976 ? S<s 04:17 0:00 /sbin/udevd -d >>>>> system_u:system_r:init_t root 1684 0.0 0.0 >>>>> 38880 456 ? Ssl 04:18 0:00 brcm_iscsiuio >>>>> system_u:system_r:init_t root 1690 0.0 0.0 >>>>> 12152 476 ? Ss 04:18 0:00 iscsid >>>>> system_u:system_r:init_t root 1691 0.0 0.4 >>>>> 12648 4460 ? S<Ls 04:18 0:00 iscsid >>>>> system_u:system_r:init_t dbus 2081 0.0 0.1 >>>>> 31520 1144 ? Ssl 04:18 0:00 dbus-daemon --system >>>>> system_u:system_r:init_t root 2215 0.0 0.1 >>>>> 52372 1492 ? Ssl 04:18 0:00 automount >>>>> system_u:system_r:init_t root 2254 0.0 0.1 >>>>> 62656 1212 ? Ss 04:18 0:00 /usr/sbin/sshd >>>>> system_u:system_r:init_t ntp 2273 0.0 0.4 >>>>> 23412 5044 ? SLs 04:18 0:00 ntpd -u ntp:ntp -p >>>>> /var /run/ntpd.pid -g system_u:system_r:init_t root >>>>> 2287 0.1 1.0 253312 10580 ? Ss 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2315 0.3 1.3 259488 13376 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2316 0.0 1.0 257436 11124 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2317 0.1 1.1 257436 11288 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2318 0.1 1.1 257436 11292 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2319 0.0 1.0 256720 10504 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2320 0.1 1.0 257436 10752 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2321 0.0 1.1 257436 11272 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t apache >>>>> 2322 0.1 1.1 257436 11356 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t root >>>>> 2386 0.0 0.0 3812 492 tty1 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty1 system_u:system_r:init_t root >>>>> 2387 0.0 0.0 3812 488 tty2 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty2 system_u:system_r:init_t root >>>>> 2390 0.0 0.0 3812 488 tty3 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty3 system_u:system_r:init_t root >>>>> 2392 0.0 0.0 3812 492 tty4 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty4 system_u:system_r:init_t root >>>>> 2394 0.0 0.0 3812 488 tty5 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty5 system_u:system_r:init_t root >>>>> 2397 0.0 0.0 3812 488 tty6 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty6 system_u:system_r:init_t apache >>>>> 2405 0.1 1.0 256412 11008 ? S 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_t root >>>>> 2406 0.3 0.3 90156 3456 ? Ss 04:18 0:00 sshd: >>>>> root@pts/0 root:system_r:initrc_t:SystemLow-SystemHigh root >>>>> 2458 0.0 0.0 61176 768 pts/0 S+ 04:18 0:00 grep init_t >>>>> >>>>> >>>>> >>>>> I also found at least one file (the audit.log file) which has >>>>> file type file_t, even though I thought the filesystem had >>>>> been re-labeled successfully because /var/www/html/robots.txt >>>>> had the correct type: >>>>> >>>>> [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt >>>>> -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t >>>>> /var/www/html/robots.txt [root@g6950-21025 ~]# ls -lZ >>>>> /var/log/audit/audit.log -rw------- root root >>>>> system_u:object_r:file_t /var/log/audit/audit.log >>>>> >>>>> >>>>> Any idea (1) what could be causing that and (2) whether it >>>>> could be related to the problem with all those init_t >>>>> processes? >>>> It's easy : your init process is broken, all these daemons but >>>> init are mis-labeled, so all the files they create (such as log >>>> files) are mis-labeled. >>>> >>>> And if the next question is "how to fix it ?", the answer is >>>> easy too : "I don't have any clue..." >>>> >>>> >>> Assuming that httpd came from CentOS, it should be appropriate >>> relabeled. If not, using the semanage -f context would fix it. >> Are you talking about changing the security context on the >> /usr/sbin/httpd file itself? What should it be set to? Right now >> it's [root@g6950-21025 ~]# ls -lZ /usr/sbin/httpd -rwxr-xr-x root >> root system_u:object_r:file_t /usr/sbin/httpd >> >>> This requires some thought. I'll respond back later. >>> >> Thanks! _______________________________________________ CentOS >> mailing list CentOS(a)centos.org >> http://lists.centos.org/mailman/listinfo/centos > What does > > restorecon -R -v /usr/sbin > > > Say? I ran that with the additional "-n" flag so it would just tell me what it *would* change (without actually changing anything) and it listed almost all the files in there (including httpd). But then I tried something else first, the page at http://wiki.centos.org/HowTos/SELinux says that "if the system has been upgraded to CentOS-5.2 with SELinux disabled, and SELinux is then enabled", then the relabel will fail, and you have to run these three commands: # genhomedircon # touch /.autorelabel # reboot I tried that and it worked -- the httpd processes are now listed with "httpd_t" as their context, the /var/log/audit/audit.log file is listed with auditd_log_t as its type instead if file_t, etc. I'm pretty sure this machine was never "upgraded to CentOS 5.2", it was just imaged with 5.7 when the hosting company set it up, but SELinux *was* off until I turned it on. So probably the doc should say, if the "system was *installed* with 5.2, then do this" (and presumably it's 5.2 or later, not just 5.2). > If this changes the label, then execute > > fixfiles restore > > Which should relabel the system. > > If restorecon does nothing or prints error messages, > > What file system are you using? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8HD6EACgkQrlYvE4MpobNGOwCgl9VK72f8XQbQVhL7IPHu5J6l > kE4AoLBVPrjUduuboqfdgnNfEkrwMi2m > =//xT > -----END PGP SIGNATURE-----

14 years, 3 months

Re: [CentOS-devel] Packaging Office hours at 16:00 UTC today

by Ljubomir Ljubojevic

On 01/22/2014 08:17 PM, Jim Perrin wrote: > > > On 01/21/2014 03:04 PM, Ljubomir Ljubojevic wrote: > . >> >> I see you avoided talking about priorities of the repositories, and I >> actually spent last 10 minutes smiling (not laughing, but smiling) and >> thinking how easy you could solve all of what you talked with carefully >> configured priorities. >> > > > It wasn't intentional. It's not something I normally consider (as I've > stated a few times). You should have joined and discussed it with us. > I was so swamped that I failed to realize it was Jan 20th. >> >> Here is what you can do with priorities: >> >> Let's say you have current repo-core (base, updates,...) priority=50, >> repo-epel priority=40, internal repo-centosplus and repo-extras with >> priority=30, repo-cloud priority=20 for common packages for all >> Variants/products/packages inside Cloud SiG, and repo-openstack, >> repo-cloudstack, repo-ovirt and repo-opennebula with priority=10. >> >> (For repositories that do not have priorities set, default would become >> priority of the base/core repo, in this case 50. Additional plugin of >> function would offer to add "Priorities=" for any repo inside >> /yum.repos.d/ and we could urge all 3rd party repos to publish new >> release packages ...bla, bla, bla, some or all that I proposed) >> >> >> So distribution of packages is following, higher repo=higher priority: >> >> repo-openstack repo-cloudstack repo-ovirt repo-opennebula >> packageZ-6.7.1 kernel-2.6.32-431-cs packageZ-6.6.5 >> >> repo-cloud >> kernel-2.6.32-431-cloud >> packageY-3.0.1 >> packageZ-6.6.2 >> >> repo-centosplus repo-extras >> kernel-2.6.32-431-centosplus >> packageX-1.0.3 >> >> repo-epel >> packageZ-6.5.8 >> >> repo-core >> kernel-2.6.32-431 >> packageX-1.0.0 >> packageY-2.5.7 >> >> >> So regular CentOS would use only repo-core and packages: >> kernel-2.6.32-431 >> packageX-1.0.0 >> packageY-2.5.7 >> >> Those that add EPEL would also have additional packages so their list of >> visible packages would be: >> kernel-2.6.32-431 >> packageX-1.0.0 >> packageY-2.5.7 >> packageZ-6.5.8 >> >> Those that on repo-core and EPEL add repo-centosplus and repo-extras >> would have their list of visible packages (for update for example): >> kernel-2.6.32-431-centosplus >> packageX-1.0.3 >> packageY-2.5.7 >> packageZ-6.5.8 >> >> Anyone wanting to use Cloud option packages that do not have special >> demands but only use common packages without overlap would use: >> repo-core, repo-epel,repo-centosplus, repo-extras, repo-cloud, and >> would have their list of visible packages (for update for example): >> kernel-2.6.32-431-cloud >> packageX-1.0.3 >> packageY-3.0.1 >> packageZ-6.6.2 >> >> >> For people using OpenNebula (in this example), they would also have >> turned on repo-opennebula on top of repo-cloud, but since it is empty, >> their list of visible packages would be same as above: >> kernel-2.6.32-431-cloud >> packageX-1.0.3 >> packageY-3.0.1 >> packageZ-6.6.2 >> >> For people using OpenStack (in this example), they would also have >> turned on repo-openstack on top of repo-cloud, and their list of visible >> packages would be: >> kernel-2.6.32-431-cloud >> packageX-1.0.3 >> packageY-3.0.1 >> packageZ-6.7.1 >> >> >> >> For people using OpenStack (in this example), they would also have >> turned on repo-cloudstack on top of repo-cloud, and their list of >> visible packages would be: >> kernel-2.6.32-431-cs >> packageX-1.0.3 >> packageY-3.0.1 >> packageZ-6.6.2 >> >> >> >> For people using OpenStack (in this example), they would also have >> turned on repo-ovirt on top of repo-cloud, and their list of visible >> packages would be: >> kernel-2.6.32-431-cloud >> packageX-1.0.3 >> packageY-3.0.1 >> packageZ-6.6.5 >> >> >> All packages in lower priority repositories would be hidden (unless >> forced) and would not mess with higher priority repositories. > > This is a reasonably limited example. As you've proposed it, it will > work. What you've proposed is only a subset of actual use cases > though.It's already been demonstrably shown by others on this list that > there are situations where this fails. You're trying to address this > issue from a user perspective. I'm trying to solve it from a > packaging/distribution one. These are not the same. If CentOS has any desire to expand on the market share, it should stop being "only-for-admins" distro. > > >> Even if some package from one of the higher repositories would show up >> in upstream or EPEL, and/or even if that package would have higher >> version, priorities would block an update by default since package with >> that name already exists in higher repository. >> >> Allowing that new package from upstream to be visible would be automatic >> (for users), you just have to remove package with same name from higher >> repository, no need to mess with include/exclude hell on each installed >> system or to release new <name>-release package for each change, just >> remove it from higher repository. > > > I never had any intention of messing with includes/excludes. That's up > to users and admins. > > >> And you can even do it partially. You could for example remove it from >> repo-cloud and/but move it to a higher repository where older version is >> needed. So if only OpenStack needs older version, new package would be >> moved from repo-cloud to repo-openstack. > > You're thinking about this in the wrong scope. The distribution > shouldn't be in the business of moving SIG packages around. The SIGs > need to do this, collaborating among themselves if possible. If we as a > distribution need to step in to do this, it should either be in a > mentoring context, or as a mediator. If top few repositories "belong" to in this case Cloud SiG, then "you" = Cloud SiG Board or whatever. I thought that people from CentOS Project would coordinate/oversee SiG's. It does not really matter who controls the repositories for priority based repositories to work, providing that there is communication between people maintaining them. But even if there is no real coordination, those on top creating Variants still can control state of their products/software. > > >> If only one Cloud software could use newer package from upstream, lets >> say oVirt, but not others, package from repo-cloud would be kept, but >> version from upstream would be "repeated"/doubled in repo-ovirt. >> >> That would provide security for people using clouds based on CentOS that >> sudden upstreams change would crash their systems. >> > > We cannot dictate this. We can recommend that they all use a common > package, enforcing this would arbitrarily prevent some SIGs from > progressing. I said nothing about enforcing. I was just explaining even such cases are easy to solve. > >> >> Similar automatic process (for users) would be to add newer versions of >> some package. Let's say OpenNebula needs newer version. They first add >> it into their repo-opennebula and use it. The others from SiG test their >> software with that version, and then you held a meeting and see what to do. >> You either move that packages down to repo-cloud, or not. If you do, >> single repo can, if necessary, add older version so they keep >> compatibility while others move on. >> > > This works without priorities as well. > > >> It will be interesting following the development of this issue. >> > > Why follow? The benefit with the structure we're working to implement is > that you're free to change most every aspect of it. > But I am not allowed to do what matters, not if your official policy is different. My opinion is that if I were to start Desktop Variant (my interest), I would have to replace centos-release with centos-desktop-release with yum-plugin-priorities mandatory and all repositories with modified priorities. I would also have to add several <repository>-release packages or to just add <repository>.repo and GPG key files as default. That would include 3rd party repositories like RPMFussion with not-so-legal packages. No actual packages, just .repo files provided. So far, I understood that neither are allowed. First will be considered non-CentOS, and you will not sign-on on second, and crucial packages will not be supported by CentOS, since CentOS does not want or can not be associated with 3rd party repositories, and those will not be allowed on git.centos.org. So what we come down, if what I wrote is essentially true, or remains true to is non-CentOS name and separate infrastructure are required. Since only few .repo files are needed, infra is not a problem, just few maintainers coming together and producing a brand not associated with CentOS. Most of the packages could be moved to newly formed repositories, but with various people hitting various restrictions, I am betting that most of 3rd party repositories will stay outside of git.centos.org. If they can not shut them down, they will want to keep the number of packages they care about. And that will mean 3rd party repository issue will not go away. But that is not what I had in mind, I wanted that CentOS, just like other distributions are tolerant of at least some 3rd party repositories. Since: - official support of such repositories is not allowed (having their <reposotiry>.repo files provided out of the box), - you will not support solution via priorities that would make their adding easy for the user, - there are no people supporting my solution, then I do not see Desktop Variant, of any market share value anyway, will be possible. And without support from others I do not see any need to waste my energy to confront you repeatedly. So this will be the end of my push for mentioned changes. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant

12 years, 2 months

Re: [CentOS] Centos 6.3 - which repos to use?

by Bry8 Star

* Another way to use multiple repo, other than what i mentioned in previous email (different repo with different priority# ), is to: * Set all repo's base, main/default, stable, extra, etc sections/channels on priority 10, and set all repo's other channels/sections like "testing", (source, debuginfo, ) etc on priority 15: repo#1 main-sections priority 10, others 15 repo#2 main-sections priority 10, others 15 repo#3 main-sections priority 10, others 15 repo#4 main-sections priority 10, others 15 * Use only RHEL compatible channels of any repo. (Avoid fedora, generic, other-non-Rhel-distro, etc, unless you are getting source/src.rpm/SRPM for rebuilding on CentOS ). * Since they all has same priority, highest/last version will get highest preference. * run : yum groupinfo "Base" It will show Mandatory, Default, etc app list for CentOS. And run this before adding other repo, so that you get a fresh list related only to CentOS. * run : yum check-update or, run : yum list updates --disableplugin=filter-data,priorities --disableexcludes=all --enablerepo=\* (First try without --enablerepo=\* option ) * You will see, (or If you see,) any other 3d party repo (other than CentOS ) app/libs, is/are trying to replace base/core components from CentOS Mandatory, Default, etc category areas, then put those pkgs/apps/libs in "exclude=pkg-name ..", inside those 3rd party repo, so that those pkgs do not replace base/core CentOS components. * And, if you choose a very specific app/lib from a very specific repo, for example, postgresql from Postgresql repo, then see my previous email for "exclude" list, place those postgresql related pkgs/items in all repo in their all sections/channels other than Postgresql repo itself, including CentOS repo in all sections/channels. * Do not do actual update, unless you see or you are 100% sure, shown repo and apps/libs/pkg are coming from the repo/channel which you want and safe, if you are not sure, ask for help here but search on google, read more docs, manuals, and research little bit first. * If you search with words like these : "pkgname error problem" or "pkgname error problem centos", then you should/will see what kind of error or problem may occur with that pkg. Take steps so that no error occurs. Please correct my mistake(s) on these simple (above ) suggestions, info. Thanks, -- Bright Star. Received from Bry8 Star, on 2013-01-30 4:08 AM: > Sorry, mentioned [pgdg92] twice. Pls ignore/delete > the [pgdg92] that has priority 15. > > > > Received from Bry8 Star, on 2013-01-28 10:16 AM: >> For PostgreSQL, i've done these (shown below) at >> initial/test stage: (pls DO NOT follow/copy it, >> try to understand pattern and do what fits for >> your case/need). >> >> From a VE instance inside HN: >> >> yum has these plugins: >> fastestmirror, filter-data, keys, >> list-data, merge-conf, presto, priorities, security, verify. >> >> # CentOS-Base.repo >> [CentOS-base] >> #<...snip...> >> enabled=1 >> # i do not want below set from centos repo >> # as these exacts are released by postgre devs >> # but other postgre portions from others i do want >> exclude=postgresql.* postgresql-contrib* >> postgresql-debuginfo* postgresql-devel* postgresql-docs* >> postgresql-jdbc.* postgresql-jdbc-debuginfo* postgresql-libs* >> postgresql-odbc.i686 postgresql-odbc-debuginfo* >> postgresql-plperl* postgresql-plpython* postgresql-pltcl* >> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo* >> postgresql-test* >> priority=1 >> >> [CentOS-updates] >> #<...snip...> >> enabled=1 >> exclude=postgresql.* >> postgresql-contrib* postgresql-debuginfo* postgresql-devel* >> postgresql-docs* postgresql-jdbc.* postgresql-jdbc-debuginfo* >> postgresql-libs* postgresql-odbc.i686 postgresql-odbc-debuginfo* >> postgresql-plperl* postgresql-plpython* postgresql-pltcl* >> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo* >> postgresql-test* >> priority=1 >> >> [CentOS-extras] >> #<...snip...> >> enabled=1 >> exclude=postgresql.* >> postgresql-contrib* postgresql-debuginfo* postgresql-devel* >> postgresql-docs* postgresql-jdbc.* postgresql-jdbc-debuginfo* >> postgresql-libs* postgresql-odbc.i686 postgresql-odbc-debuginfo* >> postgresql-plperl* postgresql-plpython* postgresql-pltcl* >> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo* >> postgresql-test* >> priority=1 >> >> [CentOSplus] >> #<...snip...> >> enabled=1 >> exclude=kernel.* >> kernel-firmware.* kernel-headers.* postgresql.* >> postgresql-contrib* postgresql-debuginfo* postgresql-devel* >> postgresql-docs* postgresql-jdbc.* postgresql-jdbc-debuginfo* >> postgresql-libs* postgresql-odbc.i686 postgresql-odbc-debuginfo* >> postgresql-plperl* postgresql-plpython* postgresql-pltcl* >> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo* >> postgresql-test* >> priority=1 >> >> # pgdg92-centos.repo >> [pgdg92] >> #<...snip...> >> enabled=1 >> priority=10 >> >> [pgdg92-source] >> #<...snip...> >> enabled=1 >> priority=10 >> >> #scntflnx.repo >> [SciLnx-6x-os] >> #<...snip...> >> enabled=1 >> exclude=redhat-rpm-config.* postgresql.* postgresql-devel* >> postgresql-docs* postgresql-contrib* postgresql-jdbc.* >> postgresql-libs* postgresql-odbc* postgresql-plperl* >> postgresql-plpython* postgresql-pltcl* postgresql-server* >> postgresql-test* >> priority=13 >> >> [SciLnx-6x-updates-fastbugs] >> #<...snip...> >> enabled=1 >> exclude=postgresql.* postgresql-devel* postgresql-docs* >> postgresql-contrib* postgresql-jdbc.* postgresql-libs* >> postgresql-odbc* postgresql-plperl* postgresql-plpython* >> postgresql-pltcl* postgresql-server* postgresql-test* >> priority=13 >> >> [SciLnx-6x-updates-security] >> #<...snip...> >> enabled=1 >> exclude=postgresql.* postgresql-devel* postgresql-docs* >> postgresql-contrib* postgresql-jdbc.* postgresql-libs* >> postgresql-odbc* postgresql-plperl* postgresql-plpython* >> postgresql-pltcl* postgresql-server* postgresql-test* >> priority=13 >> >> [SciLnx-6x-debuginfo] >> #<...snip...> >> enabled=0 >> priority=13 >> >> [SciLnx-6x-SRPMS] >> #<...snip...> >> enabled=1 >> priority=13 >> >> [pgdg92] >> #<...snip...> >> enabled=1 >> priority=15 >> >> ... other repo & distro ... >> >> In above way, i get most from PosteGre repo, and other postgre >> related side packages from other repos. if i were to place >> exclude=postgre* then all packages would have gotten excluded, >> and then the extra postgre pkg which are not released by postgre, >> would get hidden/excluded as well, though, i could have used this >> approach for to get that: >> >> includepkgs=related-extra-postgre-pkg >> >> to get those. but then i would need specific name, but what if >> new extra pkg that i dont know yet, is included, but since i have >> not specified specifically, those would get hidden/excluded. (my >> repo inquiries have shown, many other repo has at-least 1 to 3 or >> some up to 6 extra postgre related tools which are not released >> by postgre devs themselves). >> >> Few patterns/logics which i like to follow: >> >> repo#1, rpm priority 1, srpm priority 50 >> repo#2, rpm priority 10, srpm priority 40 >> repo#3, rpm priority 15, srpm priority 30 >> repo#4, rpm priority 20, srpm priority 20 >> ... >> >> Priority numbering pattern/logic: >> Since i'm using centos as my >> base, so various DISTRO & REPO rpm/binary which are closest to >> CentOS & CentOS's source RHEL, those distro & repo will get >> lowest priority# close to centos. i like to think/visualize in >> this way ... a LIST from top to down, now number them from top to >> bottom 1, 2, 3.. CentOS is at position 1, the top-most position. >> The lowest priority number, is at highest, upper position in the >> list, is chosen first by yum/installer, and has highest >> priority, if it(yum) wants to install something. >> >> my knol is this (i could be wrong): >> RHEL based source -> >> |-> CentOS base. >> |-> Scientific Linux. >> |-> Oracle Linux. >> |-> ClearOS >> Linux. >> >> (Fedora stable source -> RHEL -> RHEL source). >> >> EPEL has extra small tools/apps/libs for RHEL base apps/libs, and >> also for RHEL based clone/derivative distros (few mentioned >> above). >> RPMforge/dag has many perl related stuff. >> REMI has latest+stable PHP, MySql related stuff. >> ELrepo is for hardware latest+stable drivers, kernels. >> kdeRedhat is mostly for latest+stable KDE, QT, >> samba, etc. >> RPMFusion has closed-source-free, open-source-free, >> non-free etc apps. >> ATrpms has MythTV, Scientific Apps, etc. >> LnxTechNet has audio,video,etc apps. >> >> And Fedora 17, 18 source/src/SRPMS are needed to be re-built on >> cnetos for those apps/libs, then those can be used with centos. >> >> Pkg "Excluding" pattern/logic: >> (means, Getting specific pkg from Non-Centos repo): >> Now for example if i want something specific >> called "pkg-set-3" from repo#3, then i would have to place those >> specific pkgs inside the "exclude" line in repo(s) which are >> listed at upper position on the repo-list, so that will be >> repo#2, repo#1, so it will be: >> # repo_1.repo file inside /etc/yum.repos.d >> [repo_1] >> exclude=pkg-set-3 >> >> # repo_2.repo file inside /etc/yum.repos.d >> [repo_2] >> exclude=pkg-set-3 >> # in 'exclude' pkgs are 'space' separated >> >> Where & How to tweak & apply intelligence/knowledge and >> experience and tricks , etc for repo-config ? i like to call it >> HI (Human Intelligence), multiple (or one) developer's initial HI >> becomes AI in a software. >> >> Each repo file will most likely have one or more section/channel >> like below: >> [section-or-channel-name] >> config_options=values >> ... >> >> in repo#2, the "pkg-set-3" can be placed inside all >> section/channel of that repo file. >> >> For setting repo#1 (in our case, this is centos), we will have to >> do these: >> >> set "enabled=" to 0 in all new repo, (except centos.repo), or, by >> using yum command-line options instruct "yum" to disable all >> repo, then instruct yum to enable only >> centos-base,centos-updates, etc repo only and then do "yum >> check-update", like this: >> >> yum --disablerepo=\* --enablerepo=base,update,centosplus,extra >> check-update >> >> ... above command will show if centos repo has new updates (or >> no updates) for your system. >> >> then set enabled=1 in those section/channel which you need for >> the app/lib (pk-set-3) which you wanted. >> >> then run do "yum check-update". ... It will show list of app/lib >> which will be updated if you were to run "yum update" or "yum >> upgrade". >> >> Also see other helpful yum commands. >> >> Since these yum commands will show app/lib name and which repo >> has it, observe carefully and make a hand-written list first (or >> write on a text file on the client computer from where you're >> connecting to your centos server which you are trying to >> configure), a list, apps/libs which you need to exclude from >> which repo. >> >> Other helpful YUM COMMANDS: >> >> yum list updates '*' --disableplugin=filter-data,priorities >> --disableexcludes=all >> >> ... should show what updates will be in queue if all "excludes" >> are ignored. >> >> yum list all available 'pkg-name*' >> --disableplugin=filter-data,priorities --disableexcludes=all >> >> ... should show which of your repos has any package that are >> close to the name "pkg-name" and will also show their version # >> and what repo has it. >> >> Anytime you change any "somename.repo" file, then its better to >> do first: yum check-update (but do not update, unless you are >> sure which app is coming from which exact repo and if that is >> what you want or not). >> >> Please ADD/POST MORE/YOUR HELPFUL COMMANDS, and tell us what it >> does, where useful. >> >> Since source/SRPMS is/are needed when you/i need to make src.rpm, >> so distro & repo closest to CentOS gets higher priority, usually >> that is in reverse order than the RPM/binaries. >> >> Please correct my mistakes and add your responses, ideas, >> suggestions, logics, patterns, etc. >> >> Thanks in advance, >> >> -- Bright Star. >> >> >> >> Received from Johnny Hughes,, on 2013-01-28 12:50 AM: >>> On 01/27/2013 06:20 PM, Rob Kampen wrote: >>>> On 01/28/2013 04:43 AM, Mark LaPierre wrote: >>>>> On 01/27/2013 08:18 AM, Bry8 Star wrote: >>>>>> Hi Anthony, it would be really great, to see various >>>>>> types of repo-configs on centos wiki, now if few >>>>>> helpful& experienced users can grab this idea and come >>>>>> forward and share their repo config (and their case/usage >>>>>> scenario along with that), then that would be great. >>>>>> >>>>>> <snip> >>>>>> >>>>>> (Sorry for spelling& grammar mistakes in previous and >>>>>> in this posting, pls kindly disregard, its not a grammar >>>>>> discussion thread). >>>>>> >>>>>> -- Bry8Star. >>>>>> >>>>>> >>>>>> >>>>>> Received from Anthony K, on 2013-01-27 2:48 AM: >>>>>>> On 26/01/13 14:59, Bry8 Star wrote: >>>>>>>> CentOS webpage/site should also show to all users, >>>>>>>> some example of using multiple repos and how to >>>>>>>> implement effective includepkgs, exclude, priority >>>>>>>> etc directives properly for some certain last& >>>>>>>> STABLE app(s) (which is by default not in CentOS), so >>>>>>>> that others can understand the pattern, or have a >>>>>>>> pointer for them. Just mentioning about, that, there >>>>>>>> is such things called "includepkgs=...", >>>>>>>> "exclude=..." ad now go do it yourself (and sorry no >>>>>>>> example), obviously does not help that much to users, >>>>>>>> and its CentOS's loss as well, users go away to other >>>>>>>> distros, and ultimately many of them are lost in the >>>>>>>> jungle. -- Bright Star (Bry8Star). >>>>>>> But you appear to be missing the "C" part in CentOS >>>>>>> (or Community Enterprise OS). If you can contribute to >>>>>>> the Wiki, then the immediate problem is solved in that >>>>>>> such threads can be pointed to the Wiki and slows the >>>>>>> growth of my CentOS list folder! >>>>>>> >>>>>>> Frankly, if you have a good point to make that would >>>>>>> benefit the masses and you have spare time, then it's >>>>>>> best to create a Wiki page for it. >>>>>>> >>>>>>> Cheers, ak. >>>>>>> >>>>> There is already a fine page on this subject on the wiki. >>>>> >>>>> http://wiki.centos.org/AdditionalResources/Repositories >>>>> >>>> The point being made is that various people have the >>>> knowledge and experience to advise a startup setting for >>>> priority= for each repo I know that what I'm using has caused >>>> conflicts that have been quite time consuming to resolve - >>>> what works for others would be most helpful I do recognise >>>> that this will vary depending upon what tools are required >>>> but as a start: 1. developer workstation - what repos and >>>> what priority 2. LAMP server - probably just CentOS repos and >>>> something which deals with later php / perl / ruby 3. web / >>>> internet workstation - needs audio and video stuff working >>>> just my thoughts for starters. >>> >>> That totally depends on what you need to install and what repo >>> it is in. Since 3rd party repos are constantly adding new >>> packages that they did not have last week, it is impossible to >>> say what would be the proper priorities. >>> >>> I already posted what I personally do, which is: >>> >>> Install CentOS and set Base, updates, extras, and fasttrack to >>> a Priority=1 >>> >>> I usually do not need to enable centosplus, but if I do, I set >>> it to Priority=2 and I put "excludes=<pkg_names>" in the >>> Priority=1 repos for the packages I want let CentOS plus >>> replace in those repos. >>> >>> I then normally add EPEL and set the Priority=10 for that. >>> >>> Hopefully, that is all I need to add. >>> >>> If I have to add any more repositories, first make sure my >>> packages are currently all updated by doing a yum upgrade. >>> Then I add the new repos one at a time and I make them >>> Priority=10 (the same as EPEL) ... and after I add them , i do >>> a "yum update". If it tries to update, I look at the packages >>> and decide if I am going to allow the update or not ... if I am >>> ok to do the updates, then I do them and make sure it works. >>> Then I would install the packages I need from that repo. Then >>> I would add the next new repo till I get to the end. >>> >>> The best scenario is that all your 3rd party repos can >>> co-exist at the same Priority setting and that is where I start >>> (at Priority=10) ... and if something does not work, I >>> troubleshoot it and take individual action. >>> >>> Each individual machine is going to require a unique and >>> separate group of settings based on what you want to install >>> ... which is why there is no official recommendations. >>> >>> I personally am using the following repos right now on my main >>> Desktop, which is CentOS-6.3: >>> >>> adobe-linux-x86_64 | 951 B 00:00 base | 3.7 kB 00:00 >>> cr | 3.0 kB 00:00 elrepo | 1.9 kB 00:00 elrepo-extras | >>> 1.9 kB 00:00 extras | 3.5 kB 00:00 fasttrack | 3.5 kB >>> 00:00 google-chrome | 951 B 00:00 google-musicmanager | >>> 951 B 00:00 livna | 1.3 kB 00:00 nux-dextop | 2.7 kB >>> 00:00 rpmforge | 1.9 kB 00:00 updates | 3.5 kB 00:00 >>> >>> All of the secondary repos are set to the same priorities and >>> everything seems to work. >>> >>> Right now I have an "exclude=wxGtk*" for rpmforge for some >>> reason. And an "exclude=nx freenx*" for Nux! repo. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> CentOS mailing >>> list CentOS(a)centos.org >>> http://lists.centos.org/mailman/listinfo/centos >>> >> >> >> >> _______________________________________________ >> CentOS mailing >> list CentOS(a)centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > > > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos >

13 years, 2 months

Re: [CentOS] IPv6 broken on Linode

by Alice Wonder

On 02/16/2017 04:20 AM, James Hogarth wrote: > On 16 February 2017 at 12:02, James Hogarth <james.hogarth(a)gmail.com> wrote: >> On 16 February 2017 at 11:46, James Hogarth <james.hogarth(a)gmail.com> wrote: >>> On 16 February 2017 at 11:35, Alice Wonder <alice(a)domblogger.net> wrote: >>>> On 02/16/2017 03:28 AM, James Hogarth wrote: >>>>> >>>>> On 16 February 2017 at 10:42, Alice Wonder <alice(a)domblogger.net> wrote: >>>>>> >>>>>> On 02/16/2017 02:32 AM, James Hogarth wrote: >>>>>>> >>>>>>> >>>>>>> On 16 February 2017 at 10:17, Alice Wonder <alice(a)domblogger.net> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16 February 2017 at 09:09, Alice Wonder <alice(a)domblogger.net> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e(a)domblogger.net>, >>>>>>>>>>> Alice Wonder <alice(a)domblogger.net> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://forum.linode.com/viewtopic.php?f=19&t=14570&p=72785 >>>>>>>>>>>> >>>>>>>>>>>> I can not figure out what I need to do. >>>>>>>>>>>> >>>>>>>>>>>> Apparently according to linode support, the VM is trying to grab an >>>>>>>>>>>> IPv6 >>>>>>>>>>>> address with some privacy stuff enabled by default causing it to >>>>>>>>>>>> not >>>>>>>>>>>> grab the IPv6 address that is assigned to me. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Does the accepted answer at the following link give you any useful >>>>>>>>>>> hints? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-… >>>>>>>>>>> >>>>>>>>>>> Cheers >>>>>>>>>>> Tony >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Not really - I tried >>>>>>>>>> >>>>>>>>>> net.ipv6.conf.all.use_tempaddr = 0 >>>>>>>>>> >>>>>>>>>> and it still fails to grab the proper IPv6 >>>>>>>>>> >>>>>>>>>> -=- >>>>>>>>>> >>>>>>>>>> Just in case, I did ask Linode support to verify that my hardware >>>>>>>>>> address >>>>>>>>>> is >>>>>>>>>> what it is suppose to be. Still waiting to hear on that. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> it still is key=value ... it uses the ifcfg- files (via the rh >>>>>>>>> plugin) and they are all key=value >>>>>>>>> >>>>>>>>> It would be helpful if you could paste the journal output (journalctl >>>>>>>>> -u NetworkManager) from the time period of attempting to get an >>>>>>>>> address ... >>>>>>>>> >>>>>>>>> also the nmcli conn sh <connection_name> information for the interface >>>>>>>>> along with your ifcfg- files >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ifcfg-lo is the only one that exists on any of the servers - including >>>>>>>> the >>>>>>>> VMs that grab the correct IPv6 address. >>>>>>>> >>>>>>>> from /sbin/ifconfig -a : >>>>>>>> >>>>>>> >>>>>>> For a start stop using ifconfig ... it's broken at this point on >>>>>>> linux, especially on multi ip and ipv6 scenarios >>>>>>> >>>>>>> Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see >>>>>>> all IP address stuff regardless of family >>>>>>> >>>>>>>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>>>>>>> inet 178.79.185.217 netmask 255.255.255.0 broadcast >>>>>>>> 178.79.185.255 >>>>>>>> inet6 fe80::a8ad:d312:4ef4:7272 prefixlen 64 scopeid >>>>>>>> 0x20<link> >>>>>>>> inet6 2a01:7e00::825f:e564:ad53:72fc prefixlen 64 scopeid >>>>>>>> 0x0<global> >>>>>>>> ether f2:3c:91:18:8a:7e txqueuelen 1000 (Ethernet) >>>>>>>> RX packets 9903 bytes 1088621 (1.0 MiB) >>>>>>>> RX errors 0 dropped 0 overruns 0 frame 0 >>>>>>>> TX packets 7786 bytes 1087223 (1.0 MiB) >>>>>>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>>>>>>> >>>>>>>> That hardware address - the 18:8a:7e corresponds with what the IPv6 >>>>>>>> address >>>>>>>> is suppose to be. But that's not the address it is grabbing, despite >>>>>>>> the >>>>>>>> fact that net.ipv6.conf.all.use_tempaddr = 0 is set. >>>>>>>> >>>>>>>> I'm seriously wondering if the real issue is a mis-configured dhcp >>>>>>>> server >>>>>>>> in >>>>>>>> their London facility because nothing makes sense. >>>>>>>> >>>>>>>> journalctl -u NetworkManager >>>>>>>> >>>>>>>> reports no journal entries found. >>>>>>>> >>>>>>> >>>>>>> So are you not using NetworkManager then? there should be some logs ... >>>>>>> >>>>>>> >>>>>>>> I think the problem must be on their end. >>>>>>>> >>>>>>>> It all was working fine until they migrated the VM because of a >>>>>>>> hardware >>>>>>>> issue, and I suspect now all the hardware address privacy stuff being >>>>>>>> the >>>>>>>> issue is barking up the wrong tree because all the reading I have done >>>>>>>> seems >>>>>>>> to indicate that with >>>>>>>> >>>>>>>> net.ipv6.conf.all.use_tempaddr = 0 >>>>>>>> >>>>>>>> that a fake temporary hardware address would not be sent to their dhcp >>>>>>>> server when obtaining the address, but the real one, that should be >>>>>>>> fetching >>>>>>>> my assigned address. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Only if the kernel is doing SLAAC ... if other things (eg NM) are >>>>>>> handling it directly they may act differently ... but then from the >>>>>>> lack of logs is NM actually handling this? >>>>>>> >>>>>>> Does systemctl status NetworkManager show it running and does nmcli >>>>>>> show anything? >>>>>>> >>>>>> >>>>>> systemctl status NetworkManager >>>>>> ● NetworkManager.service - Network Manager >>>>>> Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; >>>>>> enabled; >>>>>> vendor preset: enabled) >>>>>> Active: active (running) since Thu 2017-02-16 08:19:34 UTC; 2h 19min >>>>>> ago >>>>>> >>>>>> * more stuff * >>>>>> >>>>>> nmcli >>>>>> eth0: connected to Wired connection 1 >>>>>> "Red Hat Virtio network device" >>>>>> ethernet (virtio_net), F2:3C:91:18:8A:7E, hw, mtu 1500 >>>>>> ip4 default, ip6 default >>>>>> inet4 178.79.185.217/24 >>>>>> route4 178.79.187.246/32 >>>>>> inet6 2a01:7e00::825f:e564:ad53:72fc/64 >>>>>> inet6 fe80::a8ad:d312:4ef4:7272/64 >>>>>> route6 2a01:7e00::/64 >>>>>> >>>>>> * more stuff for other interfaces * >>>>>> >>>>>> -=- >>>>>> >>>>>> The output of >>>>>> >>>>>> sysctl -a | grep net.ipv6 : >>>>>> >>>>>> https://librelamp.com/sysctl.txt >>>>>> >>>>>> It looks from that like it should not be hiding the real MAC address. >>>>>> >>>>> >>>>> >>>>> do nmcli conn show "Wired connection 1" >>>>> >>>>> the entries of interest are: >>>>> >>>>> ipv6.ip6-privacy >>>>> ipv6.addr-gen-mode >>>>> >>>>> man nm-settings to get what they mean >>>>> _______________________________________________ >>>>> CentOS mailing list >>>>> CentOS(a)centos.org >>>>> https://lists.centos.org/mailman/listinfo/centos >>>>> >>>> >>>> ipv6.ip6-privacy: -1 (unknown) >>>> ipv6.addr-gen-mode: stable-privacy >>>> >>> >>> >>> Okay so from the man page: >>> >>> The permitted values are: >>> "eui64", or >>> "stable-privacy". If >>> the property is set to >>> "eui64", the addresses >>> will be generated using >>> the interface tokens >>> derived from hardware >>> address. This makes the >>> host part of the >>> address to stay >>> constant, making it >>> possible to track >>> host's presence when it >>> changes networks. The >>> address changes when >>> the interface hardware >>> is replaced. The value >>> of "stable-privacy" >>> enables use of >>> cryptographically >>> secure hash of a secret >>> host-specific key along >>> with the connection >>> identification and the >>> network address as >>> specified by RFC7217. >>> This makes it >>> impossible to use the >>> address track host's >>> presence, and makes the >>> address stable when the >>> network interface >>> hardware is replaced. >>> >>> >>> I'm not certain (would have to go get changelogs) but I suspect this >>> was a change at 7.3 with the rebase of NetworkManager >>> >>> From what you say you want it sounds like you want eui64 - the one >>> based entire on the current MAC - whereas the present version is using >>> stable-privacy to avoid tracking. >>> >>> Note that this is distinct and different to ip6-privacy which is >>> concerned about the automatic generation of temporary addresses to use >>> for outbound communication. >> >> Okay a little more research as I'm curious when it changed from EUI64 >> by default ... >> >> https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-t… >> >> NM changed upstream to stable-privacy at 1.2 (the privacy extensions >> for the external connections were added at 1.0.4) >> >> RHEL 7.2 enabled privacy extensions by default: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht… >> >> But at that milestone we had NM 1.0.6 >> >> At the RHEL 7.3 release NM was rebased to 1.4.0 >> >> It was briefly referenced with this change in the 7.3 release notes >> but honestly it's pretty opaque ... >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht… >> >> "NetworkManager now supports new device types, improved stacking of >> virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217), >> detects duplicate IPv4 addresses, and controls a host name through >> systemd-hostnamed. Additionally, the user can set a DHCP timeout >> property and DNS priorities." >> >> Of course unless you knew what RFC 7217 was you'd have no idea this >> was the effect and there's no note that stable-privacy is the new >> default behaviour ARGH >> >> Disappointingly it's not listed in the "Networking" part of the >> release notes .... >> >> I think I'll raise the priority on my blog for the article I'm >> intending on the NM rebase ... there are nice things in the rebase >> like the arbitrary layering of teams, vlans and bridges but then >> there's unexpected stuff like this as well which should be made more >> visible. >> >> So ... Alice if you want to configure the system with the older EUI64 >> behaviour then in your ifcfg file for that interface you need >> IPV6_ADDR_GEN_MODE=eui64 and then restart NetworkManager (or `nmcli >> conn reload` rather than a full service restart or `nmcli conn mod >> "Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI >> without editing files and needing a connection reload). > > Oh and last message about this ... > > This was the email to fedora-devel at the time of the NM 1.2 introduction: > > https://lists.fedoraproject.org/pipermail/devel/2015-November/216754.html > > Systems that existed prior to the package didn't change their > configuration, it was only newly built systems that picked up the new > default - which might explain what you saw depending on how they > handled the migration. > > There's a good reason that stable-privacy was moved to for automatic > addressing, but for your setup you may want to set the older eui64 to > keep things consistent. > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > https://lists.centos.org/mailman/listinfo/centos > I suspect this is it. However - cat /etc/sysconfig/network-scripts/ifcfg-eth0 IPV6_ADDR_GEN_MODE=eui64 yet it still lists stable-privacy But I think that is it, so I'll figure it out. Thank you so much.

9 years, 1 month

Search results for query "Linux ./configure"