Project

General

Profile

Bug #17815

Avatar?id=14398&size=22x22

9.10.1-U1 still sets kern.vty to "sc" in scenarios where "vt" is needed

Added by Eric Loewenthal about 4 years ago. Updated about 4 years ago.

Status:
Closed: Behaves correctly
Priority:
Important
Assignee:
Kris Moore
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

X10SLM+-F (UEFI boot, BIOS 3.0a)

ChangeLog Required:
No

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

  • Assignee set to Mike Marshall

#2 Updated by Josh Paetzel about 4 years ago

  • Assignee changed from Mike Marshall to Kris Moore
  • Priority changed from No priority to Important
  • Target version set to 9.10.1-U2

#3 Avatar?id=14398&size=24x24 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:

  1. 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

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 Avatar?id=14398&size=24x24 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 Avatar?id=14398&size=24x24 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 Avatar?id=14398&size=24x24 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)

Also available in: Atom PDF