Feature request: hostname.default
When needing to move a disk over from one computer to another, you quite often end up with hostname.X having the wrong name. Often it can be difficult to know what the interface will be called before booting up openbsd. As many servers are just accessable with ssh (and not through keyboard and screen) this is causing some problem at migrations. Please consider to add support for a hostname.default. If no hostname.X is matching the interface, this file would be used as last resource before giving up configuring the interface.
Re: Feature request: hostname.default
On 11/12/2014 11:19 AM, Stefan Sperling wrote: On Wed, Nov 12, 2014 at 10:11:23AM +0200, Lars Engblom wrote: Please consider to add support for a hostname.default. If no hostname.X is matching the interface, this file would be used as last resource before giving up configuring the interface. Before configuring _which_ interface? I guess you mean the case of having several network interfaces. Let all of the unconfigured interfaces get the IP settings from hostname.default and write this in the documentation. It is easier to plug in just one cable than having to guess all the names of the interfaces (em0, bge0, re0, rl0 etc). After the first boot one can easily find out the names with ifconfig and then for example 'mv /etc/hostname.default /etc/hostname.em0'
panic: softdep_setup_inomapdep: found inode
On amd64 running 5.4, this message has been beginning to appear: panic: softdep_setup_inomapdep: found inode Stopped atDebugger+0x5: leave I was not able to run trace nor ps, as suggested further in the text. Upon restart, manual fsck has often been needed for the biggest and most active partition. As background: The server have a separate huge /home partition. This partition is a softraid mirror. To this partition, all backup from 5 school servers are dumped. This partition is thus seeing a lot of file activity. Both disks are OK, according to smartctl, and both are online according to bioctl. I have seen the same strange behaviour with panics on a few other servers too. All servers with this problem are running AMD-processors (as in manufactured by AMD). Sadly I am not able to provide more information as I could not run any trace nor ps, but hopefully this information together with something someone else sends in will make sense. As a side note, it might be related: I have two OpenBSD snapshot (amd64) workstations running softraid. One is running softraid mirror and the other one is running softraid crypto. Both have been having a corrupted /var/db/pkg quite frequently. They have surely not had powerloss during pkg_add -u or any other pkg_* action. pkg_check corrects the problem. Since I begun running sync manually after pkg_* actions, I have not seen the problem yet but on the other hand, I have not done that many pkg_add -u that I can be sure if that fixed the problem. Also this problem did not appear after each pkg_add -u This _might_ hint there is a problem with sync and softraid framework.
getty cannot allocate memory
In recent snapshots, I can not do a console login anymore. *dm, like xdm works still. The latest message is the date on ttyC0. authlog is full of this kind of messages: init: can't exec getty '/usr/libexec/getty' for port /dev/ttyC0: Cannot allocate memory I somehow suspect this came together with radeon fb, but I am not sure. With this particular computer, I will not have a chance to revert to an older snapshot for testing this theory. I have attached dmesg. OpenBSD 5.4-current (GENERIC.MP) #54: Tue Sep 10 17:21:35 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4187025408 (3993MB) avail mem = 4067463168 (3879MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe91c0 (21 entries) bios0: vendor American Megatrends Inc. version P1.10 date 03/07/2011 bios0: ASRock H61M-GS acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG AAFT HPET acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S4) BR20(S4) EUSB(S4) USBE(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) P0P1(S4) P0P2(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) i5-2400 CPU @ 3.10GHz, 3093.38 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3092.99 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC 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) i5-2400 CPU @ 3.10GHz, 3092.99 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC 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) i5-2400 CPU @ 3.10GHz, 3092.99 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus 3 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus -1 (PEX6) acpiprt8 at acpi0: bus -1 (PEX7) acpiprt9 at acpi0: bus 1 (P0P1) acpiprt10 at acpi0: bus -1 (P0P2) acpiprt11 at acpi0: bus -1 (P0P3) acpiprt12 at acpi0: bus -1 (P0P4) acpicpu0 at acpi0: C3, C3, C1, PSS acpicpu1 at acpi0: C3, C3, C1, PSS acpicpu2 at acpi0: C3, C3, C1, PSS acpicpu3 at acpi0: C3, C3, C1, PSS acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100, 2900, 2700, 2500, 2300, 2100, 1900, 1700, 1600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 ppb0 at pci0 dev 1 function 0 Intel Core 2G PCIE rev 0x09: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility HD 5430 rev 0x00: apic 0 int 16 drm0 at radeondrm0 azalia0 at pci1 dev 0 function 1 ATI Radeon HD 5470 Audio rev 0x00: msi azalia0: no supported codecs Intel HD Graphics 2000 rev 0x09 at pci0 dev 2 function 0 not configured Intel 6 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x05: apic 0 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia1 at pci0 dev 27 function 0 Intel 6 Series HD Audio rev 0x05: msi azalia1: codecs: Realtek ALC662 audio0 at azalia1 ppb1 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb5: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 2 Intel 6 Series PCIE rev 0xb5: msi pci3 at ppb2 bus 3 alc0 at pci3 dev 0 function 0 Attansic Technology L1D rev 0xc0: msi, address 00:25:22:c9:d9:a0 atphy0 at alc0 phy 0: F1
Re: Race condition in boot scripts when using DHCP (with wireless)
I have been checking, the bg option is not mention in fstab(5), mount(8) and mount_nfs(8). Please update the manual pages together with the faq. At this moment, there is no way anyone could figure it out by themselves. On 07/25/13 08:51, Lars Engblom wrote: OK! I will try that. Please update the fstab entry at http://www.openbsd.org/faq/faq6.html#NFS because I was following it and I assume other will run into the same kind of problems. On 07/25/13 08:46, Miod Vallat wrote: I can get the boot process to continue by pressing ctrl-c. Once it has been booting up, the network has got ready by itself and I can manually mount the NFS-share. This is showing it is all about a race condition where the NFS-mounting begins before the link is ready and the DHCP-client had time to get an IP assigned. You should mount your NFS filesystems with option bg, then. Miod
Re: Race condition in boot scripts when using DHCP (with wireless)
OK! I will try that. Please update the fstab entry at http://www.openbsd.org/faq/faq6.html#NFS because I was following it and I assume other will run into the same kind of problems. On 07/25/13 08:46, Miod Vallat wrote: I can get the boot process to continue by pressing ctrl-c. Once it has been booting up, the network has got ready by itself and I can manually mount the NFS-share. This is showing it is all about a race condition where the NFS-mounting begins before the link is ready and the DHCP-client had time to get an IP assigned. You should mount your NFS filesystems with option bg, then. Miod
Race condition in boot scripts when using DHCP (with wireless)
My scenario: I am connecting to a wireless network using WPA2 encryption. The computers are getting IP by DHCP. The computers are mounting NFS shares. Problem: Both with athn and iwn drivers, at boot time the system is often saying the link is not up and DHCP-client will go to sleep. This prevents NFS shares from getting mounted and the boot process halts completely. I can get the boot process to continue by pressing ctrl-c. Once it has been booting up, the network has got ready by itself and I can manually mount the NFS-share. This is showing it is all about a race condition where the NFS-mounting begins before the link is ready and the DHCP-client had time to get an IP assigned. This problem has been appearing earlier, but then been disappearing after some snapshots. However the problem has been in 90% of each boot in the latest few snapshots. The problem has thus been getting worse recently. I am using amd64 snapshots.
Softraid and bigger than 2Tb disks
Version: 5.3 GENERIC.MP#62 amd64 Problem: Softraid is not able to use bigger than 2Tb RAID partition without truncating the space. *How to reproduce* 1. Have two 4Tb disks (real or qemu disks). 2. fdisk -yi sd0 fdisk -yi sd1 Now we have two 2Tb partitions created as the FAQ says. 3. disklabel -E sd0 Press 'b' to change boundary (from FAQ), press '*' to get whole disk. a a Default values for the new partition, except for Filesystem that gets changed to RAID. 4. Copy over disklable to the other disk. Now we have been creating partitions according to FAQ for big disks (http://www.openbsd.org/faq/faq14.html) 5. bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid 0 sd2 gets created at this point and it is truly 2Tb, here it is not possible to change the boundary to get bigger partitions. Softraid should not care about the partition created with fdisk, it should just care about the disklabel.
Re: Softraid and bigger than 2Tb disks
A small typo in the bug report: 5. bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 My tests had not this typo, only the bug report had. On 05/02/13 09:32, Lars Engblom wrote: Version: 5.3 GENERIC.MP#62 amd64 Problem: Softraid is not able to use bigger than 2Tb RAID partition without truncating the space. *How to reproduce* 1. Have two 4Tb disks (real or qemu disks). 2. fdisk -yi sd0 fdisk -yi sd1 Now we have two 2Tb partitions created as the FAQ says. 3. disklabel -E sd0 Press 'b' to change boundary (from FAQ), press '*' to get whole disk. a a Default values for the new partition, except for Filesystem that gets changed to RAID. 4. Copy over disklable to the other disk. Now we have been creating partitions according to FAQ for big disks (http://www.openbsd.org/faq/faq14.html) 5. bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid 0 sd2 gets created at this point and it is truly 2Tb, here it is not possible to change the boundary to get bigger partitions. Softraid should not care about the partition created with fdisk, it should just care about the disklabel.
Wrong information in manual pages for booting softraid volumes
After reading http://verb.bz/installing-openbsd-using-softraid/ and http://blog.cochard.me/2012/03/openbsd-51-installation-on-sofraid4.html and http://www.undeadly.org/cgi?action=articlesid=20111002154251 it is clear OpenBSD is able to boot from a RAID 1 volume. Softraid (4) still states this: There is no boot support at this time for any disciplines. Besides this bug in documentation, I would be thankful if somebody could tell me if it is possible to boot with root on a RAID5 device. In a project I will begin soon working on, this would be useful. Regards, Lasse Engblom
Maybe a bug in documentation for BIOCTL(8)
Hello, After reading BIOCTL(8) I found this line: Use of the CRYPTO RAID 4/5 disciplines are currently considered experimental. After I have been reading this thread, I realize the documentation is probably lagging behind: http://comments.gmane.org/gmane.os.openbsd.misc/192747 Crypto is still mentioned as experimental even though one year ago it was considered stable. How is it with RAID5? I will probably have to install a server to receive backups from another backup server. It will need to run RAID5 and accurate manual pages are critical for me when I pick the OS. Most of our server are running OpenBSD and I hope the RAID5 support is mature for real use. Regards, Lasse
Re: Bindings in ksh not working as expected in snapshot
I wonder if my response to this patch got lost? It is working really
well for me... I was just wondering as i have not seen it appearing on
http://freshbsd.org/search?project=openbsdq=
If it is just lack of time, that is the cause for that this patch has
not been committed, just do it whenever you have time, I have not
intention to stress people working on it :)
On 05/21/12 14:16, Martin Pieuchot wrote:
On 21/05/12(Mon) 10:59, Lars Engblom wrote:
On current snapshot (amd64), my ksh bindings are not working anymore.
For example if I have this in .kshrc:
bind -m '^L'=^Cclear^M
set +o emacs-usemeta
This keybinding has been working for more than a year for me, prior to my
latest upgrade. The expected behavior would be Ctrl-C to interrupt the line
written followed by a 'clear' command and Enter. Now if i write 'ls'
and then
regret, wanting to clear the screen I get this visible on the screen:
$ ls^Cclear^M
This bug has been introduced in the last ksh change, thanks for reporting
it. The diff below should correct this behavior, can you confirm it works
for you?
Martin
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.45
diff -u -p -r1.45 emacs.c
--- emacs.c 30 Apr 2012 03:51:29 - 1.45
+++ emacs.c 21 May 2012 11:08:37 -
@@ -108,6 +108,7 @@ static char*killstack[KILLSIZE];
staticint killsp, killtp;
staticint x_literal_set;
staticint x_arg_set;
+static char*macro_args;
staticint prompt_skip;
staticint prompt_redraw;
@@ -343,11 +344,12 @@ x_emacs(char *buf, size_t len)
if (submatch == 1 kmatch) {
if (kmatch-ftab-xf_func == x_ins_string
- kmatch-args) {
- /* insert macro string */
- x_ins(kmatch-args);
- }
- ret = kmatch-ftab-xf_func(c);
+ kmatch-args !macro_args) {
+ /* treat macro string as input */
+ macro_args = kmatch-args;
+ ret = KSTD;
+ } else
+ ret = kmatch-ftab-xf_func(c);
} else {
if (submatch)
continue;
@@ -410,7 +412,7 @@ x_insert(int c)
static int
x_ins_string(int c)
{
- return KSTD;
+ return x_insert(c);
}
static int x_do_ins(const char *cp, int len);
@@ -1862,6 +1864,12 @@ x_e_getc(void)
if (unget_char= 0) {
c = unget_char;
unget_char = -1;
+ } else if (macro_args) {
+ c = *macro_args++;
+ if (!c) {
+ macro_args = NULL;
+ c = x_getc();
+ }
} else
c = x_getc();
Bindings in ksh not working as expected in snapshot
On current snapshot (amd64), my ksh bindings are not working anymore. For example if I have this in .kshrc: bind -m '^L'=^Cclear^M set +o emacs-usemeta This keybinding has been working for more than a year for me, prior to my latest upgrade. The expected behavior would be Ctrl-C to interrupt the line written followed by a 'clear' command and Enter. Now if i write 'ls' and then regret, wanting to clear the screen I get this visible on the screen: $ ls^Cclear^M
