Re: Epson Perfection V19 scanner

[Todd Chester]

On 11/09/2017 09:08 AM, Lamar Owen wrote:

On 11/08/2017 06:25 PM, ToddAndMargo wrote:

On 11/07/2017 06:22 PM, Nico Kadel-Garcia wrote:
On Tue, Nov 7, 2017 at 8:43 PM, ToddAndMargo  
wrote:



And you know the Cxxx series of chipsets have been around
for a while now.  Just not long enough to be out of
production at which point it will appear on Red Hat
compatibility list.


Nonsense. Our friends over at Red Hat are continuously supporting
leading edge *server* hardware. 


Niko!  The C236 chipset *IS* a server grade chipset!
And it has been around for a long time.  No doubt Red Hat
will eventually support it in about five years, which is
typical of them and useless to me.



According to SuperMicro's support matrix for their C236 motherboards at 
http://www.supermicro.com/support/resources/OS/C236.cfm most of their 
C236 motherboards are supported, with some caveats, by RHEL7 (and thus 
CentOS or SL). So the C236 chipset itself is supported by EL7, and has 
been for a while.


But it just so happens that the particular C236-chipset board you used, 
the X11SAE-M, is apparently supported by SuperMicro for EL 7.1, but not 
later.  Now, others with a C236, such as the X11SAT and X11SAT-F, list 
support for 7.2 and 7.3 (the chart hasn't been updated for 7.4).  So you 
bought a motherboard that, for EL7.4, is not supported with that OS by 
SUPERMICRO.  Not Red Hat, but SuperMicro, the manufacturer.  To be 
blunt, but not intended to be harsh, if you want to use EL, do you 
homework and buy a supported board.  (Google-fu: search for the string 
'C236 supermicro support matrix' and this chart is third on the list, 
front page).


I personally have not had that much problem using newer software in 
CentOS 7, thanks to the Software Collections concept and repositories. A 
few things are older, but the latest Chrome works fine, the latest ESR 
Firefox and Thunderbird both work fine, etc. The kernel continues to get 
new hardware drivers backported to it, and it has been pretty stable for 
me (I'm having an issue at the moment with the nVidia binary drivers 
packaged by ELrepo, but that's not a Red Hat thing).


SuperMicro typically has great support for all things Red Hat, but this 
is one of those cases where it just isn't supported; if they could 
support it they would (they being SuperMicro, not Red Hat, since 
SuperMicro has the resources to do that support).  Safer bet is buying a 
Dell, HP, or other server that has as one of its options Red Hat 
Enterprise Linux; Dell especially is very good about this.



Hi Lamar,

I find the hardware compatibility charts to be so wildly out
of date that they are next to useless.  And the problem
occurred across all versions of 7.x that I tested.

I have seen those charts used to "Oops, not on our chart.
Your problem, not ours".  Supermicro's memory charts
terrible for this.  You can't find any of the memory they
certify as it is all out of production.  "Memory
problems?  Not on our chart!"

Also, Red Hat made no complaint about this not being on their
chart, so they expected it to work.  Red Hat L-O-V-E-S
to "WON'T FIX" bug reports.  That would have been an easy
one for them to worm out of.  Instead they pulled the
"we don't have the hardware" when it could have easily been made
available tot them from Supermicro.  They still wormed
out of it, they just had to be a bit more creative.

I also asked Supermicro to remove the X11SAE-M from their Red
Hat table.  I don't know if they did or not.

If you go and read the bug report I made with Red Hat, you will
find that the X11SAE-M worked perfectly when run from
the EXACT same Live USB that I installed it with.  This is
a timing issue.  The Live USB runs slower than native
hard drive.

I though I done complete do diligence. It worked on the Live USB
PERFECTLY.  It only cost me a bit over $1000 in free consulting
to figure it out. I had to completely rip SL 7.x out and replace
everything with Fedora on a running production server  FREE OF
CHARGE. Yup, it did occasionally boot on 7.x.  About one out
of three times (it got worse).  If SL did manage to boot,
it worked perfectly.  Yes, I am still pissed.

RHEL and Clones are great for set and forget (appliance)
applications (if they work initially), but not where on
going innovation is occurring.

And I firmly believe that there is a difference between
assuring stability and procrastination.

-T


--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: Epson Perfection V19 scanner

[Todd Chester]

On 10/31/2017 02:53 AM, David Sommerseth wrote:

On 27/10/17 22:03, ToddAndMargo wrote:

On 10/25/2017 12:48 AM, ToddAndMargo wrote:

[...snip...]

So poop.  Now I get to figure out why my scanner takes EIGHT
scans every time I ask for one.  xscan is cumbersome to
use at its best.  I may switch to Simple Scan for most of
everything.  I get tired of having to fix stuff all the
time, but it is my job, so I should quit bitching and
be glad I have a job ...


Generally, I use simple-scan for most of my scans.  If I want really
high quality scans where I want to manipulate the scan in gimp or
similar, then I use xsane.

Depending on the quality settings in XSane, it might do several scans.
And each time you zoom in/out and refresh the preview it will most
commonly also do a re-scan.  So I'd have a closer look at the DPI
settings and quality settings.

But generally, simple-scan does, in my experience, a very decent job -
despite lots of knobs, whistles and bells are hidden or simply not
available.  The most annoying thing for me is that it too often wants to
save the scan as JPEG instead of PDF by default (but not always).  And
that cropping could be set to a default value as well, but setting that
before the first scan will most commonly be kept for the following scans.




I will have a shot at it Thursday.  Thank you for the feed back!

Re: abrt-cli list

[Todd Chester]

On 10/31/2017 02:58 AM, David Sommerseth wrote:

On 27/10/17 20:40, ToddAndMargo wrote:

Dar List,

I am getting a lot of these from

    # abrt-cli list --since 1508946679

    id a1fc3a2e673aef967d0497fcc505bdd7dbd51c9f
    reason: irq 18: nobody cared (try booting with the "irqpoll"
option)


This smells more like a hardware issue.  Try adding irqpoll to the
kernel command line and see if this helps.  Otherwise, have a closer
look at /var/spool/abrt/oops-2017-10-26-08:58:55-1448-1/dmesg (dmesg in
the report directory) if there are some more clues.

If it helps adding irqpoll to the kernel command line, then you might
want to consider reporting this - together with the dmesg file and
information about your hardware and in particular the motherboard
(unless it's a laptop).




Hi David,

It won't boot with irqpoll.  :'(

Me thinks it is a USB3 issue.  And it may be software related too

USB write is EXTREMELY SLOW:
https://bugzilla.redhat.com/show_bug.cgi?id=1333582
reported on 2016-05-05 (still young for a RHEL bug).

Maybe by RHEL 7.9 

-T

Re: Firefox crashes start up

[Todd Chester]

On 08/18/2017 01:22 PM, David Sommerseth wrote:

On 18/08/17 19:36, ToddAndMargo wrote:

On 08/17/2017 01:03 PM, David Sommerseth wrote:

On 17/08/17 18:33, ToddAndMargo wrote:

On 08/17/2017 09:23 AM, ToddAndMargo wrote:


Those version checks are rather pointless, IMO.  


I agree.  It is a paper chase to try to move liability from the card
providers to the merchant.

Don't ever get me started on the changing your passwords
every month thing!



They just compare
"what's the latest released version".  It's equally to complain the
Linux kernel on EL7 is insecure and unmaintained because it is
kernel-3.10 and the latest Linux kernel is 4.12.  Which is a completely
misleading statement stupid version checkers provides, since the 3.10
EL7 kernel actually carries fixes and improvements from way newer
kernels; backported, been through QA and the complete release machinery
at Red Hat.

Those version checkers can work reasonably well for private consumers,
where running bleeding edge can work without too much risks.  But for
the enterprise it is a waste of time and energy, as those environments
wants to have a more controlled and predictable base environment.




How I see it, this all is quite nonsense.  Read the Firefox ESR FAQ more
carefully:

   "Maintenance of each ESR, through point releases, is limited to
high-risk/high-impact security vulnerabilities and in rare cases may
also include off-schedule releases that address live security
vulnerabilities."

And the current Firefox build in SL7.3 is firefox-52.2.  And it gets
regular updates, and the ESR major versions also gets updated.

# grep firefox- /var/log/yum.log*
Jan 20 14:41:03 Updated: firefox-31.4.0-1.el7_0.x86_64
Mar 08 18:41:02 Updated: firefox-31.5.0-2.el7_0.x86_64
Apr 02 22:51:13 Updated: firefox-31.6.0-2.el7_1.x86_64
May 17 21:42:19 Updated: firefox-38.0-3.el7_1.x86_64
Jul 06 00:39:29 Updated: firefox-38.1.0-1.el7_1.x86_64
Aug 13 00:42:56 Updated: firefox-38.2.0-4.el7_1.x86_64
Sep 03 22:34:38 Updated: firefox-38.2.1-1.el7_1.x86_64
Sep 30 22:54:04 Updated: firefox-38.3.0-2.el7_1.x86_64
Nov 06 01:24:16 Updated: firefox-38.4.0-1.el7_1.x86_64
Dec 25 13:12:56 Updated: firefox-38.5.0-3.el7_2.x86_64
Jan 28 11:27:12 Updated: firefox-38.6.0-1.el7_2.x86_64
Feb 19 01:33:19 Updated: firefox-38.6.1-1.el7_2.x86_64
Mar 10 00:40:33 Updated: firefox-38.7.0-1.el7_2.x86_64
Apr 29 21:00:54 Updated: firefox-45.1.0-1.el7_2.x86_64
Jun 17 13:38:47 Updated: firefox-45.2.0-1.el7_2.x86_64
Nov 22 00:37:17 Updated: firefox-45.5.0-1.el7_3.x86_64
Jan 31 15:01:19 Updated: firefox-45.7.0-1.el7_3.x86_64
Mar 06 22:58:39 Updated: firefox-45.7.0-2.el7_3.x86_64
Mar 10 02:35:16 Updated: firefox-52.0-4.el7_3.x86_64
Apr 19 01:57:53 Updated: firefox-52.0-5.el7_3.x86_64
Apr 26 02:11:50 Updated: firefox-52.1.0-2.el7_3.x86_64
Jun 17 01:34:19 Updated: firefox-52.2.0-1.el7_3.x86_64

The first "Jan 20" reference is from 2015(!).


Gee wiz.  I didn't say they never did it.  I just said they
were crabby about doing it.  The times I have approached them
on various security issues they had not repaired, they were
CRABBY with me and refused.  So I stop spitting in the wind.



And that is definitely not necessarily the equivalent of running the
latest bleeding edge Firefox or Firefox ESR - neither feature wise or
security patching wise.  AFAIK, Midori is not packaged within SL, so
you're trading packaging QA for something unknown.



Midori is a stinker, but it will have to do until I firefox
fixed.


Maybe I will go to the dark side and install Chromium



That is probably somewhat saner, even though you'll need Fedora EPEL to
get a pre-built package - which does not have the same QA process as SL
packages have implicitly.


Do you know anyway to uninstall the recent updates that
caused this?



You need to undo what the tarball you installed did.  I'd take the
output of 'tar -tzf $tarball' and review that list of file, and remove
them manually.  Then do a 'yum erase firefox' and reinstall it.


The tar bar is extremely simple to undo.  It is all in the one directory.

But that was not the question.  I wanted to undo the yum update.

useradd -p question

[Todd Chester]

Hi All,

Is there a way to add include a new user's password
when creating his account with `useradd`.  There is a "-p"
option, but it requires and "encrypted password".  And
I have no idea what that would be.  I only know his actual
password.  And including his actual password gets you
some unknown password that I have to redo with `passwd`

Many thanks,
-T

Re: 7.4

[Todd Chester]

On 06/23/2017 03:04 PM, Steven Haigh wrote:

On Saturday, 24 June 2017 3:32:02 AM AEST ToddAndMargo wrote:

On 06/23/2017 07:28 AM, Sean A wrote:

Are you all referring to RHEL 7.4 Beta?

Given recent history on the past 2 releases, I would put my money on 7.4
GA in Nov. 2017.  Scientific probably not until Jan 2018.

Just 7.4.  When Red Hat Bugzilla notifies me they
have fixed something, they say they fixed it in 7.4.

The way RH sounds, RHEL is already on 7.4, but I
haven't checked.


Nope:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)



Sounds to me like RH has lost interest in fixing anything in 7.3

Re: Dell OptiPlex 755 and SL7.3 LiveDVD Installer

[Todd Chester]

On 04/20/2017 12:25 PM, James M. Pulver wrote:

I'm testing the SL7.3 and SL7.2 LiveDVD installer disk and both failed
to boot the environment for install on a Dell OptiPlex 755 I'm testing,
I get a dracut error. The CENTOS7.3 LiveDVD boots to the GUI
successfully. Does anyone have any ideas for getting SL7.3 to install to
this computer? Boot flags or something to the installer DVD? Is this a
bug? Let me know the commands or info you need to help with this.

Thanks,



Hi James,

How did you create your DVD?

Also, try using "dd" to create a bootable USB flash
drive.  The installation goes a lot faster.  You can also
use it to double check your DVD

-T

Re: cdrom not white listed ????

[Todd Chester]

On 01/24/2017 04:42 AM, ToddAndMargo wrote:

On 12/21/2016 04:05 PM, ToddAndMargo wrote:

Hi All,

SL 7.2

I am drawing a blank on Google here.

I am, trying to boot a qemu-kvm virtual machine off
of /dev/sr0 (my DVD).  But I get the following error

 Error starting domain: internal error: qemu unexpectedly
 closed the monitor: 2016-12-22T00:00:30.330333Z qemu-kvm:
 -drive file=/dev/sr0,format=raw,if=none,media=cdrom,
 id=drive-sata0-0-0,readonly=on: could not open disk
 image /dev/sr0: Driver 'host_cdrom' is not whitelisted

"Not whitelisted" 

What am I doing wrong?

Many thanks,
-T



Anyone?




On 01/23/2017 11:32 PM, Karel Lang AFD wrote:

Hi,
just quick search reveals quite a lot of things - eg.:

https://bugzilla.redhat.com/show_bug.cgi?id=760885

it says:
'
CD-ROM passthrough from to the host to a guest has been disabled in 
Red Hat Enterprise Linux 7.0 Beta for all front ends. QEMU reports 
"Driver 'host_cdrom' is not whitelisted" in this scenario.'


it also says it was fixed .. so maybe was reintroduced?

cheers



Hi Karel,

I had found that one too.   They said it had been fixed in
7.0, so I though the problem was mine, but apparently
there has been a regression.

Since SL 7.3 is about to hit and RHEL 7.3 has been around for
a while, I will report this to Red Hat if SL 7.3 does not fix it.
This to keep them from being crabby if I report it on a
previous version than the current one

Thank you for the help!
-T

Re: How I upgrade Krusader to 2.5.0 on Red Hat

[Todd Chester]

On 11/01/2016 11:05 PM, ToddAndMargo wrote:

3) install the dependencies

$ su -c "yum install  qt5-qtbase-devel kf5-kio-devel  kf5-karchive-devel 
kf5-kbookmarks-devel kf5-kcodecs-devel kf5-kcompletion-devel kf5-kcoreaddons-devel 
kf5-kconfig-devel  kf5-kdoctools-devel kf5-ki18n-devel  kf5-kiconthemes-devel  
kf5-kitemviews-devel  kf5-knotifications-devel   kf5-kparts-devel  kf5-solid-devel   
kf5-ktextwidgets-devel   kf5-kwallet-devel   kf5-kwidgetsaddons-devel  
kf5-kwindowsystem-devel   kf5-kxmlgui-devel  kf5-kguiaddons-devel   
extra-cmake-modules"


I was told this is an easier way, but I have not verified it:

su -c "yum-builddep krusader-2.5.0-1.fc26.src.rpm"

Re: How I upgrade Krusader to 2.5.0 on Red Hat

[Todd Chester]

On 11/03/2016 04:38 AM, Nico Kadel-Garcia wrote:


Or, you could try what I do for backports. Install "mock", add
yourself to the "mock" group, and run:

  mock -r epel-7-x86_64 krusader-2.5.0-1.fc26.src.rpm

Then install RPMs from /var/lib/mock/ or /var/cache/mock/


What is "mock"?

Re: GPT?

[Todd Chester]

On 06/14/2016 01:17 PM, David Sommerseth wrote:

Just some more details:




I always wondered about that.  Thank you!