Mounting encrypted drive on boot
My setup consist of OpenBSD 6.7 with full drive encryption using softraid, configured as described in FAQ: /dev/sd0a - encrypted volume /dev/sd1 - decrypted I have additional need to mount an encrypted /var volume on boot. This volume is separate drive attached to be VPS "machine". I want to mount this drive automatically on boot by adding relevant entries to /etc/fstab, but before this can be done, softraid device must be configured using bioctl. On Linux this is done by adding some entries to /etc/crypttab and the boot script performs required configuration before disks in fstab are mounted. How to do similar thing in OpenBSD? Somebody on StackOverflow advised on modifying /etc/rc and run bioctl before disks are mounted, but I'm not sure if this is a right approach, especially that attaching more disks might change the /dev/sd* numberign. What would be the best approach? Best regards, Chris signature.asc Description: PGP signature
Re: Mounting encrypted drive on boot
On 2020-06-02 19:27, Chris Narkiewicz wrote: > My setup consist of OpenBSD 6.7 with full drive encryption using > softraid, configured as described in FAQ: > > /dev/sd0a - encrypted volume > /dev/sd1 - decrypted > > I have additional need to mount an encrypted /var volume on boot. > This volume is separate drive attached to be VPS "machine". > > I want to mount this drive automatically on boot by adding > relevant entries to /etc/fstab, but before this can be done, > softraid device must be configured using bioctl. I don't think there is a good answer to your question *as asked*, so we just have to come up with a new question and solve your problem. :) I am GUESSING your real problem is "I didn't make /var big enough" You can add a second disk. And you did. I would look closely at what partitions you have on /dev/sd1c. Got a /home? Move that to your second drive, move the /var to your old /home. Or..what is the real problem with /var? Maybe /var/www? Move THAT to your second drive, leave /var (which is kinda important on boot for a lot of reasons!) on sd1. But in general, work out a way to keep /var on your primary boot drive, and put something that isn't needed in the first moments of boot on the secondary drive. Some other ideas that could be moved: /usr/local /usr/src /usr/bin /usr/ports /home Most of those would provide a good basic /var If you over-built some other partition, copy the data off, make it smaller, reload, and use the freed space for a /var. Nick.
Re: Mounting encrypted drive on boot
‐‐‐ Original Message ‐‐‐ On Wednesday, June 3, 2020 7:27 AM, Chris Narkiewicz wrote: > My setup consist of OpenBSD 6.7 with full drive encryption using > softraid, configured as described in FAQ: > > /dev/sd0a - encrypted volume > /dev/sd1 - decrypted > > I have additional need to mount an encrypted /var volume on boot. > This volume is separate drive attached to be VPS "machine". > > I want to mount this drive automatically on boot by adding > relevant entries to /etc/fstab, but before this can be done, > softraid device must be configured using bioctl. > > On Linux this is done by adding some entries to /etc/crypttab > and the boot script performs required configuration before disks > in fstab are mounted. > > How to do similar thing in OpenBSD? > > Somebody on StackOverflow advised on modifying /etc/rc > and run bioctl before disks are mounted, but I'm not sure > if this is a right approach, especially that attaching > more disks might change the /dev/sd* numberign. > > What would be the best approach? > > Best regards, > Chris Take look at https://xosc.org/enchome.html, and use the FAQ along with that document. It works for me with an encrypted /home, but /var might be a lot more problematic. Cheers Adam
Re: sysupgrade with sysmerge failure
> On Jun 2, 2020, at 02:15, rgc wrote: > > On Mon, Jun 01, 2020 at 10:47:02PM -0700, Sean Kamath wrote: >> I didn???t see any place in sysmerge that used mail, and did not receive any >> mail for the failed sysmerge. >> But I see in /etc/rc that it does mail the output of sysmerge to the root >> user. Guess I got other issues. > > did you already check /etc/mail/aliases and verified contents of > /root/.forward? The clue was in the first email — merging smtpd.conf. I had a jacked up smtpd.conf as I was working on getting internal relaying working. Sean
Re: Error messages with VMM on 6.6 and 6.7
On Tue, Jun 02, 2020 at 10:18:32AM +0800, jrmu wrote: > OpenBSD VMM suffers from error messages and possibly spontaneous crashing > > System : OpenBSD 6.7 > Details : OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT > 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > > >Description: > I ran VMM on OpenBSD 6.6 with ~30 VMs, a mixture of OpenBSD 6.6, 6.7, > and Debian, and kept seeing the following error messages in logs: > > May 28 00:54:37 srv1 vmd[97924]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 00:59:05 srv1 vmd[24983]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 01:12:35 srv1 vmd[31276]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 01:14:40 srv1 vmd[31276]: vioblk queue notify - nothing to do? > May 28 01:15:12 srv1 last message repeated 806 times > May 28 01:17:03 srv1 last message repeated 78 times > May 28 01:30:03 srv1 vmd[31276]: vioblk queue notify - nothing to do? > May 28 01:40:19 srv1 last message repeated 67 times > May 28 01:44:17 srv1 last message repeated 47 times Those messages are a bit odd, basically it means the in-guest driver notified vioblk (the VM's disk device) that there were descriptors in the ring but when the device-side implementation (in vmd(8)) went to process them, the ring was empty. There shouldn't be any side effect, although it does indicate something unexpected is happening. > May 28 01:44:19 srv1 vmd[9684]: rtc_update_rega: set non-32KHz timebase not > supported > Those messages aren't serious, Linux kernels program the RTC this way. TBH, that message has probably outlived its usefulness. Someone can remove it at this point. > Every 2-3 weeks, the system appeared to crash, but I could not find any other > error message that would narrow down the cause. I am not sure if the crash is > related to either of those two above error messages. Likely unrelated; those messages are from vmd(8), a user-mode process. I think it's difficult for vmd(8) to crash the system. > > Today I upgraded to OpenBSD 6.7 stable with hopes that the problem may have > been fixed. However, I still notice the same two error messages: > > May 31 19:06:32 srv1 vmd[72705]: vcpu_process_com_data: guest reading com1 > when not ready > May 31 19:06:33 srv1 last message repeated 2 times > May 31 19:06:40 srv1 reorder_kernel: kernel relinking done > May 31 19:09:03 srv1 vmd[72705]: rtc_update_rega: set non-32KHz timebase not > supported > > Any workaround or suggestions? What is the question here? If you are tiring of the log messages, you can remove those particular ones. As I said higher up, these messages have likely exceeded their usefulness (these were put in during early development to detect weird corner cases like this). -ml > > dmesg: > OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34306437120 (32717MB) > avail mem = 33254100992 (31713MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec830 (156 entries) > bios0: vendor American Megatrends Inc. version "3.3" date 05/23/2018 > bios0: Supermicro X9DRi-LN4+/X9DR3-LN4+ > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP APIC FPDT SRAT SLIT HPET PRAD SPMI SSDT EINJ ERST > HEST BERT DMAR MCFG > acpi0: wakeup devices P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PWVE(S4) NPE1(S4) > NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) NPEA(S4) NPE2(S4) NPE3(S4) NPE7(S4) > NPE9(S4) NPE2(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 E5-2620 0 @ 2.00GHz, 2000.27 MHz, 06-2d-07 > 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > 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 > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.02 MHz, 06-2d-07 > cpu1: >
Re: Issues expanding partition to grow disk
On Tue, Jun 2, 2020 at 2:27 PM Christian Weisgerber wrote: > > On 2020-06-02, "Darren S." wrote: > > > I'm dealing with a VPS on KVM with the disk having been recently > > expanded from 50 >> 80 GB. > > > > Disklabel shows reasonable total sectors: > > > > # disklabel sd0 > > > total sectors: 167772160 > > boundstart: 64 > > boundend: 115330635 > > The upper boundary is still set to 55G. > In the disklabel editor use b * to move it to the end of the disk. > > > Is this something to do with it being a virtual disk in a certain > > configuration? And is this a case where I may need to set the disk > > boundaries in disklabel(8) as described (although I don't know if this > > fits description of "ports with fdisk(8) partition tables where..."): > > It fits the unmentioned case of a labeled disk later growing. > Actual drives don't do that. Yep, makes sense. Thanks! - Darren
Re: Issues expanding partition to grow disk
On 2020-06-02, "Darren S." wrote: > I'm dealing with a VPS on KVM with the disk having been recently > expanded from 50 >> 80 GB. > > Disklabel shows reasonable total sectors: > > # disklabel sd0 > total sectors: 167772160 > boundstart: 64 > boundend: 115330635 The upper boundary is still set to 55G. In the disklabel editor use b * to move it to the end of the disk. > Is this something to do with it being a virtual disk in a certain > configuration? And is this a case where I may need to set the disk > boundaries in disklabel(8) as described (although I don't know if this > fits description of "ports with fdisk(8) partition tables where..."): It fits the unmentioned case of a labeled disk later growing. Actual drives don't do that. -- Christian "naddy" Weisgerber na...@mips.inka.de
Issues expanding partition to grow disk
OpenBSD 6.7 amd64 I'm dealing with a VPS on KVM with the disk having been recently expanded from 50 >> 80 GB. virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio1 scsibus2 at vioblk0: 2 targets sd0 at scsibus2 targ 0 lun 0: sd0: 81920MB, 512 bytes/sector, 167772160 sectors I want to expand the root partition as part of revising the partition layout but I'm not sure why I don't seem to see the full disk capacity in the disklabel editor. After booting to bsd.rd, I create the device node for sd0 as it seems to be absent in ramdisk /dev. Then I run `fdisk -i sd0' with this resulting MBR layout: # fdisk sd0 Disk: sd0 geometry: 10443/255/63 [167772160 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 10442 254 63 [ 64: 167766731 ] OpenBSD Disklabel shows reasonable total sectors: # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: Block Device duid: e9f2e2b690e05a87 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 7179 total sectors: 167772160 boundstart: 64 boundend: 115330635 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:103059328 64 4.2BSD 2048 16384 38128 # / b: 524288103059392swap# none c:1677721600 unused d: 11746944103583680 4.2BSD 2048 16384 12958 # /usr/local Next I run `disklabel -E sd0'. In the disklabel editor, I have deleted my 'b' and 'd' partitions to then try to (c)hange the 'a' partitiion. At this point I see: Partition a is currently 103059328 sectors in size, and can have a maximum size of 115330571 sectors. ...so I seem unable to grow any partitions into this expanded disk. Is this something to do with it being a virtual disk in a certain configuration? And is this a case where I may need to set the disk boundaries in disklabel(8) as described (although I don't know if this fits description of "ports with fdisk(8) partition tables where..."): b Set OpenBSD disk boundaries. This option tells disklabel which parts of the disk it is allowed to modify. This option is probably only useful for ports with fdisk(8) partition tables where the ending sector in the MBR is incorrect. The user may enter ‘*’ at the “Size” prompt to indicate the entire size of the disk (minus the starting sector). This is useful for disks where the fdisk partition table is incapable of storing the real size. Note: data may become corrupted if boundaries are extended such that they overlap with other resident operating systems. OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4278042624 (4079MB) avail mem = 4135768064 (3944MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5920 (10 entries) bios0: vendor SeaBIOS version "rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: ACPI 1.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel Xeon Processor (Skylake, IBRS), 2594.55 MHz, 06-55-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,AVX512F,AVX512DQ,CLWB,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 999MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel Xeon Processor (Skylake, IBRS), 2594.37 MHz, 06-55-04 cpu1:
Offline autoinstall(install.conf)
Hey I have no prior experience with BSD. I am planning to perform non interactive installation of OpenBSD with some params(like the default root password, network etc) as host on Fedora(guest) using virt-install any suggestions for that? I have already gone through the autoinstall man page but I didn't understand how to do that using local(offline without the TFTP server) file(do I need to write rewrite the bsd.rd and include the install.conf file? from https://marc.info/?l=openbsd-misc=141552533922277=2) Or is there any workaround? or can I use initrd feature of virt-install so that I can pass the install.conf (just like kickstart file for Fedora)?(if it is possible and I am not wrong)? Thanks in Advance. Best, RT
Re: Could somebody please put unveil() in ftp(1)?
I missed something.
-Luke
On Sat, May 30, 2020 at 2:53 PM Luke Small wrote:
> I’ll get to looking at ftp(1) more when I get some physical contact with
> my server. I’m quaranteaming with my girlfriend’s folks.
>
> I have a pkg_ping program (OpenBSD-specific, dns caching, latency-timed,
> architecture and version specific mirror search; which doesn’t download
> from OpenBSD.org/ftp.html anymore) that calls ftp to look up a random
> mirror’s ftplist. and it seems unreasonable that with the availability of
> unveil, that ftp is hardly secured at all outside of a program that must be
> root and then change to an unprivileged user to have much of any real file
> system safety. The fact that ftp even has an interactive mode suggests to
> me that perhaps people do use, or at least, have used it as a normal user,
> seeing that if you put yourself in a chroot and try to run it, it will in
> most cases preclude your access to ftp(1) at all.
>
> I mentioned initially:
>
> It could take 3 lines at line 389 in /usr/src/usr.bin/ftp/main.c:
> if (strcmp(outfile, "-"))
> if (unveil(outfile, "cw") == -1)
> err(1, "unveil");
>
> but it could look at several of the options like the cookie and
> certificate paths and such.
>
> I’d love to make it as safe to run as root as it is running it as an
> unprivileged chrooted user! And I love C!
>
> The reason I mentioned: “unveil(“/“, “rx”)“ is because if you unveiled
> anything like the “cw” privileges example, you’d obviously have to ensure
> that the read and exec privileges, perhaps even global ones are granted too.
>
> On Fri, May 29, 2020 at 8:50 AM Stuart Henderson
> wrote:
>
>> On 2020/05/29 08:30, Luke Small wrote:
>> > You mention a lot of files that need to be read, but a program like
>> pkg_add can make it the
>> > _pkgfetch (57) user which has no directory and I’m guessing not in
>> interactive mode. At the
>> > very least, in noninteractive mode you could unveil(“/“, “rx”); and
>> change the specified output
>> > file discover the name of the file that is to be downloaded and unveil
>> it as “cw” !
>> > --
>> > -Luke
>>
>> What problem are you trying to solve?
>>
>> If you are concerned about writes, use "ftp -o - $URL > somefile", it will
>> run without cpath/wpath, which is functionally similar to unveil("/",
>> "rx")
>> (a bit stronger, because a program trying to write will be killed, rather
>> than just having a file access error).
>>
>> pkg_add(1) already uses "ftp -o -":
>>
>> # ktrace -di pkg_add -u moo
>> quirks-3.339 signed on 2020-05-27T20:05:28Z
>>
>> # kdump | grep promise=
>> 61644 ftp STRU promise="stdio rpath dns tty inet proc exec fattr"
>> 41938 signify STRU promise="stdio rpath wpath cpath tty"
>> 41938 signify STRU promise="stdio rpath"
>> 24897 ftp STRU promise="stdio rpath dns tty inet proc exec fattr"
>> 54324 signify STRU promise="stdio rpath wpath cpath tty"
>> 54324 signify STRU promise="stdio rpath"
>> 9188 ftp STRU promise="stdio rpath dns tty inet proc exec fattr"
>>
>> --
> -Luke
>
diff
Description: Binary data
Re: unexpected behavior
Thanks! On Tue, Jun 2, 2020 at 10:48 AM Anders Andersson wrote: > > On Tue, Jun 2, 2020 at 4:30 PM Sonic wrote: > > > > Recently discovered (snapshot form May 30) having any hostname.if > > configured for dhcp, even if unplugged and inactive, prevents the > > default gateway defined in /etc/mygate from being set. Is this normal? > > "/etc/mygate is processed after all interfaces have been configured. > If any hostname.if(5) files contain "dhcp" directives, IPv4 entries in > /etc/mygate will be ignored. If they contain "autoconf" directives, > IPv6 entries will be ignored." > > Exactly as documented.
Re: unexpected behavior
On Tue, Jun 2, 2020 at 4:30 PM Sonic wrote: > > Recently discovered (snapshot form May 30) having any hostname.if > configured for dhcp, even if unplugged and inactive, prevents the > default gateway defined in /etc/mygate from being set. Is this normal? "/etc/mygate is processed after all interfaces have been configured. If any hostname.if(5) files contain "dhcp" directives, IPv4 entries in /etc/mygate will be ignored. If they contain "autoconf" directives, IPv6 entries will be ignored." Exactly as documented.
unexpected behavior
Recently discovered (snapshot form May 30) having any hostname.if configured for dhcp, even if unplugged and inactive, prevents the default gateway defined in /etc/mygate from being set. Is this normal?
Re: Message WARNING: CHECK AND RESET THE DATE! in kvm guests
On Tue, Jun 02, 2020 at 08:28:13AM +, Carlos Lopez wrote: > Hi Otto, > > After some days without problems, it has happened again: > > root on sd0a (912329c5d9d2b184.a) swap on sd0b dump on sd0b > WARNING: clock gained 3 days > WARNING: CHECK AND RESET THE DATE! > > With version 6.6 I never had these problems. I am using default conf for > ntpd, but some errors appears: If you read what I wrote earlier, this is not a problem. ntpd sets the time ok, so nothing to worry about. -Otto > > Jun 2 06:32:01 obsdfw ntpd[91858]: ntp engine ready > Jun 2 06:32:01 obsdfw ntpd[91858]: constraint reply from 9.9.9.9: offset > 1.298291 > Jun 2 06:32:03 obsdfw ntpd[91858]: cancel settime because dns probe failed > Jun 2 06:32:03 obsdfw savecore: no core dump > Jun 2 06:32:04 obsdfw ftp-proxy[73808]: listening on 127.0.0.1 port 8021 > Jun 2 06:32:08 obsdfw ntpd[91858]: constraint reply from 216.58.211.36: > offset 1.270038 > Jun 2 06:32:29 obsdfw ntpd[91858]: peer 162.159.200.123 now valid > Jun 2 06:32:30 obsdfw ntpd[91858]: peer 162.159.200.1 now valid > Jun 2 06:32:30 obsdfw ntpd[91858]: peer 147.156.7.18 now valid > Jun 2 06:32:32 obsdfw ntpd[91858]: peer 162.159.200.123 now valid > Jun 2 06:32:33 obsdfw ntpd[91858]: reply from 147.156.7.26: not synced > (alarm), next query 3184s > Jun 2 06:33:04 obsdfw ntpd[91858]: peer 147.156.7.18 now invalid > Jun 2 06:33:27 obsdfw ntpd[61176]: adjusting local clock by 1.707163s > Jun 2 06:33:50 obsdfw ntpd[91858]: peer 147.156.7.18 now valid > Jun 2 06:35:06 obsdfw ntpd[61176]: adjusting local clock by 1.212163s > Jun 2 06:37:18 obsdfw ntpd[61176]: adjusting local clock by 0.559285s > Jun 2 06:39:28 obsdfw ntpd[91858]: clock is now synced > Jun 2 06:39:28 obsdfw ntpd[91858]: constraint reply from 9.9.9.9: offset > -0.872650 > Jun 2 06:39:28 obsdfw ntpd[91858]: constraint reply from 216.58.211.36: > offset -0.880034 > Jun 2 07:02:16 obsdfw ntpd[61176]: adjusting clock frequency by -0.447350 to > 4.954650ppm > Jun 2 07:25:37 obsdfw ntpd[91858]: peer 147.156.7.26 now valid > Jun 2 07:28:08 obsdfw ntpd[61176]: adjusting clock frequency by -0.050205 to > 4.904445ppm > Jun 2 07:34:08 obsdfw ntpd[91858]: reply from 147.156.7.26: not synced > (alarm), next query 3170s > Jun 2 08:25:24 obsdfw ntpd[91858]: reply from 147.156.7.18: not synced > (alarm), next query 3154s > > Ntpctl -s all output: > 5/5 peers valid, constraint offset -1s, clock synced, stratum 4 > > peer >wt tl st next poll offset delay jitter > 162.159.200.123 time.cloudflare.com > * 1 10 3 28s 33s 1.520ms 2.347ms 0.712ms > 162.159.200.123 from pool pool.ntp.org > * 1 10 3 29s 32s 1.530ms 2.394ms 0.406ms > 147.156.7.26 from pool pool.ntp.org > 1 10 2 10s 34s 0.081ms20.071ms 0.387ms > 162.159.200.1 from pool pool.ntp.org > 1 10 3 11s 30s 1.502ms 2.442ms 0.134ms > 147.156.7.18 from pool pool.ntp.org > 1 10 2 3005s 3154s 1.199ms19.994ms 0.321ms > > On 25/05/2020, 10:20, "Otto Moerbeek" wrote: > > On Mon, May 25, 2020 at 07:53:47AM +, Carlos Lopez wrote: > > > Hi all, > > > > After upgrading four kvm guests to OpenBSD 6.7, I see the following > messages when these guests starts: > > > > WARNING: clock gained 2 days > > WARNING: CHECK AND RESET THE DATE! > > This means the clock compared to the last mounted filesystem time differ. > > Show what ntpd is doing after boot (see /var/log/daemon). If ntpd sets > the time ok, there is nothing further to be done. It's just a warning > that the kernel initially isn't sure about the time. > > -Otto > > > > > All four guests are fully patched. Dmesg output: > > > > OpenBSD 6.7 (GENERIC) #1: Sat May 16 16:07:20 MDT 2020 > > > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > real mem = 788389888 (751MB) > > avail mem = 752021504 (717MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5af0 (9 entries) > > bios0: vendor SeaBIOS version "1.11.1-4.module+el8.1.0+4066+0f1aadab" > date 04/01/2014 > > bios0: Red Hat KVM > > acpi0 at bios0: ACPI 3.0 > > acpi0: sleep states S5 > > acpi0: tables DSDT FACP APIC MCFG > > acpi0: wakeup devices > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel Core Processor (Broadwell), 1900.30 MHz, 06-3d-02 > > cpu0: >
Re: sysupgrade with sysmerge failure
On Mon, Jun 01, 2020 at 10:47:02PM -0700, Sean Kamath wrote: > I didn???t see any place in sysmerge that used mail, and did not receive any > mail for the failed sysmerge. > But I see in /etc/rc that it does mail the output of sysmerge to the root > user. Guess I got other issues. did you already check /etc/mail/aliases and verified contents of /root/.forward? > > Thanks, > Sean > > >
Re: Message WARNING: CHECK AND RESET THE DATE! in kvm guests
Hi Otto, After some days without problems, it has happened again: root on sd0a (912329c5d9d2b184.a) swap on sd0b dump on sd0b WARNING: clock gained 3 days WARNING: CHECK AND RESET THE DATE! With version 6.6 I never had these problems. I am using default conf for ntpd, but some errors appears: Jun 2 06:32:01 obsdfw ntpd[91858]: ntp engine ready Jun 2 06:32:01 obsdfw ntpd[91858]: constraint reply from 9.9.9.9: offset 1.298291 Jun 2 06:32:03 obsdfw ntpd[91858]: cancel settime because dns probe failed Jun 2 06:32:03 obsdfw savecore: no core dump Jun 2 06:32:04 obsdfw ftp-proxy[73808]: listening on 127.0.0.1 port 8021 Jun 2 06:32:08 obsdfw ntpd[91858]: constraint reply from 216.58.211.36: offset 1.270038 Jun 2 06:32:29 obsdfw ntpd[91858]: peer 162.159.200.123 now valid Jun 2 06:32:30 obsdfw ntpd[91858]: peer 162.159.200.1 now valid Jun 2 06:32:30 obsdfw ntpd[91858]: peer 147.156.7.18 now valid Jun 2 06:32:32 obsdfw ntpd[91858]: peer 162.159.200.123 now valid Jun 2 06:32:33 obsdfw ntpd[91858]: reply from 147.156.7.26: not synced (alarm), next query 3184s Jun 2 06:33:04 obsdfw ntpd[91858]: peer 147.156.7.18 now invalid Jun 2 06:33:27 obsdfw ntpd[61176]: adjusting local clock by 1.707163s Jun 2 06:33:50 obsdfw ntpd[91858]: peer 147.156.7.18 now valid Jun 2 06:35:06 obsdfw ntpd[61176]: adjusting local clock by 1.212163s Jun 2 06:37:18 obsdfw ntpd[61176]: adjusting local clock by 0.559285s Jun 2 06:39:28 obsdfw ntpd[91858]: clock is now synced Jun 2 06:39:28 obsdfw ntpd[91858]: constraint reply from 9.9.9.9: offset -0.872650 Jun 2 06:39:28 obsdfw ntpd[91858]: constraint reply from 216.58.211.36: offset -0.880034 Jun 2 07:02:16 obsdfw ntpd[61176]: adjusting clock frequency by -0.447350 to 4.954650ppm Jun 2 07:25:37 obsdfw ntpd[91858]: peer 147.156.7.26 now valid Jun 2 07:28:08 obsdfw ntpd[61176]: adjusting clock frequency by -0.050205 to 4.904445ppm Jun 2 07:34:08 obsdfw ntpd[91858]: reply from 147.156.7.26: not synced (alarm), next query 3170s Jun 2 08:25:24 obsdfw ntpd[91858]: reply from 147.156.7.18: not synced (alarm), next query 3154s Ntpctl -s all output: 5/5 peers valid, constraint offset -1s, clock synced, stratum 4 peer wt tl st next poll offset delay jitter 162.159.200.123 time.cloudflare.com * 1 10 3 28s 33s 1.520ms 2.347ms 0.712ms 162.159.200.123 from pool pool.ntp.org * 1 10 3 29s 32s 1.530ms 2.394ms 0.406ms 147.156.7.26 from pool pool.ntp.org 1 10 2 10s 34s 0.081ms20.071ms 0.387ms 162.159.200.1 from pool pool.ntp.org 1 10 3 11s 30s 1.502ms 2.442ms 0.134ms 147.156.7.18 from pool pool.ntp.org 1 10 2 3005s 3154s 1.199ms19.994ms 0.321ms On 25/05/2020, 10:20, "Otto Moerbeek" wrote: On Mon, May 25, 2020 at 07:53:47AM +, Carlos Lopez wrote: > Hi all, > > After upgrading four kvm guests to OpenBSD 6.7, I see the following messages when these guests starts: > > WARNING: clock gained 2 days > WARNING: CHECK AND RESET THE DATE! This means the clock compared to the last mounted filesystem time differ. Show what ntpd is doing after boot (see /var/log/daemon). If ntpd sets the time ok, there is nothing further to be done. It's just a warning that the kernel initially isn't sure about the time. -Otto > > All four guests are fully patched. Dmesg output: > > OpenBSD 6.7 (GENERIC) #1: Sat May 16 16:07:20 MDT 2020 > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 788389888 (751MB) > avail mem = 752021504 (717MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5af0 (9 entries) > bios0: vendor SeaBIOS version "1.11.1-4.module+el8.1.0+4066+0f1aadab" date 04/01/2014 > bios0: Red Hat KVM > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S5 > acpi0: tables DSDT FACP APIC MCFG > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel Core Processor (Broadwell), 1900.30 MHz, 06-3d-02 > 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,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,XSAVEOPT,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
