| created | 2019-10-19T03:07:14Z |
|---|---|
| begin | 2019-08-03T15:00:00Z |
| end | 2019-08-03T18:00:00Z |
| path | src/sys |
| commits | 4 |
| date | 2019-08-03T15:22:17Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/lib/libsa/Makefile | log | diff | annotate |
| src/sys/lib/libsa/fchmod.c | log | diff | annotate | |
| src/sys/lib/libsa/stand.h | log | diff | annotate | |
| src/sys/lib/libsa/ufs.c | log | diff | annotate | |
| src/sys/lib/libsa/ufs.h | log | diff | annotate | |
| src/sys/lib/libsa/ufs2.c | log | diff | annotate | |
| message |
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 |
|||
| date | 2019-08-03T15:22:19Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/arch/alpha/stand/boot/filesystem.c | log | diff | annotate |
| src/sys/arch/amd64/stand/boot/Makefile | log | diff | annotate | |
| src/sys/arch/amd64/stand/boot/conf.c | log | diff | annotate | |
| src/sys/arch/amd64/stand/cdboot/Makefile | log | diff | annotate | |
| src/sys/arch/amd64/stand/cdboot/conf.c | log | diff | annotate | |
| src/sys/arch/amd64/stand/efi32/Makefile.common | log | diff | annotate | |
| src/sys/stand/boot/boot.c | log | diff | annotate | |
| src/sys/stand/boot/cmd.c | log | diff | annotate | |
| message |
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 |
|||
| date | 2019-08-03T15:22:20Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/arch/amd64/stand/efi32/conf.c | log | diff | annotate |
| src/sys/arch/amd64/stand/efi64/Makefile.common | log | diff | annotate | |
| src/sys/arch/amd64/stand/efi64/conf.c | log | diff | annotate | |
| src/sys/arch/amd64/stand/efiboot/Makefile.common | log | diff | annotate | |
| src/sys/arch/amd64/stand/efiboot/conf.c | log | diff | annotate | |
| src/sys/arch/amd64/stand/pxeboot/Makefile | log | diff | annotate | |
| src/sys/arch/amd64/stand/pxeboot/conf.c | log | diff | annotate | |
| src/sys/arch/arm64/stand/efiboot/Makefile | log | diff | annotate | |
| src/sys/arch/arm64/stand/efiboot/conf.c | log | diff | annotate | |
| src/sys/arch/armv7/stand/efiboot/Makefile | log | diff | annotate | |
| src/sys/arch/armv7/stand/efiboot/conf.c | log | diff | annotate | |
| src/sys/arch/hppa/stand/boot/conf.c | log | diff | annotate | |
| src/sys/arch/hppa/stand/libsa/Makefile | log | diff | annotate | |
| src/sys/arch/i386/stand/boot/Makefile | log | diff | annotate | |
| src/sys/arch/i386/stand/boot/conf.c | log | diff | annotate | |
| message |
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 |
|||
| date | 2019-08-03T15:22:21Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/arch/i386/stand/cdboot/Makefile | log | diff | annotate |
| src/sys/arch/i386/stand/cdboot/conf.c | log | diff | annotate | |
| src/sys/arch/i386/stand/pxeboot/Makefile | log | diff | annotate | |
| src/sys/arch/i386/stand/pxeboot/conf.c | log | diff | annotate | |
| src/sys/arch/landisk/stand/boot/conf.c | log | diff | annotate | |
| src/sys/arch/landisk/stand/xxboot/boot1.c | log | diff | annotate | |
| src/sys/arch/loongson/stand/boot/conf.c | log | diff | annotate | |
| src/sys/arch/loongson/stand/libsa/Makefile | log | diff | annotate | |
| src/sys/arch/macppc/stand/boot.mac/Makefile | log | diff | annotate | |
| src/sys/arch/macppc/stand/ofwboot/Makefile | log | diff | annotate | |
| src/sys/arch/sgi/stand/libsa/Makefile | log | diff | annotate | |
| message |
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 |
|||