After the latest HP vendor BIOS update for my Envy x360 13m-ag0XXX I can’t boot - not even run USB installation memory stick - of Linux system (using OpenSuse Tumbleweed). The boot process does start but after a certain point (I’m not sure yet which one) the screen goes blank and the system freezes. It seems that this BIOS update has disabled my HP Envy x360 laptop from running Linux.
Here is more detailed info about the BIOS update:
Type:
BIOS
Version:
F.19 Rev.A
Operating systems:
Windows 10 (64-bit)
Release date:
Aug 29, 2018
File name: sp91692.exe(19.9 MB)
Fix and enhancements:
Fixes an issue which causes the touch screen to stop functioning properly.
It appears that this BIOS update may not be compatible with the latest Linux kernels - I also tried to boot from Ubuntu 18.04.1 LTS USB stick. After a short moment the screen goes blank and the system hangs just like in Tumbleweed case.
Interestingly, I am able to boot Leap 15 which doesn’t have the latest Kernel version.
Yes - I got the Grub boot screen and I also tried runlevel=3. Still result is the same: after a short while the screen goes blank and the system freezes. I have the feeling that the most recent HP BIOS update to “fix a touchscreen issue” on the Envy x360 13m-ag0XXX w/ AMD APU somehow messed up the latest Linux Kernel functionality. I’m trying the HP forum as well - but didn’t get a qualified response yet. Probably the issue is too new … and this BIOS update hasn’t been tested on Linux.
Further to to trying arvidjaar’s suggestions, you could also try to boot with the “nomodeset” boot code. Edit: Please advise if you need help on how to enter that code.
.
In parallel, while trying to solve this, you could raise a Bug Report on openSUSE-Tumbleweed’s kernel. There is guidance here for raising bug reports: https://en.opensuse.org/openSUSE:Submitting_bug_reports You can use your openSUSE forum username and password when raising a bug report.
Its possible the answer will be the bug report should be raised upstream < not sure > but for certain you can also get better guidance there as to the best GNU/Linux area in which such a bug report should be followed up.
There is an old bug report on the Touch Screen here: https://bugzilla.kernel.org/show_bug.cgi?id=198715 but I think that is a separate problem from what you have experienced. I note there is one post there by a user (2018-09-03 03:31:59 UTC ) claiming after the BIOS update they can not get their Ubuntu to boot.
.
There are many google posts on the HP Envy x360 and some problems, including with the latest BIOS. For example this thread: 19 / 18.x Live don’t work on HP Envy x360 15m with default BIOS settings where the user in that thread described some problems they had, where booting in a ‘legacy’ mode helped address some of them.
Another GNU/Linux thread: AMD Ryzen: Problems and Fixes where the user in that thread seemed to be happy with a boot code “idle=nomwait” … They also suggested disabling “C6 states” and I do not know if that would be similar on openSUSE.
Further, I do not know if these threads address the latest BIOS update that you are using.
Thanks for all the good advice. Using nomodeset actually helped to boot to text mode and getting a login prompt so I can access the system this way - but without graphics.
HP’s comment about their latest BIOS update says it “Fixes an issue which causes the touch screen to stop functioning properly”.
Hence could it be that the AMD graphics driver built into the latest Kernel versions is not compatible with this “BIOS fix” from HP? Is there any advice on how to best proceed from there? B.t.w. is there also a way to “circumvent” the AMD driver in the Kernel for the time being and boot into a non-accelerated standard graphics mode?
Did you try ‘nomodeset’ by itself without commanding ‘run level 3’ (ie to text mode)?
My fuzzy understanding is when the PC boots with openSUSE, for graphics configuration, it first looks in the /etc/X11 for an xorg.conf file, which is not normally present. Then it looks in the /etc/X11/xorg.conf.d/ directory for a file such as 50-device.conf, 50-monitor.conf, 50-screen.conf, or other, which it can use to configure one’s grapics. Normally the information in those files are commented out. So that normally is not used.
Then it looks for kernel drivers for the graphics via ‘mode setting’. This is typically where the graphic driver comes from.
By specifying ‘nomodeset’ as a boot code, you tell the boot process not to use those kernel drivers, but rather have X windows manager configure the graphics. Assuming no proprietary graphic driver, then neither the proprietary graphic driver, nor the open source graphic driver will be used, but possibly instead X windows will have a very basic frame buffer graphic driver (FBDEV) used, which as I stated is very basic. This frame buffer graphic driver is incredibly compatible with massive amounts of graphic hardware.
When you specify ‘run level 3’ then there will be no attempt to use the frame buffer driver from ‘nomodeset’ to boot graphics.
I’m very shaky on the above, and it likely has many inaccuracies, but hopefully it gives a sense as to what takes place.
So based on the above, if you did not do so already, please try ‘nomodeset’ without ‘run level 3’.
I tried all the above … without success. Hence my strong suspicion is still that something in the latest HP BIOS update F.19 Rev.A caused the issue with Linux AMD graphics drivers not communicating well with the Kernel.
To be honest I believe only the HP and/or Linux Kernel developers will know how to proceed from there. How can we make sure they get the message?
A lot here depends on your familiarity with text mode. When you boot your PC, it will start recording information to boot logs. That information can be very useful to figure out the problem. Unfortunately, just saying “something in the latest HP BIOS update F.19 Rev.A caused the issue with Linux AMD graphics drivers not communicating well with the Kernel” is only a starting point , and a lot more is needed. There might be information in those boot logs.
Also, the odds are, the GNU/Linux developers do not have your hardware, hence they likely depend on people like you, to provide them the information they need to proceed. Because without the information in the boot logs, they likely can not proceed. It is also (IMHO) highly unlikely that HP will help. Most PC manufacturers do not support GNU/Linux very much.
When the PC boots, it will record some graphic boot information in the file /var/log/Xorg.0.log. Then when it boots the next time, that file is renamed to Xorg.0.log.old, and a new file Xorg.0.log is created documenting the current graphic X window boot information. Dependent on your problem, it is possibly by an appropriate boot sequence , one can have useful information stored in Xorg.0.log.old.
ie boot without no-modeset nor with run level 3. The boot will fail. BUT it may copy useful graphic boot information into /var/log/Xorg.0.log. So then you force a restart/reboot. This time use ‘nomodeset’ and ‘run level-3’. The old log file “Xorg.0.log” will be renamed into a new file “Xorg.0.log.old” (dependent on far the boot process got). Both the “Xorg.0.log” and the “Xorg.0.log.old” could have useful information in them that the developers would like to see.
There are also other boot files that may have information. Those are just the 1st two that came to mind.
Obtain those files is easy for me to obtain, as I would simply boot to text mode, plug in a USB stick, manually check to see its name via text commands, then manually mount it with text commands, and then with text commands copy those files to the USB stick, unmount the USB stick via text commands, and then via another PC send the information in those files to the developers (after first checking, of course, to see if information may be useful).
Unfortunately, its possible (?) using text mode is not something you want to do. So I have no more ideas there. Possibly others may have other ideas.
Also - I know you said you tried ‘all the above’ but honestly - that does not help me much, as I don’t know what ‘all of the above’ exactly means. ie. EXACTLy what boot codes (each and every one, and what combinations of them) did you try? The developers will likely want to know that. Possibly they will be able to deduce such from what you posted. Unfortunately I’m not so good at this myself.
.
Ok I will follow your advice and obtain the Xorg.0.log.* and any other log.* files I can find to help support the debugging. B.t.w. to reply to your earlier question I only used nomodeset without any extra parameters. With this setting the boot process did finish but without graphics support and it ended up in text mode with login prompt.
Thats interesting … if I may speculate, that may suggest the FBDEV driver failed with X-windows, but as opposed to the PC freezing when the FBDEV graphic driver tried to load, you were thrown back to a text mode. Using the ‘nomodeset’ ensured only FBDEV initially used during the boot to text < I am guessing here > … while using another driver would have caused a freeze and no throwback to text mode.
Possibly both the Xorg.0.log and the Xorg.0.log.old will yield some hints as to where in process the failure occurred. If you have another PC that supports ssh on a home network, and if ssh access was setup previous, you could also ‘ssh into’ the PC when it is in text mode, and copy the files out via ssh.
.
Here is a part of the Xorg.0.log file (couldn’t attached full version due to text limit - hence I chose what I think may be of highest importance). I obtained the file by starting Linux with “nomodeset”, logged in as root and run “startx”. I didn’t get the graphics working as “startx” terminated but it created a /var/log/Xorg.0.log file
201.322] X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
201.324] Build Operating System: openSUSE SUSE LINUX
201.325] Current Operating System: Linux linux-psfi 4.18.5-1-default #1 SMP PREEMPT Fri Aug 24 12:38:43 UTC 2018 (9e91e29) x86_64
201.325] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.18.5-1-default root=UUID=0a85a54d-919c-4afb-8df1-01bb89a80934 resume=/dev/disk/by-id/nvme-SK_hynix_PC401_HFS256GD9TNG-62A0A_EI83N0363105A3U02-part7 quiet splash nomodeset
201.327] Build Date: 07 August 2018 12:00:00PM
201.328]
201.328] Current version of pixman: 0.34.0
201.329] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
201.329] Markers: (–) probed, () from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
201.332] (==) Log file: “/var/log/Xorg.0.log”, Time: Mon Sep 17 10:44:01 2018
201.332] (==) Using config directory: “/etc/X11/xorg.conf.d”
201.333] (==) Using system config directory “/usr/share/X11/xorg.conf.d”
201.333] (==) No Layout section. Using the first Screen section.
201.333] (==) No screen section available. Using defaults.
201.333] () |–>Screen “Default Screen Section” (0)
201.333] (**) | |–>Monitor “<default monitor>”
201.333] (==) No monitor specified for screen “Default Screen Section”.
Using a default monitor configuration.
201.333] (==) Automatically adding devices
201.333] (==) Automatically enabling devices
201.333] (==) Automatically adding GPU devices
201.333] (==) Max clients allowed: 256, resource mask: 0x1fffff
201.334] (WW) The directory “/usr/share/fonts/misc/sgi” does not exist.
201.334] Entry deleted from font path.
201.334] (==) FontPath set to:
/usr/share/fonts/misc:unscaled,
/usr/share/fonts/Type1/,
/usr/share/fonts/100dpi:unscaled,
/usr/share/fonts/75dpi:unscaled,
/usr/share/fonts/ghostscript/,
/usr/share/fonts/cyrillic:unscaled,
/usr/share/fonts/truetype/,
built-ins
201.334] (==) ModulePath set to “/usr/lib64/xorg/modules”
201.334] (WW) Ignoring unrecognized extension “XFree86-DGA”
201.334] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
201.334] (II) Loader magic: 0x559be34b4d00
201.334] (II) Module ABI versions:
201.334] X.Org ANSI C Emulation: 0.4
201.334] X.Org Video Driver: 24.0
201.334] X.Org XInput driver : 24.1
201.334] X.Org Server Extension : 10.0
201.334] (++) using VT number 1
201.337] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_31
201.339] (–) PCI:*(4@0:0:0) 1002:15dd:103c:8496 rev 195, Mem @ 0xe0000000/268435456, 0xf0000000/2097152, 0xfcc00000/524288, I/O @ 0x0000f000/256
201.340] (II) LoadModule: “glx”
201.340] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
201.340] (II) Module glx: vendor=“X.Org Foundation”
201.340] compiled for 1.20.1, module version = 1.0.0
201.340] ABI class: X.Org Server Extension, version 10.0
201.340] (II) Scanning /etc/X11/xorg_pci_ids directory for additional PCI ID’s supported by the drivers
201.340] (==) Matched ati as autoconfigured driver 0
201.340] (==) Matched modesetting as autoconfigured driver 1
201.340] (==) Matched fbdev as autoconfigured driver 2
201.340] (==) Matched vesa as autoconfigured driver 3
201.340] (==) Assigned the driver to the xf86ConfigLayout
201.340] (II) LoadModule: “ati”
201.341] (II) Loading /usr/lib64/xorg/modules/drivers/ati_drv.so
201.341] (II) Module ati: vendor=“X.Org Foundation”
201.341] compiled for 1.20.1, module version = 18.0.99
201.341] Module class: X.Org Video Driver
201.341] ABI class: X.Org Video Driver, version 24.0
201.405] (II) LoadModule: “radeon”
201.405] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
201.405] (II) Module radeon: vendor=“X.Org Foundation”
201.405] compiled for 1.20.1, module version = 18.0.99
201.405] Module class: X.Org Video Driver
201.405] ABI class: X.Org Video Driver, version 24.0
201.405] (II) LoadModule: “modesetting”
201.405] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
201.406] (II) Module modesetting: vendor=“X.Org Foundation”
201.406] compiled for 1.20.1, module version = 1.20.1
201.406] Module class: X.Org Video Driver
201.406] ABI class: X.Org Video Driver, version 24.0
201.406] (II) LoadModule: “fbdev”
201.406] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
201.406] (II) Module fbdev: vendor=“X.Org Foundation”
201.406] compiled for 1.20.0, module version = 0.5.0
201.406] Module class: X.Org Video Driver
201.406] ABI class: X.Org Video Driver, version 24.0
201.406] (II) LoadModule: “vesa”
201.406] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
201.406] (II) Module vesa: vendor=“X.Org Foundation”
201.406] compiled for 1.20.0, module version = 2.4.0
201.406] Module class: X.Org Video Driver
201.406] ABI class: X.Org Video Driver, version 24.0
201.406] (II) RADEON: Driver for ATI/AMD Radeon chipsets:
…
201.411] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
201.411] (II) FBDEV: driver for framebuffer: fbdev
201.411] (II) VESA: driver for VESA chipsets: vesa
201.411] (EE) open /dev/dri/card0: No such file or directory
201.411] (WW) Falling back to old probe method for modesetting
201.411] (EE) open /dev/dri/card0: No such file or directory
201.411] (II) Loading sub module “fbdevhw”
201.411] (II) LoadModule: “fbdevhw”
201.411] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
201.411] (II) Module fbdevhw: vendor=“X.Org Foundation”
201.411] compiled for 1.20.1, module version = 0.0.2
201.411] ABI class: X.Org Video Driver, version 24.0
201.412] (EE) Unable to find a valid framebuffer device
201.412] (WW) Falling back to old probe method for fbdev
201.412] (II) Loading sub module “fbdevhw”
201.412] (II) LoadModule: “fbdevhw”
201.412] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
201.412] (II) Module fbdevhw: vendor=“X.Org Foundation”
201.412] compiled for 1.20.1, module version = 0.0.2
201.412] ABI class: X.Org Video Driver, version 24.0
201.412] (II) FBDEV(2): using default device
201.412] (EE) Screen 0 deleted because of no matching config section.
201.412] (II) UnloadModule: “modesetting”
201.412] (EE) Screen 0 deleted because of no matching config section.
201.412] (II) UnloadModule: “fbdev”
201.412] (II) UnloadSubModule: “fbdevhw”
201.412] (EE)
Fatal server error:
201.412] (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
201.412] (EE)
201.412] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
201.412] (EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
201.412] (EE)
201.415] (EE) Server terminated with error (1). Closing log file.
The Xorg.0.log corroborates what oldcpu was suggesting…
201.412] (II) UnloadModule: "fbdev"
201.412] (II) UnloadSubModule: "fbdevhw"
201.412] (EE)
Fatal server error:
201.412] (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
201.412] (EE)
201.412] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
201.412] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
201.412] (EE)
201.415] (EE) Server terminated with error (1). Closing log file.
Pure speculation on my part, but from reading the man page…
man fbdev
I wonder if a minimal Xorg configuration might be sufficient here…?
maeller71, in case the above suggestion was not clear, I think deano_ferrari is speculating that you could try editing the /etc/X11/xorg.conf.d/50-device.conf file, to the content he suggested, to see if you can get the FBDEV driver to work. You can do that in text mode, with a text editor. If your PC (when booting from text mode) has internet, you can install some good text editors. I like midnight commander, which can be installed (with root permissions) in text mode with command:
zypper in mc
and then after installed, it can be run with the command “mc” (in this case with root permissions, as one needs root permissions to edit the 50-device.conf file)… I think then it is pretty self explanatory as to how the editor works. It provides a list of function keys at the bottom.
The lspci command needs to be run with root permissions.
which is likely due to that 50-device.conf not being fully configured to properly configure the fbdev graphic driver.
Also - even if you succeed getting to X with the fbdev driver, please note that the fbdev is a relatively primative driver compared to the nominal graphic driver your openSUSE Tumbleweed will use.
… but I may have this wrong. deano_ferrari has a better handle on this than myself.
i think it worth a try. You likely can always boot to run level 3 later and remove the 50-device.conf edit.