Re: reboot -r no longer reboots FreeBSD-CURRENT
- In reply to: Warner Losh : "Re: reboot -r no longer reboots FreeBSD-CURRENT"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 10 Jul 2026 17:38:01 UTC
On Fri, Jul 10, 2026 at 11:27:48AM -0600, Warner Losh wrote: > On Fri, Jul 10, 2026 at 11:07 AM Konstantin Belousov <kostikbel@gmail.com> > wrote: > > > On Fri, Jul 10, 2026 at 12:46:30PM -0400, Mark Johnston wrote: > > > On Fri, Jul 10, 2026 at 07:17:11PM +0300, Konstantin Belousov wrote: > > > > On Fri, Jul 10, 2026 at 11:58:01AM -0400, Mark Johnston wrote: > > > > > On Thu, Jul 09, 2026 at 09:51:40PM +0100, Graham Perrin wrote: > > > > > > Screenshot etc. at > > > > > > <https://mastodon.bsd.cafe/@grahamperrin/116814858405640533> > > > > > > > > > > This seems to be a regression from commit > > 24d887436dcd5b6c18a7505e477c79cae3002c3a. > > > > > > > > Well, 'the regression from' is probably not exact formulation. > > > > I do not think that correct code should change to cause SIGSEGV > > > > due to dynamic linkage. > > > > > > I merely meant that reboot -r behaves as expected when that commit is > > > reverted. > > > > > > > > I'm not sure exactly why, but after running "reboot -r", init(8) does > > > > > something to trigger SIGSEGV, and the kernel appears to hang > > delivering > > > > > the signal in a loop. In particular, init(8) registers a SIGSEGV > > > > > handler. > > > > > > > > If you set sysctl machdep.uprintf_signal to 1, does kernel emit > > anything > > > > on this occurance? If yes, perhaps take the 'procstat vm 1' before > > > > triggering the reboot, so that we can at least infer the module and > > > > source line that caused the SIGSEGV. > > > > > > We have: > > > > > > root@freebsd:~ # procstat 1 vm > > > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > > > 1 0 1 1 0 1 root wait FreeBSD ELF64 init > > > procstat: open(vm): No such file or directory > > > procstat: procstat_open() > > > root@freebsd:~ # procstat vm 1 > > > PID START END PRT RES PRES REF SHD FLAG > > TP PATH > > > 1 0x1021000 0x1024000 r-- 3 8 3 1 CN--- > > vn /sbin/init > > > 1 0x1024000 0x1029000 r-x 5 8 3 1 CN--- > > vn /sbin/init > > > 1 0x1029000 0x102a000 r-- 1 1 1 0 CN--- > > sw > > > 1 0x102a000 0x102b000 rw- 1 0 1 0 CN--- > > vn /sbin/init > > > 1 0x102b000 0x102c000 rw- 1 1 1 0 C---- > > sw > > > 1 0x80102a000 0x801030000 r-- 6 30 46 12 CN--- > > vn /libexec/ld-elf.so.1 > > > 1 0x801030000 0x801048000 r-x 24 30 46 12 CN--- > > vn /libexec/ld-elf.so.1 > > > 1 0x801048000 0x801049000 r-- 1 0 1 0 CN--- > > vn /libexec/ld-elf.so.1 > > > 1 0x801049000 0x80104a000 r-- 1 1 1 0 CN--- > > sw > > > 1 0x80104a000 0x80105f000 rw- 18 18 1 0 C---- > > sw > > > 1 0x80106e000 0x801077000 r-- 9 22 40 16 CN--- > > vn /lib/libutil.so.10 > > > 1 0x801077000 0x801084000 r-x 13 22 40 16 CN--- > > vn /lib/libutil.so.10 > > > 1 0x801084000 0x801085000 r-- 1 0 1 0 CN--- > > vn /lib/libutil.so.10 > > > 1 0x801085000 0x801087000 rw- 2 0 1 0 CN--- > > vn /lib/libutil.so.10 > > > 1 0x801087000 0x801089000 rw- 0 0 0 0 ----- > > -- > > > 1 0x801089000 0x80108c000 r-- 3 8 12 6 CN--- > > vn /lib/libcrypt.so.5 > > > 1 0x80108c000 0x801092000 r-x 6 8 12 6 CN--- > > vn /lib/libcrypt.so.5 > > > 1 0x801092000 0x801093000 r-- 1 0 1 0 CN--- > > vn /lib/libcrypt.so.5 > > > 1 0x801093000 0x801094000 rw- 1 0 1 0 CN--- > > vn /lib/libcrypt.so.5 > > > 1 0x801094000 0x801131000 r-- 109 448 58 24 CN--- > > vn /lib/libc.so.7 > > > 1 0x801131000 0x80129c000 r-x 315 448 58 24 CN--- > > vn /lib/libc.so.7 > > > 1 0x80129c000 0x8012a6000 r-- 10 0 1 0 CN--- > > vn /lib/libc.so.7 > > > 1 0x8012a6000 0x8012ae000 rw- 8 0 1 0 C---- > > vn /lib/libc.so.7 > > > 1 0x8012ae000 0x8013c9000 rw- 10 10 1 0 CN--- > > sw > > > 1 0x8013c9000 0x8013d1000 r-- 8 30 12 6 CN--- > > vn /lib/libmd.so.7 > > > 1 0x8013d1000 0x8013e8000 r-x 23 30 12 6 CN--- > > vn /lib/libmd.so.7 > > > 1 0x8013e8000 0x8013e9000 r-- 1 0 1 0 CN--- > > vn /lib/libmd.so.7 > > > 1 0x8013e9000 0x8013ea000 rw- 1 0 1 0 CN--- > > vn /lib/libmd.so.7 > > > 1 0x8013ea000 0x801400000 r-- 22 28 63 29 CN--- > > vn /lib/libsys.so.7 > > > 1 0x801400000 0x801406000 r-x 6 28 63 29 CN--- > > vn /lib/libsys.so.7 > > > 1 0x801406000 0x801407000 r-- 1 0 1 0 CN--- > > vn /lib/libsys.so.7 > > > 1 0x801407000 0x801408000 rw- 1 0 1 0 CN--- > > vn /lib/libsys.so.7 > > > 1 0x801408000 0x801438000 rw- 33 33 1 0 C---- > > sw > > > 1 0x801600000 0x802000000 rw- 59 59 1 0 C---- > > sw > > > 1 0x7fffdffff000 0x7ffffffdf000 --- 0 0 0 0 ----- > > gd > > > 1 0x7ffffffdf000 0x7ffffffff000 rw- 4 4 1 0 C--D- > > sw > > > 1 0x7ffffffff000 0x800000000000 r-x 1 1 18 0 ----- > > ph > > > root@freebsd:~ # sysctl machdep.uprintf_signal=1 > > > machdep.uprintf_signal: 0 -> 1 > > > root@freebsd:~ # reboot -r > > > Jul 10 16:36:07 freebsd reroot[1366]: rerooted by root > > > Stopping sshd. > > > Waiting for PIDS: 1294. > > > Stopping cron. > > > Waiting for PIDS: 1299. > > > Stopping devd. > > > Waiting for PIDS: 800. > > > Writing entropy file: . > > > Writing early boot entropy file: . > > > . > > > Terminated > > > Trying to mount root from ufs:/dev/gpt/rootfs [rw]... > > > pid 1 comm init: signal 11 err 0x6 code 1 type 12 addr 0 rsp > > 0x7fffffffe288 rip 0x8014024aa rax 0 fsb 0x80142a790 gsb 0 <00 00 00 00 00 > > 00 00 00> > > > pid 1 comm init: signal 11 err 0x6 code 1 type 12 addr 0x3000000008 rsp > > 0x7fffffffd588 rip 0x801030bd0 rax 0x3000000008 fsb 0x80142a790 gsb 0 <00 > > 00 00 00 00 00 00 00> > > > ... > > > > > > So the PC was in libsys.so, and the RIP corresponds to the instruction > > > following the syscall: > > > > > > (gdb) disas 0x8014024aa > > > Dump of assembler code for function reboot: > > > 0x00000008014024a0 <+0>: mov $0x37,%eax > > > 0x00000008014024a5 <+5>: mov %rcx,%r10 > > > 0x00000008014024a8 <+8>: syscall > > > 0x00000008014024aa <+10>: jb 0x801402028 <.cerror> > > > 0x00000008014024b0 <+16>: ret > > > > > > /lib/libsys.so.7 belongs to the same filesystem as /sbin/init, so I > > > wouldn't expect reboot(RB_REROOT) to affect it... > > > > Oh, this is reroot, not reboot. > > Then I see what is going on: init copies itself into transient tmpfs, > > from which it executes its own copy. > > > > Yea, I was going to suggest we need to copy /rescue/init or the libraries > it needs. I have a somewhat different plan. I will create a small static reroot_seed binary consisting basically of reroot_phase_two(), and embed it into the init binary. Then it will be copied to the transient tmpfs mount instead of init. It has an additional advantage of not going to de-sync with the init itself.