Opened 3 years ago
Last modified 2 years ago
#17264 reopened bug
fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start (UEFI hardware)
| Reported by: | rudolfc | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | - General | Version: | R1/beta3 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
On UEFI systems the unpackaged driver hierarchy won’t work at all, no matter if 32 or 64bit, no matter if UEFI or legacy setup, for app_server: since the drivers there are published too late for it to find them at it's scanning time.
In order to test drivers the only way I can get it done is by using a fully unpacked system and update the system hierarchy directly.
Change History (9)
comment:1 by , 3 years ago
comment:5 by , 3 years ago
Tried that, does not help. This is certainly not the problem. The problem is exactly as I described in the description of the ticket.. (I modified app_server to double check this, when it scans /dev/ hierarchy, the non-packaged drivers are not yet published there.)
comment:6 by , 3 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
From the looks of it this is solved somewhere down the (time)line. Currently I am testing with the intel_extreme driver via the unpackaged hierarchy on recent nightlies, so I'll close this ticket.
Thanks!
Update:
comment:7 by , 2 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | fixed |
| Status: | closed → reopened |
| Summary: | fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start → fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start (UEFI hardware) |
comment:8 by , 2 years ago
I think earlier there indeed also was a problem temporary on older legacy hardware, but that works these days. I now have a Z170 mainboard from ASUSTEK that is UEFI, where its impossible to use the unpackaged hierarchy for app_server as is mentioned in the description.
I tested 32bit and 64bit USB and hardrive fresh installs, I tested using UEFI boot and compatibility boot, I tested hd with uefi layout and old layout for partitions.
Nogo, never.
comment:9 by , 2 years ago
Oh BTW: on 32bit ACPI will hang the boot process around the time the desktop appears. (blue screen with fixed cursor, or not even yet a blue screen, but a black screen (icons lighted up and disappeared nicely).
So the 32bit tests were with disabled ACPI support in the kernel settings.
In case of a regression, could bisecting help to find the triggering commit?