Re: reorder_kernel - GENERIC.MP/ not updated at system upgrade
bernward@arcor.de wrote: > On 2019-11-05 05:52, Theo de Raadt wrote: > > > > > The directory GENERIC.MP in /usr/share/relink/kernel/ was > > > obviosly not updated (but directory GENERIC was updated!). > > > > I doubt it. Upon upgrade, they are both replaced. Then the undesired > > one is deleted to avoid overflowing /usr partition, since many users who > > have upgraded repeatedly are using older partioning layouts and after > > the flip to clang /usr is a bit tight for them. > > I confirm again, the directory GENERIC.MP in /usr/share/relink/kernel/ > was old, most files from the old GENERIC.MP have date April 13, > while most files in the new one are from October 12. Ah, there was a change. On extract, the other dir is skipped. But I thought we deleted the entire compile zone. Anyways, even if they were new files it would not have worked since the MP kernel was selected, and because you manipulated /bsd to be incoherent with the saved hash.
kernel protection fault trap on -current i386
>Synopsis: kernel protection fault trap on -current i386
>Category: i386
>Environment:
System : OpenBSD 6.6
Details : OpenBSD 6.6-current (GENERIC) #330: Sun Oct 27 23:36:34
MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Architecture: OpenBSD.i386
Machine : i386
>Description:
After upgrading to i386 current from Build date: 1572724605 -
Sat Nov 2 19:56:45 UTC 2019 i got an
kernel: protection fault trap, code=0
Stopped at pmap_apte_flush+0x6 movl %eax,%cr3
full trace at
https://ibb.co/yWb1tyg
>How-To-Repeat:
>Fix:
Either comment out start of pflogd or
downgrade to Build date: 1572242750 - Mon Oct 28 06:05:50 UTC
2019
dmesg:
OpenBSD 6.6-current (GENERIC) #330: Sun Oct 27 23:36:34 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 1063731200 (1014MB)
avail mem = 1028657152 (981MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 12/03/04, BIOS32 rev. 0 @ 0xfd6c0, SMBIOS rev. 2.31 @
0xeff40 (86 entries)
bios0: vendor FUJITSU SIEMENS // Phoenix Technologies Ltd. version "5.00
R1.08.1844" date 12/03/2004
bios0: FUJITSU SIEMENS SCENIC E
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP ASF! SSDT MCFG APIC BOOT
acpi0: wakeup devices PEXA(S4) PEXB(S4) PEXC(S4) PEXD(S4) PEXE(S4) USB1(S4)
USB2(S4) USB3(S4) USB4(S4) USB5(S4) PCIH(S4) AC97(S4) MC97(S4) KEYB(S4)
PS2M(S4) COM1(S1) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xd000, bus 0-10
acpimcfg0: addr 0x1, bus 0-0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 GHz,
0f-04-01
cpu0:
FPU,V86,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,DTES64,MWAIT,DS-CPL,TM2,CNXT-ID,xTPR,NXE,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEXA)
acpiprt2 at acpi0: bus 3 (PEXB)
acpiprt3 at acpi0: bus 5 (PEXC)
acpiprt4 at acpi0: bus 7 (PEXD)
acpiprt5 at acpi0: bus 9 (PEXE)
acpiprt6 at acpi0: bus 11 (PCIH)
acpicpu0 at acpi0: C1(@1 halt!), FVS, 2800, 2800 MHz
acpibtn0 at acpi0: PWRB
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
bios0: ROM list: 0xc/0xa600! 0xca800/0x1000 0xcb800/0x800 0xe/0x4000!
memory map conflict 0xfff0/0x10
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915G Host" rev 0x04
inteldrm0 at pci0 dev 2 function 0 "Intel 82915G Video" rev 0x04
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: apic 1 int 16
ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03: apic 1 int 17
pci1 at ppb0 bus 3
bge0 at pci1 dev 0 function 0 "Broadcom BCM5751" rev 0x01, BCM5750 A1 (0x4001):
apic 1 int 16, address 00:30:05:84:5e:53
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb1 at pci0 dev 28 function 1 "Intel 82801FB PCIE" rev 0x03: apic 1 int 16
pci2 at ppb1 bus 5
ppb2 at pci0 dev 28 function 2 "Intel 82801FB PCIE" rev 0x03: apic 1 int 18
pci3 at ppb2 bus 7
ppb3 at pci0 dev 28 function 3 "Intel 82801FB PCIE" rev 0x03: apic 1 int 19
pci4 at ppb3 bus 9
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 22
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 21
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 20
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xd3
pci5 at ppb4 bus 11
xl0 at pci5 dev 5 function 0 "3Com 3c905C" rev 0x78: apic 1 int 22, address
00:04:75:95:21:3f
exphy0 at xl0 phy 24: 3Com internal media interface
puc0 at pci5 dev 7 function 0 "NetMos Nm9835" rev 0x01: ports: 15 com, 1 lpt
com4 at puc0 port 0 apic 1 int 21: ns16550a, 16 byte fifo
com5 at puc0 port 1 apic 1 int 21: ns16550a, 16 byte fifo
lpt3 at puc0 port 2 apic 1 int 21
auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int 17,
ICH6
ac97: codec id 0x41445378 (Analog Devices <78>)
ac97: codec features headphone, 20 bit DAC, No 3D Stereo
audio0 at auich0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FB LPC" rev 0x03: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801FB IDE" rev 0x03: DMA, channel 0
configured to compatibility, ch
PS: reorder_kernel - GENERIC.MP/ not updated at system upgrade
The upgrade was made using the install kernel bsd.rd, as described in https://www.openbsd.org/faq/upgrade66.html Best regards, Bernward.
Re: reorder_kernel - GENERIC.MP/ not updated at system upgrade
On 2019-11-05 05:52, Theo de Raadt wrote: > > > The directory GENERIC.MP in /usr/share/relink/kernel/ was > > obviosly not updated (but directory GENERIC was updated!). > > I doubt it. Upon upgrade, they are both replaced. Then the undesired > one is deleted to avoid overflowing /usr partition, since many users who > have upgraded repeatedly are using older partioning layouts and after > the flip to clang /usr is a bit tight for them. I confirm again, the directory GENERIC.MP in /usr/share/relink/kernel/ was old, most files from the old GENERIC.MP have date April 13, while most files in the new one are from October 12. Best regards, Bernward.
Re: reorder_kernel - GENERIC.MP/ not updated at system upgrade
bernward@arcor.de wrote: > >Synopsis:system upgrade: /usr/share/relink/kernel/GENERIC.MP was not > >updated > >Category:system > >Environment: > System : OpenBSD 6.6 > Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT > 2019 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > > I upgraded from system 6.5 to 6.6. After successful reboot > I changed the kernel from SP to MP by mv bsd bsd.sp; mv bsd.mp bsd > and rebooted. I got the error message "reorder_kernel: failed > -- see /usr/share/relink/kernel/GENERIC.MP/relink.log". > Sorry that is correct behaviour. When you change /bsd to not satisfy the stored hash, that is precisely the behaviour you have requested. > The directory GENERIC.MP in /usr/share/relink/kernel/ was > obviosly not updated (but directory GENERIC was updated!). I doubt it. Upon upgrade, they are both replaced. Then the undesired one is deleted to avoid overflowing /usr partition, since many users who have upgraded repeatedly are using older partioning layouts and after the flip to clang /usr is a bit tight for them.
Re: Small error in chflags man page
On Tue, Nov 05, 2019 at 04:43:59AM +0100, Jonathan Drews wrote: > To: bugs@openbsd.org > Subject: Small error in chflags man page > From: Jonathan > Cc: cleetus > Reply-To: easyfashioncloth...@gmx.com>Synopsis: chflags man page has an > error > >Category: Documentation > >Environment: > System : OpenBSD 6.6 > Details : OpenBSD 6.6 (GENERIC.MP) #1: Sun Oct 27 16:19:23 MDT 2019 > clee...@leo.cats.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > The man page for chflags says to prepend "no" to one of the > flags. To unset the nodump flag you would then do: > $chlags nonodump file.txt > However this does not work. > >How-To-Repeat: > leo$ ls -lohd mp3/ > drwxr-xr-x 15 cleetus cleetus uchg,nodump 512B May 6 14:33 mp3/ > leo$ chflags -R nonodump mp3/ > chflags: invalid flag: nonodump > leo$ chflags -R dump mp3/ > leo$ ls -lohd mp3/ > drwxr-xr-x 15 cleetus cleetus uchg 512B May 6 14:33 mp3/ > leo$>Fix: > The man page should say: Putting the letters no before a flag name causes > the flag to > be turned off except in the case of the nodump flag. To turn > off nodump, use dump. Do not use nonodump. > EXAMPLE: > chflags dump somefile.txt morning. i think part of this is just learning curve. if you think about it, there's enough info there to work it out. the question would be more whether specifying "dump" actually does anything other than achieve what already happens if you don;t specify "nodump". other than that, i think there's enough there to work it out. jmc
