Date: Mon, 02 Oct 2023 16:40:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP Message-ID: <bug-273715-227-bWYUsvGLuq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273715-227@https.bugs.freebsd.org/bugzilla/> References: <bug-273715-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273715 --- Comment #11 from Zhenlei Huang <zlei@FreeBSD.org> --- A minimal snip to repeat this bug: ``` # dumpon -i 0 -c 192.168.255.3 -g 192.168.255.1 -s 192.168.255.1 nonexist ``` > I see various options how to resolve this: > 1. Always allow using the physical device name (so it would somehow poke = around and find it) > 2. Add a flag to dumpon (e.g., `-f` for force) to skip the device exists/= device supports debugnet check > 3. Allow specifying multiple devices netdump_client to try when dumping > 4. Determine based on the device name if it can exist early (feels wonky) The `dumpon` start quite early, even before `FILESYSTEMS`. At that time `ne= tif` (interface renaming) has no chances to run. I guess it is intended to let dumpon run as early as possible so that almost all kernel panics can be caught rightly. Well for netdump(4), if a pubkey is requested, then dumpon requires `FILESYSTEMS`. I guess we want to defer the setup of netdump(4), until `FILESYSTEMS` (prob= ably also `netif`) is/are ready. Or we can split the rc.d/dumpon into `rc.d/dumpon` and `rc.d/netdump`. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273715-227-bWYUsvGLuq>