Re: heads up: amd64 snap
On Sat, Mar 07, 2020 at 04:19:17PM +0100, Otto Moerbeek wrote: > It looks like some BIOS do not like the recent biosboot changes. > Symptoms are a hang in the bios. > > I reverted them, the next amd64 snap should be ok again. > > -Otto i read notice last Sat ... Mon i was in the office and updated my "toy machine" with OpenBSD ... but not all the mirrors have fetched the latest snapshot, yet. i got bad snapshot. reading the whole thread it seems the most affected brand was Dell. the "toy machine" is a Dell Vostro 470 BIOS A14. it seems the Dell BIOS reads the disks before even going into a boot selection menu. for this Dell, going to BIOS means selecting the option from the "boot selection menu". HDD with bad biosboot + USB (install66.fs) fails to bring up the boot selection menu. i had to remove the HDD data cable for the machine to get back the "boot selection menu". - rgc
Re: heads up: amd64 snap
On Mon, Mar 09, 2020 at 07:28:10PM +0100, Paul de Weerd wrote: | Indeed it did :) My machine would not POST anymore (Dell Optiplex | 9020; dmesg at the end) I meant: dmesg in the follow-up e-mail... OpenBSD 6.6-current (GENERIC.MP) #38: Sat Mar 7 19:58:17 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34243903488 (32657MB) avail mem = 33193492480 (31655MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries) bios0: vendor Dell Inc. version "A22" date 02/01/2018 bios0: Dell Inc. OptiPlex 9020 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR acpi0: wakeup devices UAR1(S3) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) PEG0(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.95 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.47 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.47 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.47 MHz, 06-3c-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP05) acpiprt3 at acpi0: bus -1 (PEG0) acpiprt4 at acpi0: bus -1 (PEG1) acpiprt5 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 3691 MHz: speeds: 3401, 3400, 3200, 3000, 2800, 2700, 2500, 2300, 2100, 1900, 1700, 1500, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06 drm0 at inteldrm0 inteldrm0: msi
Re: heads up: amd64 snap
On Mon, Mar 09, 2020 at 06:47:10PM +0100, Sebastien Marie wrote: | On Mon, Mar 09, 2020 at 04:51:00PM +, Anthony Campbell wrote: | > On 09 Mar 2020, Otto Moerbeek wrote: | > > On Mon, Mar 09, 2020 at 03:56:53PM +, Anthony Campbell wrote: | > > | > > > This discussion is very interesting. The same thing happened to me | > > > on 6 March, when after completing the upgrade my Dell Optiplex 3020 | > > > refused to boot. I assumed it was a hardware failure and spent the | > > > next three days bringing up an older Acer n460 which the Dell had | > > > replaced. | | yes, it looks like a hardware failure. Indeed it did :) My machine would not POST anymore (Dell Optiplex 9020; dmesg at the end) | in my case, 4 hosts with the same motherboard model failed at the same time (I | ran sysupgrade via ansible), so hardware failure was a bit excluded. I only have this one machine that showed the behaviour. Several VMs, my gateway and my laptop worked fine so I didn't really tie it to the bootloader changes (especially since the machine didn't POST). I couldn't boot from any other medium as long as the boot disk (an SSD) was connected; my conclusion was that a failed SSD prevented the system from POSTing (something I've seen in the past with failed HDDs). | > > > I don't have the facility at present to put the disk in another | > > > machine so it looks like I'm stuck. | | I agree it could be difficult. If the disk is plugged, bios stuck. If the disk | is unplugged, bios is fine, but you can't modify the disk data. | | As sthen@ said, you could try to change bios setting to make the bios to not | look at the disk. I dunno if it would work or not. I played around with that a little bit, but didn't get to a working machine. | Alternatively, if you disk support hotplugging (sata disk should), try to | connect the disk after the bios started could help. If so, I would try to plug | it as soon as possible after bios init. That was a bit of a scary option for me :) | Depending your configuration, you could also try to use USB/SATA or USB/IDE | adapter (depending your disk), in order to plug the disk after bios init. For | me, I had problem with this method too: when my sata disk is plugged in sata | connector it is showed with 512 bytes/sector, whereas with USB/SATA connector it | showed with 4096 bytes/sector and so disklabel is incoherent. In the end, after reading Otto's mail about reverting his changes, I connected the SSD from my not-booting machine to my laptop and upgraded the snapshot on it. That allowed my desktop machine to boot properly again. I've seen Otto's commit message from earlier today, so I will test out the next snap on my machine tomorrow. At least now I know not to jump to conclusions about failing hardware :) Thanks to Otto for his work on this area; looking forward to running my machine on all-ffs2. Cheers, Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: heads up: amd64 snap
On Mon, Mar 09, 2020 at 04:51:00PM +, Anthony Campbell wrote: > On 09 Mar 2020, Otto Moerbeek wrote: > > On Mon, Mar 09, 2020 at 03:56:53PM +, Anthony Campbell wrote: > > > > > This discussion is very interesting. The same thing happened to me > > > on 6 March, when after completing the upgrade my Dell Optiplex 3020 > > > refused to boot. I assumed it was a hardware failure and spent the > > > next three days bringing up an older Acer n460 which the Dell had > > > replaced. yes, it looks like a hardware failure. in my case, 4 hosts with the same motherboard model failed at the same time (I ran sysupgrade via ansible), so hardware failure was a bit excluded. > > > I don't have the facility at present to put the disk in another > > > machine so it looks like I'm stuck. I agree it could be difficult. If the disk is plugged, bios stuck. If the disk is unplugged, bios is fine, but you can't modify the disk data. As sthen@ said, you could try to change bios setting to make the bios to not look at the disk. I dunno if it would work or not. Alternatively, if you disk support hotplugging (sata disk should), try to connect the disk after the bios started could help. If so, I would try to plug it as soon as possible after bios init. Depending your configuration, you could also try to use USB/SATA or USB/IDE adapter (depending your disk), in order to plug the disk after bios init. For me, I had problem with this method too: when my sata disk is plugged in sata connector it is showed with 512 bytes/sector, whereas with USB/SATA connector it showed with 4096 bytes/sector and so disklabel is incoherent. I hope it helps. -- Sebastien Marie
Re: heads up: amd64 snap
On 09 Mar 2020, Anthony Campbell wrote: > On 09 Mar 2020, Otto Moerbeek wrote: > > On Mon, Mar 09, 2020 at 03:56:53PM +, Anthony Campbell wrote: > > > > > On 07 Mar 2020, Amit Kulkarni wrote: > > > [snip] > > > > > > > > > > > will do as you suggest. > > > > > > > > Thanks > > > > > > > > > > > > > > This discussion is very interesting. The same thing happened to me > > > on 6 March, when after completing the upgrade my Dell Optiplex 3020 > > > refused to boot. I assumed it was a hardware failure and spent the > > > next three days bringing up an older Acer n460 which the Dell had > > > replaced. > > > > > > > > > I don't have the facility at present to put the disk in another > > > machine so it looks like I'm stuck. > > > > > > > > > Anthony > > > > > > -- > > > Anthony Campbell http://www.acampbell.uk > > > > > > > There are other ways: dd a miniroot to a usb stick, boot from that > > into boot> > > boot the harddisk and do an upgrade. See the boot(8) man page for details. > > > > -Otto > > > > > > Unfortunately I can't access the BIOS at all to tell it to boot from > the stick. Pressing F2 during boot is supposed to do this but I've > tried about a hundred times without success. > Sorry, I misunderstood - I've just tried it out and I see that the Dell will boot from the stick without needing to be told to do so by the BIOS. I'll take that route. Apologies for the noise. Anthony > -- > Anthony Campbell http://www.acampbell.uk -- Anthony Campbellhttp://www.acampbell.uk
Re: heads up: amd64 snap
On 2020-03-09, Anthony Campbell wrote: > > Unfortunately I can't access the BIOS at all to tell it to boot from > the stick. Pressing F2 during boot is supposed to do this but I've > tried about a hundred times without success. Try unplugging the disk and see if you can then get into the bios menu. Maybe with the boot order altered it will just boot from USB anyway, if not, I have had times in the past where I've had to get past POST and into a bootloader before powering up the disk in able to be able to wipe something that the bios didn't like. Not sure if this is 'recommended' but it has got me out of a hole before.
Re: heads up: amd64 snap
Anthony Campbell wrote: > On 09 Mar 2020, Otto Moerbeek wrote: > > On Mon, Mar 09, 2020 at 03:56:53PM +, Anthony Campbell wrote: > > > > > On 07 Mar 2020, Amit Kulkarni wrote: > > > [snip] > > > > > > > > > > > will do as you suggest. > > > > > > > > Thanks > > > > > > > > > > > > > > This discussion is very interesting. The same thing happened to me > > > on 6 March, when after completing the upgrade my Dell Optiplex 3020 > > > refused to boot. I assumed it was a hardware failure and spent the > > > next three days bringing up an older Acer n460 which the Dell had > > > replaced. > > > > > > > > > I don't have the facility at present to put the disk in another > > > machine so it looks like I'm stuck. > > > > > > > > > Anthony > > > > > > -- > > > Anthony Campbell http://www.acampbell.uk > > > > > > > There are other ways: dd a miniroot to a usb stick, boot from that > > into boot> > > boot the harddisk and do an upgrade. See the boot(8) man page for details. > > > > -Otto > > > > > > Unfortunately I can't access the BIOS at all to tell it to boot from > the stick. Pressing F2 during boot is supposed to do this but I've > tried about a hundred times without success. Wow sounds like quite a drama.. it must have been IMPOSSIBLE to install openbsd in the first place /sarc...
Re: heads up: amd64 snap
On 09 Mar 2020, Otto Moerbeek wrote: > On Mon, Mar 09, 2020 at 03:56:53PM +, Anthony Campbell wrote: > > > On 07 Mar 2020, Amit Kulkarni wrote: > > [snip] > > > > > > > > will do as you suggest. > > > > > > Thanks > > > > > > > > > > This discussion is very interesting. The same thing happened to me > > on 6 March, when after completing the upgrade my Dell Optiplex 3020 > > refused to boot. I assumed it was a hardware failure and spent the > > next three days bringing up an older Acer n460 which the Dell had > > replaced. > > > > > > I don't have the facility at present to put the disk in another > > machine so it looks like I'm stuck. > > > > > > Anthony > > > > -- > > Anthony Campbellhttp://www.acampbell.uk > > > > There are other ways: dd a miniroot to a usb stick, boot from that > into boot> > boot the harddisk and do an upgrade. See the boot(8) man page for details. > > -Otto > > Unfortunately I can't access the BIOS at all to tell it to boot from the stick. Pressing F2 during boot is supposed to do this but I've tried about a hundred times without success. -- Anthony Campbellhttp://www.acampbell.uk
Re: heads up: amd64 snap
On Mon, Mar 09, 2020 at 03:56:53PM +, Anthony Campbell wrote: > On 07 Mar 2020, Amit Kulkarni wrote: > [snip] > > > > > will do as you suggest. > > > > Thanks > > > > > > This discussion is very interesting. The same thing happened to me > on 6 March, when after completing the upgrade my Dell Optiplex 3020 > refused to boot. I assumed it was a hardware failure and spent the > next three days bringing up an older Acer n460 which the Dell had > replaced. > > > I don't have the facility at present to put the disk in another > machine so it looks like I'm stuck. > > > Anthony > > -- > Anthony Campbell http://www.acampbell.uk > There are other ways: dd a miniroot to a usb stick, boot from that into boot> boot the harddisk and do an upgrade. See the boot(8) man page for details. -Otto
Re: heads up: amd64 snap
On 07 Mar 2020, Amit Kulkarni wrote: [snip] > > will do as you suggest. > > Thanks > > This discussion is very interesting. The same thing happened to me on 6 March, when after completing the upgrade my Dell Optiplex 3020 refused to boot. I assumed it was a hardware failure and spent the next three days bringing up an older Acer n460 which the Dell had replaced. I don't have the facility at present to put the disk in another machine so it looks like I'm stuck. Anthony -- Anthony Campbellhttp://www.acampbell.uk
Re: heads up: amd64 snap
On Sat, Mar 7, 2020 at 1:25 PM Sebastien Marie wrote: > > On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote: > > > > Should I try to pull the boot > > hard drive into another running system, and then manually try to copy > > over a clean /bsd.mp on the next snapshot? > > just to complete what otto@ already said. > > the problem isn't the kernel (bsd.mp), so copying it manually will not solve > the > problem. the problem is with the biosboot(8) file installed on the disk. > > to quote the man page of biosboot: > > This small program (roughly 512 bytes of code) is responsible for > loading > the second-stage boot(8) program (typically /boot), which in turn will > load the kernel. > > (see https://man.openbsd.org/biosboot.8 for complete explanation) > > > to install it manually, you need installboot(8) command + biosboot(8) file (by > default, it is using the one in /usr/mdec). > > unplugging the disk, put it in another machine, and next doing a upgrade will > run the right command, so it is the more simple approch. > will do as you suggest. Thanks
Re: heads up: amd64 snap
On Sat, Mar 7, 2020 at 11:15 AM Otto Moerbeek wrote: > > On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote: > > > Hi, > > > > How does this show itself? > > > > I have an older 2013 era system with Pentium G2020 or so (going from > > memory here, so might be wrong), which does not go into OpenBSD > > install. Just sits there with Dell logo. Only takes a Ctrl-Alt-Del > > command for a reboot, and if I try to enter into BIOS, it does not. It > > does not come into the OpenBSD boot prompt. > > > > I am trying to decide if this is due to the above changes or something > > else, like hardware failure etc. I last installed a snapshot on it 3 > > days ago, and it has never come back up. Should I try to pull the boot > > hard drive into another running system, and then manually try to copy > > over a clean /bsd.mp on the next snapshot? > > > > thanks > > > > On Sat, Mar 7, 2020 at 9:20 AM Otto Moerbeek wrote: > > > > > > It looks like some BIOS do not like the recent biosboot changes. > > > Symptoms are a hang in the bios. > > > > > > I reverted them, the next amd64 snap should be ok again. > > > > > > -Otto > > > > > Yes, this sounds very much like the issue I'm talking about. > > Updating the kernel will not help. The problem is in some bad > interaction between *some* BIOS implementations and the updated > biosboot. > > It is very likely that the disk will boot in another system without > issues. On that system, install the new snap when it arrives. Then you > can put the disk back in the problem system. > > There are probably workarounds, like putting the disk in another > system and running an older installboot from that system on the disk > containing the trouble. But if you do not feel comfortable doing that > please do an upgrade. > > And next time please try to report this earlier. The sooner we learn > about these issues the better. > Sorry for not reporting earlier Otto, I sincerely thought this is a hardware related issue, and was going to wait for the weekend to try various things. Thanks
Re: heads up: amd64 snap
On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote: > > Should I try to pull the boot > hard drive into another running system, and then manually try to copy > over a clean /bsd.mp on the next snapshot? just to complete what otto@ already said. the problem isn't the kernel (bsd.mp), so copying it manually will not solve the problem. the problem is with the biosboot(8) file installed on the disk. to quote the man page of biosboot: This small program (roughly 512 bytes of code) is responsible for loading the second-stage boot(8) program (typically /boot), which in turn will load the kernel. (see https://man.openbsd.org/biosboot.8 for complete explanation) to install it manually, you need installboot(8) command + biosboot(8) file (by default, it is using the one in /usr/mdec). unplugging the disk, put it in another machine, and next doing a upgrade will run the right command, so it is the more simple approch. Thanks. -- Sebastien Marie
Re: heads up: amd64 snap
On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote: > Hi, > > How does this show itself? > > I have an older 2013 era system with Pentium G2020 or so (going from > memory here, so might be wrong), which does not go into OpenBSD > install. Just sits there with Dell logo. Only takes a Ctrl-Alt-Del > command for a reboot, and if I try to enter into BIOS, it does not. It > does not come into the OpenBSD boot prompt. > > I am trying to decide if this is due to the above changes or something > else, like hardware failure etc. I last installed a snapshot on it 3 > days ago, and it has never come back up. Should I try to pull the boot > hard drive into another running system, and then manually try to copy > over a clean /bsd.mp on the next snapshot? > > thanks > > On Sat, Mar 7, 2020 at 9:20 AM Otto Moerbeek wrote: > > > > It looks like some BIOS do not like the recent biosboot changes. > > Symptoms are a hang in the bios. > > > > I reverted them, the next amd64 snap should be ok again. > > > > -Otto > > Yes, this sounds very much like the issue I'm talking about. Updating the kernel will not help. The problem is in some bad interaction between *some* BIOS implementations and the updated biosboot. It is very likely that the disk will boot in another system without issues. On that system, install the new snap when it arrives. Then you can put the disk back in the problem system. There are probably workarounds, like putting the disk in another system and running an older installboot from that system on the disk containing the trouble. But if you do not feel comfortable doing that please do an upgrade. And next time please try to report this earlier. The sooner we learn about these issues the better. -Otto
Re: heads up: amd64 snap
Hi, How does this show itself? I have an older 2013 era system with Pentium G2020 or so (going from memory here, so might be wrong), which does not go into OpenBSD install. Just sits there with Dell logo. Only takes a Ctrl-Alt-Del command for a reboot, and if I try to enter into BIOS, it does not. It does not come into the OpenBSD boot prompt. I am trying to decide if this is due to the above changes or something else, like hardware failure etc. I last installed a snapshot on it 3 days ago, and it has never come back up. Should I try to pull the boot hard drive into another running system, and then manually try to copy over a clean /bsd.mp on the next snapshot? thanks On Sat, Mar 7, 2020 at 9:20 AM Otto Moerbeek wrote: > > It looks like some BIOS do not like the recent biosboot changes. > Symptoms are a hang in the bios. > > I reverted them, the next amd64 snap should be ok again. > > -Otto >
