Re: Memory alignment
On Sat, 28 Jan 2017, Kyoung Jae Seo wrote: Maybe posix_memalign(3) is API you are looking for. No. This allocates memory. I already have the buffer. I am trying to use space within it. Regards - Damian Pacific Engineering Systems International, 277-279 Broadway, 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: netbooting OpenBSD (6.0) i386 and amd64 clients from one server
On Sat, Jan 28, 2017 at 12:17:40AM +0100, Sven-Volker Nowarra wrote: > I am netbooting many systems, and last recently stepped on the issue, that I > had an amd64 and an i386 client in the same network. I wanted to boot them > into a "full" OpenBSD (not ramdisk kernel). That is not possible with the > default installation, cause pxeboot can not distinguish between these > Intel/AMD systems. DHCP server can distinguish by MAC address, but then when > pxeboot is loaded, the kernel is per default "bsd". This must clash either > with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry. > So I went through some older mailing list entries, adapted them, and updated > my meanwhile extensive netboot document. I updated this into a PDF, covering > many, many details (now ~50 pages). Wanted to give something back to the > community. The PDF is currently located here: > http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf > Thanks, interesting document. Isn't better to use rewrite/file remapping instead of hacking pxeboot? If an i386 machine would request /etc/boot.conf via tftp you could rewrite it to (based on fact you know that that machine is i386 - during provisioning) /etc/i386/boot.conf. For the client I suppose it would still think it gets /etc/boot.conf. j.
Re: Migrate Mailserver from sendmail/Curier/LDAP to OpenSMTP/Dovecot/LDAP
Hi Markus, On 2017-01-27 Fri 12:24 PM |, Markus Rosjat wrote: > I dont like the idea of one single virtual user handling all the traffic to > the maildirectories. Me neither. Here, all users have proper shell accounts & SSH access, for mutt, etc. Stop Dovecot, unmount /var/mail (where mail stays), dump(1). No SQL "spool". There is no LDAP nor SQL, it is all simple stuff;- *) The MTA delivers via LMTP to Dovecot - which sieves mail. (Thunderbird & other mail clients have a sieve plugin.) *) Users IMAP/POP/SMTP auth via an individual passwd file, which they change via a script (which calls pwqcheck(1) in ports). /etc/passwd is _NOT_ used for mail authentication. (MTA SMTP submission port auth relaying is validated by Dovecot too.) No webmail; everybody is expected to have their own IMAP/POP/SSH device.$ doveconf -n # 2.2.24 (a82c823): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.14 (099a97c) # OS: OpenBSD 6.0 i386 ffs auth_mechanisms = cram-md5 apop auth_username_format = %Ln first_valid_uid = 1000 listen = * mail_location = maildir:/var/mail/%u managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext mbox_write_locks = fcntl mmap_disable = yes namespace inbox { inbox = yes location = mailbox Archive { auto = subscribe special_use = \Archive } mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Junk { auto = subscribe special_use = \Junk } mailbox Sent { auto = subscribe special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Templates { auto = subscribe } mailbox Trash { auto = subscribe special_use = \Trash } prefix = separator = / type = private } passdb { args = /var/dovecot/auth.d/%u/passwd.CRAM-MD5 driver = passwd-file } passdb { args = /var/dovecot/auth.d/%u/passwd.CLEAR driver = passwd-file skip = authenticated } plugin { sieve = file:/var/mail/%u/sieve/;active=active.sieve } protocols = imap pop3 lmtp sieve service auth { unix_listener /var/spool/postfix/private/dovecot-auth { group = _postfix mode = 0660 user = _postfix } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = _postfix mode = 0660 user = _postfix } } service managesieve-login { inet_listener sieve { port = 4190 } } ssl = no userdb { args = blocking=no driver = passwd result_failure = return-fail } protocol lmtp { mail_plugins = " sieve" postmaster_address = postmaster } In the future I hope to be able to deploy OpenSMTPd, when the filtering & other work has stabilised. Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
tftpd rewrite example
Hi, has anybody written some tftpd rewrite daemon/script which could be shared as example? j.
mprotect W^X violation and JDK
Every time I start or stop a java program, I see something similar to the following logged in /var/log/messages Jan 28 02:15:46 wtestvm3 /bsd: java(37284): mprotect W^X violation My /usr/local partition is mounted with wxallowed. Are these warnings/errors expected? My limited understanding of the wxallowed flag was that it mean that programs were allowed to commit W^X violations. Below are some details about the environment I am running java in. It is openbsd 6.0 running inside virtualbox on a windows pc. >Environment: System : OpenBSD 6.0 Details : OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 >How-To-Repeat: do fresh openbsd install verify that your /usr/local lies within a wxallowed partition set your PKG_PATH run pkg_add jdk (select jdk 8 from the menu) add /usr/local/jdk-1.8.0 to your path create a "hello world" java program(see example below). public class Test { public static void main(String[] args) { System.out.println("hello world"); } } run javac Test.java in one terminal window, tail -100f /var/log/messages in another run java Test observe the W^X violation being logged >Fix: programs seem like they work properly, however I wanted to check whether this logging is the expected behavior or no as it is a bit worrysome. dmesg: OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1056899072 (1007MB) avail mem = 1020502016 (973MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries) bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006 bios0: innotek GmbH VirtualBox acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.85 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: CPU supports MTRRs but not enabled by BIOS cpu0: apic clock running at 999MHz cpu0: mwait min=64, max=64 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) "PNP0303" at acpi0 not configured "PNP0F03" at acpi0 not configured acpibat0 at acpi0: BAT0 model "1" serial 0 type VBOX oem "innotek" acpiac0 at acpi0: AC unit offline acpivideo0 at acpi0: GFX0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0:ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 1 int 19, address 08:00:27:55:21:4c "InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not configured auich0 at pci0 dev 5 function 0 "Intel 82801AA AC97" rev 0x01: apic 1 int 21, ICH AC97 ac97: codec id 0x83847600 (SigmaTel STAC9700) audio0 at auich0 ohci0 at pci0 dev 6 function 0 "Apple Intrepid USB" rev 0x00: apic 1 int 22, version 1.0 piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 1 int 23 iic0 at piixpm0 em1 at pci0 dev 8 function 0 "Intel 82540EM" rev 0x02: apic 1 int 16, address 08:00:27:63:6d:5f isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 usb0 at ohci0: USB revision 1.0 uhub0 at usb0 "Apple OHCI root hub" rev 1.00/1.00 addr 1 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on wd0a (24555dc8f83a2ce7.a) swap on wd0b dump on wd0b usbdevs:
Re: mprotect W^X violation and JDK
Java doesn't work with write xor execute and this is the kernels way of letting you know. Java still runs because the partition is mounted with wxallowed, but the kernel still prints the error to let you know that Java isn't respecting a security feature.
Re: mprotect W^X violation and JDK
On 2017-01-28, Currell Berrywrote: > Every time I start or stop a java program, I see something similar to > the following logged in /var/log/messages > > Jan 28 02:15:46 wtestvm3 /bsd: java(37284): mprotect W^X violation > > My /usr/local partition is mounted with wxallowed. Are these > warnings/errors expected? My limited understanding of the wxallowed > flag was that it mean that programs were allowed to commit W^X > violations. Expected in 6.0, it will go away in 6.1/-current.
netbooting OpenBSD (6.0) i386 and amd64 clients from one server
I am netbooting many systems, and last recently stepped on the issue, that I had an amd64 and an i386 client in the same network. I wanted to boot them into a "full" OpenBSD (not ramdisk kernel). That is not possible with the default installation, cause pxeboot can not distinguish between these Intel/AMD systems. DHCP server can distinguish by MAC address, but then when pxeboot is loaded, the kernel is per default "bsd". This must clash either with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry. So I went through some older mailing list entries, adapted them, and updated my meanwhile extensive netboot document. I updated this into a PDF, covering many, many details (now ~50 pages). Wanted to give something back to the community. The PDF is currently located here: http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf
Re: Skype issue with office behind PF
On 2017-01-27, lilit-aibolitwrote: > Hi list, I have an office behind NAT with PF. > There are mostly Win7 workstations with > different Skype versions but mostly with > 7.3x or the latest versions. > Two days ago any skype call started to drop > after few seconds without any voice from > opposite side. > I got skype support which remotely looked > at affected machines and after a while he > resolved this by installing 7.15 version. > > However there is no trouble with skype > by using it from other places of from personal > hotspot 3G connection so I suspect here > maybe be an issue with PF which somehow > doesn't met to how last skype versions work. > Any thoughts about that? > > They might be sending packets which are passed by some NAT devices but not by PF. Use "log" on your block rules and watch pflog0, see if something is being blocked. tcpdump -n -e -i pflog0
Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server
On Sat, Jan 28, 2017 at 06:41:34PM +0100, Sven-Volker Nowarra wrote: > > Isn't better to use rewrite/file remapping instead of hacking pxeboot? > > If an i386 machine would request /etc/boot.conf via tftp you could rewrite > > it to (based on fact you know that that machine is i386 - during > > provisioning) > > /etc/i386/boot.conf. For the client I suppose it would still think it gets > > /etc/boot.conf. > If this works, I could get rid of recompiling pxeboot everytime a > new release comes out. Well, sometimes pxeboot also supports "older" > OpenBSDs, but that is another topic. > > I understand, the tftp server has a "root dir" for the client > specified. In the dhcpd.conf I declare per client a MAC address and > its filename (usually "/pxeboot"). The i386 pxeboot manual says: > "pxeboot boot program will look for an /etc/boot.conf configuration > file on the TFTP server." I didn't find a reference to a different > sub structure... > > Anyway, I tried a structure like you proposed, but pxeboot didn't > find the boot.conf, and didn't even show the echo lines from this > file (so useless to play with bsd location). This was my setup: > > location of boot.conf: > /tftpboot/etc/i386/boot.conf > > $ cat /tftpboot/etc/i386/boot.conf > echo ### > echo ### hello from tftpd@192.168.88.12, with /etc/i386/boot.conf ### > echo ### > boot bsd.rd > > $ cat /etc/dhcpd.conf | grep filename >filename "/pxeboot"; > > I also tried to play with the dhcpd.conf settings, by using a different > subdir for pxeboot, but I didn't get the system to find "his" boot.conf in > the i386 directory. It seems you missed part about tftpd rewrite/file remapping. The client will still request /etc/boot.conf but you fake it via rewrite script. man tftpd -r socket Issue filename rewrite requests to the specified UNIX domain socket. tftpd will write lines in the format "IP OP filename", terminated by a newline, where IP is the client's IP address, and OP is one of "read" or "write". tftpd expects replies in the format "filename" terminated by a newline. All rewrite requests from the daemon must be answered (even if it is with the original filename) before the TFTP request will continue. By default tftpd does not use filename rewriting. j.
Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server
> Am 28.01.2017 um 14:56 schrieb Jiri B: > > On Sat, Jan 28, 2017 at 12:17:40AM +0100, Sven-Volker Nowarra wrote: >> I am netbooting many systems, and last recently stepped on the issue, that I >> had an amd64 and an i386 client in the same network. I wanted to boot them >> into a "full" OpenBSD (not ramdisk kernel). That is not possible with the >> default installation, cause pxeboot can not distinguish between these >> Intel/AMD systems. DHCP server can distinguish by MAC address, but then when >> pxeboot is loaded, the kernel is per default "bsd". This must clash either >> with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry. >> So I went through some older mailing list entries, adapted them, and updated >> my meanwhile extensive netboot document. I updated this into a PDF, covering >> many, many details (now ~50 pages). Wanted to give something back to the >> community. The PDF is currently located here: >> http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf >> > > Thanks, interesting document. > > Isn't better to use rewrite/file remapping instead of hacking pxeboot? > If an i386 machine would request /etc/boot.conf via tftp you could rewrite > it to (based on fact you know that that machine is i386 - during provisioning) > /etc/i386/boot.conf. For the client I suppose it would still think it gets > /etc/boot.conf. > > j. If this works, I could get rid of recompiling pxeboot everytime a new release comes out. Well, sometimes pxeboot also supports "older" OpenBSDs, but that is another topic. I understand, the tftp server has a "root dir" for the client specified. In the dhcpd.conf I declare per client a MAC address and its filename (usually "/pxeboot"). The i386 pxeboot manual says: "pxeboot boot program will look for an /etc/boot.conf configuration file on the TFTP server." I didn't find a reference to a different sub structure... Anyway, I tried a structure like you proposed, but pxeboot didn't find the boot.conf, and didn't even show the echo lines from this file (so useless to play with bsd location). This was my setup: location of boot.conf: /tftpboot/etc/i386/boot.conf $ cat /tftpboot/etc/i386/boot.conf echo ### echo ### hello from tftpd@192.168.88.12, with /etc/i386/boot.conf ### echo ### boot bsd.rd $ cat /etc/dhcpd.conf | grep filename filename "/pxeboot"; I also tried to play with the dhcpd.conf settings, by using a different subdir for pxeboot, but I didn't get the system to find "his" boot.conf in the i386 directory.
Re: mprotect W^X violation and JDK
On Jan 28, 2017 2:02 PM, Christian Schultewrote: Am 01/28/17 um 10:04 schrieb Alex McWhirter: > Java doesn't work with write xor execute and this is the kernels way of > letting you know. Java still runs because the partition is mounted with > wxallowed, but the kernel still prints the error to let you know that > Java isn't respecting a security feature. > What should the VM do instead? It allocates memory, JIT compiles bytecode to machinecode and then executes that machinecode. Should it mprotect the memory after generating the machinecode? It would still execute code from memory it could write to. Regards, -- Christian Java's memory strategy would have to change. IIRC, java basically allocates one big chunk of memory and the JVM uses it as a single heap. The most simple way I can think of would be to enable w^x support in the java language itself and allow each java application to define whether or not they use it and how they use it. Another is to make the JVM smart enough to know what needs write and what needs execute, but not both. But that's up to Oracle im afraid, and im not certain of how much they really care. Most likely it will be done when every other OS on the planet starts enforcing w^x and Oracle kinda has to do it.
Re: mprotect W^X violation and JDK
Ok, thank you. That resolves my concern that something was broken. Alex McWhirter writes: > Java doesn't work with write xor execute and this is the kernels way > of letting you know. Java still runs because the partition is mounted > with wxallowed, but the kernel still prints the error to let you know > that Java isn't respecting a security feature.
Re: mprotect W^X violation and JDK
Am 01/28/17 um 10:04 schrieb Alex McWhirter: > Java doesn't work with write xor execute and this is the kernels way of > letting you know. Java still runs because the partition is mounted with > wxallowed, but the kernel still prints the error to let you know that > Java isn't respecting a security feature. > What should the VM do instead? It allocates memory, JIT compiles bytecode to machinecode and then executes that machinecode. Should it mprotect the memory after generating the machinecode? It would still execute code from memory it could write to. Regards, -- Christian
Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server
On Sun, Jan 29, 2017 at 01:17:48AM +0200, li...@wrant.com wrote: > Sample excerpts from host specific DHCP server config, for i386 and amd64: > > next-server 10.0.0.32; > filename "auto_upgrade"; > > next-server 10.0.0.64; > filename "auto_upgrade"; > > Quoting autoinstall(8) for netbooting: http://man.openbsd.org/autoinstall > > On architectures where the filename statement is used to provide the > name of the file to netboot it is necessary to create symbolic links > called auto_install and auto_upgrade that point to the expected boot > program and to change the value of the filename statement in the > dhcpd.conf(5) file to be auto_install or auto_upgrade. > > # ln -s /tftpboot/i386/pxeboot /tftpboot/i386/auto_upgrade > # ln -s /tftpboot/amd64/pxeboot /tftpboot/amd64/auto_upgrade > > Needless to say, you need to populate the /tftpboot/{i386,amd64} locations > with the system installation packages from the local mirror / compilation. > > It is also quite easy to combine both the DHCP server and two instances of > tftpd(8), started independently listening on 2 IP address aliases, serving > pxeboot(8) respectively for i386 and amd64 systems stand alone each other. > > See rcctl(8) to run a second copy of a daemon http://man.openbsd.org/rcctl > > The recommended way to run a second copy of a given daemon for a > different purpose is to create a symbolic link to its rc.d(8) control > script: > > # ln -s /etc/rc.d/tftpd /etc/rc.d/tftpd2 > # rcctl set tftpd status on > # rcctl set tftpd2 status on > # rcctl set tftpd flags -4 -l 10.0.0.32 /tftpboot/i386 > # rcctl set tftpd2 flags -4 -l 10.0.0.64 /tftpboot/amd64 > # rcctl start tftpd > # rcctl start tftpd2 Nice trick to define multiple tftp servers for each x86 architecture :) Thanks! j.
Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server
Sat, 28 Jan 2017 00:17:40 +0100 Sven-Volker Nowarra> I am netbooting many systems, and last recently stepped on the issue, that I > had an amd64 and an i386 client in the same network. I wanted to boot them > into a "full" OpenBSD (not ramdisk kernel). That is not possible with the > default installation, cause pxeboot can not distinguish between these > Intel/AMD systems. Hi Sven-Volker, Jiri, I am also booting over network many systems in the same network, including i386 and amd64 systems. It is in fact quite possible to achieve this with the default installation, with the help of the DHCP next-server statement. > DHCP server can distinguish by MAC address, but then when > pxeboot is loaded, the kernel is per default "bsd". This must clash either > with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry. Quoting dhcpd.conf(5), please see here: http://man.openbsd.org/dhcpd.conf next-server server-name; The next-server statement is used to specify the host address of the server from which the initial boot file (specified in the filename statement) is to be loaded. server-name should be a numeric IP address or a domain name. If no next-server parameter applies to a given client, the DHCP server's IP address is used. Sample excerpts from host specific DHCP server config, for i386 and amd64: next-server 10.0.0.32; filename "auto_upgrade"; next-server 10.0.0.64; filename "auto_upgrade"; Quoting autoinstall(8) for netbooting: http://man.openbsd.org/autoinstall On architectures where the filename statement is used to provide the name of the file to netboot it is necessary to create symbolic links called auto_install and auto_upgrade that point to the expected boot program and to change the value of the filename statement in the dhcpd.conf(5) file to be auto_install or auto_upgrade. # ln -s /tftpboot/i386/pxeboot /tftpboot/i386/auto_upgrade # ln -s /tftpboot/amd64/pxeboot /tftpboot/amd64/auto_upgrade Needless to say, you need to populate the /tftpboot/{i386,amd64} locations with the system installation packages from the local mirror / compilation. It is also quite easy to combine both the DHCP server and two instances of tftpd(8), started independently listening on 2 IP address aliases, serving pxeboot(8) respectively for i386 and amd64 systems stand alone each other. See rcctl(8) to run a second copy of a daemon http://man.openbsd.org/rcctl The recommended way to run a second copy of a given daemon for a different purpose is to create a symbolic link to its rc.d(8) control script: # ln -s /etc/rc.d/tftpd /etc/rc.d/tftpd2 # rcctl set tftpd status on # rcctl set tftpd2 status on # rcctl set tftpd flags -4 -l 10.0.0.32 /tftpboot/i386 # rcctl set tftpd2 flags -4 -l 10.0.0.64 /tftpboot/amd64 # rcctl start tftpd # rcctl start tftpd2 For the list of the flags for tftpd(8), see: http://man.openbsd.org/tftpd When you need to upgrade a system, link the boot.conf to a file with this: boot tftp:/bsd.rd When done, link it back the boot.conf file to a file that has the generic: boot hd0a:/bsd This way you always net boot the system, then make it auto_upgrade, or run the already installed system from the first hard disk where the system is. Of course you may want to adjust these as per your environment and set up. I would be glad if you could share an idea how to toggle boot.conf better. I would be further much more grateful if there is in the near future a way to provide automatic response file for local install for the serve system. > So I went through some older mailing list entries, adapted them, and updated > my meanwhile extensive netboot document. I updated this into a PDF, covering > many, many details (now ~50 pages). Wanted to give something back to the > community. The PDF is currently located here: > http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf Nice read, thank you. Hopefully you could further extend it, for multiple concurrent network boot environments for simpler setup w/o custom patches. Kind regards, Anton
Kernel panic after upgrade -CURRENT
Hi, A very strange issue... After the previous update of CURRENT I started to have issues with ftpproxy not loading some directories, an example being shrubbery.net rancid directory. Today I attempted an upgrade to see if that might kick things into gear and now my OBSD machine won't boot and Kernel panics upon starting network services. Here is an image of the hang: https://www.dropbox.com/s/74e5mjg7sn8jrck/20170129_025823.jpg?dl=0 As instructed by the terminal I read through: https://www.openbsd.org/ddb.html However, I am unable to input anything on the keyboard post hang?? Basically my keyboard becomes unresponsive and any key pressed does nothing. I am able to boot into Single User mode without panic but that's about it. What can I do to resolve this? Or what more info could I provide that is useful, considering that I am unable to run any ddb commands?? Thanks. Kaya Sent from my Samsung Galaxy smartphone.
Re: Kernel panic after upgrade -CURRENT
On 29.1.2017. 4:13, kayasaman wrote: > Hi, > A very strange issue... > After the previous update of CURRENT I started to have issues with ftpproxy > not loading some directories, an example being shrubbery.net rancid directory. > Today I attempted an upgrade to see if that might kick things into gear and > now my OBSD machine won't boot and Kernel panics upon starting network > services. > Here is an image of the hang: > https://www.dropbox.com/s/74e5mjg7sn8jrck/20170129_025823.jpg?dl=0 > As instructed by the terminal I read through: > https://www.openbsd.org/ddb.html > However, I am unable to input anything on the keyboard post hang?? Basically > my keyboard becomes unresponsive and any key pressed does nothing. > I am able to boot into Single User mode without panic but that's about it. > What can I do to resolve this? Or what more info could I provide that is > useful, considering that I am unable to run any ddb commands?? > Thanks. > Kaya > > > Sent from my Samsung Galaxy smartphone. > Hi, send this report to b...@openbsd.org. Please see this mail thread https://www.mail-archive.com/tech@openbsd.org/msg36980.html