I'm having what appears at first glance to be a kickstart+anaconda issue on CentOS 7.4.
As near as I can tell in the program.log in the anaconda environment, the partitioning instructions downloaded with the kickstart from cobbler appear to simply not be applied. Then /mnt/sysimage is not mounted, the logs are not copied to /mnt/sysimage/root and the installation stalls due to the anamon checking. (Also anaconda is trying to e2fsck /dev/loop devices which is puzzling.)
If anybody has hints about what I would double-check or if you've resolved a similar issue I would be quite interested.
More details:
I see the same behaviour after cutting most items out of the cobbler kickstart template, however I confirm that /run/install/ks.cfg in the anaconda environment has the following:
ignoredisk --only-use=sda
zerombr
bootloader --location=mbr
clearpart --all
part / --label="/" --fstype=ext4 --grow --asprimary
program.log from the anaconda environment is here:
https://gist.github.com/christopherwood/72f390d7e5788b9bc9e841d40c926895
The system does boot and install just fine from the CentOS 7.4 iso without being kickstarted.
This is on vmware (esxi 6.0), I've tried with the paravirtual and lsi logic scsi controllers with the same result.
I've tried different previously (CentOS 7.3) working cobbler profiles that do not work with 7.4 now.
If I change the drive name (sda) to a ludicrous value anaconda simply errors, so at some level it's understanding about sda.
Anyone know of a repository with the current - 1.0 - version of
FreeTDS? Â
The packaged version 0.91 from EPEL is considerably out of data.
--
Meetings Coordinator, Michigan Association of Railroad Passengers
537 Shirley St NE Grand Rapids, MI 49503-1754 Phone: 616.581.8010
E-mail: awilliam(a)whitemice.org GPG#D95ED383 Web: http://www.marp.org
Hi, folks,
Is there *any* way, other than writing my own logging driver, to get
the docker daemon to write to its very own file, like, say,
/var/log/docker, so that it doesn't spew crap into /var/log/messages?
Thanks in advance.
mark
Hi everyone,
http://php.net/eol.php says that PHP 5.5 and 5.4 are EOL, but a freshly installed Centos 7 box, then fully upgraded, gives me PHP 5.4.16-42.el7. What do people do about maintaining current versions of software on a variety of machines? We have some users who manage their own machines, and would rather not force them to jump through hoops of managing repos to get later versions.
I just hope I've missed something straightforward, and that someone here can offer advice.
TIA,
Greg.
On Wed, November 1, 2017 10:51, Michael Hennebry wrote:
>
> I'm running NoScript because otherwise Firefox freezes up a lot.
> Recently I've had difficulty accessing a site.
> I suspect the reason is that it uses redirection in a way that
> frustrates my efforts to give it permission.
> To test the notion, I'm considering temporarily allowing script
> globally.
> How hard is it to reverse?
> Will I need to redo previous permissions one at a time?
>
The way I handle this is by creating a special profile which has no
extensions or security settings.
Inside your desktop manager open a terminal session and run 'firefox
-P --no-remote' The no-remote option opens a new Firefox window and
session whether or not you already have one running. Then press
'Create Profile', give it a name, and use that whenever you get into a
Firefox / Extensions conflict on a particular web site.
I have my Firefox panel launcher set up to use 'firefox -P
--no-remote' always. Tthis allows me vastly more flexibility dealing
with multiple websites at the price of a trivial delay during the
browser start-up.
This problem is the result of recent changes made to the extensions
interface. I can hardly wait to see what is broken with v57.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
I'm running NoScript because otherwise Firefox freezes up a lot.
Recently I've had difficulty accessing a site.
I suspect the reason is that it uses redirection in a way that
frustrates my efforts to give it permission.
To test the notion, I'm considering temporarily allowing script globally.
How hard is it to reverse?
Will I need to redo previous permissions one at a time?
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"Sorry but your password must contain an uppercase letter, a number,
a haiku, a gang sign, a heiroglyph, and the blood of a virgin."
-- someeecards
Everyone,
I have two desktop units with : Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
that do not allow the login screen to appear after the update of :
kernel-3.10.0-693.5.2.el7.x86_64 and kernel-3.10.0-693.2.2.el7.x86_64
Both of these units worked properly with
kernel.x86_64 3.10.0-514.26.2.el7
I am not sufficiently familiar with grub to know if the problem is
related to grub or related to the kernel. I have been able to boot
the machines by the use of kernel.x86_64 3.10.0-514.26.2.el7.
When using kernel-3.10.0-693 the login screen is blank and the login
prompt is missing, however each machine is accessible via the terminal
interface, or remotely with ssh.
Does anyone have any ideas ?
Greg
I recently installed mariadb-server 10.1 by adding the following repository:
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
...all was well until we had a power failure and upon rebooting unixodbc
was segfaulting. Once I did a yum undo, the mysql odbc driver was
functional.
I traced it to the following:
[root@ec-ast yum.repos.d]# ldd /usr/lib64/libmyodbc5w.so | grep -iE
"my|maria"
libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18
(0x00007f3dfb34c000)
You have new mail in /var/spool/mail/root
[root@ec-ast yum.repos.d]# repoquery -l MariaDB-server MariaDB-client
MariaDB-commo MariaDB-shared galera boost-program-options jemalloc rsync
lsof | grep lib64 | grep libmysqlclient
/usr/lib64/libmysqlclient.so
/usr/lib64/libmysqlclient.so.18
/usr/lib64/libmysqlclient.so.18.0.0
/usr/lib64/libmysqlclient_r.so
/usr/lib64/libmysqlclient_r.so.18
/usr/lib64/libmysqlclient_r.so.18.0.0
...notice the change in the path (/usr/lib64/mysql/).
I could reinstall mariadb-server, add a symlink and it would probably work,
but I thought it would be better to post and hopefully the maintainer of
whichever package (unixodbc, maria, mysql-connector...) should be
addressed, could be alerted to this issue in the event that it could (or
should) be fixed on a package level.
John
We have been fortunate to hang onto one of our summer interns
for part time work on weekends during the current school year.
One of the intern's jobs is to load documents and data which
are then processed. The documents are .txt, .docx, and .pdf
files. The data files are raw sensor outputs usually captured
using ADCs mostly with eight bit precision. All files are
loaded or moved from one machine to another with sftp.
The intern noticed right a way that the documents will transfer
perfectly from our PPC and SPARC machines to our Intel/CentOS
platforms. The raw data files, not so much. There is always
an Endian (Thanks Gulliver) issue, which we assume is due to
the bytes of data being formatted into 32 bit words somewhere
in the Big Endian systems. It is not totally clear why the
document files do not have this issue. If there is a known
principle behind these observations, we would appreciate very
much any information that can shared.