Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUnable to boot with kernel-latest-4.15.6-1 #3790
Comments
andrewdavidwong
added
bug
C: kernel
labels
Apr 6, 2018
andrewdavidwong
added this to the Release 4.0 updates milestone
Apr 6, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
JohnDoe02
Apr 12, 2018
It had the same issue, when I tried to install Qubes on the HP Envy x360. I fixed the missing firmware files by installing the firmware package of the (still in development) Fedora 28.
However, with kernel 4.15, the Envy would almost always freeze during boot (with 4.14 it would boot, but Xorg wouldn't start). Compiling a kernel from drm-next fixed that, however, I had heavy graphical glitches which made the system unusable.
So it seems that the support for Raven Ridge is still somewhat buggy, good look for your efforts.
JohnDoe02
commented
Apr 12, 2018
|
It had the same issue, when I tried to install Qubes on the HP Envy x360. I fixed the missing firmware files by installing the firmware package of the (still in development) Fedora 28. However, with kernel 4.15, the Envy would almost always freeze during boot (with 4.14 it would boot, but Xorg wouldn't start). Compiling a kernel from drm-next fixed that, however, I had heavy graphical glitches which made the system unusable. So it seems that the support for Raven Ridge is still somewhat buggy, good look for your efforts. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Apr 21, 2018
Member
There is updated kernel-latest package - 4.16.2. Does is still happen there?
|
There is updated kernel-latest package - 4.16.2. Does is still happen there? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
May 11, 2018
Hello, @marmarek
I have the exact same issue as @JohnDoe02 and @coeusite on an HP Envy x360 (Ryzen 5, 2500U APU).
I can confirm it still happens with the Linux-Firmware package from Qubes unstable repository which includes the Raven driver for AMDGPU, and any of the available 4.15+ Qubes kernels.
Update details
I've tested all available Qubes 4.15+ kernels, and compiled the 4.16 kernel my self too, they all gave the same error results.
- linux-firmware-20180402-83.git8c1e439c.qubes1.fc25.noarch.rpm
- kernel-latest-4.15.1-1.pvops.qubes.x86_64.rpm
- kernel-latest-4.15.6-1.pvops.qubes.x86_64.rpm
- kernel-latest-4.16.2-1.pvops.qubes.x86_64.rpm
- kernel-latest-4.16.2-1.pvops.qubes.x86_64.rpm (Compiled with CONFIG_DRM_AMDGPU=y).
Most of my tests are from an installed Qubes and not the installer
To clarify, the installer also fail to install with graphics, but I either install Qubes with a kickstart file in text mode, or I transfer a fully functional fresh installed non-encrypted Qubes OS system over with the DD command from another working Qubes machine, following up with dracut and grub2-mkconfig.
The new problem emerging after driver and kernel update
Doing the above steps seems to solve the initial problems with the lack of driver and dependencies, xorg also no longer printed errors during boot. But now instead it lead to kernel panics, and the graphics never loaded. I never got as far as JohnDoe02 or coeusite, mine always resulted in kernel panic before any graphics can load, no matter which 4.15+ kernel or kernel settings I tried. The odd part is the kernel panics location during the boot process seems to change very easily by changing settings, such as acpi=off and amdgpu.dc=1, and similar related commands, but it's hard to find any patterns. It does kind of look like memory/power management issues in either Xen or the AMDGPU driver? But It's outside my expertise to figure out if that truly is the case. Looking through the logs for Xen, I found some errors toward and near the end of the logs, but I'm not sure how relevant they are.
/var/logs for HP Envy x360 (Ryzen 5, 2500U APU)
hypervisor.log
boot.log
Xorg.9.log
Other OS systems work fine on the laptop
- Successfully installed Fedora-27 (Ran smooth while testing, a couple of days).
- Successfully installed Fedora-28 (Ran smooth while testing, a day or so).
- Original install Windows 10 for the brief time I had it installed ran pretty decently too,
- Also worked fine when re-installed to update to latest F17 Rev.A BIOS.
I've been speculating about copying the Fedora-27 kernel config settings and try adjust kernel-latest-4.16.2-1.pvops.qubes.x86_64, but I haven't gotten around to it yet, it's on my list to try. I do unfortunately not remember where I found this minor clue, but the NVMe drive's driver module is also on my suspect list. I'm wondering if I should break warranty to insert a regular SSD instead, but I'm not quite there yet. Booting an existing installed Qubes from an USB drive failed miserably, seemingly because the NVMe somehow messes it up, but I have not confirmed that yet.
It's a lot of small clues and no real suspect, but for now I get the feeling that it's either Xen or AMDGPU bug related. But since it works on Fedora-27/28, it might rather be Xen causing issues? Could it be? I'll happily provide more logs if you need any. For now I transcribed one of the typical boot errors down below, when the kernel panic occurs.
The kernel panic seen on screen during boot
- (( )) messages below are my own inserted notes,
- (~) represents memory/code address code-lines (bunch of numbers and letters),
- I'll gladly edit and include modules and (~) values if they are needed to debug.
((Starting from the usual green (OK) messages during Qubes boot))
- Starting The Xen xenstore... (OK)
- Starting Qubes memory management... (OK)
- Starting Daemon for power management... (OK)
- Started D-Bus System Message Bus. (OK)
- general protection fault: 0000 [s1] SMP MOPTI
- Modules linked in: btusb btrtl btbcm btintel, and the list goes on for several lines of various different modules.
((Oddly it posts a second output (two outputs with a list of modules) without any explanation as to why))
- CPU: 0 PID: 8 Comm: swapper/0 Tainted: G WC 4.16.2.-1.pvops.qubes.x86_64 #1
- Hardware name: HP HP ENVY x360 Convertible
- RIP: e838:switch_mm:irqs_off+8xe2/8x510
((A whole bunch of code addresses specified by letters and numbers that I don't believe is needed, referenced as (~), however I'll write them down if they can be useful to debug.))
- RSP: (e02b:ffffc900017c7940) EFLAGS: (~) ORIG_RAX: (~)
- RAX: (~) RBX: (~) RCX: (~)
- RDX: (~) RSI: (~) RDI: (~)
- RBP: (~) R08: (~) R09: (~)
- R10: (~) R11: (~) R12: (~)
- R13: (~) R14: (~) R15: (~)
- FS: (~) GS: (~) knIGS: (~)
- CS: (~) ES: (~) CR0: (~)
- CR2: (~) CR3: (~) CR4: (~)
- Call Trace:
__shcedule+0x39d/0x880
? hrtimer_start_range_ns+0x199/0x2c0
schedule+0x32/0x80
schedule_hrtimeout_range_clock+8xb9/0x1a0
? __hrtimer_init+0xb0/0xb0
poll_schdule_timeout+0x41/0x70
do_sys_poll+0x514/0x5d0
? _raw_spin_unlock_irqrestore+0x16/0x20
? ep_poll_callback+0x11d/0x2e0
? __alloc_skb+0x96/0x1c0
? __wake_up_common+0x96/0x100
? _raw_spin_unlock_irqrestore+0x16/0x20
? __wake_up_common_lock+0x09/0xc0
? cond_resched+0x16/0x40
? mutex_lock+0xe/0x30
? unix_stream_read_generic+0x225/0x0e0
? compact_poll_select_copy_remaining+0x140/0x140
? import_iovoc+0x37/0xd0
? unix_stream_recvmsg+0x53/0x230
? unix_state_double_unlock+0x40/0x40
? ___sys_recvmsg+0x18b/0x230
? seccomp_run_filters+0x58/0xb0
? xen_set_pte_at+0x8d/0x520
? __seccomp_filter+0x59/0x170
? ktime_get_ts64+0x58/0x520
? sys_ppoll+0x162/0x180
- SyS_ppoll+0x162/0x180
- do_syscall_64+0x74/0x180
- entry_SYSCALL_64_after_hwframe+0x3d/0xa2
- RIP: 00xx:0x776c0fa3dfad
((Below different numbers to the above numbers and letters, I'll edit to include if needed))
- RSP: (002b:00007ffe225f0f80) EFLAGS: (~) ORIG_RAX: (~)
- RAX: (~) RBX: (~) RCX: (~)
- RDX: (~) RSI: (~) RDI: (~)
- RBP: (~) R08: (~) R09: (~)
- R10: (~) R11: (~) R12: (~)
- R13: (~) R14: (~) R15: (~)
- Code: 85 c0 74 29 48 3b 90 e8 +2 ++ ++ 74 20 48 8b 80 70 03 00 00 83 e0 03 83 83f8 01 74 11b9 49 00 00 00 b8 01 00 00 00 ba 00 00 00 00 <0f> 30 48 89 e0 48 8b 53 50 48 c1 e8 27 25 ff 01 00 00 48 8d 3c
- RIP: switch_mm_irqs_off+0xe2/0x510 RSP: ffffc900017c7940
---[ end trace b98f9ba97a6ed38 ]---
- Kernel panic - not syncing: Fatal exception
- Kernel Offset: disabled
Screen stays like a freeze for a second or two, and then goes into a reboot. Repeat in an endless circle.
Notes:
- In regard to what coeusite said about no responses from keys, I noticed this happening to me too when I use the
acpi=offcommand. This is specifically on the 4.14 kernel, I never get enough time to verify this on kernel 4.15+ kernels due to the kernel panic.
Aekez
commented
May 11, 2018
|
Hello, @marmarek I can confirm it still happens with the Linux-Firmware package from Qubes unstable repository which includes the Raven driver for AMDGPU, and any of the available 4.15+ Qubes kernels. Update details
Most of my tests are from an installed Qubes and not the installer The new problem emerging after driver and kernel update /var/logs for HP Envy x360 (Ryzen 5, 2500U APU) Other OS systems work fine on the laptop
I've been speculating about copying the Fedora-27 kernel config settings and try adjust kernel-latest-4.16.2-1.pvops.qubes.x86_64, but I haven't gotten around to it yet, it's on my list to try. I do unfortunately not remember where I found this minor clue, but the NVMe drive's driver module is also on my suspect list. I'm wondering if I should break warranty to insert a regular SSD instead, but I'm not quite there yet. Booting an existing installed Qubes from an USB drive failed miserably, seemingly because the NVMe somehow messes it up, but I have not confirmed that yet. It's a lot of small clues and no real suspect, but for now I get the feeling that it's either Xen or AMDGPU bug related. But since it works on Fedora-27/28, it might rather be Xen causing issues? Could it be? I'll happily provide more logs if you need any. For now I transcribed one of the typical boot errors down below, when the kernel panic occurs. The kernel panic seen on screen during boot
Screen stays like a freeze for a second or two, and then goes into a reboot. Repeat in an endless circle. Notes:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
coeusite
May 12, 2018
@Aekez Actually, the installer's graphics is not working for amd a8-9600 (Bristol Ridge), so probably not working for all AM4 PC. However, I can simply boot a flesh encrypted-Qubes installation with an AMD AM4 PC (QubesOS on USB SSD) if there is not a kernel panic error.
You can add 'noreboot'(?) parameter to prevent the system from auto reboot, but it is not related to the kernel panic thing.
Currently I use an Intel PC for my Qubes system.
coeusite
commented
May 12, 2018
•
edited
Edited 4 times
-
coeusite
edited May 12, 2018 (most recent)
-
coeusite
edited
May 12, 2018
-
coeusite
edited
May 12, 2018
-
coeusite
edited
May 12, 2018
edited
-
May 12, 2018 (most recent) -
May 12, 2018 -
May 12, 2018 -
May 12, 2018
|
@Aekez Actually, the installer's graphics is not working for amd a8-9600 (Bristol Ridge), so probably not working for all AM4 PC. However, I can simply boot a flesh encrypted-Qubes installation with an AMD AM4 PC (QubesOS on USB SSD) if there is not a kernel panic error. You can add 'noreboot'(?) parameter to prevent the system from auto reboot, but it is not related to the kernel panic thing. Currently I use an Intel PC for my Qubes system. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
May 13, 2018
@coeusite
Turns out I had given up too early on the external USB approach, I went back and tried your external drive suggestion and to my surprise managed to get it to work! It's very, very odd though, the other approaches should have worked if this works, so I'm a bit puzzled. However it's not the first time I had issues with installing Qubes on systems with a NVMe drive, where I had to move the NVMe to another machine, install Qubes, and then move it back to the original machine. Perhaps this is the same? I'm surprised if it is though since it acted very different from last time (the kernel panics and all).
I appreciate your suggestion to use the external USB approach, thanks!
For anyone stumbling over this issue needing the same solution and the used steps to get it from USB drive to the laptops SSD/NVMe/HDD drive, see steps below. I realize it may not be the perfect approach, but it works nonetheless.
Approach for anyone finding this issue trying to solve this issue before Qubes 4.1. is out
This list is probably not perfect, it may be improved. However it works, so for now this will do.
- Install Qubes on another drive on a computer Qubes works on.
- Update Qubes completely.
- Upgrade kernel to 4.15+ or newest available (check current/current-testing/unstable).
- Note it may be in normal Qubes repository at time of reading.
- Upgrade Linux-Firmware to the newest, can be found in Qubes repositories (check current/current-testing/unstable).
- Note it may be in normal Qubes repository at time of reading.
- Use the Qubes installer to get a secured shell command (option 3 for plain normal shell, do not boot into the existing Qubes OS at this point. Copying a running system is a recipe for disaster).
- Use
ddto transfer Qubes, either directly from drive to Qubes, or to an .img file for temporary storage. - Once
ddhas been either directly or indirectly copied to the new drive, reboot and boot from the Qubes installer again. This time instead pick option 1, and enter existing Qubes shell. Wait for it, apparently by the looks of it, it might take longer than usual after a dd transfer. - Then
chroot /mnt/sysimageto get bash inside Qubes dom0. - Once done, change this command to the kernel you're using
dracut -f /boot/initramfs-4.16.2-1.pvops.qubes.x86_64.img 4.16.2-1.pvops.qubes.x86_64and let it run. - Finally
gurb2-mkconfig -o /boot/grub2/grub.cfg - Use
exitcommand to leave chroot, and then restart the system. - Once Qubes boots up, change the sys-net network devices (and sys-usb if used).
It boggles my mind
Why Qubes wanted to be installed on an USB drive first, I wonder if the NVMe or other hardware causes issues during install? I've installed Qubes in so many different ways on this laptop, and updated the exact same packages/kernels as with this working USB method, yet using an external USB drive where Qubes was installed on a different machine is the only thing that worked, despite doing the same update/upgrade steps with the other approaches. It feels a bit like a sick joke after all this time, but hey, I should be happy, it now works! w00!
I'll stay in touch on how stable the system is after a couple of days of use, for now I see no issues.
Aekez
commented
May 13, 2018
•
edited
Edited 13 times
-
Aekez
edited May 13, 2018 (most recent)
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
-
Aekez
edited
May 13, 2018
edited
-
May 13, 2018 (most recent) -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018 -
May 13, 2018
|
@coeusite I appreciate your suggestion to use the external USB approach, thanks! For anyone stumbling over this issue needing the same solution and the used steps to get it from USB drive to the laptops SSD/NVMe/HDD drive, see steps below. I realize it may not be the perfect approach, but it works nonetheless. Approach for anyone finding this issue trying to solve this issue before Qubes 4.1. is out
It boggles my mind I'll stay in touch on how stable the system is after a couple of days of use, for now I see no issues. |
coeusite commentedApr 5, 2018
Qubes OS version:
R4.0-rc5 with updates from current-testing repo
Affected component(s):
kernel
Steps to reproduce the behavior:
The build:
To reproduce this issue:
Expected behavior:
Actual behavior:
General notes:
Related issues:
The GPU of raven ridge APU requires kernel 4.15 or above to work properly, otherwise the only display resolution is 1600x1200. I, thus, wanna try kernel-latest package, but this bug stops me from doing so.