Postings by Stijn De Weirdt

kickstart leavebootorder

hi all,

we have hosts that we want to pxeboot first, always. with uefi,
anaconda/kickstart always set the freshly installed disk as first
bootdevice and there seems to be no way to disable this behaviour.

the rhel7 docs describe a "leavebootorder" option
(<a href="" title=""></a>)

but it doesn't "leave [the] boot order", it still (as described in the
doc) puts the new one on top.

memory cgroup max_usage_in_bytes question

hi all,

can someone help explaining what we are seeing?

kmod c74 broken: howto report it

hi all,

latest kmod update 20-15.el7_4.6 is broken on our systems, while
previous 20-15.el7_4.4 was working fine (and downgrading fixes the issue).

the issue is with modules from mellanox kmod rpms that are symlinked in
the weak-updates dir.

yum repo issue

hi all,

i'm trying to understand an issue i'm having with a yum repo (it's a
mirror of the c74 repo).

there's an rpm in the repo (ibutils-libs in this case); but the client
using this repo says it cannot find this rpm (i did yum info
ibutils-libs --disablerepo=* --enablerepo=c74 to exclude all other repos).

other rpms are ok to use, so nothing structural going wrong (i think)

the repo sqlite.bz2 on the client (in /var/cache/yum/...) mentions the
rpm (bunzip ...sqlite3.bz2; sqlite3 ...sqlite .dump |grep ibutils-libs),
so i guess that one is ok.

i downloaded the rpm from our repo and offi

(re)build sssd-client.i686 for x86_64

hi all,

i'm trying to rebuild the current sssd-client.i686 rpm that is part of
the x86_64 repo, but i fail to do so. rebuilding the sssd.src.rpm on
x86_64 does not produce this rpm.

i can rebuild sssd.src.rpm with --target=i686, but that sssd-client rpm
has conflicts and a whole bunch of i686 deps that the rpm from the
centos repo doesn't have.

tips/help welcome


how to get bug fixed by TUV

hi all,

i have a general question (a bit surprised ti's not on the centos faq):

we found a bug in a package in a centos install, and we are wondering
what the best approach is to get TUV to fix it (and release an update),
so it gets fixed in centos rebuild and thus on our nodes.

gdbm update and GDBM_File

hi all,

i'm stuck debugging a problem that appeared after this update made it to
our systems:
<a href="" title=""></a>

GDBM_File fails simple operation (which works with 1.8.0-36 of gdbm)

could someone with same perl and gdbm confirm the issue via simple
script below?