Re: tablets?

[Hans de Goede]

Hi,

On Tuesday, January 22, 2019 10:54:18 PM EST ToddAndMargo via users wrote:

Hi All,

Any sign of Fedora on a tablet?


I've been working on Linux/Fedora Bay- and Cherry-Trail based
hardware support for the last year or so.

The current state of this is pretty good. If you are interested
in Fedora on a tablet I would advice you to buy a Cherry Trail based
tablet. If you buy a model for which I've not done the hardwar-enabling
yet, you may need to do some (simple-ish) work to help me enable
the touchscreen, accelerometer and to get audio to work 100%.

This may require some device(model) specific firmware files from the Windows
installation, so it is best to start with running from a liveusb and if then
either wifi or the touchscreen don't work, drop me an email an I
can walk you through getting the necessary files from the Windows
install before you wipe it.

Alternatively you can find a device which you like and send me
a link to a webpage describing it, then I can probably tell you before
hand how much work it is going to need, if any at all.

Regards,

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

Re: How to Troubleshoot? No trackpad right button Inspiron 5558 F29

[Hans de Goede]

Hi,

On 1/11/19 12:30 AM, Ted Roche wrote:

Dell Inspiron 5558, upgraded from F28 to F29 and all seemed well, until I 
noticed right mouse button on trackpad was not registering. With a cordless 
Logitech mouse plugged in, right-mouse clicks bring up the appropriate context 
menus.

Running the "mouse and touchpad" app under devices in GNOME Settings show both 
right and left mouse clicks detected as a primary button.

Tested GNOME on Xorg and Wayland.

I'd welcome suggestions on what I might try or look at for troubleshooting.


I guess your trackpad is a clickpad, iow it does not have separate physical 
buttons,
but you click the bottom right / left of the pad down to click, correct?

In that case GNOME3 now defaults to clicking the pad anywhere with 2 fingers
at the same time to do a right click.

If you want the old bottom right area is a right click behavior, install
gnome-tweaks, run it and go to: "Keyboard and Mouse" and then for
"Mouse Click Emulation" select "Area".

Regards,

Hans





The logs include:
16:07:46 kernel: psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 
0x1e2b1, caps: 0xd00323/0x840300/0x12e800/0x0, board id: 3014, fw id: 1832337
16:07:46 kernel: psmouse serio1: synaptics: Your touchpad (PNP: DLLb6ae PNP0f13) says 
it can support a different bus. If i2c-hid and hid-rmi are not used, you might want 
to try setting psmouse.synaptics_intertouch to 1 and report this to 
linux-in...@vger.kernel.org .
16:07:46 kernel: psmouse serio1: synaptics: queried min coordinates: x 
[1278..], y [1206..]
16:07:46 kernel: psmouse serio1: synaptics: queried max coordinates: x 
[..5664], y [..4648]


--
Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: New f29 install, windows 10 not detected / grub2-editenv nit

[Hans de Goede]

Hi,

On 09-01-19 19:16, Hans de Goede wrote:

Hi,

On 09-01-19 16:10, Richard Shaw wrote:

On Wed, Jan 9, 2019 at 8:57 AM Hans de Goede mailto:hdego...@redhat.com>> wrote:

    Hi,

    On 09-01-19 15:11, Richard Shaw wrote:
 > Following up on Windows 10 not being detected I have a strange (to me) 
issue...
 >
 > Windows 10 created an EFI partition
 >
 > Fedora did a EFI install but DID NOT install the EFI data to the EFI 
partition that Windows created and DID NOT create one of its own. The Fedora EFI 
files are installed to the plain /boot partition.
 >
 > Now I will say this is a somewhat older computer and has pretty early 
EFI support (EFI Ready). There's no configurable EFI options in the BIOS other 
than for CD/DVD booting.
 >
 > Thoughts?

    I believe this means that Fedora did not recognize your machine as using 
UEFI
    and is using classic BIOS boot instead. When you installed Fedora and
    booted from a CD or USB stick, you likely got the option to either boot
    Fedora in classic BIOS mode (probably marked in your BIOS boot menu as just "USB 
storage"
    or some such) and to boot it in UEFI mode (marked with EFI in the name 
somewhere),
    I think you probably picked the classic option, causing Fedora to do
    a classic install.


Ok... I thought the presence of /boot/efi/EFI meant it was booting UEFI but I 
checked my MythTV system which hasn't seen a fresh install since 2012 and it 
has those directories as well. It does have BIOS_BOOT since the main HD is gpt 
partitioned.

    Since you are getting what is most likely a classic BIOS grub version now
    when booting now your BIOS likely remembered that you booted in classic mode
    the last time and stuck with that.

    If Windows 10 expects to be loaded through UEFI then chainloading won't 
work.
    Take a look in your BIOS if you can turn EFI mode on, or try hitting F12 / 
F8
    (or some such) to get your BIOS boot menu. Probably you can choose between
    UEFI and classic booting your harddisk.


I'll double check but it treats the USB has a hard disk and I don't recall 
seeing a EFI option. The ONLY option related to EFI in the BIOS is for CD/DVD 
devices which is set, hence Win10 getting installed EFI using the disc. I may 
have to actually burn the ISO to disk to get it to boot in UEFI mode.


In that case it is probably easier to convert your existing install to UEFI:

1) Move /boot/efi contents to some place
2) Edit fstab mount the existing EFI system partition on /boot/efi
3) mount /boot/efi
4) move /boot/efi contents back in place
5) Run efibootmgr, doing something like:

efibootmgr -c -d /dev/sda -p 1 -L Fedora -l '\EFI\fedora\grubx64.efi'

This will tell your BIOS to add a "Fedora" entry to its UEFI boot menu.

You may need to adjust the /dev/sda and the partition "1" to match
your system. Also this assume your system and Fedora install are 64 bits,
UEFI is only supported with a 64 bit install. Perhaps that is why
your BIOS is not giving an EFI option for the USB disk ?

For some more info on how to convert a system to UEFI see:
https://oded.blog/2017/11/13/fedora-bios-to-uefi/

You may also want to use the -o option after running the -c
(for create) command to make Fedora the default.

Ugh I just realized that efibootmgr will only work if
you are already booted in UEFI mode. If you can get Windows
to boot again by trying to re-enable UEFI or some such
in the BIOS you can probably find a similar tool under
Windows. Sometimes UEFI BIOS also allow you to select an
EFI binary to execute, in that case you can navigate to
EFI\fedora\grubx64.efi and execute it directly or if
you can start an EFI commandline shell you can start
grubx64.efi from there.

Once you've booted Fedora in UEFI mode that way you can
use the efibootmgr command to permanently add Fedora to
the list of OS-es the UEFI part of your BIOS knows about.

If there is none of these options you may need to clear your mbr
or open fdisk and re-write the existing GPT table, so that you get
a dummy old style partition table (as is normally used with GPT)
that may kick the BIOS back into UEFI mode and give you Windows 10
again.

Note steps 1-4 are harmless (if done correct) and you will still
be able to boot in legacy mode regardless.


p.s.

Once you have Fedora booting in UEFI mode, re-run grub2-mkconfig and
now it will hopefully pickup the Windows install.

REgards,

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

Re: New f29 install, windows 10 not detected / grub2-editenv nit

[Hans de Goede]

Hi,

On 09-01-19 16:10, Richard Shaw wrote:

On Wed, Jan 9, 2019 at 8:57 AM Hans de Goede mailto:hdego...@redhat.com>> wrote:

Hi,

On 09-01-19 15:11, Richard Shaw wrote:
 > Following up on Windows 10 not being detected I have a strange (to me) 
issue...
 >
 > Windows 10 created an EFI partition
 >
 > Fedora did a EFI install but DID NOT install the EFI data to the EFI 
partition that Windows created and DID NOT create one of its own. The Fedora EFI 
files are installed to the plain /boot partition.
 >
 > Now I will say this is a somewhat older computer and has pretty early 
EFI support (EFI Ready). There's no configurable EFI options in the BIOS other 
than for CD/DVD booting.
 >
 > Thoughts?

I believe this means that Fedora did not recognize your machine as using 
UEFI
and is using classic BIOS boot instead. When you installed Fedora and
booted from a CD or USB stick, you likely got the option to either boot
Fedora in classic BIOS mode (probably marked in your BIOS boot menu as just "USB 
storage"
or some such) and to boot it in UEFI mode (marked with EFI in the name 
somewhere),
I think you probably picked the classic option, causing Fedora to do
a classic install.


Ok... I thought the presence of /boot/efi/EFI meant it was booting UEFI but I 
checked my MythTV system which hasn't seen a fresh install since 2012 and it 
has those directories as well. It does have BIOS_BOOT since the main HD is gpt 
partitioned.

Since you are getting what is most likely a classic BIOS grub version now
when booting now your BIOS likely remembered that you booted in classic mode
the last time and stuck with that.

If Windows 10 expects to be loaded through UEFI then chainloading won't 
work.
Take a look in your BIOS if you can turn EFI mode on, or try hitting F12 / 
F8
(or some such) to get your BIOS boot menu. Probably you can choose between
UEFI and classic booting your harddisk.


I'll double check but it treats the USB has a hard disk and I don't recall 
seeing a EFI option. The ONLY option related to EFI in the BIOS is for CD/DVD 
devices which is set, hence Win10 getting installed EFI using the disc. I may 
have to actually burn the ISO to disk to get it to boot in UEFI mode.


In that case it is probably easier to convert your existing install to UEFI:

1) Move /boot/efi contents to some place
2) Edit fstab mount the existing EFI system partition on /boot/efi
3) mount /boot/efi
4) move /boot/efi contents back in place
5) Run efibootmgr, doing something like:

efibootmgr -c -d /dev/sda -p 1 -L Fedora -l '\EFI\fedora\grubx64.efi'

This will tell your BIOS to add a "Fedora" entry to its UEFI boot menu.

You may need to adjust the /dev/sda and the partition "1" to match
your system. Also this assume your system and Fedora install are 64 bits,
UEFI is only supported with a 64 bit install. Perhaps that is why
your BIOS is not giving an EFI option for the USB disk ?

For some more info on how to convert a system to UEFI see:
https://oded.blog/2017/11/13/fedora-bios-to-uefi/

You may also want to use the -o option after running the -c
(for create) command to make Fedora the default.

Ugh I just realized that efibootmgr will only work if
you are already booted in UEFI mode. If you can get Windows
to boot again by trying to re-enable UEFI or some such
in the BIOS you can probably find a similar tool under
Windows. Sometimes UEFI BIOS also allow you to select an
EFI binary to execute, in that case you can navigate to
EFI\fedora\grubx64.efi and execute it directly or if
you can start an EFI commandline shell you can start
grubx64.efi from there.

Once you've booted Fedora in UEFI mode that way you can
use the efibootmgr command to permanently add Fedora to
the list of OS-es the UEFI part of your BIOS knows about.

If there is none of these options you may need to clear your mbr
or open fdisk and re-write the existing GPT table, so that you get
a dummy old style partition table (as is normally used with GPT)
that may kick the BIOS back into UEFI mode and give you Windows 10
again.

Note steps 1-4 are harmless (if done correct) and you will still
be able to boot in legacy mode regardless.

Regards,

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

Re: New f29 install, windows 10 not detected / grub2-editenv nit

[Hans de Goede]

Hi,

On 09-01-19 15:11, Richard Shaw wrote:

Following up on Windows 10 not being detected I have a strange (to me) issue...

Windows 10 created an EFI partition

Fedora did a EFI install but DID NOT install the EFI data to the EFI partition 
that Windows created and DID NOT create one of its own. The Fedora EFI files 
are installed to the plain /boot partition.

Now I will say this is a somewhat older computer and has pretty early EFI 
support (EFI Ready). There's no configurable EFI options in the BIOS other than 
for CD/DVD booting.

Thoughts?


I believe this means that Fedora did not recognize your machine as using UEFI
and is using classic BIOS boot instead. When you installed Fedora and
booted from a CD or USB stick, you likely got the option to either boot
Fedora in classic BIOS mode (probably marked in your BIOS boot menu as just "USB 
storage"
or some such) and to boot it in UEFI mode (marked with EFI in the name 
somewhere),
I think you probably picked the classic option, causing Fedora to do
a classic install.

Since you are getting what is most likely a classic BIOS grub version now
when booting now your BIOS likely remembered that you booted in classic mode
the last time and stuck with that.

If Windows 10 expects to be loaded through UEFI then chainloading won't work.
Take a look in your BIOS if you can turn EFI mode on, or try hitting F12 / F8
(or some such) to get your BIOS boot menu. Probably you can choose between
UEFI and classic booting your harddisk.

If you've not customized Fedora a lot yet, it is probably best to
re-install Fedora and make sure you pick the UEFI boot option this time.

Regards,

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

Re: grub menu

[Hans de Goede]

Hi,

On Mon, Nov 12, 2018 at 3:05 PM Tom Horsley  wrote:


If I edit the grub.cfg file and replace this absurd
chunk of gibberish:

if [ x$feature_timeout_style = xy ] ; then
  if [ "${menu_show_once}" ]; then
unset menu_show_once
save_env menu_show_once
set timeout_style=menu
set timeout=60
  elif [ "${menu_auto_hide}" -a "${last_boot_ok}" = "1" ]; then
set orig_timeout_style=${timeout_style}
set orig_timeout=${timeout}
if [ "${fastboot}" = "1" ]; then
  # timeout_style=menu + timeout=0 avoids the countdown code keypress check
  set timeout_style=menu
  set timeout=0
else
  set timeout_style=hidden
  set timeout=1
fi
  fi
fi

with just

set timeout=5

will I get my grub menu back so I can do things
like choose previous kernels?

Or should I just delete the entire chunk of code
between the 01_menu_auto_hide comments?

And why isn't there a way to disable the whole
auto hide nonsense? The only thing it appears to be
checking is a serial console, no define you can provide
to just say "Dammit! Don't hide my menu!"


I see that you've already solved this. For the record,
this can be disabled much easier by doing:

sudo grub2-editenv - unset menu_auto_hide

As documented in the GRUB hidden menu change FAQ:
https://hansdegoede.livejournal.com/19081.html

Which is linked from the change page:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu#Documentation

Regards,

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

Re: 132 packages were deleted from my system

[Hans de Goede]

Hi,

On 17-07-18 14:45, Hans de Goede wrote:

Hi,

On 17-07-18 03:35, pgaltieri wrote:

I just discovered that a whole bunch of packages just got deleted from my F27 
system after doing an update.  This happened on 2 different systems.  I 
discovered this after I had to reboot one of them because the laptop screen 
went blank.  After rebooting it never went to graphics mode.  I discovered then 
that the gdm package had been deleted.  I then looked at the dnf.log file and 
it shows that 12 packages were updated and 119 packages were removed.  WTF?


The root cause for this is likely my bad, sorry.

I did a security update for soundtouch and I did not realize
that F27 was at an older version, so the update introduces
a soname change.

I became aware of this yesterday but did not immediately rush
to fix it, because dnf's normal behavior is to just ignore
the new soundtouch package due to broken deps.

AFAIK the behavior you are seeing should only happen if you
specify --allow-erasing or have set the same option
in your dnf.conf.

My apologies for this. I believe the main culprit in the
dep-chain leading to this removals is gstreamer1-plugins-bad-free
I will go and do a rebuild of that against the new
soundtouch right away (and after that also rebuild the
other packages depending on soundtouch).


All packages depending on soundtouch have been rebuild, updates here:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-cfa159de56
https://bodhi.fedoraproject.org/updates/FEDORA-2018-3044ef3ee5

I've also filed a ticket with FESCO to ask them to look into
improving the update process to automatically catch updates
causing broken deps and not allow the update into stable:

https://pagure.io/fesco/issue/1946  

And somewhat related a request to improve the filtering options
for fedmsg notifications:

https://pagure.io/fesco/issue/1947

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/TSDDDKLYBK6P4A6MC75NS4U3THZMWUSW/

Re: 132 packages were deleted from my system

[Hans de Goede]

Hi,

On 17-07-18 14:45, Hans de Goede wrote:

Hi,

On 17-07-18 03:35, pgaltieri wrote:

I just discovered that a whole bunch of packages just got deleted from my F27 
system after doing an update.  This happened on 2 different systems.  I 
discovered this after I had to reboot one of them because the laptop screen 
went blank.  After rebooting it never went to graphics mode.  I discovered then 
that the gdm package had been deleted.  I then looked at the dnf.log file and 
it shows that 12 packages were updated and 119 packages were removed.  WTF?


The root cause for this is likely my bad, sorry.

I did a security update for soundtouch and I did not realize
that F27 was at an older version, so the update introduces
a soname change.

I became aware of this yesterday but did not immediately rush
to fix it, because dnf's normal behavior is to just ignore
the new soundtouch package due to broken deps.

AFAIK the behavior you are seeing should only happen if you
specify --allow-erasing or have set the same option
in your dnf.conf.

My apologies for this. I believe the main culprit in the
dep-chain leading to this removals is gstreamer1-plugins-bad-free
I will go and do a rebuild of that against the new
soundtouch right away (and after that also rebuild the
other packages depending on soundtouch).


Leigh already rebuild gstreamer1-plugins-bad-free for this:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-cfa159de56

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/YUD3LOMW72GYIPHVVM5DAIXQKPYSGIES/

Re: 132 packages were deleted from my system

[Hans de Goede]

Hi,

On 17-07-18 03:35, pgaltieri wrote:

I just discovered that a whole bunch of packages just got deleted from my F27 
system after doing an update.  This happened on 2 different systems.  I 
discovered this after I had to reboot one of them because the laptop screen 
went blank.  After rebooting it never went to graphics mode.  I discovered then 
that the gdm package had been deleted.  I then looked at the dnf.log file and 
it shows that 12 packages were updated and 119 packages were removed.  WTF?


The root cause for this is likely my bad, sorry.

I did a security update for soundtouch and I did not realize
that F27 was at an older version, so the update introduces
a soname change.

I became aware of this yesterday but did not immediately rush
to fix it, because dnf's normal behavior is to just ignore
the new soundtouch package due to broken deps.

AFAIK the behavior you are seeing should only happen if you
specify --allow-erasing or have set the same option
in your dnf.conf.

My apologies for this. I believe the main culprit in the
dep-chain leading to this removals is gstreamer1-plugins-bad-free
I will go and do a rebuild of that against the new
soundtouch right away (and after that also rebuild the
other packages depending on soundtouch).

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/VYS2FWUP3DKNMU4ECKXNJCHPZVIO62HR/

Re: F28 - kernel-PAE missing?

[Hans de Goede]

Hi,

On 04-05-18 01:36, Jim Simmons wrote:

On Thu, May 03, 2018 at 01:36:43PM -0700, Samuel Sieb wrote:

On 05/03/2018 01:07 PM, Joe Zeff wrote:

On 05/03/2018 12:46 PM, Samuel Sieb wrote:

Ok, so using the F27 installed kernel works on F28.


What else would you expect?  The kernel doesn't care what version
of Fedora you're running.  If it did, the upgrade would have
removed the F27 kernels.


That was just a lead in to the issue being with dracut.  I
reconsidered how to write that part a few times and I think in the
end I lost part of what I was thinking and wanted to say. :-)


I'm pretty sure it is dracut.  Installing the normal kernel from
Fedora 27 and it won't boot either.  I saw dracut complaining about
not finding busybox and biosdevname so I installed them and
reinstalled the kernel - same results.  I also get a couple of grep
errors referring to /usr/lib/plymouth/plymouth-populate-initrd but
I think they're harmless and dnf whatprovides can't find that file.

I'm going to try booting a live cd (xfce f28 i386) and if that works
I'll just reinstall.  Otherwise I'll leave it like it is until I can
get the machine cleaned out and shutdown for good.

If I can figure out what is different in the initrd, I'll reply with
the info.


If you're using BIOS RAID on a non Intel controller (so you've a RAID
set which the BIOS can see so it can boot from it) then it might very
well be a problem with dmraid, which is the tool which recognizes the
RAID headers.

Try running dmraid -r that will show a list of recognized RAID sets,
if that does not see any sets try downgrading dmraid to the version
from F27 and see if it then does recognize your raidset.

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: portable (really) Fedora on stick

[Hans de Goede]

Hi,

On 23-04-18 16:20, Aleksandar Kostadinov wrote:

Hi,

I'm reading documentation [1] for Fedora on a USB stick. The only option to 
have a portable fedora on a stick seems to be by creating an overlay FS and 
this certainly leads to getting out of disk space at some point.

I would really like to create Fedora on USB that I can plug anywhere and work 
off it.

I was thinking that perhaps I can just install regular fedora on a USB stick 
like I would do on a hard drive. Then it can be updated and used just like any 
other Fedora machine. Perhaps disable persistent logging and swap so that flash 
memory doesn't wear out.

One issue I presently know about is dracut. It creates by default images that 
only support a specific hardware. i.e. if I install kernel on a machine with an 
nforce  disk controller, it will put in intird only that module thus Fedora 
will not boot on a machine with AHCI controller.

Maybe this wouldn't matter when all things are on the USB drive but then can 
there be a problem with different USB controller modules?

I was wondering if anybody tried that and has tips for greated portability.


Just installing to an USB stick instead of running a live iso from
the USB stick will work. But USB sticks tend to be slow, someone else
in the thread already gave some tips for some better performing
USB sticks, but if you're going to spend some money on the hardware
side I've a different suggestion:

I often carry an extra Fedora install with me on a m2 sata SSD in
an usb enclosure like this:

https://www.aliexpress.com/item/JEYI-R8-TYPE-C-USB3-0-USB3-0-m-2-NGFF-SSD-Mobile-Drive-VIA-VLI713/32839908764.html

Or if you want 10Gbps USB-3.1 gen2:

https://www.aliexpress.com/item/M-2-B-Key-SSD-to-USB-3-1-Type-C-Enclosure-Card-Converter-Adapter-External/32863999463.html

This will allow you to use any m2 *SATA* SSD of your choice, and
these are often a whole lot faster then USB sticks.

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: SATA errors (only) when on battery

[Hans de Goede]

Hi,

On 11-02-18 21:03, Clemens Eisserer wrote:

Hi Gordon,


Is there a way to disable SATA link power management at the kernel command
line?


Start by checking the value of
/sys/class/scsi_host/*/link_power_management_policy


I do / did - the value is changing depending whether the laptop is on
battery or wall power.
When on wall power, it is set to maximum-performance and I don't get
any errors, otherwise the SATA errors start to appear.

Because the value is changed depending on power state (maybe by udev
scripts), it doesn't make sence to set it statically.


The only thing I know of changing that value dynamically is
TLP, do you perhaps have TLP installed?


What I wonder - weren't those changes targeted for Fedora-28?
How did they slip into F27?


Those changes are not in F27 and they do not change the level
depending on battery vs wall power.

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: webcam

[Hans de Goede]

Hi,

On 10-02-18 21:04, Patrick Dupre wrote:

Hello,

I have a laptop with a webcam.
Can I activate it?
I run cheese
It say No device detected.

Should I install some drivers?

mplayer tv://
MPlayer 1.3.0-7 (C) 2000-2016 MPlayer Team

Playing tv://.
TV file format detected.
Selected driver: v4l2
  name: Video 4 Linux 2 input
  author: Martin Olschewski 
  comment: first try, more to come ;-)
v4l2: unable to open '/dev/video0': No such file or directory
v4l2: ioctl set mute failed: Bad file descriptor
v4l2: 0 frames successfully processed, 0 frames dropped.


What is the output of "cat /proc/cpuinfo" and of "lsusb" ?

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Hans de Goede]

Hi Andrew,

On 05-02-18 23:02, Andrew Lutomirski wrote:

On Thu, Feb 1, 2018 at 11:34 AM, Hans de Goede <hdego...@redhat.com> wrote:


Hi All,

For the "Improved Laptop Battery Life" feature:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

I'm working on for Fedora 28 I would like to also try and enable
Panel Self Refresh on laptops with Intel graphics, some quick tests
have shown this to save another 0.5W (when idle / nothing on the
screen changes). This is currently off be default because it is
known to cause issues on some devices. So I think we will probably
need a white- or black-list. But first we need more data on this.

If you can spare 10 minutes, please see my blogpost for how to test
this and send me a mail with the info request in the blogpost:
https://hansdegoede.livejournal.com/18653.html



I suspect that the results may be odd.  After falling into a rabbit
hole when I tried to do this test, I learned a few things about the
i915 driver's PSR support:

  - Intel doesn't currently have any working CI coverage for PSR.

  - There's an Intel person who seems to be actively trying to fix PSR.

  - PSR on 4.15 on newish hardware (at least Skylake) is completely broken.

  - There are other known bugs.

So I'm not sure that trying to tabulate PSR functionality based on
panel type seems like it may be the wrong approach.


Thank you for your poking around wrt this. Can you send me an (off-list)
email with the contact info for the Intel person you are talking about,
before spending more time on this I would like to touch base with him/her.

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Hans de Goede]

Hi,

On 01-02-18 15:59, Don Zickus wrote:

On Thu, Feb 01, 2018 at 12:34:50PM +0100, Hans de Goede wrote:

Hi All,

For the "Improved Laptop Battery Life" feature:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

I'm working on for Fedora 28 I would like to also try and enable
Panel Self Refresh on laptops with Intel graphics, some quick tests
have shown this to save another 0.5W (when idle / nothing on the
screen changes). This is currently off be default because it is
known to cause issues on some devices. So I think we will probably
need a white- or black-list. But first we need more data on this.

If you can spare 10 minutes, please see my blogpost for how to test
this and send me a mail with the info request in the blogpost:
https://hansdegoede.livejournal.com/18653.html


Hi Hans,

I didn't exactly play with the psr like you asked, but your blog intrigued
me to play with powertop again.

On my Dell 5510 laptop, which has two graphics chips (intel for display,
nvidia for external displays), setting the following to good:

Runtime PM for PCI Device NVIDIA Corporation GM107GLM [Quadro M1000M]

dropped me from 14W down to 6-7W.  And doubled my battery life.  Considering
I normally don't connect up the external display, I find this a huge
savings.

So indirectly I want to say thank you!


Interesting, nouveau.runpm defaults to 1, so I wonder why it is not doing
this by default on your system. Can you file a bug against xorg-x11-drv-nouveau
please and put the following people in the Cc:

Ben Skeggs <bske...@redhat.com>
Lyude Paul <ly...@redhat.com>
Hans de Goede <hdego...@redhat.com>

Note Lyude works from the Westford office, not sure where you are located,
but if you're also in Westford you might just want to drop by her desk :)

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: EXTERNAL: Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Hans de Goede]

Hi,

On 01-02-18 16:33, Wells, Roger K. wrote:

On 02/01/2018 10:21 AM, Ian Pilcher wrote:

On 02/01/2018 05:34 AM, Hans de Goede wrote:

If you can spare 10 minutes, please see my blogpost for how to test
this and send me a mail with the info request in the blogpost:
https://hansdegoede.livejournal.com/18653.html


Should this testing be done on AC power or unplugged (or does it not
matter)?


Unplugged, because that is the only state in which powertop can
measure energy consumption.


also, how to determine if "i915.enable_psr=1" was entered correctly and 
accepted?


I've updated my blogpost with some info on how to check that
adding that option actually does anything, see:

https://hansdegoede.livejournal.com/18653.html

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Hans de Goede]

Hi All,

For the "Improved Laptop Battery Life" feature:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

I'm working on for Fedora 28 I would like to also try and enable
Panel Self Refresh on laptops with Intel graphics, some quick tests
have shown this to save another 0.5W (when idle / nothing on the
screen changes). This is currently off be default because it is
known to cause issues on some devices. So I think we will probably
need a white- or black-list. But first we need more data on this.

If you can spare 10 minutes, please see my blogpost for how to test
this and send me a mail with the info request in the blogpost:
https://hansdegoede.livejournal.com/18653.html

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Heads up: SATA kernel change coming to rawhide with a (small) chance of disk corruption!

[Hans de Goede]

Hi All,

As part of: https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
I'm pushing a change to the Fedora Rawhide kernel to enable the new
med_power_with_dipm sata link powermanagement policy by default on
mobile Intel chipsets (Laptops, NuCs, etc.).

The good news about this change is that on laptops using a sata disk
it will typically save about 1W - 1.5W of power when the laptop is idle.

The bad news is that the min_power policy is known to cause data corruption
with some disks (has been reported with older sandisk ssds and some crucial
ssds). The new med_power_with_dipm sata lpm policy mirrors the default
Windows IRST lpm settings, so it should be safe to use, but the proof is
in the pudding.

I've done a blog post a while back asking users to test
this: https://hansdegoede.livejournal.com/18412.html and here is a list
of successfully tested systens + disks:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife#How_To_Test

So far no problems have been reported but if you're running rawhide now
would be a good time to make sure your backups are in order before
upgrading to the next rawhide kernel.

TL;DR: The next rawhide kernel build contains SATA changes which _may_
cause disk corruption, they shouldn't, but please check your backups
before updating.

Regards,

Hans
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org