9.10.1-U1 still sets kern.vty to "sc" in scenarios where "vt" is needed
X10SLM+-F (UEFI boot, BIOS 3.0a)
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.
#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.
#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
- 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).