/bsd: proc: table is full (OpenBSD server 4.0 GENERIC#1107 i386)
Hello list,
I am having problems with my server, this box has been running OBSD
for the last 3/4 years without problems. A few months ago the box
begun to experience lockups once time at week during peak hours, now
the lockup is several times a week.
The last messages in the system logs are "/bsd: proc: table is full", I
think that the load (which isn't very high) is stressing the machine and
finally hangs the server. If I don't get it wrong a properly configurated
system doesn't fail under stress.
I tunned some system variables but the problem persist so I am going to
ask for advice about how I can monitor to discover the culprit.
does anyone knows that system parameters I must monitor?
below I attach the relevant files and dmesg.
Thank you.
/etc/sysctl.conf:
=
net.inet.ip.redirect = 0
ddb.console=1 # 1=Permit entry of ddb from the console
kern.securelevel=0
vm.swapencrypt.enable=1
machdep.kbdreset=1 # permit console CTRL-ALT-DEL to do a nice halt
kern.maxfiles=8192
kern.maxproc=2048
/etc/login.conf:
default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\
:umask=022:\
:datasize-max=192M:\
:datasize-cur=75M:\
:maxproc-max=128:\
:maxproc-cur=64:\
:openfiles-cur=64:\
:stacksize-cur=4M:\
:localcipher=blowfish,6:\
:ypcipher=old:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:
daemon:\
:ignorenologin:\
:datasize=infinity:\
:maxproc=256:\
:openfiles-cur=128:\
:stacksize-cur=8M:\
:localcipher=blowfish,8:\
:tc=default:
staff:\
:datasize-cur=75M:\
:datasize-max=infinity:\
:maxproc-max=256:\
:maxproc-cur=128:\
:ignorenologin:\
:requirehome@:\
:tc=default:
user001:\
:path=/usr/local/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/bin:\
:maxproc=512:\
:coredumpsize=0:\
:openfiles-cur=4096:\
:tc=default:
users:\
:tc=default:
vpn:\
:datasize-cur=128M:\
:maxproc=256:\
:openfiles-cur=512:\
:stacksize-cur=18M:\
:tc=default:
Mar 5 12:32:55 server /bsd: proc: table is full
Mar 5 12:33:31 server last message repeated 3 times
Mar 5 12:35:10 server last message repeated 9 times
Mar 5 12:35:20 server /bsd: proc: table is full
Mar 5 12:35:52 server last message repeated 3 times
Mar 5 12:37:45 server last message repeated 10 times
Mar 5 12:38:37 server last message repeated 4 times
Mar 5 12:38:44 server pppd[4222]: Serial link appears to be disconnected.
Mar 5 12:38:48 server /bsd: proc: table is full
Mar 5 12:39:08 server last message repeated 2 times
Mar 5 12:39:49 server last message repeated 3 times
Mar 5 12:39:57 server pppd[8989]: Serial link appears to be disconnected.
Mar 5 12:40:00 server /bsd: proc: table is full
Mar 5 12:40:40 server last message repeated 3 times
Mar 5 12:41:44 server last message repeated 5 times
Mar 5 12:42:01 server pppd[22398]: Serial link appears to be disconnected.
Mar 5 12:42:01 server /bsd: proc: table is full
Mar 5 12:42:41 server last message repeated 3 times
Mar 5 12:44:51 server last message repeated 10 times
Mar 5 12:55:02 server syslogd: restart
Mar 5 12:55:02 server /bsd: OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58
MDT 2006
Mar 5 12:55:02 server /bsd: [EMAIL
PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
Mar 5 12:55:02 server /bsd: cpu0: Intel(R) Pentium(R) 4 CPU 1.70GHz
("GenuineIntel" 686-class) 1.72 GHz
Mar 5 12:55:02 server /bsd: cpu0:
FPU,V86,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
Mar 5 12:55:02 server /bsd: real mem = 536424448 (523852K)
Mar 5 12:55:02 server /bsd: avail mem = 481374208 (470092K)
Mar 5 12:55:02 server /bsd: using 4256 buffers containing 26923008 bytes
(26292K) of memory
Mar 5 12:55:02 server /bsd: mainbus0 (root)
Mar 5 12:55:02 server /bsd: bios0 at mainbus0: AT/286+(3d) BIOS, date
04/30/02, BIOS32 rev. 0 @ 0xf1380, SMBIOS rev. 2.3 @ 0xf3460 (50 entries)
Mar 5 12:55:02 server /bsd: bios0: ASUSTeK Computer INC. P4S533
Mar 5 12:55:02 server /bsd: apm0 at bios0: Power Management spec V1.2 (BIOS
mgmt disabled)
Mar 5 12:55:02 server /bsd: apm0: APM power management enable: unrecognized
device ID (9)
Mar 5 12:55:02 server /bsd: apm0: APM engage (device 1): power management
disabled (1)
Mar 5 12:55:02 server /bsd: apm0: AC on, battery charge unknown
Mar 5 12:55:02 server /bsd: apm0: flags b0102 dobusy 0 doidle 1
Mar 5 12:55:02 server /bsd: pcibios0 at bios0: rev 2.1 @ 0xf/0x1bb2
Mar 5 12:55:02 server /bsd: pcibios0: PCI IRQ Routing Table rev 1.0 @
0xf1af0/192 (10 entries)
Mar 5 12:55:02 server /bsd: pcibios0: PCI Interrupt Router at 000:02:0 ("SiS 85C503
System" rev 0x00)
Mar 5 12:55:02 server /bsd: pcibios0: PCI bus #1 is the last bus
Mar 5 12:55:02 serv
Re: /bsd: proc: table is full (OpenBSD server 4.0 GENERIC#1107 i386)
Bob Beck wrote: I am having problems with my server, this box has been running OBSD for the last 3/4 years without problems. A few months ago the box begun to experience lockups once time at week during peak hours, now the lockup is several times a week. The last messages in the system logs are "/bsd: proc: table is full", I think that the load (which isn't very high) is stressing the machine and finally hangs the server. If I don't get it wrong a properly configurated system doesn't fail under stress. "load" meaning load average measures the run queue. Your kernel is screaming that it's out of processes. perhaps you should sorry about not being more contrete here. I said "load" in a more general sense, not "load average" as reported by some system utilities. the CPU is idle 50% of the time, there is sufficient memory for regular processes and the machine is not swapping. Only sporadic and bursty read/ write operations happen at the disks. run a ps -auwx and see what's chewing them all up? When you are out of processes, not much happens. unfortunatelly when I get the "table is full" error is too late and the machine is hang :-(
Re: /bsd: proc: table is full (OpenBSD server 4.0 GENERIC#1107 i386)
Darren Tucker wrote: > If you have a logged-in shell you can do "exec ps -auwx" which won't require a new process table slot. It replaces the shell so you'll be effectively logged out after the ps completes, but hopefully with better information :-) "exec ps -auwx" doesn't helps here because the box is locked by the time I get the error. Alternatively you could put the ps into a cron job and log to a file every minute or so and do post-mortem analysis. yes, it was one of my first ideas but I would like retrieve all the infomation related to the system status and I wonder if top is the proper tool for this purpose? By now I have vmstat and iostat logging to a file.
SCSI and disk geometry
Hello, I'm trying to install OpenBSD in three servers with identical hardware and I was able to install it in two of them but not in the third. Each server detects a diferent geometry for the SCSI disks :-? server1 -> geometry: 817199/87/1 [71096313 Sectors] server2 -> geometry: 2843852/25/1 [71096300 Sectors] server3 -> geometry: 4425/255/63 [71087625 Sectors] in the third server the geometry causes a broken MBR anyone knows that can be causing this? Thank you. dmesg, fdisk and disklabel: http://195.55.55.164/tests/OpenBSD/server1.txt http://195.55.55.164/tests/OpenBSD/server2.txt http://195.55.55.164/tests/OpenBSD/server3.txt -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
Re: SCSI and disk geometry
K WESTERBACK wrote: > --- "Josi M. Fandiqo" <[EMAIL PROTECTED]> wrote: > > I'm trying to install OpenBSD in three servers with > > identical hardware and I was able to install it in > > two > > of them but not in the third. > > > > Each server detects a diferent geometry for the SCSI > > disks :-? > > > > server1 -> geometry: 817199/87/1 [71096313 Sectors] > > server2 -> geometry: 2843852/25/1 [71096300 Sectors] > > server3 -> geometry: 4425/255/63 [71087625 Sectors] > > > > dmesg, fdisk and disklabel: > > http://195.55.55.164/tests/OpenBSD/server1.txt > > http://195.55.55.164/tests/OpenBSD/server2.txt > > http://195.55.55.164/tests/OpenBSD/server3.txt > And in particular > > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 > bytes/sec, 71096320 sec total > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 > bytes/sec, 71096320 sec total > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 > bytes/sec, 71096320 sec total > > sd1: 34715MB, 27150 cyl, 4 head, 654 sec, 512 > bytes/sec, 71096640 sec total > sd1: 34715MB, 31310 cyl, 4 head, 567 sec, 512 > bytes/sec, 71096640 sec total > sd1: 34715MB, 27150 cyl, 4 head, 654 sec, 512 > bytes/sec, 71096640 sec total I forget what the servers have tree disks hd0 hd1 and hd2. hd0 and hd1 is a hardware raid-1 so OpenBSD see it as sd0, however hd2 is a stand alone disk and is detected as sd1. > So OpenBSD is finding identical geometry for sd0 on > all three servers. And the numbers match (34715*16*128 > = 71096320). > > For sd1 one result differs from the other two and > neither set of values seem to match. sd1 is not important to me. thank you. -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
Re: SCSI and disk geometry
Otto Moerbeek wrote: > On Wed, 29 Jun 2005, [iso-8859-15] Josi M. [iso-8859-15] Fandiqo wrote: > > I'm trying to install OpenBSD in three servers with > > identical hardware and I was able to install it in two > > of them but not in the third. > > > > Each server detects a diferent geometry for the SCSI > > disks :-? > > > > server1 -> geometry: 817199/87/1 [71096313 Sectors] > > server2 -> geometry: 2843852/25/1 [71096300 Sectors] > > server3 -> geometry: 4425/255/63 [71087625 Sectors] > > dmesg, fdisk and disklabel: > > http://195.55.55.164/tests/OpenBSD/server1.txt > > http://195.55.55.164/tests/OpenBSD/server2.txt > > http://195.55.55.164/tests/OpenBSD/server3.txt > I cannot explain the differences in geometry. Your disklabels look OK, > it might be a BIOS thing that hits you. This smells like a problem > Nick loves ;-) definitely he is the man to find it. > You server3 log puzzles me, since it is incomplete. I do not see you > setting the size in fdisk. This is important since there are a few > CAVEATS; see fdisk(8). it is a full install process. > I see you violate the MBR boundary rules on server 1 and 2 as well. > You might be just lucky the other two servers work, and have a hidden > problem there as well. It was my first impression since they are very weird geometries. > If possible, it is easiest to just use the whole disk for OpenBSD, > since fdisk -i (as done by the installer) just takes care of > everything. it isn't possible. I plan use the remain MBR partitions to store old OpenBSD installations, so if an update fails I can revert to the previous version immediately. -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
Re: SCSI and disk geometry
Nick Holland wrote: > >> Each server detects a diferent geometry for the SCSI > >> disks :-? > >> > >> server1 -> geometry: 817199/87/1 [71096313 Sectors] > >> server2 -> geometry: 2843852/25/1 [71096300 Sectors] > >> server3 -> geometry: 4425/255/63 [71087625 Sectors] > >> dmesg, fdisk and disklabel: > >> http://195.55.55.164/tests/OpenBSD/server1.txt > >> http://195.55.55.164/tests/OpenBSD/server2.txt > >> http://195.55.55.164/tests/OpenBSD/server3.txt > Ken was zooming in on something, I'm looking at something I am finding > even stranger: > > sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 bytes/sec, 71096320 sec total > sd1 at scsibus1 targ 2 lun 0: SCSI3 0/direct > fixed > sd1: 34715MB, 27150 cyl, 4 head, 654 sec, 512 bytes/sec, 71096640 sec total Nick, might it be the hardware raid1 for the first two disks the guilty? (note that hd0+hd1=sd0 and hd2=sd1) afaik hardware raid is abstracted to the OS and it _should_ be transparent. Certainly it works with SuSE Linux and FreeBSD, even they were able to use the ServerRaid 6i controller but since it isn't supported by OpenBSD I remove it. Anyway the onboard SCSI card can do hardware raid1 which I'm using in all servers, simply because it's a lot more easy to configure it that software raid for the root partition. I would like to keep the configuration as easy as possible and not too OpenBSD specific since not all coworkers are BSD guys :-( > Since when did LSILOGIC start making HARD DISKS with the exact same > model number as their SCSI adapter?? Something is going seriously > wrong there. (I'm guessing since you have three "identical" machines, > they probably have six identical HDs). I think the driver is confused by the hardware raid. > At this point, Simplify, Simplify, Simplify. > Drop to one drive, then the other. Something is going seriously > wrong there. I will try to install OpenBSD in a spare disk. > Otto's right, I think at this point, the fact that anything here is > working here is more good luck than good management. Something is > broke. You don't have one bad and two good machines, you got three > stinkers, but one of them rubs your nose in it more. the servers aren't in production so this is the moment to test things like these. > Does your adapter's BIOS see the drives properly (i.e., not > LSILOGIC 1030. Most will give you some kinda clue what kinda drive > they have attached)? Try a different adapter, try a different cable, > different drives, etc. > > Move the drives that "work" to the machine that doesn't -- does the > problem follow the drive, the computer or the SCSI adapter? (probably > on board...but if not, move the adapters around, too). > > At this point...I'm suspicious you found a nasty bug in the SCSI driver > for that card, but a (set??) of really bad cables might explain it, too. do you mean in the OBSD SCSI driver? > Yes, I have seen piles of parts were every single one was bad in a similar > way... Could also be a very bad jumper option on the drives, too. Do you know if it's a supported configuration for OpenBSD? -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
Re: SCSI and disk geometry
Marco Peereboom wrote: > > Are you sure you wiped all RAID meta data of the disks? > Did you reuse a disk that was part of a RAID set by any chance? > Go to the card BIOS and wipe all RAID sets; that might just fix your > problem. the raid was reconstructed with the vendor utilities and finally I get a broken MBR :( the geometry of sd1 (not sd0 the mirrored pair) in the tree servers is 4425/255/63. I did a new installation with the consequent broken MBR message at the end of the process. > RAID volumes will work; just super slow. I'm curious about the very low speeds in transfers, but that will be a completely new thread. -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
Re: SCSI and disk geometry
more on this issue. K WESTERBACK wrote: > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 > bytes/sec, 71096320 sec total > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 > bytes/sec, 71096320 sec total > sd0: 34715MB, 34715 cyl, 16 head, 128 sec, 512 > bytes/sec, 71096320 sec total > > sd1: 34715MB, 27150 cyl, 4 head, 654 sec, 512 > bytes/sec, 71096640 sec total > sd1: 34715MB, 31310 cyl, 4 head, 567 sec, 512 > bytes/sec, 71096640 sec total > sd1: 34715MB, 27150 cyl, 4 head, 654 sec, 512 > bytes/sec, 71096640 sec total I did a test with FreeBSD and it detects a geometry of 4425/255/63 in mirrored (sd0) and not mirrored (sd1) disks, and the installation was successful. > So OpenBSD is finding identical geometry for sd0 on > all three servers. And the numbers match (34715*16*128 > = 71096320). > > For sd1 one result differs from the other two and > neither set of values seem to match. > > I suspect sd1 is behaving badly in some way. I would > suggest trying a -current snapshot as the geometry > code has been getting a lot of work lately. If you can > (and want to) you can compile a kernel with the > options > > option SCSIDEBUG > option SCSIDEBUG_LEVEL=0xf0 > option SCSIDEBUG_BUSES=0x2 > option SCSIDEBUG_TARGETS=0x5 > option SCSIDEBUG_LUNS=0xff > > and send me the output. It will show exactly what the > disks are saying about their geometry. http://195.55.55.164/tests/OpenBSD/server3-dmesg-orig.txt http://195.55.55.164/tests/OpenBSD/server3-dmesg-SCSIDEBUG.txt http://195.55.55.164/tests/OpenBSD/server3-fdisk.txt http://195.55.55.164/tests/OpenBSD/server3-label.txt http://195.55.55.164/tests/OpenBSD/server3-sysctl.txt -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
unable to use a read-only root with 3.8
Hello list,
I'm in a situation where I must configure a couple of soekris boxes (net4801)
with very minimal services (pf and syslogd sending all logs to a remote
server), they will be unattended and various thousands of kilometers away.
Also the system is probable to suffer electrical failures and since OBSD
is contained in a CF card I become very interested in running it over an
unique read-only partition.
The first option was add the "ro" flag to the fstab file, but it's ignored
and the system leaves the root fs in "rw" mode. The second (and desesperate)
option was add "mount -o ro /" to /etc/rc.local which seems cause a kernel
panic (no suprise here)
is it possible to have a root fs in read-only mode with OBSD?
POST: 0123456789bcefghipajklnopq,,,tvwxy[2J
comBIOS ver. 1.28 20050529 Copyright (C) 2000-2005 Soekris Engineering.
net4801
CPU Geode 266 Mhz Mbyte Memory0128
Pri Mas SanDisk SDCFB-256 LBA 980-16-32 251 Mbyte
Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1Base2 Int
---
0:00:0 1078 0001 0600 0107 0280 00 00 00
0:06:0 100B 0020 0200 0107 0290 00 3F 00 E101 A000 10
0:07:0 100B 0020 0200 0107 0290 00 3F 00 E201 A0001000 10
0:08:0 100B 0020 0200 0107 0290 00 3F 00 E301 A0002000 10
0:18:2 100B 0502 01018001 0005 0280 00 00 00
0:19:0 0E11 A0F8 0C031008 0117 0280 08 38 00 A0003000 11
Seconds to automatic boot. Press Ctrl-P for entering Monitor. 5 4 3 2 1
Using drive 0, partition 3.
Loading...
probing: pc0 com0 com1 pci mem[639K 127M a20=on]
disk: hd0+
>> OpenBSD/i386 BOOT 2.10
|/-\|/-
com0: 19200 baud
switching console to com0
>> OpenBSD/i386 BOOT 2.10
boot>
booting hd0a:/bsd: ...snip...
entry point at 0x100120
[ using 476508 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2005 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC"
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem = 133799936 (130664K)
avail mem = 115474432 (112768K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 20/50/29, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10,
address 00:00:24:c4:ff:1c
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10,
address 00:00:24:c4:ff:1d
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10,
address 00:00:24:c4:ff:1e
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI/ACPI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 245MB, 501760 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3
wdstatus 0
ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 11, version
1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Compaq OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
isa0 at gscpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
sysbeep0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
biomask fbe5 netmask ffe5 ttymask ffe7
pctr: no performance counters in CPU
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
Automatic boot in progress: starting file system checks.
/dev/rwd0a: file system is clean; not
Re: unable to use a read-only root with 3.8
> Also the system is probable to suffer electrical failures and since OBSD > is contained in a CF card I become very interested in running it over an > unique read-only partition. > > The first option was add the "ro" flag to the fstab file, but it's ignored > and the system leaves the root fs in "rw" mode. The second (and desesperate) > option was add "mount -o ro /" to /etc/rc.local which seems cause a kernel > panic (no suprise here) > > is it possible to have a root fs in read-only mode with OBSD? I think I found a valid solution. OBSD is installed in the soekris box by means of PEX/DHCP/TFTP, so no problems with geometry mismatches as with the flashdist approach. Next copy /dev/MAKEDEV to /root (or whatever place that you like) and modidy /etc/rc around the line 200 (after the mount -a command group) ... mount_mfs -s 1 swap /dev mount_mfs -s 1000 swap /tmp mount_mfs -s 1000 swap /var/log mount_mfs -s 1000 swap /var/run # add mfs mountpoints for other critical directories. cd /dev ; /root/MAKEDEV ramdisk wscons pty pf tun mount -o ro / ... ramdisk, wscons and pty seems to be minimal devices to get basic funcionality. pf permits run pf and tun permits openvpn to work. Regards -- GCS/IT d- s+:+() a31 C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++ G++ e- h+(++) !r !z --END GEEK CODE BLOCK--
