Re: openbsd : mailx users : how-to include previous mail text (only)?
On Sun, Oct 26, 2014 at 11:27:26PM EDT, Mayuresh Kathe wrote: hello, i have been trying to fix the problem of mailx including the entire header-set when issuing a tilde + m in a reply to include only the previous emails body text (content). one of the docs suggested using tilde + p, but dang, it didn't work for me during tests executed just now. ~f, or better yet ~m and set identprefix to . You may also need to set ignore. if anyone here uses mailx under openbsd regularly, can they please advise? thanks. Regularly? No. Occasionally? Yes, when Mutt isn't available ;^) BTW, it's all in the man page. Regards, Raf
Re: Fan control not working as intended
Same problem with x220 bios 1.39 and with -current sync'ed on 26th Oct. With apmd -C, FAN runs around 3400-3500 even if the machine is not attended and nothing runs in the background (load average ~0.06-0.09) Cheers, On Tue, Oct 21, 2014 at 6:52 PM, Julian Andrej j.and...@gmx.de wrote: I'm experiencing the same issues with an x220 and the latest bios (1.39). Another x220 with an older bios (1.20) works fine. The fan runs at ~2000rpm.
Dumb (non-RAID) HBA to use with SAS tape drive
Hi misc, I'm setting up a new backup server, and I'm looking at using a SAS connected tape drive. Now, last time I set up a tape station UWSCSI was in high fashion, so it was a while ago... :-) I've tried to research how to best connect the (not yet purchased) drive to an OpenBSD box, but come up blank so far. I don't need a full SAS RAID controller (and I'm not sure they would accept tape drives), so I'm looking at simple dumb HBA:s. (And I'm assuming normal dumb SATA interfaces aren't up to the task.) Would something like the LSI SAS 9211-4i work, and would the st(4) driver pick up a tape drive attached to one? http://www.pc-pitstop.com/sas_hba/sas9211-4i.asp Or does anyone have a better (read: cheaper) suggestion, perferrably something that is field-tested and known to work? :-) Any pointers are much appreciated and I'm open to any idea except use hard drives, they're cheap. :-) No, I need a tape drive for this. Thanks, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: panic: ffs_blkfree: bad size
Philip Guenther, 26 Oct 2014 14:23: From the backtrace, either a bogus block number ended up in a single-indirect block, or the filesystem superblock was corrupted. Or something is scrambling memory. I think you're correct that this filesystem has been damaged by whatever memory corruption you've been experiencing beyond the point fsck handles. Time to backup, newfs, reinstall and restore. And if you're still seeing memory corruptions then maybe roll back to a version that didn't experience those and see if you can bisect to whatever change caused the problem. done and done, reinstalled. for the time being, can i minimize panic related fs errors by mounting using `sync` flag? -f -- i could prove god statistically. -- george gallup
Re: crypto softraid and keydisk on same harddrive
On Sun, Oct 26, 2014 at 09:19:25PM +0100, Patrik Lundin wrote: Hello, I have a usecase for full disk encryption using softraid where the keydisk is placed on the same harddrive as the encrypted partition. This is not for protecting data on the drive in case it gets stolen, but rather to allow for a quick way of making the data unrecoverable (by destroying the keydisk and rebooting). I am not sure this is even supposed to work, but I have now been trying to make this work for a few hours and am getting pretty strange results. I am currently testing this on a virtual machine which when booted into the installer has a single physical drive: wd0. The way i have been going about this is to start the installer, directly drop to a shell and then do the following: # fdisk -iy wd0 # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. I'd use wd0d instead of wd0a, because 'a' is usually expected to contain a root partition, not a softraid volume. That has nothing to do with the problem at hand though. # bioctl -c C -l /dev/wd0a -k /dev/wd0d softraid0 After this sd0 is created, and i exit back to the installer where i select install and answer all the questions as usual. When it asks for a drive I give it sd0, and use the automatic partition layout inside sd0. Everything looks good at this point, but when rebooting the bootloader stops with the following message: === Using drive 0, partition 3. Loading. ERR M === This error means biosboot(8) can't find the boot(8) program. When booting from softraid, the boot program is stored at a particular offset in the softraid meta data area, and installboot(8) patches that offset into biosboot(8) before copying biosboot(8) to the MBR. Apparently, biosboot(8) has the wrong offset in your case. Your report lacks some information: - architecture (i386 / amd64 / ...) - full output of 'disklabel wd0' to show exactly how you configured partitions - output of running installboot with the -v option on the softraid volume: installboot -v sd0 If I boot back into the the installer at this point sd0 appears automatically, so even while the bootloader does not like what it finds, the softraid crypto device is able to assemble itself like it is supposed to. This is where it gets really funky. I _have_ been able to get it to work using the following schema: #1. Install the system with only wd0b (swap) and wd0a (RAID) using a passphrase. #2. Reinstall the system and modify the disklabel to look like: wd0b (swap), wd0d (RAID, 1M), wd0a. (Like my original plan). When I do this the system manages to boot without a passphrase, using the encrypted drive. I suspect there is a problem in installboot(8) in case the keydisk is on the same disk as the crypto volume. The boot(8) program which is the first program to interpret softraid meta data doesn't even get to run in your case. It feels to me like the key is that in the above order, the keydisk (wd0d) will align to the where wd0a with the passphrase was originally. As if there are some remains that makes it possible for the bootloader to locate it or something (that is not overwritten when it is used as the target for the -k argument. Any input on this would be greatly appreaciated! Regards, Patrik Lundin
Re: Wireless PCIe (Host AP mode) recommendations
Hi Gordon and list I am using Rt61 for almost two years as a 'ap' mode without any problem. On 27 Oct 2014 01:13, Gordon Turner tur...@ftn.net wrote: Hey List, I am planning a new router / firewall / Wifi AP based on the Supermicro SYS-5015A-EHF-D525 (http://www.newegg.ca/Product/Product.aspx?Item= N82E16816101364) and was hoping that I could get some feedback on PCIe wifi cards. After going over the wireless FAQ and then doing some research, I was planning to use either one of these cards: Rosewill RNX-N150PCe (http://www.newegg.ca/Product/Product.aspx?Item= N82E16833166047) - Up to 150Mbps - Atheros AR9285 - Supported by athn http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/athn.4 Rosewill RNX-G300LX (http://www.newegg.ca/Product/Product.aspx?Item= N82E16833166021) - Up to 54Mbps - Chipset RaLink RT2561/RT61 - Supported by ral http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/ man4/ral.4?query=ralsec=4 Am I correct that these are both supported by OpenBSD? Has anyone used these in Host AP mode? Does anyone have other PCIe wifi cards that support Host AP mode they can recommend? Thanks! Gord. -- http://gordonturner.ca
Re: mutt and gmail
without full debugging it is not possible to know which component is failing in the chain. it's just that there is a lot of ongoing work on SSL in openbsd, so i thought i might bring it up here as the error message specifically mentioned SSL. This is not an openbsd issue at all. I suffer through using mutt against gmail directly; I guess there is a load balancer up front and backend servers are continually rebooted or taken in and out of service; the client has to reconnect.
Re: pkg_add -u and unneeded updates
On Fri 24/10 11:29, Ingo Schwarze wrote: Hi Ingo, Almost certainly not unneeded; Marc Espie@ has spent a lot of effort on getting that right. At least, you don't show any evidence for that claim, or for any bug in this area. My bad; I should have said maybe unneeded?... [...] packages(7): The full version (package name and dependency names) is known as the `update signature', and can be queried with pkg_info -S, for packages, or make print-update-signature for ports. [...] So, packages are automatically updated when new versions are available compiled again newer libraries or newer dependencies, even if the Makefile of the package itself (and hence its own version number) did not change. That prevents .libs-* packages from needlessly accumulating on your system. Got it; the concept of package signature was in fact obscure to me. Thanks a lot for your precious clarifications. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: pkg_add -u and unneeded updates
Hi Marc, On Fri 24/10 14:58, Marc Espie wrote: [...] Look, either you use it as as simple user, and then you trust the tool. Or you want to really understand what's going on and you have to dig deeper. What pkg_add shows you *by default* is the simple story. Try pkg_add -v for more details. You'll figure it out. You're definitely right; I'll try to dig a bit deeper next time. Sorry for the noise. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
5.6 on Axiomtek NA570: BIOS freeze on reboot
Hi folks, I've got 2 NA570 (a network appliance from Axiomtek). Problem: OpenBSD 5.6 installs fine, but this seems to poison the installation target disk somehow. It doesn't boot. :-( I have to overwrite the MBR just to make the BIOS work again. Or I have to use a 4GB CF card for booting. Surely not OpenBSD's fault; the BIOS should work no matter what. But I wonder what the is going on? Anybody got an idea? Have you seen something similar? I found a similar problem on http://www.tomshardware.co.uk/answers/id-1779492/computer-freezes-boot-sequence.html indicating that the BIOS might not like the hardware, but in my case there is no bleeding edge hardware included. Esp. the disk is a usual 500 GByte 2,5 WD drive. Linux installs and runs fine. Every helpful comment is highly appreciated Harri OpenBSD 5.6-current (GENERIC.MP) #452: Mon Oct 20 01:29:08 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8473657344 (8081MB) avail mem = 8239382528 (7857MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9880 (78 entries) bios0: vendor American Megatrends Inc. version 4.6.5 date 02/17/2014 bios0: INTEL Corporation DENLOW_WS acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT ASF! SPCR DMAR EINJ ERST HEST BERT acpi0: wakeup devices PS2K(S3) PS2M(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.67 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT ,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSB ASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.14 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT ,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSB ASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT ,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSB ASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT ,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSB ASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 4 (RP04) acpiprt5 at acpi0: bus 5 (RP05) acpiprt6 at acpi0: bus 6 (RP06) acpiprt7 at acpi0: bus 7 (RP07) acpiprt8 at acpi0: bus 8 (RP08) acpiprt9 at acpi0: bus -1 (P0P2) acpiprt10 at acpi0: bus -1 (P0PA) acpiprt11 at acpi0: bus -1 (P0PB) acpiprt12 at acpi0: bus -1 (PEG0) acpiprt13 at acpi0: bus -1 (PEG1) acpiprt14 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpicpu2 at acpi0: PSS acpicpu3 at acpi0: PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC
Re: Wireless PCIe (Host AP mode) recommendations
Thanks, Do you know what manufacture / model you have? On 2014-10-27 09:16, jinhitmanBarracuda wrote: Hi Gordon and list I am using Rt61 for almost two years as a 'ap' mode without any problem. On 27 Oct 2014 01:13, Gordon Turner tur...@ftn.net wrote: Hey List, I am planning a new router / firewall / Wifi AP based on the Supermicro SYS-5015A-EHF-D525 (http://www.newegg.ca/Product/Product.aspx?Item=N82E16816101364 [1]) and was hoping that I could get some feedback on PCIe wifi cards. After going over the wireless FAQ and then doing some research, I was planning to use either one of these cards: Rosewill RNX-N150PCe (http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166047 [2]) - Up to 150Mbps - Atheros AR9285 - Supported by athn http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/athn.4 [3] Rosewill RNX-G300LX (http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166021 [4]) - Up to 54Mbps - Chipset RaLink RT2561/RT61 - Supported by ral http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ral.4?query=ralsec=4 [5] Am I correct that these are both supported by OpenBSD? Has anyone used these in Host AP mode? Does anyone have other PCIe wifi cards that support Host AP mode they can recommend? Thanks! Gord. -- http://gordonturner.ca [6] Links: -- [1] http://www.newegg.ca/Product/Product.aspx?Item=N82E16816101364 [2] http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166047 [3] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/athn.4 [4] http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166021 [5] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ral.4?query=ralamp;sec=4 [6] http://gordonturner.ca -- http://gordonturner.ca
Upgrade dry run - restore backup from physical to virtualbox VM?
Hi, I have an older system on physical hardware that needs upgrading. I've been procrastinating because it's the type of thing that needs to be done from start to finish, and it's rather out of date (OpenBSD 5.2-current) so I know there will be all sorts of surprises. I have Virtualbox (2.2.4) running on my Windows PC and able to boot/install OpenBSD in it. I had (what I think is) a great thought today that maybe I could (somehow) restore a backup from my physical hardware into the Virtualbox VM and do a test upgrade there, figuring things out bit by bit with no pressure of my system being down. Once I had the upgrade process figured out, I'd then be better prepared to do it to my physical system. I have never done a dump/restore of a complete system before. I do know that on my physical system, the hard disk is sd0 whereas the VM, it's wd0 (with an OpenBSD 5.5 install... yes, I know 5.6 is imminent). Not a big deal to tweak /etc/fstab though. I'm reasonably comfortable with dump/restore, but not to completely clone a system. How can I do a dump of the root filesystem over top of a running system (in the VM)? Does it have to be in single user mode? Are there any other things that are going to need to be tweaked other than /etc/fstab? Am I going to need to run installboot or some other such utility to get it to boot correctly after a restore? Any thoughts of this idea in general? Thanks, Steve Williams
Re: crypto softraid and keydisk on same harddrive
Thank you Stefan for taking a look, see comments inline: On Mon, Oct 27, 2014 at 12:32:30PM +0100, Stefan Sperling wrote: On Sun, Oct 26, 2014 at 09:19:25PM +0100, Patrik Lundin wrote: # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. I'd use wd0d instead of wd0a, because 'a' is usually expected to contain a root partition, not a softraid volume. That has nothing to do with the problem at hand though. Given that wd0d is used for the keydisk, do you mean i should use wd0e for the remainder of the drive instead of 'a'? Would this also mean I should skip creating a sd0a altogether? === Using drive 0, partition 3. Loading. ERR M === This error means biosboot(8) can't find the boot(8) program. When booting from softraid, the boot program is stored at a particular offset in the softraid meta data area, and installboot(8) patches that offset into biosboot(8) before copying biosboot(8) to the MBR. Apparently, biosboot(8) has the wrong offset in your case. Hmm, interesting, thanks for the description! Your report lacks some information: - architecture (i386 / amd64 / ...) I am using amd64. - full output of 'disklabel wd0' to show exactly how you configured partitions I stuck to my original layout for consistency (this has been written down by hand): === # disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: VBOX HARDDISK duid: 175d4587e45a04a5 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 3916 total sectors: 62914560 boundstart: 64 boundend: 62910540 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a:586854454225095RAID b: 4208966 64swap c:62914560 0 unused d: 160654209030RAID === So wd0a is 28GB, wd0b is 2G, and wd0d is 7.8M. - output of running installboot with the -v option on the softraid volume: installboot -v sd0 Since I am not able to boot on the device i have to run installboot as the last step in the installer. For this i need to add -r /mnt (of course the following is also copied by hand): === # installbook -v -r /mnt sd0 Using /mnt as root installing bootstrap on /dev/rsd0c using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot sd0: softraid volume with 2 disk(s) sd0: installing boot loader on softraid volume /mnt/usr/mdec/boot is 5 blocks x 16384 bytes wd0a: installing boot blocks on /dev/rwd0c, part offset 4225175 master boot record (MBR) at sector 0 partition 3: type 0xA6 offset 64 size 62910476 /mnt/usr/mdec/biosboot will be written at sector 64 wd0d: installing boot blocks on /dev/rwd0c, part offset 4209110 master boot record (MBR) at sector 0 partition 3: type 0xA6 offset 64 size 62910476 /mnt/usr/mdec/biosboot will be written at sector 64 === When I do this the system manages to boot without a passphrase, using the encrypted drive. I suspect there is a problem in installboot(8) in case the keydisk is on the same disk as the crypto volume. The boot(8) program which is the first program to interpret softraid meta data doesn't even get to run in your case. I see, I hope the output I supplied above can give you some insight! Regards, Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Mon, Oct 27, 2014 at 07:14:10PM +0100, Patrik Lundin wrote: Given that wd0d is used for the keydisk, do you mean i should use wd0e for the remainder of the drive instead of 'a'? Would this also mean I should skip creating a sd0a altogether? Of course i meant Would this also mean I should skip creating a wd0a altogether? Regards, Patrik Lundin
KITCHEN_SINK
Reading strftime.c I came across this: #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ pt = _add(kitchen sink, pt, ptlim); continue; #endif /* defined KITCHEN_SINK */ Is there a back story to that? Jan
Re: 5.6 arrived
Hi folks, How is the current install56.iso in pub/OpenBSD/snapshots/amd64/ on the mirrors related to the shipped 5.6 CDs? Regards Harri
Re: 5.6 arrived
How is the current install56.iso in pub/OpenBSD/snapshots/amd64/ on the mirrors related to the shipped 5.6 CDs? From the ftp site: -rw-r--r-- 1 root wheel 58741116 Oct 27 01:42 base56.tgz That is around 11 hours ago. Probably a bit newer than what people will find on their CDs.
Re: 5.6 arrived
On 10/27/14 19:44, Theo de Raadt wrote: How is the current install56.iso in pub/OpenBSD/snapshots/amd64/ on the mirrors related to the shipped 5.6 CDs? From the ftp site: -rw-r--r-- 1 root wheel 58741116 Oct 27 01:42 base56.tgz That is around 11 hours ago. Probably a bit newer than what people will find on their CDs. Sure, but is this still 5.6 (some kind of stable-5.6 iso)? Hopefully there are just minor differences? Regards Harri
Re: 5.6 arrived
On 10/27/14 19:44, Theo de Raadt wrote: How is the current install56.iso in pub/OpenBSD/snapshots/amd64/ on the mirrors related to the shipped 5.6 CDs? From the ftp site: -rw-r--r-- 1 root wheel 58741116 Oct 27 01:42 base56.tgz That is around 11 hours ago. Probably a bit newer than what people will find on their CDs. Sure, but is this still 5.6 (some kind of stable-5.6 iso)? Hopefully there are just minor differences? Major differences. The snapshot code is -current. That includes commits from only a few hours earlier. From time to time, it also contains changes which are not yet commited. This is all described in the FAQ. Furthermore, there are no -stable builds made available. - we do not have the machines to do such stable builds; - we do not have people who want to run that operation on an on-going basis; - and since OpenBSD is essentially a 'software research group' of volunteers developers, there is no clear way to push anyone towards doing this. -stable builds might be what some people want, but they have never stepped up to handle it from beginning to end. So it doesn't happen.
Re: 5.6 on Axiomtek NA570: BIOS freeze on reboot
On Mon, 27 Oct 2014, Harald Dunkel wrote: Hi folks, I've got 2 NA570 (a network appliance from Axiomtek). Problem: OpenBSD 5.6 installs fine, but this seems to poison the installation target disk somehow. It doesn't boot. :-( I have to overwrite the MBR just to make the BIOS work again. Or I have to use a 4GB CF card for booting. Surely not OpenBSD's fault; the BIOS should work no matter what. But I wonder what the is going on? Anybody got an idea? Have you seen something similar? This quite recent thread comes to mind: http://marc.info/?t=13988430601r=1w=2 Are your symptoms similar? AMI BIOS versions dated close to each other, maybe. Regards, David
Re: Upgrade dry run - restore backup from physical to virtualbox VM?
On 2014-10-27 14:14, Steve Williams wrote: Hi, I have an older system on physical hardware that needs upgrading. I've been procrastinating because it's the type of thing that needs to be done from start to finish, and it's rather out of date (OpenBSD 5.2-current) so I know there will be all sorts of surprises. If you follow the Upgrade Guides, there shouldn't be any. 5.2- 5.3, 5.3 - 5.4, 5.4 - 5.5, and then 5.5 - 5.6 starting on Saturday. :) I have Virtualbox (2.2.4) running on my Windows PC and able to boot/install OpenBSD in it. I had (what I think is) a great thought today that maybe I could (somehow) restore a backup from my physical hardware into the Virtualbox VM and do a test upgrade there, figuring things out bit by bit with no pressure of my system being down. Once I had the upgrade process figured out, I'd then be better prepared to do it to my physical system. Excellent idea I have never done a dump/restore of a complete system before. I do know that on my physical system, the hard disk is sd0 whereas the VM, it's wd0 (with an OpenBSD 5.5 install... yes, I know 5.6 is imminent). Not a big deal to tweak /etc/fstab though. If your production /etc/fstab used DUID rather than device number, you may need to revise the DUID in your virtual machine's disklabel rather than editing fstab(5). Either way. I'm reasonably comfortable with dump/restore, but not to completely clone a system. How can I do a dump of the root filesystem over top of a running system (in the VM)? Does it have to be in single user mode? Are there any other things that are going to need to be tweaked other than /etc/fstab? The following how-to is from memory, and I may have missed a step (or two). Use only with that understanding. If' you get confused, let me know and I'll try to help. You do the restore from the ramdisk kernel, since restore(8) is included. You will need to have a mounted /tmp, since restore requires it. 1. Boot the ramdisk kernel, bsd.rd. 2. Use fdisk(8) to create an MBR on your new system's drive. 3. Use disklabel(8) to create partitions on your new system's drive. You can edit by hand or use -R with a copy of your producition disklabel. You will create a disklabel with a new DUID either way. If your fstab(8) uses DUIDs and you wish to retain them, edit the new drive's DUID to match your production system's. 4. Create, format, and mount a /tmp filesystem. If you don't have a /tmp partition or you use MFS for /tmp, you may find your swap partition b is handy to format and mount as /tmp. Use disklabel(8) to create the partition, use newfs(8) to format, and use mount(8), of course. 5. For each filesystem to restore, format with newfs(8) and mount with mount(8). For speed during restore, you will find -o async or -o async,noatime helpful. 6. Now just cd(1) into each mounted, empty filesystem, and restore(8) with -r. starting with dump level 0 and lather, rinse, repeat with other levels. 7. When each partition has been restored, you may remove the restoresymtable file in the root of each restored filesystem. 8. You must install bootblocks manually. For a 5.2 system, the installboot(8) program is located in /usr/mdec, along with the biosboot(8) first stage bootloader. The /boot second stage bootloader should already be in your root filesystem. example (for 5.2 and wd0's root partition mounted at /mnt): # /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot wd0 9. If you need to adjust /etc/fstab instead of DUIDs, edit before booting.
Re: The Book of PF, 3rd ed: You own the first author signed copy and support OpenBSD!
Michael W. Lucas mwlu...@michaelwlucas.com writes: BAH! You think you can steal my idea for supporting OpenBSD? I don't think it's that easy. MY auction raised $1145. There is no way that BoPF3 can POSSIBLY raise more than that! Consider the gauntlet thrown. :D After two days, the highest bit lists as US $493.88, which means a) that bid was likely entered in a non-USD currency (or somebody has an odd sense of humor, I'm fine with both) b) we're on a pretty good trajectory for beating Mr. Lucas on the fundraising front One again, the auction is at http://www.ebay.com/itm/The-Book-of-PF-3rd-ed-signed-by-the-author-First-Copy-signed-/321563281902? The blog post with the nice pictures is at http://bsdly.blogspot.no/2014/10/the-book-of-pf-3rd-edition-is-here.html And if your bid turns out not to be the successful one, please make the amount of your highest bid a direct donation to OpenBSD instead. Even if you wouldn't consider bidding, go on, head over to http://www.openbsd.org/orders.html or http://www.openbsd.org/donations.html and spend some money! - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Upgrade dry run - restore backup from physical to virtualbox VM?
On 14-10-27 01:14 PM, Steve Williams wrote: Hi, I have an older system on physical hardware that needs upgrading. I've been procrastinating because it's the type of thing that needs to be done from start to finish, and it's rather out of date (OpenBSD 5.2-current) so I know there will be all sorts of surprises. The big one is the time_t flag day, of course... from 5.2 to 5.4 won't be too painful. From 5.4 to 5.5 will be painful unless you're running a pure OpenBSD system with no ports, packages, or self-compiled binaries. Then 5.5 to 5.6 should be pretty normal again. I had (what I think is) a great thought today that maybe I could (somehow) restore a backup from my physical hardware into the Virtualbox VM and do a test upgrade there, figuring things out bit by bit with no pressure of my system being down. Once I had the upgrade process figured out, I'd then be better prepared to do it to my physical system. This works, usually. Be careful to isolate the VM on an disconnected network segment when you first bring it up, lest you have conflicting IP addresses. I have never done a dump/restore of a complete system before. I do know that on my physical system, the hard disk is sd0 whereas the VM, it's wd0 (with an OpenBSD 5.5 install... yes, I know 5.6 is imminent). Not a big deal to tweak /etc/fstab though. No, it's not a big deal to edit fstab. If you use DUIDs those will AFAIK break as well. I'm reasonably comfortable with dump/restore, but not to completely clone a system. Before I explain any further, please make sure you've read http://www.openbsd.org/faq/faq14.html#Backup and http://www.openbsd.org/faq/faq10.html#DupFS . It may be much easier to just reinstall at this point; you'll have to go 5.2 - 5.3 - 5.4 - [major upgrade here] - 5.5 - 5.6. That's a lot of upgrading, and the 5.4 to 5.5 step requires you to uninstall and reinstall all your packages/ports anyway. However, if you want to proceed: From an OpenBSD bsd.rd (i.e. typically boot from ISO) of comparable version to your *source* system, you'll want to: - fdisk the new (virtual) disk, - disklabel the new (v)disk, - newfs the new root filesystem, - newfs any other on-disk filesystems you need to restore, - restore the entire dump onto the root filesystem, - mount the other filesystems (assuming they're all one level deep), - restore them individually, - installboot the new (v)disk, - reboot, - fix everything, - boot from the *next* version's ISO (From upgrade55.html: /Note: Upgrades are only supported from one release to the release immediately following it. Do not skip releases. If you got lucky skipping releases in the past, you may not this time.///) - run the in-place upgrade - fix everything - boot from the *next* version's ISO - fix everything - lather, rinse, repeat, until you're on 5.6-RELEASE. Note that this typically means either having the network up and running from inside the new machine, or having your entire dump reside on a device somehow accessible to the bsd.rd environment inside the VM. Some people use USB-attached disks for this, some use NFS mountpoints, YMMV. If doing this over the network, you can avoid the need to store an image of your system; use something like (from the target system) ssh oldsystem dump -0af - / | ( cd /mountpoint ; restore -rf - ) or from the source system dump -0af - / | ssh newsystem (cd /mountpoint;restore -rf -). Another approach is to boot both systems into single-user mode, bring up networking on both, and use dd(1) over the wire to copy an exact bit-wise image of the source disk... this is probably unnecessary and will take much longer than a dump/restore pass, especially if you dump(8) to a fast storage medium of some sort and then you can restore at your leisure as many times as you want. How can I do a dump of the root filesystem over top of a running system (in the VM)? Does it have to be in single user mode? Yes, it should be in single-user mode. In fact, you should have booted from another device altogether. And you don't do that in the first place, see above. Are there any other things that are going to need to be tweaked other than /etc/fstab? /etc/hostname.* , /etc/mygate Am I going to need to run installboot or some other such utility to get it to boot correctly after a restore? Yes. Any thoughts of this idea in general? It's a fairly safe way to test upgrades. Keep in mind that any bugs w.r.t. VirtualBox or w.r.t. the physical hardware won't show up in the other environment. There are about as many ways to do this are there are system administrators reading this list; I've only outlined some of the more common techniques. You could also restore an entire system using Amanda, Bacula, BackupPC, or even just tar(1). Oh, and note that while you can run dump(8) on a running, multi-user system, the resultant dumpset is not atomically self-consistent. Depending on your
pf rdr-to and access from internal network
Hello I'm using pf's rdr-to to forward external connections on port 5281 to a machine (called pc5) on my internal network, using this line in pf.conf: pass in on egress proto tcp from any to any port 5281 rdr-to pc5 port 5281 This works fine, but i can't get the forwarding to also work from my internal network. The FAQ http://www.openbsd.org/faq/pf/rdr.html talks about solutions to this exact problem; the solution that is entirely in pf.conf is two extra lines like: pass in on $int_if proto tcp from $int_net to $ext_if port 80 rdr-to $server pass out on $int_if proto tcp to $server port 80 received-on $int_if nat-to $int_if First question - what is '$int_net' ? I can't find it defined in the pf.conf man page or FAQ. I've assumed that it's a typo for $int_if, but please let me know if that's wrong. So my version of these two lines is: pass in on $int_if proto tcp from $int_if to $ext_if port 5281 rdr-to pc5 pass out on $int_if proto tcp to pc5 port 5281 received-on $int_if nat-to $int_if But this doesn't work - e.g. trying to telnet to my OpenBSD machine from a local machine on port 5281, ends up with 'connection refused'. Apologies if i've missed something obvious. I've read the pf.conf man page and didn't find any alternative info there. This is on OpenBSD 5.5. Thanks for any help, - Julian -- http://op59.net
Re: pf rdr-to and access from internal network
Julian Smith ju...@op59.net writes: pass in on $int_if proto tcp from $int_net to $ext_if port 80 rdr-to $server pass out on $int_if proto tcp to $server port 80 received-on $int_if nat-to $int_if First question - what is '$int_net' ? I can't find it defined in the pf.conf man page or FAQ. I've assumed that it's a typo for $int_if, but please let me know if that's wrong. I't just another macro, and could *in principle* stand for anything, but most likely it's intended to be equivalen to $int_if:network or the network directly connected to the internal-facing interface. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: KITCHEN_SINK
Hi Jan, Jan Stary wrote on Mon, Oct 27, 2014 at 07:32:22PM +0100: Reading strftime.c I came across this: #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ pt = _add(kitchen sink, pt, ptlim); continue; #endif /* defined KITCHEN_SINK */ Is there a back story to that? Not sure, but: https://github.com/eggert/tz/commit/41122a78e6401b7f693e95e23b377a1a24de5a5b Arthur David Olson might remember what his commit message System V compatible meant. Yours, Ingo
Re: Upgrade dry run - restore backup from physical to virtualbox VM?
On 2014-10-27 19:14, Steve Williams wrote: I have never done a dump/restore of a complete system before. I do know that on my physical system, the hard disk is sd0 whereas the VM, it's wd0 (with an OpenBSD 5.5 install... yes, I know 5.6 is imminent). Not a big deal to tweak /etc/fstab though. Easy enough to fix - add an SAS controller to your VM, move your disk image file to that controller and reboot. Now OpenBSD thinks you have sd0. I'm reasonably comfortable with dump/restore, but not to completely clone a system. How can I do a dump of the root filesystem over top of a running system (in the VM)? Does it have to be in single user mode? Are there any other things that are going to need to be tweaked other than /etc/fstab? Am I going to need to run installboot or some other such utility to get it to boot correctly after a restore? Any thoughts of this idea in general? I'd just do a minimal install of 5.2 on the VM system. Layout the disks similar to what you have now. Then boot into single user mode and simply do something like this: # cd / # ssh therealserver (cd /; find / -print | grep -v ^/boot$ | cpio -oBz) | cpio -icvBdmz # reboot ...and hope for some good luck. :-) Note that if you don't copy /boot, you won't have to risk having to fiddle with installboot. (Just realized you're running -current, but I think it's a fairly safe bet to gamble that /boot haven't changed fatally since -release, so you can make do with the one installed with release. I mean, it's only your test run - you just need to get it to boot with a copy of your running server, then there's going to be new /boot:s installed with the upgrades anyway.) Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Searching for cluestick - iked(8) peer to peer
I am testing an extremely simple lab environment with iked(8) and failing to establish flows and SAs on one of two platforms. I'm sure its somthing extremely simple, but I'm at a loss to figure it out on my own. A cluestick would be appreciated. The entire network only has two systems: a.lab, 10.0.0.1/24 b.lab, 10.0.0.2/24 These names are in /etc/myname and /etc/hosts. /etc/resolv.conf contains: lookup file iked.conf for a.lab: ikev2 a2b from a.lab to b.lab psk test iked.conf for b.lab: ikev2 b2a active from b.lab to a.lab psk test Flows and SAs are established on a.lab, which is passive: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.2 to 10.0.0.1 peer 10.0.0.2 srcid FQDN/a.lab dstid FQDN/b.lab type use flow esp out from 10.0.0.1 to 10.0.0.2 peer 10.0.0.2 srcid FQDN/a.lab dstid FQDN/b.lab type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 10.0.0.2 to 10.0.0.1 spi 0x4e79e0b2 auth hmac-sha2-256 enc aes-256 esp tunnel from 10.0.0.1 to 10.0.0.2 spi 0xf2f84086 auth hmac-sha2-256 enc aes-256 # Flows and SAs are not established on b.lab, which is active: # ipsecctl -sa FLOWS: flow esp out from ::/0 to ::/0 type deny SAD: No entries # The only thing I see in iked -vvd output that catches my eye is: sa_state: cannot switch: AUTH_SUCCESS - VALID The two iked -vvd logs follow, and then a dmesg. I'm testing in QEMU virtual machines, a.lab iked log: ca_privkey_serialize: type RSA_KEY length 1192 ca_pubkey_serialize: type RSA_KEY length 270 /etc/iked.conf: loaded 1 configuration rules ca_reload: local cert type RSA_KEY config_getocsp: ocsp_url none config_getpolicy: received policy ikev2 a2b passive esp inet from 10.0.0.1 to 10.0.0.2 local 10.0.0.1 peer 10.0.0.2 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1,hmac-md5 auth hmac-sha2-256,hmac-sha1,hmac-md5 group modp2048-256,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 lifetime 10800 bytes 536870912 psk 0x74657374 config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getsocket: received socket fd 7 config_getsocket: received socket fd 8 ikev2_recv: IKE_SA_INIT request from initiator 10.0.0.2:500 to 10.0.0.1:500 policy 'a2b' id 0, 520 bytes ikev2_recv: ispi 0xf071110c5e30f9dd rspi 0x ikev2_policy2id: srcid FQDN/a.lab length 9 ikev2_pld_parse: header ispi 0xf071110c5e30f9dd rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 520 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 136 ikev2_pld_sa: more 0 reserved 0 length 132 proposal #1 protoid IKE spisize 0 xforms 14 spi 0 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_MD5 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_MD5_96 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048_256 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048 ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1536 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024 ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 264 ikev2_pld_ke: dh group MODP_2048_256 reserved 0 ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 36 ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28 ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP ikev2_nat_detection: peer source 0xf071110c5e30f9dd 0x 10.0.0.2:500 ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 28 ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP ikev2_nat_detection: peer destination 0xf071110c5e30f9dd 0x 10.0.0.1:500 sa_state: INIT - SA_INIT ikev2_sa_negotiate: score 4 sa_stateok: SA_INIT flags 0x00, require 0x00 sa_stateflags: 0x00 - 0x10 sa (required 0x00 ) ikev2_sa_keys: SKEYSEED with 32 bytes ikev2_sa_keys: S with 80 bytes ikev2_prfplus: T1 with 32 bytes
Re: Upgrade dry run - restore backup from physical to virtualbox VM?
Hi, That's fantastic. Thanks for the information. Cheers, Steve Williams On 10/27/2014 1:35 PM, Josh Grosse wrote: On 2014-10-27 14:14, Steve Williams wrote: Hi, I have an older system on physical hardware that needs upgrading. I've been procrastinating because it's the type of thing that needs to be done from start to finish, and it's rather out of date (OpenBSD 5.2-current) so I know there will be all sorts of surprises. If you follow the Upgrade Guides, there shouldn't be any. 5.2- 5.3, 5.3 - 5.4, 5.4 - 5.5, and then 5.5 - 5.6 starting on Saturday. :) I have Virtualbox (2.2.4) running on my Windows PC and able to boot/install OpenBSD in it. I had (what I think is) a great thought today that maybe I could (somehow) restore a backup from my physical hardware into the Virtualbox VM and do a test upgrade there, figuring things out bit by bit with no pressure of my system being down. Once I had the upgrade process figured out, I'd then be better prepared to do it to my physical system. Excellent idea I have never done a dump/restore of a complete system before. I do know that on my physical system, the hard disk is sd0 whereas the VM, it's wd0 (with an OpenBSD 5.5 install... yes, I know 5.6 is imminent). Not a big deal to tweak /etc/fstab though. If your production /etc/fstab used DUID rather than device number, you may need to revise the DUID in your virtual machine's disklabel rather than editing fstab(5). Either way. I'm reasonably comfortable with dump/restore, but not to completely clone a system. How can I do a dump of the root filesystem over top of a running system (in the VM)? Does it have to be in single user mode? Are there any other things that are going to need to be tweaked other than /etc/fstab? The following how-to is from memory, and I may have missed a step (or two). Use only with that understanding. If' you get confused, let me know and I'll try to help. You do the restore from the ramdisk kernel, since restore(8) is included. You will need to have a mounted /tmp, since restore requires it. 1. Boot the ramdisk kernel, bsd.rd. 2. Use fdisk(8) to create an MBR on your new system's drive. 3. Use disklabel(8) to create partitions on your new system's drive. You can edit by hand or use -R with a copy of your producition disklabel. You will create a disklabel with a new DUID either way. If your fstab(8) uses DUIDs and you wish to retain them, edit the new drive's DUID to match your production system's. 4. Create, format, and mount a /tmp filesystem. If you don't have a /tmp partition or you use MFS for /tmp, you may find your swap partition b is handy to format and mount as /tmp. Use disklabel(8) to create the partition, use newfs(8) to format, and use mount(8), of course. 5. For each filesystem to restore, format with newfs(8) and mount with mount(8). For speed during restore, you will find -o async or -o async,noatime helpful. 6. Now just cd(1) into each mounted, empty filesystem, and restore(8) with -r. starting with dump level 0 and lather, rinse, repeat with other levels. 7. When each partition has been restored, you may remove the restoresymtable file in the root of each restored filesystem. 8. You must install bootblocks manually. For a 5.2 system, the installboot(8) program is located in /usr/mdec, along with the biosboot(8) first stage bootloader. The /boot second stage bootloader should already be in your root filesystem. example (for 5.2 and wd0's root partition mounted at /mnt): # /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot wd0 9. If you need to adjust /etc/fstab instead of DUIDs, edit before booting.
Re: The Book of PF, 3rd ed: You own the first author signed copy and support OpenBSD!
On Mon, Oct 27, 2014 at 09:04:48PM +0100, Peter N. M. Hansteen wrote: Michael W. Lucas mwlu...@michaelwlucas.com writes: BAH! You think you can steal my idea for supporting OpenBSD? I don't think it's that easy. MY auction raised $1145. There is no way that BoPF3 can POSSIBLY raise more than that! Consider the gauntlet thrown. :D After two days, the highest bit lists as US $493.88, which means a) that bid was likely entered in a non-USD currency (or somebody has an odd sense of humor, I'm fine with both) b) we're on a pretty good trajectory for beating Mr. Lucas on the fundraising front Humpf. It is just BARELY possible that Mr. Hansteen's work will raise more money than mine. If so, it will clearly be the result of nepotism, collusion, and intrigue. If this happens, I'll have to write another OpenBSD book. One that will raise EVEN MORE MONEY than this petty little BoPF3 auction. ==ml One again, the auction is at http://www.ebay.com/itm/The-Book-of-PF-3rd-ed-signed-by-the-author-First-Copy-signed-/321563281902? The blog post with the nice pictures is at http://bsdly.blogspot.no/2014/10/the-book-of-pf-3rd-edition-is-here.html And if your bid turns out not to be the successful one, please make the amount of your highest bid a direct donation to OpenBSD instead. Even if you wouldn't consider bidding, go on, head over to http://www.openbsd.org/orders.html or http://www.openbsd.org/donations.html and spend some money! - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: 5.6 arrived
On Fri, 24 Oct 2014 12:21:15 +0100, Maurice McCarthy wrote: OpenBSD 5.6 arrived Swansea UK today, 24 Oct 2014. Arrived north of Chicago IL, USA on 27 Oct 2014 On new website looked at shipping address during order and realized a couple things needed to be rearranged to make things look US normal, so did that. I understand the website has changed that a little since.
OT: integrating git branch output into ksh PS1 shell prompt?
Git fans like to know what branch is current, and bash's implementation of PS1 allows for update each time it is displayed. All of my attempts of adding a call to a ksh function into PS1 appear to be evaluated at the time that PS1 is set, but not upon each new display of the shell prompt. Does anyone have suggestions on how to have ksh execute a function upon each display of PS1? Thanks!
