| Age | Commit message (Collapse) | Author |
|---|
|
ask_yn() returns 0/1 on yes/no, so use the shorter '|| skip' found in
install.sub; no functional change.
OK solene
|
|
ok kn@ millert@
|
|
It takes just one, the disk; the second snuck from earlier development into
the intial r1.1231 commit.
|
|
|
|
|
|
Encrypt the root disk? (disk, no or '?' for details) [no]
Which disk is the root disk? ('?' for details) [sdN]
becomes
Which disk is the root disk? ('?' for details) [sd0]
Encrypt the root disk? (yes, no or '?' for details) [no]
so that answering 'sd0' at this point during installation behaves the same
as before the new question: specifying the root disk.
Users no longer deal with two (softraid chunk sd0, root disk sd1), but just
one disk as before, while sdN are dealt with transparently.
Code also gets simpler and should enable more improvements soon.
Feedback OK afresh1
|
|
|
|
to require "no", instead of "n" or "no" which works at every other damn prompt
in the installer. This seems to be an artifact of relentlessly pushing people
towards softraid by default, and I think that is a bit nasty and pushy.
|
|
|
|
blocks to 6080 blocks with etc.alpha/disktab r1.24.
Noticed by deraadt@
|
|
|
|
|
|
The timer(4/sparc64) driver was effectively disabled during the
previous release. Nobody has come forward asking for it to be adapted
to work with the new clockintr framework, so it's time to remove the
driver from the tree.
As of today, if you want to run OpenBSD on SPARC v9 hardware, that
hardware needs to sport either %tick and %tick_compare (%asr23), or
%stick (%asr24) and %stick_compare (%asr25).
All Sun/Oracle SPARC v9 hardware meets these conditions, from the
UltraSPARC I onward.
Most HAL/Fujitsu SPARC v9 hardware meets these conditions, from the
SPARC64 III onward. The only HAL/Fujitsu hardware that might not have
%tick_compare are the HAL SPARC64 I and SPARC64 II, for which I can
find no documentation. However, those processors are currently
unsupported by OpenBSD for other reasons, so their support status is
unchanged by the removal of this driver.
With help from miod@.
Link: https://marc.info/?l=openbsd-tech&m=167898759928206&w=2
"after unlock" deraadt@, ok mlarkin@ miod@
|
|
installboot'ing due to incorrect d_type (must be 'floppy' not
'vnd') in disklabel.
Noticed by deraadt@ and sthen@
|
|
invocations, making the geometry information written to the
disklabel a bit more logically related to the disktab information
from whence it came. Also makes FSDISKTYPE usage consistent.
Flip the disklabel(8) invocations to the "echo '/ *'"
idiom to make it obvious that the desire is to create a single
'a' partition containing all free space.
No intentional functional change. MBRs, disklabels and newfs
outputs appear identical.
reads good to kn@
|
|
confusing users with FFS attributes that only experts should
fiddle with. Actual use has withered away with functionality
rendered moot or moved elsewhere.
'-e' remains for the truly obscure corner cases.
Simply excise the code for now to see if hidden users/uses are
exposed. Further simplifications are possible if no such
users/uses surface.
ok with sthen@ millert@ kn@ otto@
|
|
|
|
Tested with Comfast CF-WU710N v4.
"go ahead" deraadt@
OK stsp@
|
|
Make sure we don't newfs the EFI Sys partition on systems that have an
"apfsisc" partition in the case we're installing with softraid crypto.
Debugged with help from and came up with a fix with kn@
"go ahead" kettenis@
"no objections" krw@
OK kn@
|
|
Chosing [W]hole on a GPT disk means it needs non-default `-b' fdisk(8)
to account for existing EFI Sys partitions, whether it modifies an existing
GPT (Apple APFS ISC) or writing a new one.
With 'Encrypt the root disk?' answered postively, the crypto disk instead of
the root disk becomes the boot disk.
Extend the logic to both crypto and root disk, really asking
"is this a boot disk?".
with caspar
|
|
|
|
|
|
|
|
|
|
Chosing [W]hole on a GPT disk means it needs non-default `-b' fdisk(8)
to boot and preserve any existing BIOS boot partition.
With 'Encrypt the root disk?' answered postively, the crypto disk instead of
the root disk becomes the boot disk.
Extend the sanity check to both crypto and root disk, really asking
"is this a boot disk?".
This preserves existing boot partitions when using guided disk encryption.
|
|
Chosing an existing OpenBSD partition on GPT during disk setup requires an
existing EFI Sys partition (the installer does not create it in thi case).
With 'Encrypt the root disk?' answered postively, the crypto disk instead of
the root disk becomes the boot disk.
Extend the EFI Sys sanity check to both crypto and root disk, really asking
"is this a boot disk?".
|
|
values for the block/fragment sizes that some install media need.
Hoist the desired values into the newfs(8) invocations to make it
obvious non-default values are required and what the values are.
No functional change.
|
|
values for the block/fragment sizes that some install media need.
Hoist the desired values into the newfs(8) invocations to make it
obvious non-default values are required and what the values are.
No functional change.
ok kn@
|
|
ramdisk, so just keep or remove the conditional sections.
ok kn@ miod@
|
|
|
|
|
|
|
|
|
|
No functional change.
ok kn@
|
|
No functional change.
Noticed by & ok kn@
|
|
No functional change.
ok patrick@
|
|
|
|
|
|
and the block devices work just fine.
|
|
|
|
|
|
'install' disktab entries.
No functional change.
|
|
'?' output to list available answers could better distuingish from questions
and other lines, like sets selection does with four leading spaces.
OK deraadt
|
|
the install media would grow too much, so use the same strategy as we
for stack protector and other things: disable them, just on the install
media
ok kettenis
|
|
except for bootblocks. This way we have built-in leak detecction
always (if enable by malloc flags). See man pages for details.
|
|
on apple silicon so that we don't fill up the ramdisk by extracting the
whole tarball
while here, change the code so that the machdep.compatible sysctl gets
read once and then that value is used in the script instead of calling
sysctl several times
from input and ok kn@, kettenis@
|
|
|
|
For installation, no partitions whatsoever are mounted, so 'yes' is always
wrong unless the user manually mounted stuff before that question.
No change for upgrade, where partitions on the root disk are mounted.
Idea from naddy, diff from Mikhail (mp39590 AT gmail)
Tweaks from me
OK op afresh1
|
|
Save the softraid volume's device and make it root disk default, being the
only legit choice in this case; this gets it always right on systems with
multiple physical disks.
All other install/upgrade cases keep picking the first available [sw]d* disk
as root disk default.
OK afresh1
|
|
|
