#
126dac3c |
| 22-Jul-2023 |
jsg <jsg@openbsd.org> |
BOOTARG_UCODE for AMD ok deraadt@
|
#
d55930ef |
| 25-Apr-2023 |
kn <kn@openbsd.org> |
Do not attempt to write to read-only softraid
Bootloaders have no write support for softraid volumes, which manifests in, e.g. /bsd.upgrade not being stripped of its 'x' permission bit to prevent sy
Do not attempt to write to read-only softraid
Bootloaders have no write support for softraid volumes, which manifests in, e.g. /bsd.upgrade not being stripped of its 'x' permission bit to prevent sysupgrade loops in case of upgrade failure.
Set a no-write flag handled by libsa to bail out early in write calls. There should be no real behaviour change, writes just fail earlier now.
i386 BIOS. Crank minor. Tested inside amd64 vmm.
show more ...
|
#
3e58d19e |
| 09-Dec-2020 |
krw <krw@openbsd.org> |
Use daddr_t and not daddr32_t in boot media.
At a minimum, amd64/i386 should now boot from 4TB GPT formatted disks.
More daddr32_t terminations with extreme prejudice to follow.
Tested by various,
Use daddr_t and not daddr32_t in boot media.
At a minimum, amd64/i386 should now boot from 4TB GPT formatted disks.
More daddr32_t terminations with extreme prejudice to follow.
Tested by various, in snaps for a few days.
ok deraadt@
show more ...
|
#
29c02c14 |
| 14-Jun-2020 |
deraadt <deraadt@openbsd.org> |
crank version number
|
#
ed5a52b6 |
| 26-May-2020 |
deraadt <deraadt@openbsd.org> |
increment version numbers, due to recent RB_GOODSEED and fchmod +T changes
|
#
08fe3245 |
| 21-Mar-2020 |
otto <otto@openbsd.org> |
Teach i386 boot98) and friends about ffs2. fdboot(8) is the exception: ffs2 support does not fit there. But the the kernel loaded by the floppy ramdisk does support ffs2.
|
#
f65494e6 |
| 29-Oct-2019 |
deraadt <deraadt@openbsd.org> |
Use arc4 to bit-spread the 512-byte random buffer over the .openbsd.randomdata section, which has grown a fair bit with the introduction of retguard. Mortimer discovered the repeated 512-byte sequenc
Use arc4 to bit-spread the 512-byte random buffer over the .openbsd.randomdata section, which has grown a fair bit with the introduction of retguard. Mortimer discovered the repeated 512-byte sequence as retguard keys, and this resolves the issue. (Chacha does not fit on the media, so 1.5K early drop RC4 is hopefully sufficient in our KARL link universe) Version crank the bootblocks. sysupgrade -s will install new bootblocks. ok djm mortimer
show more ...
|
#
55653afa |
| 04-Aug-2019 |
deraadt <deraadt@openbsd.org> |
crank version, following fchmod change
|
#
044dcf88 |
| 03-Aug-2019 |
deraadt <deraadt@openbsd.org> |
In the bootblocks, after discovering and opening /bsd.upgrade, fchmod -x so the file cannot be re-executed upon the next boot. This provides a stronger one-shot-upgrade model than the upgrade script
In the bootblocks, after discovering and opening /bsd.upgrade, fchmod -x so the file cannot be re-executed upon the next boot. This provides a stronger one-shot-upgrade model than the upgrade script's rm /bsd.upgrade. Now various forms of upgrade failure will reboot into /bsd, which is probably more recoverable. Performing fchmod -x depends on (1) use of MI boot.c (not alpha/macppc/sparc64/sgi/octeon) and (2) "can write blocks" functionality in the IO layer. Most architectures have this support now.
Two diagnostics "fchmod a-x %s: failed" and "/bsd.upgrade is not u+x" will remain in the tree while refinements happen for some of the laggard architectures.
based upon a discussion florian tested in snapshots for more than a week without any complaints
show more ...
|
#
b5554a61 |
| 10-Apr-2019 |
deraadt <deraadt@openbsd.org> |
crank versions
|
#
ca679d8d |
| 08-Apr-2019 |
florian <florian@openbsd.org> |
crank version; looks good deraadt
|
#
dc1d99a7 |
| 07-Mar-2019 |
jsg <jsg@openbsd.org> |
Return early in ucode loading if cpuid is not available. Should fix booting on 486s without cpuid. Reported by Falk Richter and diagnosed by guenther@
|
#
4a222fdf |
| 23-Aug-2018 |
jsg <jsg@openbsd.org> |
port the amd64 code for loading intel microcode on boot to i386 ok deraadt@ mlarkin@
|
#
dbaca21c |
| 11-Jul-2018 |
mlarkin <mlarkin@openbsd.org> |
Detect vmm(4) in the bootloader and automatically switch to the serial console at 115200 baud.
ok deraadt
|
#
b27348b2 |
| 08-Sep-2017 |
deraadt <deraadt@openbsd.org> |
If you use sys/param.h, you don't need sys/types.h
|
#
c09c459a |
| 18-Sep-2016 |
jsing <jsing@openbsd.org> |
Bump boot loader versions due to bcrypt pbkdf support.
|
#
dbbf2b89 |
| 13-Sep-2016 |
jasper <jasper@openbsd.org> |
crank bootloader version after .SUNW_ctf change
as discussed with jsing@ it's easier this way to ensure people have bootblocks capable of loading the section
|
#
70df4988 |
| 28-May-2016 |
sthen <sthen@openbsd.org> |
crank version numbers of those bootloaders that have been changed by the com_init fix. ok beck deraadt
|
#
f80c7ac8 |
| 19-Feb-2016 |
naddy <naddy@openbsd.org> |
belatedly bump bootstrap version after mdrandom() changes; ok deraadt@
|
#
c9bca34d |
| 18-Sep-2015 |
miod <miod@openbsd.org> |
Remove support for building the boot blocks with DEBUGFLAGS=-D_TEST, which is supposed to create a userland binary in order to test non-boot related functionality. This feature has been bitrotting in
Remove support for building the boot blocks with DEBUGFLAGS=-D_TEST, which is supposed to create a userland binary in order to test non-boot related functionality. This feature has been bitrotting in a non-compiling state for years, and causes a too-many-ifdefs disease now that there are intrusive EFI changes.
No functional change.
show more ...
|
#
fce71ba5 |
| 02-Sep-2015 |
yasuoka <yasuoka@openbsd.org> |
Bring the boot changes on amd64 to i386. alloca is deleted. Also fix the boot from BIOS and bump the version.
input and ok deraadt
|
#
504684fb |
| 18-Feb-2014 |
jsing <jsing@openbsd.org> |
Bump version numbers.
|
#
aca02d0b |
| 02-Jan-2014 |
deraadt <deraadt@openbsd.org> |
crank version after random instruction fix from jsing
|
#
e1630d5b |
| 28-Dec-2013 |
deraadt <deraadt@openbsd.org> |
crank the version
|
#
53b6afce |
| 20-Oct-2013 |
stsp <stsp@openbsd.org> |
Add i386/amd64 boot(8) support for keydisk-based softraid crypto volumes.
So far, only passphrase-based crypto volumes were bootable. Full disk encryption with keydisks required a non-crypto partiti
Add i386/amd64 boot(8) support for keydisk-based softraid crypto volumes.
So far, only passphrase-based crypto volumes were bootable. Full disk encryption with keydisks required a non-crypto partition to load the kernel.
The bootloader now scans all BIOS-visible disks for RAID partitions and automatically associates keydisk partitions with their crypto volume. Attempting to boot from a volume without its keydisk currently results in a passphrase prompt (this might be changed in the future).
There is no need to re-create existing volumes. Moving the root partition onto the crypto disk and running installboot(8) is all that's needed.
help & ok jsing
show more ...
|