Bug 24592
| Summary: | dmesg.boot Gets Overwritten without Reboot | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Crist J. Clark <cjc> |
| Component: | bin | Assignee: | Mark Linimon <linimon> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->cjc Taking over my own old PRs. (And actually doing it the right way this time.) Would there be a problem with simply backing it up before smashing it? Then the sysadmin, who knows that single-user trashes his boot info, can restore it manually if we go back to multi-user rather than down. -- Alan Eldridge State Changed From-To: open->feedback Is this still a problem with recent versions of FreeBSD? Responsible Changed From-To: cjc->linimon Reset PR assigned to inactive committer who has not responded to email. State Changed From-To: feedback->closed Feedback timeout (> 2 months). |
The file containing the kernel boot messages, /var/run/dmesg.boot, will be overwritten when a user drops into single-user mode and comes back up into multi-user without a reboot. Fix: Writing dmesg.boot is in the clean_var funnction of /etc/rc. I am not familiar enough with init(8) and rc(8) to figure out how to let /etc/rc know if we are going into multi-user after a fresh reboot or from single-user without a recent reboot. I see a problem in telling the difference between, reboot -> single-user -> multi-user Versus, multi-user -> single-user -> multi-user That is, what state information can survive the single-user stage. How-To-Repeat: Drop into single-user mode and then go right back to multi-user. Do not reboot. # ls -l /var/run/dmesg.boot -rw-r--r-- 1 root wheel 3623 Jan 17 19:35 /var/run/dmesg.boot # shutdown now <shutdown messages> Enter full pathname of shell or RETURN for /bin/sh: # exit <startup, NOT boot, output> # ls -l /var/run/dmesg.boot -rw-r--r-- 1 root wheel 11188 Jan 23 22:05 /var/run/dmesg.boot