Re: Change in latest update – suspending

[Ahmad Samir]

On 22 February 2018 at 18:39, Michal Jaegermann <michal@gmail.com> wrote:
> On Thu, Feb 22, 2018 at 04:00:44PM +0200, Ahmad Samir wrote:
>> On 22 February 2018 at 14:58, Russel Winder <rus...@winder.org.uk> wrote:
>> > On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
>> >> […]
>> >>
>> >> Anything settable in control-center is likely backed with a dconf key
>> >> you could set.
>> >
>> > True. Finding the path to the key is not always obvious though. I am
>> > guessing that in this case org.gnome.session-daemon may be the place.
>> >
>>
>> $ gsettings list-keys org.gnome.settings-daemon.plugins.power
>>
>> (I usually find that grep'ing in '/usr/share/glib-2.0/schemas/' is
>> sort of faster/easier).
>
> This still leaves a question how you are going to modify that for
> gdm on a machine of a type "server - most of the time"? If I understood
> Russel correctly such setup is hugely affected.
>
>Michal

I missed that part, sorry. One (hackish) way would be to create a new
user account, modify only those gsettings keys then copy
~/.config/dconf/user to (the gdm user home dir[1])
/var/lib/gdm/.config/ and of course make the file owned by gdm.

I haven't tested that method though; but IIRC, one way to get gdm to
use custom multiple monitor settings was to copy
~/.config/monitors.xml (created by the display module of
gnome-control-center) from your regular user account to
/var/lib/gdm/.config/ .

I hope that helps.

[1] which I could see/guess in /etc/passwd.

-- 
Ahmad Samir
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Change in latest update – suspending

[Ahmad Samir]

On 22 February 2018 at 14:58, Russel Winder <rus...@winder.org.uk> wrote:
> On Thu, 2018-02-22 at 04:04 -0800, Adam Williamson wrote:
>> […]
>>
>> Anything settable in control-center is likely backed with a dconf key
>> you could set.
>
> True. Finding the path to the key is not always obvious though. I am
> guessing that in this case org.gnome.session-daemon may be the place.
>

$ gsettings list-keys org.gnome.settings-daemon.plugins.power

(I usually find that grep'ing in '/usr/share/glib-2.0/schemas/' is
sort of faster/easier).

[]

-- 
Ahmad Samir
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: F27 kernel installation big time waster

[Ahmad Samir]

On 8 October 2017 at 11:14, Felix Miata <mrma...@earthlink.net> wrote:
> FWIW in case it could matter, grub* and os-prober are not installed.
>
> I've tried 5 times to dnf install 4.13.4-300.fc27.x86_64 on host p5bse, once
> thru 'dnf update', and 4 more times either dnf reinstall or delete first then
> install. Each time goes through the motions without changing anything in 
> /boot/
> except for the timestamps on the loader and  subdirs. The new kernel
> and initrd do get produced in the  tree. rpm query has shown success
> each time. dnf.rpm.log shows non-fatal POSTTRANS scriptlet failures the first 
> 2
> times, but not the last 3 times. I don't see any details on what is actually
> failing in any of the logs.
>
> Trying to install kernel, core and modules directly with rpm produces a broken
> pipe cat write error, but otherwise no better result than dnf.
>
> Manually copying and renaming the kernel and initrd from  to /boot/
> produces normally booting and running 4.13.4 kernel.
>
> Anyone else experiencing this?

Sounds like this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1475565

--
Ahmad Samir
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: release criteria for final - bug 1320967

[Ahmad Samir]

On 18 May 2016 at 14:41, Joerg Lechner  wrote:

> Hi,
> my question and suggestion is not to have an important issue like this
> -for having one computer as test machine for a new release and in parallell
> for another OS -  as a blocker for Final but earlier as a blocker for Alpha
> or Beta, then at least for me it's easier to help testing in a new release.


I misunderstood then, sorry about the noise :|.


> This is a suggestion for F25, currently for my use I  can still run F23 ||
> Win 8.1, but I can not so easily contribute to F24 testing. Is there a bug
> report helpful?
> Kind regards
>
>
>
I am not sure about the process/procedure to change the criteria, but
posting to this list is a logical first step, I think.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: release criteria for final - bug 1320967

[Ahmad Samir]

On 18 May 2016 at 07:39, Joerg Lechner <julech...@aol.com> wrote:

> Hi,
> I use an about one year old Acer laptop, internal disk Win 8.1, F23/F24 on
> usb flash media, for F20/21/22/23 I tested as user, using the Fedora
> version in development. Because of "
> F24 Alpha 1.7 Desktop - Grub boot menue, not possible to start Win 8.1
> <https://bugzilla.redhat.com/show_bug.cgi?id=1320967>" - Bug 1320967, in
> F24 I don't test very frequently, because unplugging/plugging (in my case
> neccessary for F24) the usb media very often I forget, when I switch from
> Win to Fedora and vice versa. This problem of Grub is a release criteria
> for final. Is it possible to have it for F25 as a release criteria for Beta
> or Alpha?
> Kind Regards
>
>
It's a known issue
https://fedoraproject.org/wiki/Common_F24_bugs#uefi-chainloading-error

-- 
Ahmad Samir
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: /boot/efi not possible to delete via automatic config in installation

[Ahmad Samir]

On 4 May 2016 at 13:34, Joerg Lechner <julech...@aol.com> wrote:

> Hi,
> in F24 Beta 1.6 using automatic configuration of partitions in the
> installation now the EFI System Partition is not possible to delete, as all
> other partitions of the previous build to get space for the installation.
> Is the "old" /boot/efi code also used in the new installation, or is only
> the partition size kept?
> Kind regards
>
>
I did a couple of tests on UEFI and installed using both the workstation
Live and the workstation netinstall iso's respectively and could delete the
EFI system partition without problems

If you're still hitting that issue file a bug report and attach the files
in /var/log/anaconda/ as text files.

-- 
Ahmad Samir
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Self-introduction: Ahmad Samir

[Ahmad Samir]

Hello. My name is Ahmad; I started using Linux a couple of years ago. I
used other distros then switched to Fedora and it seems I'll be sticking
around for a while so might as well try to use my free time to give back to
the Linux/Fedora ecosystem.

I'd spent some time in the past doing bugzilla work (triage among other
things) in two other distros (Mandriva and then Mageia); I can't say I did
stellar work but I always tried to do my best. Things seem different here
in the Fedora land. I am looking forward to trying my hand at this QA work.

I read some of the articles in the wiki about QA ... etc, so I have a
general idea about what's going on but I certainly look forward to older
hands' help/guidance.

-- 
Ahmad Samir
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: SELinux is preventing logrotate from read access on the directory /var/cache/dnf.

[Ahmad Samir]

2014-12-21 15:59 GMT+02:00 Lawrence E Graves lgrave...@gmail.com:
 SELinux is preventing logrotate from read access on the directory
 /var/cache/dnf.


IIUC, this bug was reported and has already been fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1163438

-- 
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F21 emergency.target when root pw isn't set

[Ahmad Samir]

On 20 December 2014 at 09:38, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Sat, 2014-12-20 at 07:47 +0200, Ahmad Samir wrote:

 I've tested the F20 desktop live CD, the installer doesn't let me
 continue unless I set a root password.

 It is happy so long as you *either* set a root password *or* create an
 admin user account.

I missed the bit about the admin user account (I usually never enable
that option).

-- 
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F21 emergency.target when root pw isn't set

[Ahmad Samir]

On 19 December 2014 at 00:35, Chris Murphy li...@colorremedies.com wrote:
 On Thu, Dec 18, 2014 at 3:30 PM, Chris Murphy li...@colorremedies.com wrote:
 On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson

 init=/bin/bash

 There was a fun bug with that if you had encrypted filesystems in F20,
 but I think it's fixed now.

 WTH, I tried that earlier and got a kernel panic twice in a row, and I
 just tried it again and now I'm not.

 Ahha! It matters where it goes in the argument line. If I put it in
 the middle right after ro (changed to rw) then I get a kp. If I put it
 at the end of the line where quiet rhgb are, then I don't get a kp.

 However, after changing the root password, the command reboot is not
 found. And exit causes a kernel panic!



You'd have to use:
/sbin/reboot -f

Have a look at https://fedoraproject.org/wiki/How_to_reset_a_root_password
(FWIW that bit, among others, was added by the systemd maintainer in Fedora).

-- 
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F21 emergency.target when root pw isn't set

[Ahmad Samir]

On 19 December 2014 at 20:49, Chris Murphy li...@colorremedies.com wrote:
 On Fri, Dec 19, 2014 at 2:17 AM, Ahmad Samir ahmadsamir3...@gmail.com wrote:

 You'd have to use:
 /sbin/reboot -f

 Right, thanks.

 Have a look at https://fedoraproject.org/wiki/How_to_reset_a_root_password
 (FWIW that bit, among others, was added by the systemd maintainer in Fedora).

 I referred to that same wiki earlier in this thread. It seemed dated
 because it starts out saying that setting a root password is
 mandatory, which isn't correct. And a big part of the problem is this
 incongruence between systemd requiring a root password but the
 installer not requiring a root password. So in the however likely
 event the user needs emergency target, or is inadvertently dropped
 there, some percent of users are stuck because they don't have a root
 password and they're not really informed of this in advance. So it's a
 catch-22.


I've tested the F20 desktop live CD, the installer doesn't let me
continue unless I set a root password.

So the problem here is a corner case where you want to boot the live
CD to the emergency/rescue target where the live system doesn't have a
root password set.

 Either systemd needs to back off on the root password requirement,
 which seems unlikely,

I agree with what you said in a previous email; the emergency/rescue
target requiring the root password doesn't make much sense to me.

Having physical access to the machine means that the only practical
security against tampering is having your filesystems encrypted. (It's
cheaper to encrypt one's filesystems than buying a titanium vault to
store the box).

So what's the point of using sulogin if that can be worked around
using 'init=/bin/bash'? (and I don't think a grub password is much
help against someone having physical access to the machine).
Previously the rescue/emergency target used sushell.

 or the installer needs to insist the user set a
 root password, which is sorta icky because two passwords to do an
 installation? And then the most likely user who will fall into this
 trap is the Fedora Workstation user, who also has media that can't
 boot in rescue mode (i.e. anaconda rescue mode).

 Still, short term I think it's better if the user is required to set a
 root password. I think we have more users who end up getting dropped
 to emergency shell with a reference to rdsosreport than users exposing
 themselves to vulnerability by having a root password set (vs not
 set).



[...]

-- 
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: default kernel

[Ahmad Samir]

On 19/08/14 01:15, Ed Greshko wrote:

On 08/19/14 03:28, Bruno Wolff III wrote:

On Mon, Aug 18, 2014 at 15:04:53 -0400,
  Tom Horsley horsley1...@gmail.com wrote:

On Mon, 18 Aug 2014 07:59:53 -0500
Bruno Wolff III wrote:


Normally whether to use the lastest or previous kernel by default is
set in /etc/sysconfig/kernel.


Well, I finally got a chance to check that file and it says:

UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel-core

Not sure what the kernel-core setting means, but it definitely
looks as if UPDATEDEFAULT=yes was ignored.


If you were using a PAE kernel, it would have had kernel-PAE-core (or 
kernel-PAE). This matters if you have both PAE and non-PAE kernels installed. 
(Previously SMP kernels used to be available as well.) It says which varient 
should be used for the default boot.


I don't yet have an F21 system.  But on an F20 system these are set to

UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel

If there is no package type of kernel-core then I suspect all bets are off as 
to the behavior.



For F21 the kernel team have changed how the kernel packages are split: 
http://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud


--
Ahmad Samir
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: default kernel

[Ahmad Samir]

On 18/08/14 22:04, Tom Horsley wrote:

On Mon, 18 Aug 2014 07:59:53 -0500
Bruno Wolff III wrote:


Normally whether to use the lastest or previous kernel by default is
set in /etc/sysconfig/kernel.


Well, I finally got a chance to check that file and it says:

UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel-core

Not sure what the kernel-core setting means, but it definitely
looks as if UPDATEDEFAULT=yes was ignored.



Did you try reinstalling that latest kernel package? it could simply be 
the rpm post install scripts didn't run/finish properly the first time 
around..


--
Ahmad Samir
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: slow mirror workaround?

[Ahmad Samir]

On 8 December 2013 03:45, Felix Miata mrma...@earthlink.net wrote:

 On 2013-04-23 04:43 (GMT-0500) Kamil Paral composed:


  Trying to yum upgrade 19 is stuck on a mirror with no useful throughput.
 What
 kind of workaround for this is available? Nothing jumps at me in the yum
 man
 page. How do I specify to use a particular mirror know to work?


 If the speed is below some threshold, yum should blacklist the mirror and
 use a different one


 Yum doesn't bother to show URL of inept mirror in use. How do I figure out
 which to blacklist?



I know this is an old thread.

Try setting the env var URLGRABBER_DEBUG=1, e.g. 'URLGRABBER_DEBUG=1 yum
install foo', it gives a huge amount of extra debug output; the point is it
shows the mirror yum picked to download a package.


 next time. If you don't have the patience, try hitting Ctrl+C during the
 download. Ideally this should switch to a different mirror (but I'm not
 sure if this functionality wasn't removed).

 Not happening.


  Of course, you can also edit /etc/yum/*.repo and hardcode some fast
 mirror near you:
 https://mirrors.fedoraproject.org/


 From looking at these repo files, it's non-obvious how to deviate from the
 standard configuration's use of variables.


  But that doesn't guard you against outdated mirrors, and doesn't provide
 fallback if your chosen mirror is down.

 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test




-- 
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is yum groups broken in f20 ?

[Ahmad Samir]

On 12 December 2013 06:35, Michael Cronenworth m...@cchtml.com wrote:
 On 12/08/2013 08:37 AM, Mateusz Marzantowicz wrote:

 Curious, why it blew up right now, just before F20 is released. It
 should have happened in alpha and not now.

 Workaround is to yum group mark remove group name here for every group
 on the list. What a waste of time.


 Whatever you do - do not run yum group mark convert. Now one of my systems
 wants to install every Fedora package with yum update.

 This affects all Fedoras with yum -120. Here's the parent bug:
 https://bugzilla.redhat.com/show_bug.cgi?id=1014202


It looks like setting upgrade_group_objects_upgrade=0 or
group_command=simple sorts that issue out. (FWIW, I went for the
big-axe solution and 'yum group mark remove' all the groups yum
complained about, ~ 20+ groups).

Honestly I still can't get my head around that yum-groups-as-objects change...

 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test



-- 
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: consider people with poor vision

[Ahmad Samir]

On 19 June 2013 17:46, Adam Williamson awill...@redhat.com wrote:

 On Wed, 2013-06-19 at 10:41 -0500, Michael Hennebry wrote:
  On Tue, 18 Jun 2013, Adam Williamson wrote:
 
   On Tue, 2013-06-18 at 15:02 -0500, John Morris wrote:
 
   So lemme recap what you have been saying in this and other posts
   The
   current design breaks both internationalization and accessability and
   you recognize that reality.  Fixing these problems isn't an option
   though because well because.
  
   Tearing Anaconda apart and rebuilding it from the ground up was an
   imperative, complaints be damned, because the Anaconda devs had a
   hankering to do that; they had a fever and the only cure was some
   more
   cowbell.  But making it useable while they already had it tore apart?
   Nobody was interested in that.
 
   What I'm saying is that there isn't a quick fix to this, which is what
   Felix always suggests; his suggestions always boil down to make the
   fonts bigger! now!
 
   Given all of that, it's almost never the case that there's a 'quick
   fix'
   for anything when it comes to the UI. If we're going to make anaconda
   more accessible we need to take an overview of how to do it without
   compromising its other design goals, not just start throwing out quick
   fix ideas.
 
  While I doubt that there is a quick road to perfection,
  making things better should not be all that nasty.
  There is no need to ask the display how big it is.
  Just ask the user if a bigger font is desired.
  The user does not need to be given a lot of choices.
  96, 192 and something in between would be an improvement.

 It'd be an improvement for the still small number of people who need it.

I haven't tested the F19 installer, but in the F18 installer, under
Troubleshooting, there's an Install Fedora using basic graphics
mode option which makes Anaconda use the Vesa driver. I think anyone
can see the text in the installer under that mode.

[]

--
Ahmad Samir
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test