The code to select boot partition in RAID assumed thet had a name,
which is true when there is a GPT inside the RAID, but not when there
is a disklabel inside the RAID. This caused a regression from behavior
of NetBSD 8.1.
We fix this by allowing nameless partition to be boot candidates.
This fixes misc/54748
While there, let raid device be used in the boot specification, like
raid0a:/netbsd.
of "real" disklabels. Auto-enable this (at run time) when there is no other
partitioning scheme but disklabel configured.
Hard-coded enable this for x68k to allow using kernel based translations
for native Human68k partitions.
I picked ERESTART to mean `all channels are occupied' because that's
what opencrypto(9) uses to decide whether to queue a request, but
it's not appropriate for sysctl(2) to return that.
Found on, e.g., the Pinebook.
Only used for TRNG at the moment, but hooking it up to opencrypto(9)
shouldn't be too hard if anyone still cares about that these days.
The distribution of the alleged TRNG is very nonuniform distributed
seems to alternate between toward runs with exceptionally high
fractions of 0 bits and runs with exceptionally high fractions of 1
bits -- initially all my samples were mostly 0's, and then all my
samples were mostly 1's, and now I'm seeing more oscillation between
these runs.
So I've wired it up as RND_TYPE_UNKNOWN, not RND_TYPE_RNG (it will
immediately flunk our rngtest and be disabled), and I estimated it to
provide at most one bit of entropy per byte of data -- which may
still be optimistic. I also added a sysctl node hw.sun8icryptoN.rng
to read out 1024-byte samples for analysis, and I left the driver
commented out in GENERIC64 for now.
(If anyone has contacts at Allwinner who can tell us about how the
alleged TRNG is supposed to work, please let me know!)
If a builtin command or function is the final command intended to be
executed, and is interrupted by a caught signal, the trap handler for
that signal was not executed - the shell simply exited (an exit trap
handler would still have been run - if there was one the handler
for the signal may have been invoked during the execution of the
exit trap handler, which, if it happened, is incorrect sequencing).
Now, if we're exiting, and there are pending signals, run their handlers
just before running the EXIT trap handler, if any.
There are almost certainly plenty more issues with traps that need
solving. Later,
XXX pullup -9
(-8 is too different in this area, and this problem suitably obscure,
that we won't bother) (the -7 sh is simply obsolete).
Having traps set should not enforce a fork for the next command,
whatever that command happens to be, only for commands which would
normally fork if they weren't the last command expected to be
executed (ie: builtins and functions shouldn't be exexuted in a
sub-shell merely because a trap is set).
As it was (for example)
trap 'whatever' SIGANY; wait $anypid
was guaranteed to fail the wait, as the subshell it was executed
in could not have any children.
XXX pullup -9
script takes care of mounting filesystems.
Don't try to unmount all file systems before unloading the ZFS module, leave
that to the operator in preperation or the mountall script to take care
of. Module will of course fail to unload then if file systems are still
mounted.
