No code changes in this commit. An earlier commit in the stack (D58931) needed a commit-message reword per review feedback, which required a bottom-up arc diff refresh of every commit above it to keep the stack applying cleanly. That refresh is what reset this revision's accepted status, not a content change.

@jlduran, could you re-accept when you get a chance?

In D58963#1356316, @senguptaangshuman17_gmail.com wrote:

No code changes in this commit. An earlier commit in the stack (D58931) needed a commit-message reword per review feedback, which required a bottom-up arc diff refresh of every commit above it to keep the stack applying cleanly. That refresh is what reset this revision's accepted status, not a content change.

@jlduran, could you re-accept when you get a chance?

I fail to understand the "matching the existing entropy settings for the read only root" part in the commit message though.

In D58963#1357308, @jlduran wrote:

In D58963#1356316, @senguptaangshuman17_gmail.com wrote:

No code changes in this commit. An earlier commit in the stack (D58931) needed a commit-message reword per review feedback, which required a bottom-up arc diff refresh of every commit above it to keep the stack applying cleanly. That refresh is what reset this revision's accepted status, not a content change.

@jlduran, could you re-accept when you get a chance?

I fail to understand the "matching the existing entropy settings for the read only root" part in the commit message though.

As per my reading and understanding, I thought this was in line with the entropy disabling part, that dump device should also be disabled for that reason.
I looked up now again and maybe found the real reason that nanobsd doesn't ship with a dump device so dumpon should be disabled so that it doesn't try configure a dump device.
If this is the actual reason let me know I will update the message and summary and also move this earlier in the stack.

In D58963#1357598, @senguptaangshuman17_gmail.com wrote:

In D58963#1357308, @jlduran wrote:

In D58963#1356316, @senguptaangshuman17_gmail.com wrote:

No code changes in this commit. An earlier commit in the stack (D58931) needed a commit-message reword per review feedback, which required a bottom-up arc diff refresh of every commit above it to keep the stack applying cleanly. That refresh is what reset this revision's accepted status, not a content change.

@jlduran, could you re-accept when you get a chance?

I fail to understand the "matching the existing entropy settings for the read only root" part in the commit message though.

As per my reading and understanding, I thought this was in line with the entropy disabling part, that dump device should also be disabled for that reason.
I looked up now again and maybe found the real reason that nanobsd doesn't ship with a dump device so dumpon should be disabled so that it doesn't try configure a dump device.
If this is the actual reason let me know I will update the message and summary and also move this earlier in the stack.

The way I understand the commit message is that dumpon(8) is somehow related to random(4).

https://docs.freebsd.org/en/articles/committers-guide/#_focus_on_what_and_why_not_how

In D58963#1357689, @jlduran wrote:

https://docs.freebsd.org/en/articles/committers-guide/#_focus_on_what_and_why_not_how

will this be fine as commit message?

nanobsd: Disable dumpdev

Ship by default with a disabled crash dump device, since nanobsd
doesn't configure a dump target for dumpon(8) to use.

Differential Revision:  https://reviews.freebsd.org/D58963

In D58963#1357695, @senguptaangshuman17_gmail.com wrote:

In D58963#1357689, @jlduran wrote:

https://docs.freebsd.org/en/articles/committers-guide/#_focus_on_what_and_why_not_how

will this be fine as commit message?

nanobsd: Disable dumpdev

Ship by default with a disabled crash dump device, since nanobsd
doesn't configure a dump target for dumpon(8) to use.

Differential Revision:  https://reviews.freebsd.org/D58963

This has a bit of a circular reference---we're saying we disable it because NanoBSD doesn't configure it, but NanoBSD won't configure it because we're disabling it here. Let's update the rationale to explain why NanoBSD shouldn't have a dump device in the first place (e.g., read only file system, resource-constraints, etc.).

In D58963#1357697, @jlduran wrote:

In D58963#1357695, @senguptaangshuman17_gmail.com wrote:

In D58963#1357689, @jlduran wrote:

https://docs.freebsd.org/en/articles/committers-guide/#_focus_on_what_and_why_not_how

will this be fine as commit message?

nanobsd: Disable dumpdev

Ship by default with a disabled crash dump device, since nanobsd
doesn't configure a dump target for dumpon(8) to use.

Differential Revision:  https://reviews.freebsd.org/D58963

This has a bit of a circular reference---we're saying we disable it because NanoBSD doesn't configure it, but NanoBSD won't configure it because we're disabling it here. Let's update the rationale to explain why NanoBSD shouldn't have a dump device in the first place (e.g., read only file system, resource-constraints, etc.).

will this do?

nanobsd: Disable dumpdev

nanobsd targets resource-constrained embedded media, so images ship
without a swap partition by default and cannot spare storage to
persist a crash dump. The root filesystem is also read only.

Differential Revision:  https://reviews.freebsd.org/D58963

Maybe something closer to:

nanobsd: Disable dumpdev

The root filesystem is read-only by default, making crash dumps
non-functional.
Disable dumpdev to prevent dumpon warnings.