No login prompt on console ttyC0 after boot
Hello I have been following current since 5.6, and had been pretty good about updates until this last year (issues not related). Anyway, I asked about updating, found some suggestions that it would work, and decided to blaze ahead. And, it basically worked. I have a few things to clean up, but overall the update to current from my last update in July 2021 went well. However, in planning for this, I decided to hook up a monitor and keyboard directly, as I have basically just used a serial console ever since I first installed the systems at 5.6. Unfortunately, I did not look at the monitor before updating to current (OpenBSD 7.1-current (GENERIC.MP) #587: Fri Jun 17 08:49:40 MDT 2022 - full DMESG below), but after the update I found that there is no login prompt on the monitor (ttyC0), and the keyboard does not do anything (I cannot ALT-CTRL-F2 to change to another virtual console. I don't know when this happened, since I haven't attached a monitor/keyboard in a very long time. But, now that I know, I am trying to fix it, but can't seem to understand why/how to do so. When the machine boots, the monitor and keyboard work, and I can access the bios pages and make changes. Then, if I allow the boot to start, I get the "switching to com0" message, and that's it. When the boot is complete, I can access the system using a serial console (tty00) or ssh, but the direct monitor shows nothing after "switching to com0," and the keyboard does nothing. The /etc/boot.conf file correctly routes things to the serial console: stty com0 115200 set tty com0 I have not changed /etc/ttys in a long time: # # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ # # name getty typestatus comments # console "/usr/libexec/getty std.9600" vt220 off secure ttyC0 "/usr/libexec/getty std.9600" vt220 on secure ttyC1 "/usr/libexec/getty std.9600" vt220 on secure ttyC2 "/usr/libexec/getty std.9600" vt220 on secure ttyC3 "/usr/libexec/getty std.9600" vt220 on secure ttyC4 "/usr/libexec/getty std.9600" vt220 off secure ttyC5 "/usr/libexec/getty std.9600" vt220 on secure ttyC6 "/usr/libexec/getty std.9600" vt220 off secure ttyC7 "/usr/libexec/getty std.9600" vt220 off secure ttyC8 "/usr/libexec/getty std.9600" vt220 off secure ttyC9 "/usr/libexec/getty std.9600" vt220 off secure ttyCa "/usr/libexec/getty std.9600" vt220 off secure ttyCb "/usr/libexec/getty std.9600" vt220 off secure tty00 "/usr/libexec/getty autologin" vt220on secure tty01 "/usr/libexec/getty std.9600" unknown off tty02 "/usr/libexec/getty std.9600" unknown off tty03 "/usr/libexec/getty std.9600" unknown off tty04 "/usr/libexec/getty std.9600" unknown off tty05 "/usr/libexec/getty std.9600" unknown off tty06 "/usr/libexec/getty std.9600" unknown off tty07 "/usr/libexec/getty std.9600" unknown off I also noticed these errors in DMESG-S: ... /dev/sd2g (be3bcca0ef32a6bd.g): file system is clean; not checking wsconsctl: /dev/ttyC0: Device not configured wsconsctl: /dev/ttyC0: Device not configured wsconsctl: /dev/ttyC0: Device not configured pf enabled ... The wsconsctl.conf file has also not been changed in a long time, and only had three things enabled: display.vblank=on # enable vertical sync blank for screen burner display.screen_off=6# set screen burner timeout to 60 seconds display.kbdact=on # restore on keyboard input If I comment out the three parameters above, then "Device not configured" messages disappear, but there is still no login prompt on the ttyC0 monitor, and the keyboard still does not appear to function (I still cannot change virtual consoles). As far as I can tell, there should be a login prompt on ttyC0, but there is not. What am I missing? (Or, what did I miss when following current since 5.6 that may have changed?) Thanks Ted DMESG: OpenBSD 7.1-current (GENERIC.MP) #587: Fri Jun 17 08:49:40 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4249260032 (4052MB) avail mem = 4103114752 (3913MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb5a0 (55 entries) bios0: vendor American Megatrends Inc. version "2.3a" date 01/06/2021 bios0: Supermicro X9SCL/X9SCM acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT SPCR EINJ ERST HEST BERT acpi0: wakeup devices UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(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) i3-3220T CPU @ 2.80GHz, 2800.47 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,A
Myricom myx reliability
Just wanted to mention that Myricom myx NICs, which are totally obsolete (Myricom was absorbed into Google), are much more reliable under OpenBSD than under FreeBSD with Myricom's own driver. The OpenBSD myx can run at full tilt for 700+ days without resetting the NIC, whereas FreeBSD has to constantly reset and deal with weird firmware errors that shut down the card. I regret running FreeBSD for ZFS with this NIC!
Re: network interface becomes inoperable - No buffer space available
How do the following look? pfctl -si systat -b mbuf vmstat -m Comparing normal + failed might be useful too. Are you using queues in pf? The ifconfig output you included looks normal. (rxpause/txpause is "has negotiated flow control" and doesn't indicate what flow control is actually blocking) On 2022-06-22, Boyd Stephens wrote: > On 6/22/22 03:36, Boyd Stephens wrote: >> We're current running a 1U platform (dmesg below) that currentl serves >> as our network gateway to a 3Gbps fiber based circuit. After operating >> for a number of hours the ix0 device becomes inaccessible and when a >> ping/traceroute/... command is attempted from the device through the >> external network interface facing the Internet ie ix0 the following >> error occurs >> >> # ping 8.8.8.8 >> PING 8.8.8.8 (8.8.8.8): 56 data bytes >> ping: sendmsg: No buffer space available >> ping: wrote 8.8.8.8 64 chars, ret=-1 >> ping: sendmsg: No buffer space available >> ping: wrote 8.8.8.8 64 chars, ret=-1 >> >> a netstat -nI for the both ix0(external) and em0(internal) interface >> produces the following >> >> Name Mtu Network Address Ipkts Ifail Opkts >> Ofail Colls >> ix0 1500 198.64.189. 198.64.189.200 24396906 0 13619148 >> 906752 0 >> >> em0 1500 10.10.210/24 10.10.210.50 15138143 0 25142717 >> 285044 0 >> >> Aslo while the servcies are inoperable nestat -m produces the following >> >> $ netstat -m >> 2544 mbufs in use: >> 2461 mbufs allocated to data >> 1 mbuf allocated to packet headers >> 82 mbufs allocated to socket names and addresses >> 16/88 mbuf 2048 byte clusters in use (current/peak) >> 2315/2415 mbuf 2112 byte clusters in use (current/peak) >> 0/56 mbuf 4096 byte clusters in use (current/peak) >> 0/32 mbuf 8192 byte clusters in use (current/peak) >> 0/0 mbuf 9216 byte clusters in use (current/peak) >> 0/0 mbuf 12288 byte clusters in use (current/peak) >> 0/0 mbuf 16384 byte clusters in use (current/peak) >> 0/0 mbuf 65536 byte clusters in use (current/peak) >> 6476/6476/524288 Kbytes allocated to network (current/peak/max) >> 0 requests for memory denied >> 0 requests for memory delayed >> 0 calls to protocol drain routines >> >> A reboot clears things up and the services will then work for a period >> of time. Although a pfctl -F all( or some derivative of the modifier) >> allows the device to once again pass traffic all of its network >> functionality does not return in that certain network requests such as >> pkg_add are not successfully processed. >> >> While snagging traffic on the ix0 interface while the device in >> malfunctioning noticed a response from the one-hop away/default gateway >> for the services making an arp request, namely >> >> tcpdump: listening on ix0, link-type EN10MB >> 20:28:13.811695 arp who-has 198.64.189.200 tell 198.64.189.199 >> 20:28:14.611323 arp who-has 198.64.189.200 tell 198.64.189.199 >> >> the following results are produced from >> >> # sysctl | grep buf >> >> kern.msgbufsize=131032 >> kern.malloc.kmemnames=free,,devbuf,,pcb,rtableifaddr,,sysctl,counters,,ioctlops,iov,mount,,NFS_req,NFS_mount,log,vnodes,,UFS_quota,UFS_mount,shm,VM_map,sem,dirhash,ACPI,VM_pmap,file_desc,sigio,proc,subprocMFS_node,,,Export_Host,NFS_srvsock,,NFS_daemon,ip_moptions,in_multi,ether_multi,mrt,ISOFS_mount,ISOFS_node,MSDOSFS_mount,MSDOSFS_fat,MSDOSFS_node,ttys,exec,miscfs_mount,fusefs_mount,pfkey_data,tdb,xform_data,,pagedep,inodedep,newblk,,,indirdep,VM_swap,,UVM_amap,UVM_aobj,,USB,USB_device,USB_HC,witness,memdesc,,,crypto_data,,IPsec_creds,ip6_options,NDP,,,temp,NTFS_mount,NTFS_node,NTFS_fnode,NTFS_dir,NTFS_hash,NTFS_attr,NTFS_data,NTFS_decomp,NTFS_vrun,kqueue,,SYN_cache,UDF_mount,UDF_file_entry,UDF_file_id,,AGP_Memory,DRM >> >> >> kern.malloc.kmemstat.devbuf=(inuse = 6179, calls = 7341, memuse = 8537K, >> limblocks = 0, maxused = 8602K, limit = 78644K, spare = 0, sizes = >> (16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144)) >> kern.bufcachepercent=20 >> kern.consbufsize=16344 >> net.bpf.bufsize=32768 >> net.bpf.maxbufsize=2097152 >> vfs.fuse.fusefs_fbufs_in=0 >> vfs.fuse.fusefs_fbufs_wait=0 >> >> We utilize similar platform with similar deployments (1Gbps Internet >> circuits) and have not seen this issue previously. >> >> sAny thoughts on the culprit of the buffer exhaustion? >> >> --- >> Boyd Stephens >> >> >> dmesg: >> >> OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022 >> >> r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> >> real mem = 17058750464 (16268MB) >> avail mem = 16524451840 (15758MB) >> random: good seed from bootblocks >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x8ec16000 (47 entries) >> bios0: vendor American Megatrends Inc. version "1.5" date 10/05/2020 >> bios0: Supermicro Su
Re: Convert a Linux VPS to OpenBSD
On Mon, 2022-06-20 at 16:47 +0100, Étienne wrote:
> Hello there,
>
> This is a bit of a long shot, but I'm trying my luck: There used to
> be a
> community thread on Scaleway's documentation website that explained
> how
> to convert a Linux instance to an OpenBSD instance, because no
> OpenBSD
> ISO image was available in their console. It seems that this doc
> disappeared as their documentation section has changed format, and I
> can't find it on archive.org either. I would like to try and apply
> the
> same process at another VPS provider. Does anyone remember or know
> how
> this was done, and would they be kind enough to summarise it here,
> please?
>
> Thanks!
I've successfully installed OpenBSD on a OVH VPS (which has kvm) using
Linux's grub facility to boot an OpenBSD kernel.
I've simply dropped the bsd.rd file into /boot and added the
corresponding menu entry like (you can edit /boot/grub/grub.cfg
directly):
menuentry OpenBSD {
kopenbsd bsd.rd
}
If the machine is using UEFI (but most VPS don't) you can even use
efibootmgr instead.
I think I've done it using
https://themimitoof.fr/installer-openbsd-7-0-sur-gandicloud-vps/
It's in french but only the grub entry is really important. If you
don't have a KVM you will need to provide an autoinstall script.
HTH
--
David
