Bug #17815
9.10.1-U1 still sets kern.vty to "sc" in scenarios where "vt" is needed
X10SLM+-F (UEFI boot, BIOS 3.0a)
Description
Follow-up from #16700.
9.10.1-U1 did not fix this for me. FreeNAS still boots with sc instead of vt. Installed with UEFI, not BIOS legacy mode.
As a result, local console (as viewed from IPMI or VGA) is absolutely blank.
Platform is Supermicro X10SLM+-F, BIOS 3.0a.
History
#1
Updated by Heather Ownby about 4 years ago
Updated by Heather Ownby - Assignee set to Mike Marshall
#2
Updated by Josh Paetzel about 4 years ago
Updated by Josh Paetzel - Assignee changed from Mike Marshall to Kris Moore
- Priority changed from No priority to Important
- Target version set to 9.10.1-U2
#3
Updated by Kris Moore about 4 years ago
- Status changed from Unscreened to Investigation
Did you do a fresh install or upgrade? If upgrade you may need to kick grub another time with:
- grub-mkconfig -o /boot/grub/grub.cfg
After that reboot and see if vt is enabled again. If not I'll need to see your grub.cfg file.
#4
Updated by Eric Loewenthal about 4 years ago
Updated by Eric Loewenthal Upgrade from 9.10.1
The config generation fixed it. Console works and "vt" is reported back.
Can this step be automated for upgrades?
#5
Updated by Kris Moore about 4 years ago
- Status changed from Investigation to Unscreened
- Assignee changed from Kris Moore to Sean Fagan
The fix is indeed in and working, however I think the updater is using the previous version of GRUB files when it makes the new boot-environment. Over to Sean for his thoughts. Not sure if its possible to re-gen the grub-config again post-update or not.
#6
Updated by Sean Fagan about 4 years ago
Updated by Sean Fagan - Status changed from Unscreened to 15
Correct, the "beadm activate" runs in the context of the current system. So it would take two updates to fix, or boot into the new BE, and then do something with boot environments. (It doesn't really matter what -- activate the previous one, and then re-activate the current one, and then reboot.)
#7
Updated by Kris Moore about 4 years ago
Do you think we should do something to the updater to touch the BE's in order to trigger that post-update "refresh" of grub.cfg? Otherwise I can see it keep biting us if a fix goes out to GRUB that really doesn't get applied until the 2nd update (or manual BE touching occurs).
#8
Updated by Sean Fagan about 4 years ago
- Assignee changed from Sean Fagan to Kris Moore
The updater can't really do it, because -- again -- it runs the activate in the context of the old version.
But, one thing we could do is use the /data/sentinels directory: the purpose of this is to create flags to change post-boot behaviour. So during boot, if /data/sentinel/grub-efi-fix-1 doesn't exist, create it, re-create the grub.cfg file, and reboot. Or something like that. But I suspect it could also be done with another post-boot fix (basically, if it's an EFI boot, and grub.cfg doesn't have the right entry in it, then rebuild it and reboot).
#9
Updated by Kris Moore about 4 years ago
- Status changed from 15 to Closed: Behaves correctly
Sean, Ok cool. I'll close this for now, since the original issue was fixed. I'll look at if we can target some new functionality like this for 9.10.2/3 (in another ticket)