Re: Booting OpenBSD 7.3's i386 bsd.rd
Are you sure you're using i386 and not amd64? Paul 'WEiRD' de Weerd On Mon, May 01, 2023 at 12:26:41PM +1000, Damian McGuckin wrote: | | What is required please? | | I am trying to boot this bsd.rd (which is a file 4Mb big) on an old | NET5500 which has 512MBytes of RAM. On a running system, | | From the | | boot> | | prompt, doing | | boot> boot bsd.rd | | it appears to loads bsd.rd, but then drops straight back into the BIOS | and starts the BIOS boot. | | Any suggestions. | | Thanks - Damian | | Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037 | Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here | Views & opinions here are mine and not those of any past or present employer | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Booting OpenBSD 7.3's i386 bsd.rd
How are you getting to the boot> prompt? On Mon, May 1, 2023 at 12:28 PM Damian McGuckin wrote: > > > What is required please? > > I am trying to boot this bsd.rd (which is a file 4Mb big) on an old > NET5500 which has 512MBytes of RAM. On a running system, > > From the > > boot> > > prompt, doing > > boot> boot bsd.rd > > it appears to loads bsd.rd, but then drops straight back into the BIOS > and starts the BIOS boot. > > Any suggestions. > > Thanks - Damian > > Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037 > Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here > Views & opinions here are mine and not those of any past or present employer > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Booting OpenBSD 7.3's i386 bsd.rd
What is required please? I am trying to boot this bsd.rd (which is a file 4Mb big) on an old NET5500 which has 512MBytes of RAM. On a running system, From the boot> prompt, doing boot> boot bsd.rd it appears to loads bsd.rd, but then drops straight back into the BIOS and starts the BIOS boot. Any suggestions. Thanks - Damian Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Re: OpenBSD 7.2 on Oracle Cloud
On Mon, May 1, 2023 at 10:08 AM Aaron Mason wrote: > > I can reproduce it with this in QEMU 8.0 in Winders (thanks Antun who > sent something like this to the bugs@ list): > > qemu-system-x86_64 -accel whpx,kernel-irqchip=off -machine q35 \ >-cpu EPYC-Rome,-monitor -m 8g -smp 6,sockets=1,cores=6 \ >-nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 -vga virtio \ >-drive if=virtio,file=miniroot73.img -device virtio-scsi-pci,id=scsi > > The temporary workaround patch results in a booting system. > The same occurs in 7.2 under Winders. > On Mon, May 1, 2023 at 4:56 AM Stefan Fritsch wrote: > > > > Hi, > > > > what qemu version are you using? I cannot reproduce this with qemu 7.2. > > Can you try with a newer qemu? > > > > Cheers, > > Stefan > > > > Am 25.04.23 um 14:53 schrieb Aaron Mason: > > [REDACTED] -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: OpenBSD 7.2 on Oracle Cloud
I can reproduce it with this in QEMU 8.0 in Winders (thanks Antun who
sent something like this to the bugs@ list):
qemu-system-x86_64 -accel whpx,kernel-irqchip=off -machine q35 \
-cpu EPYC-Rome,-monitor -m 8g -smp 6,sockets=1,cores=6 \
-nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 -vga virtio \
-drive if=virtio,file=miniroot73.img -device virtio-scsi-pci,id=scsi
The temporary workaround patch results in a booting system.
On Mon, May 1, 2023 at 4:56 AM Stefan Fritsch wrote:
>
> Hi,
>
> what qemu version are you using? I cannot reproduce this with qemu 7.2.
> Can you try with a newer qemu?
>
> Cheers,
> Stefan
>
> Am 25.04.23 um 14:53 schrieb Aaron Mason:
> Yeah I'm getting the same thing. Trying a build in QEMU and
> transferring in to see if that helps. Will report back.
>
> >>>
> >>> Ok, good news, it still crashes at the same spot, but this time I've
> >>> got more data. Copying in tech@ - if I've forgotten anything let me
> >>> know and I'll fire up a fresh instance.
> >>>
> >>> [REDACTED]
> >>> vioscsi_req_done(e,80024a00,fd803f81c338,e,80024a00,800
> >>> d3228) at vioscsi_req_done+0x26
> >>> [REDACTED]
> >>
> >> Ok, so based on the trace I got, I was able to trace the stop itself
> >> back to line 299 of vioscsi.c (thank. you. random relink. And
> >> anonymous CVS):
> >>
> >> 293 vioscsi_req_done(struct vioscsi_softc *sc, struct virtio_softc
> >> *vsc,
> >> 294 struct vioscsi_req *vr)
> >> 295 {
> >> 296 struct scsi_xfer *xs = vr->vr_xs;
> >> 297 DPRINTF("vioscsi_req_done: enter vr: %p xs: %p\n", vr,
> >> xs);
> >> 298
> >> -->299 int isread = !!(xs->flags & SCSI_DATA_IN);
> >> 300 bus_dmamap_sync(vsc->sc_dmat, vr->vr_control,
> >> 301 offsetof(struct vioscsi_req, vr_req),
> >> 302 sizeof(struct virtio_scsi_req_hdr),
> >> 303 BUS_DMASYNC_POSTWRITE);
> >>
> >> Maybe if I follow the rabbit hole enough, I might find out what's
> >> going wrong between the driver and OCI. I've got a day off tomorrow
> >> (yay for war I guess), I'll give it a bash and see where we end up.
> >>
> >> --
> >> Aaron Mason - Programmer, open source addict
> >> I've taken my software vows - for beta or for worse
> >
> > I enabled debugging on the vioscsi driver, rebuilt the RAMDISK kernel
> > with those drivers enabled, and got this:
> >
> > vioscsi0 at virtio1: qsize 128
> > scsibus0 at vioscsi0: 255 targets
> > vioscsi_req_get: 0xfd803f80d338
> > vioscsi_scsi_cmd: enter
> > vioscsi_scsi_cmd: polling...
> > vioscsi_scsi_cmd: polling timeout
> > vioscsi_scsi_cmd: done (timeout=0)
> > vioscsi_scsi_cmd: enter
> > vioscsi_scsi_cmd: polling...
> > vioscsi_vq_done: enter
> > vioscsi_vq_done: slot=127
> > vioscsi_req_done: enter vr: 0xfd803f80d338 xs: 0xfd803f8a5e58
> > vioscsi_req_done: done 0, 2, 0
> > vioscsi_vq_done: slot=127
> > vioscsi_req_done: enter vr: 0xfd803f80d338 xs: 0x0
> > uvm_fault(0x813ec2e0, 0x8, 0, 1) -> e
> > fatal page fault in supervisor mode
> > trap type 6 code 0 rip 810e6190 cs 8 rflags 10286 cr2 8 cpl e
> > rsp 81606670
> > gsbase 0x813dfff0 kgsbase 0x0
> > panic: trap type 6, code=0, pc=810e6190
> >
> > That "xs: 0x0" bit feels like a clue. It should be trivial to pick up
> > and handle, but what would be the correct way to handle that?
> >
> > If I have it return if "xs" is found to be NULL, it continues - the
> > debugging suggests it goes through each possible target before
> > finishing up. I don't know if that's correct, but it seems to continue
> > booting after that even if my example didn't detect the drive with the
> > kernel I built (I used the RAMDISK kernel and it was pretty stripped
> > down).
> >
> > I'm about to attempt a -STABLE build (I've got 7.3 installed and thus
> > can't yet build a snapshot, but I will do that if this test succeeds)
> > - here's the patch that hopefully fixes the problem. (and hopefully
> > gmail doesn't clobber the tabs)
> >
> > Index: sys/dev/pv/vioscsi.c
> > ===
> > RCS file: /cvs/src/sys/dev/pv/vioscsi.c,v
> > retrieving revision 1.30
> > diff -u -p -u -p -r1.30 vioscsi.c
> > --- sys/dev/pv/vioscsi.c 16 Apr 2022 19:19:59 - 1.30
> > +++ sys/dev/pv/vioscsi.c 25 Apr 2023 12:51:16 -
> > @@ -296,6 +296,7 @@ vioscsi_req_done(struct vioscsi_softc *s
> >struct scsi_xfer *xs = vr->vr_xs;
> >DPRINTF("vioscsi_req_done: enter vr: %p xs: %p\n", vr, xs);
> >
> > + if (xs == NULL) return;
> >int isread = !!(xs->flags & SCSI_DATA_IN);
> >bus_dmamap_sync(vsc->sc_dmat, vr->vr_control,
> >offsetof(struct vioscsi_req, vr_req),
> >
> >
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: OpenBSD 7.2 on Oracle Cloud
Hi,
what qemu version are you using? I cannot reproduce this with qemu 7.2.
Can you try with a newer qemu?
Cheers,
Stefan
Am 25.04.23 um 14:53 schrieb Aaron Mason:
Yeah I'm getting the same thing. Trying a build in QEMU and
transferring in to see if that helps. Will report back.
Ok, good news, it still crashes at the same spot, but this time I've
got more data. Copying in tech@ - if I've forgotten anything let me
know and I'll fire up a fresh instance.
[REDACTED]
vioscsi_req_done(e,80024a00,fd803f81c338,e,80024a00,800
d3228) at vioscsi_req_done+0x26
[REDACTED]
Ok, so based on the trace I got, I was able to trace the stop itself
back to line 299 of vioscsi.c (thank. you. random relink. And
anonymous CVS):
293 vioscsi_req_done(struct vioscsi_softc *sc, struct virtio_softc *vsc,
294 struct vioscsi_req *vr)
295 {
296 struct scsi_xfer *xs = vr->vr_xs;
297 DPRINTF("vioscsi_req_done: enter vr: %p xs: %p\n", vr, xs);
298
-->299 int isread = !!(xs->flags & SCSI_DATA_IN);
300 bus_dmamap_sync(vsc->sc_dmat, vr->vr_control,
301 offsetof(struct vioscsi_req, vr_req),
302 sizeof(struct virtio_scsi_req_hdr),
303 BUS_DMASYNC_POSTWRITE);
Maybe if I follow the rabbit hole enough, I might find out what's
going wrong between the driver and OCI. I've got a day off tomorrow
(yay for war I guess), I'll give it a bash and see where we end up.
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
I enabled debugging on the vioscsi driver, rebuilt the RAMDISK kernel
with those drivers enabled, and got this:
vioscsi0 at virtio1: qsize 128
scsibus0 at vioscsi0: 255 targets
vioscsi_req_get: 0xfd803f80d338
vioscsi_scsi_cmd: enter
vioscsi_scsi_cmd: polling...
vioscsi_scsi_cmd: polling timeout
vioscsi_scsi_cmd: done (timeout=0)
vioscsi_scsi_cmd: enter
vioscsi_scsi_cmd: polling...
vioscsi_vq_done: enter
vioscsi_vq_done: slot=127
vioscsi_req_done: enter vr: 0xfd803f80d338 xs: 0xfd803f8a5e58
vioscsi_req_done: done 0, 2, 0
vioscsi_vq_done: slot=127
vioscsi_req_done: enter vr: 0xfd803f80d338 xs: 0x0
uvm_fault(0x813ec2e0, 0x8, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 810e6190 cs 8 rflags 10286 cr2 8 cpl e
rsp 81606670
gsbase 0x813dfff0 kgsbase 0x0
panic: trap type 6, code=0, pc=810e6190
That "xs: 0x0" bit feels like a clue. It should be trivial to pick up
and handle, but what would be the correct way to handle that?
If I have it return if "xs" is found to be NULL, it continues - the
debugging suggests it goes through each possible target before
finishing up. I don't know if that's correct, but it seems to continue
booting after that even if my example didn't detect the drive with the
kernel I built (I used the RAMDISK kernel and it was pretty stripped
down).
I'm about to attempt a -STABLE build (I've got 7.3 installed and thus
can't yet build a snapshot, but I will do that if this test succeeds)
- here's the patch that hopefully fixes the problem. (and hopefully
gmail doesn't clobber the tabs)
Index: sys/dev/pv/vioscsi.c
===
RCS file: /cvs/src/sys/dev/pv/vioscsi.c,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 vioscsi.c
--- sys/dev/pv/vioscsi.c 16 Apr 2022 19:19:59 - 1.30
+++ sys/dev/pv/vioscsi.c 25 Apr 2023 12:51:16 -
@@ -296,6 +296,7 @@ vioscsi_req_done(struct vioscsi_softc *s
struct scsi_xfer *xs = vr->vr_xs;
DPRINTF("vioscsi_req_done: enter vr: %p xs: %p\n", vr, xs);
+ if (xs == NULL) return;
int isread = !!(xs->flags & SCSI_DATA_IN);
bus_dmamap_sync(vsc->sc_dmat, vr->vr_control,
offsetof(struct vioscsi_req, vr_req),
Re: 7.2 panic and "reorder_kernel: failed" ...
On Sun, Apr 30, 2023, at 8:14 AM, Why 42? The lists account. wrote:
> After running fsck manually to clean one of the filesystems I did an
> additional reboot, just to be sure the system would/could come up
> cleanly.
>
> I noticed this message on the console, seemingly as the system was
> shutting down:
>> stopping package daemons: nginx slowcgi postfix cyrus_imapd(killed) amavisd
>> clamd sshguardreorder_kernel: failed -- see
>> /usr/share/relink/kernel/GENERIC.MP/relink.log
>
> That relink.log file looks like this:
>> root:[~]# ls -ltr /usr/share/relink/kernel/GENERIC.MP/relink.log
>> -rw-r--r-- 1 root wheel 142 Apr 30 14:29
>> /usr/share/relink/kernel/GENERIC.MP/relink.log
>
>> root:[~]# cat /usr/share/relink/kernel/GENERIC.MP/relink.log
>> (SHA256) /bsd: OK
>> LD="ld" sh makegap.sh 0x gapdummy.o
>> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
>> ${OBJS}
>> root:[~]#
>
> What might that mean? Is it significant?
I can't speak to the panic, but I think the relink error is just the background
process getting killed when you rebooted the system immediately after finishing
boot.
Brian Conway
RCE Software, LLC
Re: Minimum install size
Theo de Raadt writes: > Yoshihiro Kawamata wrote: > > > From: Janne Johansson > > Subject: Re: Minimum install size > > Date: Fri, 28 Apr 2023 09:09:49 +0200 > > > > > Do not assume "desireable" and "possible" are always the same. > > > > My point was whether the wording "installable on 512MB of storage" is > > appropriate to put in the OpenBSD 7.3 FAQ, and whether "desirable" and > > "possible" are the same is outside the discussion. > > No, it is optimistic oversell by the faq authors > > It should be realistic & accurate, or it should say nothing at all. To be fair the FAQ does cover itself by saying that squeezing into 512MB is "something for advanced users" and it looks like despite the march of time that can still just about be done. On the other hand I routinely run into problems (the obvious sort you expect) when I allocate just 2GB for OpenBSD. Storage is cheap and getting cheaper. I have more terabytes than I ever dreamed could exist just ... sitting on the desk, unused. You can fit it in 2GB or even 512MB if you really must but why? Even 10GB quickly fills up --- this workstation I'm on has 17GB in /usr/local and that's with me keeping it trim because the machine "only" has 128GB. So without further ado, here's some HTML. Matthew Index: faq/faq4.html === RCS file: /src/openbsd/cvs/www/faq/faq4.html,v retrieving revision 1.554 diff -u -p -r1.554 faq4.html --- faq/faq4.html 10 Apr 2023 02:55:09 - 1.554 +++ faq/faq4.html 30 Apr 2023 14:34:18 - @@ -412,9 +412,11 @@ When you get to the list of file sets, s Disk Partitioning -OpenBSD can be installed in as little as 512MB, but using a device that small -is something for advanced users. -Until you have some experience, 8GB or more disk space is recommended. +With a little extra work OpenBSD can be installed in as little as +2GB but such a small device isn't recommended even for advanced +users due to the effort required at every new release. Until you +have some experience, 20GB or more disk space is recommended which +includes room for some large packages. Unlike some other operating systems, OpenBSD encourages users to split their
7.2 panic and "reorder_kernel: failed" ...
Hi All,
Our 7.2 system just paniced again in pmap_page_remove / uvm_fault:
> ddb{1}> show panic
> *cpu1: uvm_fault(0xfd818b0ca560, 0x7f817ca74cb0, 0, 2) -> e
> ddb{1}> trace
> pmap_page_remove(fd8109c56480) at pmap_page_remove+0x21d
> uvm_anfree_list(fd804a0e7e40,800022eab518) at uvm_anfree_list+0x56
> amap_wipeout(fd80553d12e0) at amap_wipeout+0x113
> uvm_unmap_detach(800022eab5d8,0) at uvm_unmap_detach+0x6d
> sys_munmap(800022720010,800022eab640,800022eab6a0) at
> sys_munmap+0x113
> syscall(800022eab710) at syscall+0x35f
> Xsyscall() at Xsyscall+0x128
> end of kernel
> end trace frame: 0x7f7dcd10, count: -7
(See also bug report from 24.4, subject: "kernel panic in pmap_page_remove")
After running fsck manually to clean one of the filesystems I did an
additional reboot, just to be sure the system would/could come up
cleanly.
I noticed this message on the console, seemingly as the system was
shutting down:
> stopping package daemons: nginx slowcgi postfix cyrus_imapd(killed) amavisd
> clamd sshguardreorder_kernel: failed -- see
> /usr/share/relink/kernel/GENERIC.MP/relink.log
That relink.log file looks like this:
> root:[~]# ls -ltr /usr/share/relink/kernel/GENERIC.MP/relink.log
> -rw-r--r-- 1 root wheel 142 Apr 30 14:29
> /usr/share/relink/kernel/GENERIC.MP/relink.log
> root:[~]# cat /usr/share/relink/kernel/GENERIC.MP/relink.log
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0x gapdummy.o
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> root:[~]#
What might that mean? Is it significant?
This is a virtualised OpenBSD instance running on QEMU / Debian Linux.
I've included some additional info, regarding the panic, output from ddb,
below ... if that is of interest.
Cheers,
Robb.
ddb{0}> show uvm
Current UVM status:
pagesize=4096 (0x1000), pagemask=0xfff, pageshift=121519007 VM pages: 615597
active, 54738 inactive, 1 wired, 299836 free (77933 zero)
min 10% (25) anon, 10% (25) vnode, 5% (12) vtext
freemin=50633, free-target=67510, inactive-target=0, wired-max=506335
faults=147405838, traps=149196391, intrs=4821202, ctxswitch=33921314
fpuswitch=0
softint=46722165, syscalls=281857273, kmapent=11
fault counts:
noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
ok relocks(total)=238350(239289), anget(retries)=19653204(0),
amapcopy=11109730
neighbor anon/obj pg=5361492/21511643, gets(lock/unlock)=9626010/239342
cases: anon=17935690, anoncow=1717514, obj=5849938, prcopy=3775080,
przero=118127605
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=1
swpages=526128, swpginuse=0, swpgonly=0 paging=0
kernel pointers:
objs(kern)=0x822e7588
ddb{0}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
85463 376479 19056543 30x8a kqreadlmtpd
40689 333687 63656507 30x92 kqreadlmtp
20679 171977 63656507 3 0x192 kqreadcleanup
62580 393095 63656507 30x92 kqreadsmtpd
94055 484524 63656507 3 0x192 kqreadtrivial-rewrite
63319 120941 63656507 3 0x192 kqreadanvil
18813 417198 63656507 30x92 kqreadsmtpd
25010 114571 19056543 30x82 lockf imapd
53158 375953 19056543 30x8a kqreadimapd
68381 324871 63656507 30x92 kqreadtlsproxy
63605 58831 19056543 30x8a kqreadimapd
52360 292291 19056543 30x8a kqreadimapd
99886 433302 63656507 30x92 lockf dnsblog
768012093 19056543 7 0x2lmtpd
25035 175379 17871530 30x90 kqreadperl
6203 299107 17871530 30x90 lockf perl
71793 709 19056543 30x8a kqreadimapd
79965 216521 19056543 30x8a kqreadimapd
62342 450749 19056543 30x8a kqreadimapd
13176 514534 63656507 30x92 kqreaddnsblog
27955 360632 63656507 30x92 lockf dnsblog
69483 431512 63656507 30x92 kqreadpostscreen
10002 58404 19056543 30x8a kqreadimapd
46558 211092 19056543 30x8a kqreadimapd
46541 45982 19056543 30x8a kqreadimapd
14453 401009 19056543 30x8a kqreadimapd
36547 92359 63656507 3 0x192 kqreadpickup
68439 377693 17871530 30x90 lockf perl
20312 193348 17871530 30x90 lockf perl
29531 309738 17871530 30x90 lockf perl
47097 134056 19056543 30x8a kqreadimapd
57064 215926 19056543 3
Re: pf - traffic flow through 2 routers
Hi. Check your PF rules and also confirm you have set net.inet.ip.forwarding=1 via sysctl. Regards, Roman On 30.04.23 11:23, Gurra wrote: Hi list, I’m stuck setting up this configuration - 2 OpenBSD 7.3 boxes connected via a private network 192.168.2.0/24. The clients connected to box 1 on 192.168.1.0/24 should be able to reach the server on 192.168.2.0/24 with ip 192.168.2.2 on port 1234 tcp The communication between clients and server needs to go through the 192.168.2.0/24 network Box 1 can communicate with the server but the clients can not reach the server. internet ^ | em0 v +-+ em1 | OpenBSD |<> clients |1|192.168.1./24 192.168.1.0/24 +-+ em2 192.168.2.10/24 ^ | v em1 192.168.2.1/24 +-+ server | OpenBSD | <> |2|192.168.2.2 port 1234 +-+ ^ | | em0 | v internet Any pointers? Cheers, Gurra
Re: pf - traffic flow through 2 routers
> I’m stuck setting up this configuration - 2 OpenBSD 7.3 boxes > connected via a private network 192.168.2.0/24. > The clients connected to box 1 on 192.168.1.0/24 should be able to reach the > server > on 192.168.2.0/24 with ip 192.168.2.2 on port 1234 tcp > The communication between clients and server needs to go through the > 192.168.2.0/24 network > Box 1 can communicate with the server but the clients can not reach the > server. > Any pointers? Use tcpdump to figure out where those packets go and where they stop going, so you know on which machine to look for the issue. If you use PF, enable logging on rules (man pflog) and see which rule those packets hit. -- May the most significant bit of your life be positive.
pf - traffic flow through 2 routers
Hi list, I’m stuck setting up this configuration - 2 OpenBSD 7.3 boxes connected via a private network 192.168.2.0/24. The clients connected to box 1 on 192.168.1.0/24 should be able to reach the server on 192.168.2.0/24 with ip 192.168.2.2 on port 1234 tcp The communication between clients and server needs to go through the 192.168.2.0/24 network Box 1 can communicate with the server but the clients can not reach the server. internet ^ | em0 v +-+ em1 | OpenBSD |<> clients |1|192.168.1./24 192.168.1.0/24 +-+ em2 192.168.2.10/24 ^ | v em1 192.168.2.1/24 +-+ server | OpenBSD | <> |2|192.168.2.2 port 1234 +-+ ^ | | em0 | v internet Any pointers? Cheers, Gurra
unclean / on every boot (SD card in APU1C)
This is current/amd64 on an APU1C (dmesg below). It runs off a microSD card (sd1 in a SD card adapter in the SD slot) and has a 60GB mSATA (sd0 in the mSATA slot ) for backups of others. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 501M106M370M23%/ /dev/sd1d 989M6.0K940M 1%/tmp /dev/sd1e 249M6.7M229M 3%/var /dev/sd1f 989M950K939M 1%/var/log /dev/sd1g 1.5G1.4M1.4G 1%/var/www /dev/sd1h 1.9G651M1.2G35%/usr /dev/sd1i 4.8G193M4.4G 5%/usr/local /dev/sd1l 4.8G 54.3M4.5G 2%/home /dev/sd0a 55.8G129M 52.9G 1%/backup The problem is the root filesystem is always unclean after a reboot. That is, after a warm reboot with 'shutdown -r' or 'reboot': WARNING: / was not properly unmounted Automatic boot in progress: starting file system checks. /dev/sd1a (47e56166cfb1e429.a): 1758 files, 54169 used, 202494 free (38 frags, 25307 blocks, 0.0% fragmentation) /dev/sd1a (47e56166cfb1e429.a): MARKING FILE SYSTEM CLEAN This never happens with a cold reboot (shutdown -h or halt). It also never happens with the mSATA disk. The shutdown (cold or warm) does report 'syncing disks ... done' and doesn't report any problems. How can I debug this? Is it something specific about microSD cards? In every case, the filesystem just got fsck'ed on boot and runs fine; but it seems unreliable booting an unclean / Jan OpenBSD 7.3-current (GENERIC.MP) #0: Sat Apr 29 23:58:22 CEST 2023 h...@stary.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2098511872 (2001MB) avail mem = 2015338496 (1921MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.01 MHz, 14-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGPB) acpiprt2 at acpi0: bus -1 (HDMI) acpiprt3 at acpi0: bus 1 (PBR4) acpiprt4 at acpi0: bus 2 (PBR5) acpiprt5 at acpi0: bus 3 (PBR6) acpiprt6 at acpi0: bus -1 (PBR7) acpiprt7 at acpi0: bus 5 (PE20) acpiprt8 at acpi0: bus -1 (PE21) acpiprt9 at acpi0: bus -1 (PE22) acpiprt10 at acpi0: bus -1 (PE23) acpiprt11 at acpi0: bus 4 (PIBR) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fc rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fd rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD 14h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:3d:bb:fe rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev
