Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Mr Brian Domenick]

Thanks to all who assisted me. I am now running Fedora 31 on Intel 
graphic with i915 driver. I blacklisted permanently with grubby Nouveau 
and that resolved my issue with upgrading on slowness for login to come 
up in fedora 30 and 31 and grey screen after login in 31.


Brian

On 1/23/20 2:50 PM, Andrew J. Caines wrote:

Brian,
FWIW, I'm running my single HDMI-via-dock-connected UHD display at
3840x2160@30Hz out of the Fedora 31 box with Wayland on a Dell Latitude
5500 with Intel UHD Graphics 620 and a Core i5-8365U.

8<
$ sudo lshw -class video
   *-display
description: VGA compatible controller
product: UHD Graphics 620 (Whiskey Lake)
vendor: Intel Corporation
physical id: 2
bus info: pci@:00:02.0
version: 02
width: 64 bits
clock: 33MHz
capabilities: pciexpress msi pm vga_controller bus_master
cap_list rom
configuration: driver=i915 latency=0
resources: irq:130 memory:9000-90ff
memory:8000-8fff ioport:3000(size=64) memory:c-d
$ xrandr --query | head -3
Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767
XWAYLAND1 connected 3840x2160+0+0 (normal left inverted right x axis y
axis) 710mm x 400mm
3840x2160 29.98*+
8<

Don't explect much of unaccelerated UHD video or 3D performance.

While I've not used it for some time, I've had many years of good
results from Nvidia's proprietary driver, however it relied on 32 bit
components which would be unsuitable today.


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: system-upgrade F30->31 prompt oddness: phr009D777;preexecphr009C',data=iris)' - Some Progress

[Philip Rhoades]

People,


On 2020-01-17 08:35, George N. White III wrote:

Before bash got PS0 there was bash-preexec.sh [1].   If your system
was

upgraded serially from before PS0 came to bash this might be leftovers
from bash-preexec.sh.



Sounds plausible - and:


On 2020-01-17 09:03, Samuel Sieb wrote:

On 1/16/20 1:56 PM, Ed Greshko wrote:

Oh, BTW, I have

[egreshko@f31k ~]$ rpm -q setup
setup-2.13.6-1.fc31.noarch



I get the same.



And I know I've not altered /etc/bashrc and I get..

[egreshko@f31k ~]$ sha256sum /etc/bashrc
d925e7ec2fdd6861be5f3a6d5a08a1ff13a10d23ebbb8d26717b1b75ca4f118f  
/etc/bashrc



I get the same.


You should get the same if the file has not be changed if you have the 
same package version installed


Or you can just do "rpm -V setup" to see if anything has changed.



# rpm -V setup
.M...  c /etc/fstab
S.5T.  c /etc/printcap
.MG..  g /var/log/lastlog


Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server 1.4.3.2

[Mark Reynolds]

   389 Directory Server 1.4.3.2

The 389 Directory Server team is proud to announce 389-ds-base version 
1.4.3.2


Fedora packages are available on rawhide.

https://koji.fedoraproject.org/koji/taskinfo?taskID=40928882 
 - Rawhide


The new packages and versions are:

 * 389-ds-base-1.4.3.2-1

Source tarballs are available for download at Download 
389-ds-base Source 




 Highlights in 1.4.3.2

 * Bug fixes


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install the server use *dnf install 389-ds-base*

To install the Cockpit UI plugin use *dnf install cockpit-389-ds*

After rpm install completes, run *dscreate interactive*

For upgrades, simply install the package. There are no further 
steps required.


There are no upgrade steps besides installing the new rpms

See Install_Guide 
 for 
more information about the initial installation and setup


See Source  
for information about source tarballs and SCM (git) access.



 New UI Progress (Cockpit plugin)

The new UI is fully functional. There are still parts that need to be 
converted to ReactJS, but every feature is available.


Configuration Tab
Functional
Written in ReactJS
Server Tab  Yes No (coming soon)
Security TabYes Yes
Database TabYes Yes
Replication Tab Yes Yes
Schema Tab  Yes Yes
Plugin Tab  Yes Yes
Monitor Tab Yes Yes


 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org


If you find a bug, or would like to see a new feature, file it in our 
Pagure project: https://pagure.io/389-ds-base


 * Bump version to 1.4.3.2
 * Issue 49254 - Fix compiler failures and warnings
 * Issue 50741 - cont bdb_start - Detected Disorderly Shutdown
 * Issue 50836 - Port Schema UI tab to React
 * Issue 50842 - Decrease 389-console Cockpit component size
 * Issue 50790 - Add result text when filter is invalid
 * Issue 50627 - Add ASAN logs to HTML report
 * Issue 50834 - Incorrectly setting the NSS default SSL version max
 * Issue 50829 - Disk monitoring rotated log cleanup
   causes heap-use-after-free
 * Issue 50709 - (cont) Several memory leaks reported by Valgrind for
   389-ds 1.3.9.1-10
 * Issue 50784 - performance testing scripts
 * Issue 50599 - Fix memory leak when removing db region files
 * Issue 49395 - Set the default TLS version min to TLS1.2
 * Issue 50818 - dsconf pwdpolicy get error
 * Issue 50824 - dsctl remove fails with “name ‘ensure_str’ is not defined”
 * Issue 50599 - Remove db region files prior to db recovery
 * Issue 50812 - dscontainer executable should be placed
   under /usr/libexec/dirsrv/
 * Issue 50816 - dsconf allows the root password to be set to nothing
 * Issue 50798 - incorrect bytes in format string(fix import issue)

--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

Re: permission woes with systemd

[Samuel Sieb]

On 1/23/20 12:59 PM, sean darcy wrote:

On 1/22/20 3:47 PM, Samuel Sieb wrote:

On 1/22/20 12:00 PM, sean darcy wrote:

On 1/22/20 1:01 AM, Samuel Sieb wrote:

restorecon -rv /etc/asterisk"


Thanks. That did it.

I'll never understand selinux.


My guess is that you copied or more likely moved files into there from 
somewhere else.  Is that right?
Generally, if you get a permission error even though the file 
ownership is correct, check for an selinux context being wrong.

___



OK, but why would it work if I started it directly, and fail from 
systemd, set for the same user?


When it's started from systemd, the selinux context is more restricted 
by design.  When you run it manually, it runs in the unconfined_t 
context, but when run from systemd, it ends up as asterisk_t.  You can 
see that by adding the "Z" option to "ps".


# ps auxwZ | grep asterisk
system_u:system_r:asterisk_t:s0 asterisk   966  0.4  0.2 2167796 62056 ? 
  Ssl   2019 779:32 /usr/sbin/asterisk -f -C 
/etc/asterisk/asterisk.conf

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Andrew J. Caines]

Brian,
FWIW, I'm running my single HDMI-via-dock-connected UHD display at
3840x2160@30Hz out of the Fedora 31 box with Wayland on a Dell Latitude
5500 with Intel UHD Graphics 620 and a Core i5-8365U.

8<
$ sudo lshw -class video
  *-display
   description: VGA compatible controller
   product: UHD Graphics 620 (Whiskey Lake)
   vendor: Intel Corporation
   physical id: 2
   bus info: pci@:00:02.0
   version: 02
   width: 64 bits
   clock: 33MHz
   capabilities: pciexpress msi pm vga_controller bus_master
cap_list rom
   configuration: driver=i915 latency=0
   resources: irq:130 memory:9000-90ff
memory:8000-8fff ioport:3000(size=64) memory:c-d
$ xrandr --query | head -3
Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767
XWAYLAND1 connected 3840x2160+0+0 (normal left inverted right x axis y
axis) 710mm x 400mm
   3840x2160 29.98*+
8<

Don't explect much of unaccelerated UHD video or 3D performance.

While I've not used it for some time, I've had many years of good
results from Nvidia's proprietary driver, however it relied on 32 bit
components which would be unsuitable today.

-- 
-Andrew J. Caines-   Unix Systems Architect   a.j.cai...@halplant.com
  "Machines take me by surprise with great frequency" - Alan Turing
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /etc/bash_completion.d/conda is missing

[Todd Zullinger]

Hiisi wrote:
>> Thanks, Todd! The bug has been submitted:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1791068
>>
> The issue got resolved at updates-testing. Thanks everyone.

Excellent!  It's always nice to see a quick fix from a bug
report.

Thank you for filing it and to Orion for taking care of it
(I've never met Orion, but he's always been very good at
fixing up bugs in the packages he maintains -- and even
those he doesn't.)

-- 
Todd


signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Mr Brian Domenick]

Thank you, that solved my delayed login in 30. I updated using grubby 
the boot menu. I am now in the process of upgrading to 31 and 
optimistic. Thanks to all.



Brian

On 1/23/20 1:41 PM, Ed Greshko wrote:

On 2020-01-24 05:06, Brian Domenick wrote:

Hi, If I blacklist what will be my driver? Thanks.

Should be using

Graphics: Device-1: Intel UHD Graphics 620 vendor: Hewlett-Packard driver: i915 
v:
kernel bus ID: 00:02.0 chip ID: 8086:5917

So, i915 and Intel HW.


On Thu, Jan 23, 2020, 9:24 AM Richard Shaw mailto:hobbes1...@gmail.com>> wrote:

 On Thu, Jan 23, 2020 at 6:22 AM Patrick O'Callaghan mailto:pocallag...@gmail.com>> wrote:

 On Wed, 2020-01-22 at 17:05 -0800, Mr Brian Domenick wrote:
 > Thanks, I know on some laptops you can bios disable the nvidia, but 
not
 > on this one. What is showing thats contrary to what I said ?

 You can blacklist the Nouveau driver in the kernel boot line using e.g.

 modprobe.blacklist=nouveau rd.blacklist=nouveau


 The other option would be to try the binary nvidia drivers from RPM 
Fusion. I've used them for years for good deinterlacing of 1080i TV with MythTV 
and light gaming.

 Thanks,
 Richard
 ___
 users mailing list -- users@lists.fedoraproject.org 

 To unsubscribe send an email to users-le...@lists.fedoraproject.org 

 Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
 List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org



___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Ed Greshko]

On 2020-01-24 05:06, Brian Domenick wrote:
> Hi, If I blacklist what will be my driver? Thanks.

Should be using

Graphics: Device-1: Intel UHD Graphics 620 vendor: Hewlett-Packard driver: i915 
v:
kernel bus ID: 00:02.0 chip ID: 8086:5917

So, i915 and Intel HW.

>
> On Thu, Jan 23, 2020, 9:24 AM Richard Shaw  > wrote:
>
> On Thu, Jan 23, 2020 at 6:22 AM Patrick O'Callaghan 
> mailto:pocallag...@gmail.com>> wrote:
>
> On Wed, 2020-01-22 at 17:05 -0800, Mr Brian Domenick wrote:
> > Thanks, I know on some laptops you can bios disable the nvidia, but 
> not
> > on this one. What is showing thats contrary to what I said ?
>
> You can blacklist the Nouveau driver in the kernel boot line using 
> e.g.
>
> modprobe.blacklist=nouveau rd.blacklist=nouveau
>
>
> The other option would be to try the binary nvidia drivers from RPM 
> Fusion. I've used them for years for good deinterlacing of 1080i TV with 
> MythTV and light gaming. 
>
> Thanks,
> Richard 
> ___
> users mailing list -- users@lists.fedoraproject.org 
> 
> To unsubscribe send an email to users-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


-- 
The key to getting good answers is to ask good questions.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Brian Domenick]

Hi, If I blacklist what will be my driver? Thanks.

On Thu, Jan 23, 2020, 9:24 AM Richard Shaw  wrote:

> On Thu, Jan 23, 2020 at 6:22 AM Patrick O'Callaghan 
> wrote:
>
>> On Wed, 2020-01-22 at 17:05 -0800, Mr Brian Domenick wrote:
>> > Thanks, I know on some laptops you can bios disable the nvidia, but not
>> > on this one. What is showing thats contrary to what I said ?
>>
>> You can blacklist the Nouveau driver in the kernel boot line using e.g.
>>
>> modprobe.blacklist=nouveau rd.blacklist=nouveau
>>
>
> The other option would be to try the binary nvidia drivers from RPM
> Fusion. I've used them for years for good deinterlacing of 1080i TV with
> MythTV and light gaming.
>
> Thanks,
> Richard
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: permission woes with systemd

[sean darcy]

On 1/22/20 3:47 PM, Samuel Sieb wrote:

On 1/22/20 12:00 PM, sean darcy wrote:

On 1/22/20 1:01 AM, Samuel Sieb wrote:

restorecon -rv /etc/asterisk"


Thanks. That did it.

I'll never understand selinux.


My guess is that you copied or more likely moved files into there from 
somewhere else.  Is that right?
Generally, if you get a permission error even though the file ownership 
is correct, check for an selinux context being wrong.

___



OK, but why would it work if I started it directly, and fail from 
systemd, set for the same user?

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

[389-users] Re: healthcheck problems

[Mark Reynolds]

On 1/23/20 2:52 PM, Alberto Viana wrote:

Mark,

# make -f rpm.mk  rpms
# cd dist/rpms


Just like you (I think) hehehe


;-)  That's right!

Now, run this command and provide the output:  rpm -qa | grep 389

Thanks,
Mark


For me, not a big deal anyway.

Thanks

Alberto Viana

On Thu, Jan 23, 2020 at 4:34 PM Mark Reynolds > wrote:



On 1/23/20 1:17 PM, Alberto Viana wrote:

Mark,

I using python3-lib389-1.4.3.1-20200116gita08202a5b.el8.noarch
python3.6

And still got the same error:

DEBUG: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
Traceback (most recent call last):
  File "/usr/sbin/dsctl", line 134, in 
    result = args.func(inst, log, args)
  File
"/usr/lib/python3.6/site-packages/lib389/cli_ctl/health.py", line
88, in health_check_run
    lo_inst = lo(inst)
  File "/usr/lib/python3.6/site-packages/lib389/dseldif.py", line
49, in __init__
    with open(self.path, 'r') as file_dse:
FileNotFoundError: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
ERROR: Error: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'

Should I file a ticket or it already fixed in?

I have never seen this error.  dsctl works fine on RHEL 8 for me. 
Well I did fix an issue around the certificate expiration health
check and python 36 vs 37, but other than that it works.  Like I
said before it looks like your version of lib389 is wrong as this
is an error in a fundamental part of the CLI (looking up the
instance). This code has not changed in a long time which is why I
think you have a problem with how you are trying to deploy the
server.  How are you building the rpms again?


Thanks

On Thu, Jan 16, 2020 at 4:27 PM Alberto Viana
mailto:alberto...@gmail.com>> wrote:

Mark,

Thanks, I'm now building the packages as well.


Alberto Viana

On Mon, Jan 13, 2020 at 4:58 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:


On 1/13/20 2:56 PM, Alberto Viana wrote:

Mark,

Just to let you know, I'm cloning pagure repo and
in /src/lib389 the VERSION file points me to this version:

~# cat VERSION
1.0.4

That's obsolete since we made it a subpackage of
389-ds-base...


Thanks

Alberto Viana

On Mon, Jan 13, 2020 at 4:48 PM Alberto Viana
mailto:alberto...@gmail.com>> wrote:

Mark,

I'm installing it from source, to install lib389 I run:
make lib389-install

Am I missing something?

Thanks

Alberto Viana

On Mon, Jan 13, 2020 at 4:36 PM Mark Reynolds
mailto:mreyno...@redhat.com>>
wrote:


On 1/13/20 2:24 PM, Alberto Viana wrote:

Mark,

Here's:

INFO: Checking DSEldif ...
DEBUG: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
Traceback (most recent call last):
  File "/usr/sbin/dsctl", line 134, in 
    result = args.func(inst, log, args)
  File

"/usr/local/lib/python3.6/site-packages/lib389-1.4.0.1-py3.6.egg/lib389/cli_ctl/health.py",
line 88, in health_check_run
    lo_inst = lo(inst)
  File

"/usr/local/lib/python3.6/site-packages/lib389-1.4.0.1-py3.6.egg/lib389/dseldif.py",
line 49, in __init__
    with open(self.path, 'r') as file_dse:


This is the wrong python-lib389 version.  It
would be something like 1.4.2.4.x.  It would
(needs to) match the 389-ds-base package version.

What does "rpm -qa | grep lib389" show?

Thanks,
Mark


FileNotFoundError: [Errno 2] No such file or
directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
ERROR: Error: [Errno 2] No such file or
directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'

Thanks.

Alberto Viana

On Mon, Jan 13, 2020 at 4:19 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:


On 1/13/20 2:07 PM, Alberto Viana wrote:

Hi Guys,

In 389 version 1.4.2.4 healthcheck works fine:

~# dsconf RNP healthcheck

[389-users] Re: healthcheck problems

[Alberto Viana]

Mark,

# make -f rpm.mk rpms
# cd dist/rpms


Just like you (I think) hehehe
For me, not a big deal anyway.

Thanks

Alberto Viana

On Thu, Jan 23, 2020 at 4:34 PM Mark Reynolds  wrote:

>
> On 1/23/20 1:17 PM, Alberto Viana wrote:
>
> Mark,
>
> I using python3-lib389-1.4.3.1-20200116gita08202a5b.el8.noarch
> python3.6
>
> And still got the same error:
>
> DEBUG: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
> Traceback (most recent call last):
>   File "/usr/sbin/dsctl", line 134, in 
> result = args.func(inst, log, args)
>   File "/usr/lib/python3.6/site-packages/lib389/cli_ctl/health.py", line
> 88, in health_check_run
> lo_inst = lo(inst)
>   File "/usr/lib/python3.6/site-packages/lib389/dseldif.py", line 49, in
> __init__
> with open(self.path, 'r') as file_dse:
> FileNotFoundError: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
> ERROR: Error: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
>
> Should I file a ticket or it already fixed in?
>
> I have never seen this error.  dsctl works fine on RHEL 8 for me.  Well I
> did fix an issue around the certificate expiration health check and python
> 36 vs 37, but other than that it works.  Like I said before it looks like
> your version of lib389 is wrong as this is an error in a fundamental part
> of the CLI (looking up the instance).   This code has not changed in a long
> time which is why I think you have a problem with how you are trying to
> deploy the server.  How are you building the rpms again?
>
>
> Thanks
>
> On Thu, Jan 16, 2020 at 4:27 PM Alberto Viana 
> wrote:
>
>> Mark,
>>
>> Thanks, I'm now building the packages as well.
>>
>>
>> Alberto Viana
>>
>> On Mon, Jan 13, 2020 at 4:58 PM Mark Reynolds 
>> wrote:
>>
>>>
>>> On 1/13/20 2:56 PM, Alberto Viana wrote:
>>>
>>> Mark,
>>>
>>> Just to let you know, I'm cloning pagure repo and in /src/lib389 the
>>> VERSION file points me to this version:
>>>
>>> ~# cat VERSION
>>> 1.0.4
>>>
>>> That's obsolete since we made it a subpackage of 389-ds-base...
>>>
>>>
>>> Thanks
>>>
>>> Alberto Viana
>>>
>>> On Mon, Jan 13, 2020 at 4:48 PM Alberto Viana 
>>> wrote:
>>>
 Mark,

 I'm installing it from source, to install lib389 I run:
 make lib389-install

 Am I missing something?

 Thanks

 Alberto Viana

 On Mon, Jan 13, 2020 at 4:36 PM Mark Reynolds 
 wrote:

>
> On 1/13/20 2:24 PM, Alberto Viana wrote:
>
> Mark,
>
> Here's:
>
> INFO: Checking DSEldif ...
> DEBUG: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
> Traceback (most recent call last):
>   File "/usr/sbin/dsctl", line 134, in 
> result = args.func(inst, log, args)
>   File
> "/usr/local/lib/python3.6/site-packages/lib389-1.4.0.1-py3.6.egg/lib389/cli_ctl/health.py",
> line 88, in health_check_run
> lo_inst = lo(inst)
>   File
> "/usr/local/lib/python3.6/site-packages/lib389-1.4.0.1-py3.6.egg/lib389/dseldif.py",
> line 49, in __init__
> with open(self.path, 'r') as file_dse:
>
> This is the wrong python-lib389 version.  It would be something like
> 1.4.2.4.x.  It would (needs to) match the 389-ds-base package version.
>
> What does "rpm -qa | grep lib389" show?
>
> Thanks,
> Mark
>
> FileNotFoundError: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
> ERROR: Error: [Errno 2] No such file or directory:
> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
>
> Thanks.
>
> Alberto Viana
>
> On Mon, Jan 13, 2020 at 4:19 PM Mark Reynolds 
> wrote:
>
>>
>> On 1/13/20 2:07 PM, Alberto Viana wrote:
>>
>> Hi Guys,
>>
>> In 389 version 1.4.2.4 healthcheck works fine:
>>
>> ~# dsconf RNP healthcheck
>> Enter password for cn=Directory Manager on ldaps://localhost:
>> Beginning lint report, this could take a while ...
>> Checking Backends ...
>> Checking Config ...
>> Checking Encryption ...
>> Checking ReferentialIntegrityPlugin ...
>> Healthcheck complete!
>>
>> And seems that function was moved to dsctl
>> but in 1.4.2.5 I got this error:
>>
>> ~# dsctl RNP healthcheck
>> Beginning lint report, this could take a while ...
>> Checking Backends ...
>> Checking Config ...
>> Checking Encryption ...
>> Checking FSChecks ...
>> Checking ReferentialIntegrityPlugin ...
>> Checking MonitorDiskSpace ...
>> Checking Replica ...
>> Checking Changelog5 ...
>> Checking DSEldif ...
>> Error: [Errno 2] No such file or directory:
>> '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
>>
>> Is that a bug?
>>
>> Probably, but not one I've seen.  Maybe 1.4.2 is missing a patch that
>> is in Master branch?  I'll be doing 

[389-users] Re: cockpit ui problem

[Mark Reynolds]

On 1/23/20 1:31 PM, Alberto Viana wrote:
1. UI never shows password administrator field (always blank), even if 
is set:

~# dsconf instace_name config get passwordAdminDN
passwordAdminDN: cn=GRP_SRV_PREHASHED_PASSWORD,ou=test,dc=my,dc=domain


Also tried to setup via UI, but it's blank again after clink on save 
button.


Should I file a ticket?
Yes, and for me I can not even add the password admin in the UI. The 
save button doesn't do anything, which means that setting is being 
completely ignored.


Thanks

Alberto Viana

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org


--

389 Directory Server Development Team

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: healthcheck problems

[Mark Reynolds]

On 1/23/20 1:17 PM, Alberto Viana wrote:

Mark,

I using python3-lib389-1.4.3.1-20200116gita08202a5b.el8.noarch
python3.6

And still got the same error:

DEBUG: [Errno 2] No such file or directory: 
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'

Traceback (most recent call last):
  File "/usr/sbin/dsctl", line 134, in 
    result = args.func(inst, log, args)
  File "/usr/lib/python3.6/site-packages/lib389/cli_ctl/health.py", 
line 88, in health_check_run

    lo_inst = lo(inst)
  File "/usr/lib/python3.6/site-packages/lib389/dseldif.py", line 49, 
in __init__

    with open(self.path, 'r') as file_dse:
FileNotFoundError: [Errno 2] No such file or directory: 
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
ERROR: Error: [Errno 2] No such file or directory: 
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'


Should I file a ticket or it already fixed in?
I have never seen this error.  dsctl works fine on RHEL 8 for me. Well I 
did fix an issue around the certificate expiration health check and 
python 36 vs 37, but other than that it works.  Like I said before it 
looks like your version of lib389 is wrong as this is an error in a 
fundamental part of the CLI (looking up the instance).   This code has 
not changed in a long time which is why I think you have a problem with 
how you are trying to deploy the server.  How are you building the rpms 
again?


Thanks

On Thu, Jan 16, 2020 at 4:27 PM Alberto Viana > wrote:


Mark,

Thanks, I'm now building the packages as well.


Alberto Viana

On Mon, Jan 13, 2020 at 4:58 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:


On 1/13/20 2:56 PM, Alberto Viana wrote:

Mark,

Just to let you know, I'm cloning pagure repo and
in /src/lib389 the VERSION file points me to this version:

~# cat VERSION
1.0.4

That's obsolete since we made it a subpackage of 389-ds-base...


Thanks

Alberto Viana

On Mon, Jan 13, 2020 at 4:48 PM Alberto Viana
mailto:alberto...@gmail.com>> wrote:

Mark,

I'm installing it from source, to install lib389 I run:
make lib389-install

Am I missing something?

Thanks

Alberto Viana

On Mon, Jan 13, 2020 at 4:36 PM Mark Reynolds
mailto:mreyno...@redhat.com>> wrote:


On 1/13/20 2:24 PM, Alberto Viana wrote:

Mark,

Here's:

INFO: Checking DSEldif ...
DEBUG: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
Traceback (most recent call last):
  File "/usr/sbin/dsctl", line 134, in 
    result = args.func(inst, log, args)
  File

"/usr/local/lib/python3.6/site-packages/lib389-1.4.0.1-py3.6.egg/lib389/cli_ctl/health.py",
line 88, in health_check_run
    lo_inst = lo(inst)
  File

"/usr/local/lib/python3.6/site-packages/lib389-1.4.0.1-py3.6.egg/lib389/dseldif.py",
line 49, in __init__
    with open(self.path, 'r') as file_dse:


This is the wrong python-lib389 version. It would be
something like 1.4.2.4.x.  It would (needs to) match
the 389-ds-base package version.

What does "rpm -qa | grep lib389" show?

Thanks,
Mark


FileNotFoundError: [Errno 2] No such file or
directory: '/etc/dirsrv/slapd-{instance_name}/dse.ldif'
ERROR: Error: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'

Thanks.

Alberto Viana

On Mon, Jan 13, 2020 at 4:19 PM Mark Reynolds
mailto:mreyno...@redhat.com>>
wrote:


On 1/13/20 2:07 PM, Alberto Viana wrote:

Hi Guys,

In 389 version 1.4.2.4 healthcheck works fine:

~# dsconf RNP healthcheck
Enter password for cn=Directory Manager on
ldaps://localhost:
Beginning lint report, this could take a while ...
Checking Backends ...
Checking Config ...
Checking Encryption ...
Checking ReferentialIntegrityPlugin ...
Healthcheck complete!

And seems that function was moved to dsctl
but in 1.4.2.5 I got this error:

~# dsctl RNP healthcheck
Beginning lint report, this could take a while ...
Checking Backends ...
Checking Config ...
Checking Encryption ...

[389-users] cockpit ui problem

[Alberto Viana]

1. UI never shows password administrator field (always blank), even if is
set:
~# dsconf instace_name config get passwordAdminDN
passwordAdminDN: cn=GRP_SRV_PREHASHED_PASSWORD,ou=test,dc=my,dc=domain


Also tried to setup via UI, but it's blank again after clink on save button.

Should I file a ticket?

Thanks

Alberto Viana
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Richard Shaw]

On Thu, Jan 23, 2020 at 6:22 AM Patrick O'Callaghan 
wrote:

> On Wed, 2020-01-22 at 17:05 -0800, Mr Brian Domenick wrote:
> > Thanks, I know on some laptops you can bios disable the nvidia, but not
> > on this one. What is showing thats contrary to what I said ?
>
> You can blacklist the Nouveau driver in the kernel boot line using e.g.
>
> modprobe.blacklist=nouveau rd.blacklist=nouveau
>

The other option would be to try the binary nvidia drivers from RPM Fusion.
I've used them for years for good deinterlacing of 1080i TV with MythTV and
light gaming.

Thanks,
Richard
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Brian Domenick]

Thanks, I can try that, but as I posted from dmesg multiple crashes inside.
Did you see that in my email?

Thanks Brian

On Thu, Jan 23, 2020, 4:22 AM Patrick O'Callaghan 
wrote:

> On Wed, 2020-01-22 at 17:05 -0800, Mr Brian Domenick wrote:
> > Thanks, I know on some laptops you can bios disable the nvidia, but not
> > on this one. What is showing thats contrary to what I said ?
>
> You can blacklist the Nouveau driver in the kernel boot line using e.g.
>
> modprobe.blacklist=nouveau rd.blacklist=nouveau
>
> Try editing the boot menu entry by hitting 'e' when the menu appears at
> boot, then adding the above to the line starting 'linux' and hit Ctrl-x
>
> If this works, the problem is with the Nouveau driver.
>
> poc
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: /etc/bash_completion.d/conda is missing

[Hiisi]

On Tue, Jan 14, 2020 at 2:12 PM Hiisi  wrote:
> > ¹ conda/shell/etc/bash_completion.d/conda in the current
> >   conda-4.8.0 tarball.
> >
> > --
> > Todd
> > ___
>
> Thanks, Todd! The bug has been submitted:
> https://bugzilla.redhat.com/show_bug.cgi?id=1791068
>
The issue got resolved at updates-testing. Thanks everyone.

-- 
Hiisi.
Registered Linux User #487982. Be counted at: https://linuxcounter.net/
--
Spandex is a privilege, not a right.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Problems connecting to VM via ssh (Ed Greshko)

[Patrick O'Callaghan]

On Thu, 2020-01-23 at 04:56 +, George R Goffe via users wrote:
> You suggested that this should go to the tst mailing list. Isn't that for 
> testers? Maybe that's what I am? I enjoy being on the bleeding edge and 
> reporting bugs.

If you're using anything other than the released version (currently F30
and F31) you are a tester by definition. It's important to note that
many people on the Test List do not read this (the Users) list.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Fedora upgrade to 30 sluggish X startup then upgrade to 31 grey screen after login

[Patrick O'Callaghan]

On Wed, 2020-01-22 at 17:05 -0800, Mr Brian Domenick wrote:
> Thanks, I know on some laptops you can bios disable the nvidia, but not 
> on this one. What is showing thats contrary to what I said ?

You can blacklist the Nouveau driver in the kernel boot line using e.g.

modprobe.blacklist=nouveau rd.blacklist=nouveau

Try editing the boot menu entry by hitting 'e' when the menu appears at
boot, then adding the above to the line starting 'linux' and hit Ctrl-x

If this works, the problem is with the Nouveau driver.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org