Re: panic softdep_deallocate_dependencies
On Fri, Jul 19, 2013 at 1:13 PM, Roger Hammerstein wrote:
> i had another machine panic with this, and no disk errors.amd64, openbsd 5.3.
...
> ddb{0}> show panic
> softdep_deallocate_dependencies: unrecovered I/O error
> ddb{0}> trace
> Debugger() at Debugger+0x5
> panic() at panic+0xe4
> softdep_deallocate_dependencies() at softdep_deallocate_dependencies+0x43
> brelse() at brelse+0x68
> sd_buf_done() at sd_buf_done+0x7a
> mpi_intr() at mpi_intr+0x40
> Xintr_ioapic_edge18() at Xintr_ioapic_edge18+0xe8
So in the email thread you cited, the original poster turned off
softdeps and miod noted that should should avoid the panic. You
haven't done so because...you like to panic? softdeps speeds things
up for you so much that it makes up for the occasional panics?
(If I was hitting that, I might be tempted to add a printf() to the
default case of sd_buf_done() that showed the exact error and any
other info that might be pulled the from the xs, like the associated
buf's blkno and/or lblkno.)
Philip Guenther
Re: dhcp address in /etc/hosts
On Sat, Jul 20, 2013 at 08:42:21PM -0400, Sam Fourman Jr. wrote: > I don't like this diff. > > > > > But perhaps because I totally hate that the installer is placing that > > name there. I believe that dynamically learned names should not be > > saved in that fashion. > > > > > > I don't really get a vote as i'm not a developer, however cookies to anyone > who fixes this the correct way. > > -- > > Sam Fourman Jr. > Define 'correct way'. :-) Ken
Re: dhcp address in /etc/hosts
I don't like this diff. > > But perhaps because I totally hate that the installer is placing that > name there. I believe that dynamically learned names should not be > saved in that fashion. > > I don't really get a vote as i'm not a developer, however cookies to anyone who fixes this the correct way. -- Sam Fourman Jr.
Re: panic: ext2fs_dirbadentry
> On Wed, Jul 17, 2013 at 12:11, Sergey Bronnikov wrote: > > Bug was catched by fsfuzzer. Probably that bug cannot be > > found in real life with real usecase, but anyway it is a bug. > > Sorry, but I don't think these bugs are interesting. The filesystem > code panics when it encounters a broken filesystem. That is by design. > Attempting to continue given that we know the filesystem is > inconsistent would only make things worse. I concur. If the filesystem is that broken, I want it to panic. If you read up on the history of how filesystems work, it is as Ted says -- by design. If you don't that design, the filesystem structures and code would be substantially different from what they are now.
Re: dhcp address in /etc/hosts
> On Jul 20 22:14:52, h...@stare.cz wrote: > > I believe I have bitched about this before, > > but I have come to it again with new install. > > > > If I use [dhcp] to configure an interface during an install, > > the ephemeral DHCP-assigned address gets written into /etc/hosts. > > > > That address is meaningless after the reboot, possibly even > > conflicting when I later decide on a fixed IP for the machine. > > > > Should it be removed from /etc/hosts after the install, > > when we have DNS set up and all? Should it at least > > be mentioned in afterboot(8)? > > > --- afterboot.8.orig Sat Jul 20 22:24:03 2013 > +++ afterboot.8 Sat Jul 20 22:28:51 2013 > @@ -153,6 +153,13 @@ if it needs to be changed. > You will also need to edit the > .Pa /etc/myname > file to have it stick around for the next reboot. > +.Pp > +Note that the hostname chosen during installation is saved in > +.Pa /etc/hosts > +with whatever address was used then. > +If you later decide on another address for the machine, > +remember to remove the conflicting one from > +.Pa /etc/hosts . > .Ss Verify network interface configuration > The first thing to do is an > .Ic ifconfig -a > I don't like this diff. But perhaps because I totally hate that the installer is placing that name there. I believe that dynamically learned names should not be saved in that fashion.
Re: current/macppc on Mac Mini
On Sat, Jul 20, 2013 at 08:23:35PM +0200, Jan Stary wrote:
> On Jul 20 11:23:01, kwesterb...@rogers.com wrote:
> > On Sat, Jul 20, 2013 at 11:45:07AM +0200, Jan Stary wrote:
> > > > What troubles me is that whatever device (device name) I try,
> > > > it is the 'ofwboot' which is not found.
> > > > I don't mind calling my disk 'cd' in the boot sequence
> > > > or altering the devaliases, or "setenv boot-device cd:,ofwboot",
> > > > but that doesn't work either, as shown above.
> > > > How can I make sure that the installer
> > > > has actually put the ofwboot on my disk?
> > >
> > > I mean, the ofwboot is supposed to be _somewhere_
> > > on my disk, right? Where? In the small DOS partition
> > > at the beginning of the disk?
> > >
> >
> > Yes. From macppc install.md:
> >
> > md_installboot() {
> > local _disk=$1
> >
> > # If there is an MSDOS partition on the boot disk, copy ofwboot
> > # into it.
> > if fdisk $_disk | grep -q 'Signature: 0xAA55'; then
> > if fdisk $_disk | grep -q '^..: 06 '; then
> > if mount /dev/${_disk}i /mnt2 >/dev/null 2>&1; then
> > # Use cat to avoid holes created by cp(1)
> > cat /mnt/usr/mdec/ofwboot > /mnt2/ofwboot
> > umount /mnt2
> > fi
> > fi
> > fi
> > }
> >
>
> Ha! This seems to assume that the (fdisk) DOS partition
> is the 'i' partition in the disklabel - it is not;
> I created a [c]ustom disklabel.
It does make the assumption that the DOS partition is the first spoofed
partition, i.e. 'i'. This should probably be revisited since we relaxed
the rules on partition naming a while ago.
>
> When in the install sequence is this copy of ofwboot done?
It's done at the very end in the finish_up() function in install.sub.
> Even my real wd0i partition, which is /usr/xobj
> (untouched since install) does not contain ofwboot.
Your wd0i isn't an MBR partition.
> That leads me to speculate that this ofwboot copy
> is performed _before_ the installing user edits
> the disklabel; but perhaps at that moment,
> wd0i _is_ really the DOS partiton, and later
> I can make the disklabel what I want?
Nope. See above. :-)
>
> Or did I miss it somewhere in the macppc install documentation
> to leave 'i' alone so that ofwboot gets copied to the right place?
In INSTALL.macppc:
"If you have DOS or Linux partitions defined on the disk, these will
usually show up as 'i', 'j', and so on."
and
"If the disk is partitioned using MBR, the bootloader will be
automatically installed if you setup a small (a few MB) MSDOS
partition as position `i' in the label."
>
> Anyway, I tried getting to that copy ofwboot now, as follows:
> I enlarged the disklabel-maintained area to the whole disk ('b')
> and created a partion for the DOS piece of the disk. Looking at
>
> Disk: wd0 geometry: 155061/16/63 [156301488 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start:size ]
> ---
> *0: 06 0 0 2 - 2 0 33 [ 1:2048 ] DOS >
> 32MB
> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 3: A6 4 1 2 - 155060 15 63 [4096: 156297392 ] OpenBSD
>
>
> I made the DOS partition start at 512 (and then 1024
> and then everything under 4096 wherethe obsd part starts),
> but never could I mount that DOS partition ...
>
> I will reinstall again, leaving the [a]uto disklabel untouched.
>
Good plan.
Ken
Re: dhcp address in /etc/hosts
On Jul 20 22:14:52, h...@stare.cz wrote: > I believe I have bitched about this before, > but I have come to it again with new install. > > If I use [dhcp] to configure an interface during an install, > the ephemeral DHCP-assigned address gets written into /etc/hosts. > > That address is meaningless after the reboot, possibly even > conflicting when I later decide on a fixed IP for the machine. > > Should it be removed from /etc/hosts after the install, > when we have DNS set up and all? Should it at least > be mentioned in afterboot(8)? --- afterboot.8.origSat Jul 20 22:24:03 2013 +++ afterboot.8 Sat Jul 20 22:28:51 2013 @@ -153,6 +153,13 @@ if it needs to be changed. You will also need to edit the .Pa /etc/myname file to have it stick around for the next reboot. +.Pp +Note that the hostname chosen during installation is saved in +.Pa /etc/hosts +with whatever address was used then. +If you later decide on another address for the machine, +remember to remove the conflicting one from +.Pa /etc/hosts . .Ss Verify network interface configuration The first thing to do is an .Ic ifconfig -a
dhcp address in /etc/hosts
I believe I have bitched about this before, but I have come to it again with new install. If I use [dhcp] to configure an interface during an install, the ephemeral DHCP-assigned address gets written into /etc/hosts. That address is meaningless after the reboot, possibly even conflicting when I later decide on a fixed IP for the machine. Should it be removed from /etc/hosts after the install, when we have DNS set up and all? Should it at least be mentioned in afterboot(8)? Jan
Re: current/macppc on Mac Mini
> I made the DOS partition start at 512 (and then 1024 > and then everything under 4096 wherethe obsd part starts), > but never could I mount that DOS partition ... Silly me, it's 1, not 512; and it mounts, and the ofwboot is NOT there, and not in the wd0i as designated by me either. So there is no copy of ofwboot on my disk. That is surely wrong. > I will reinstall again, leaving the [a]uto disklabel untouched. Yes, this creates an 'i' entry for the DOS partition, which gets the ofwboot alright, and I can boot it, - just have to call it cd:,ofwboot in my OpenFirmware (or setup a devalias). When I do edit the disklabel during the install, but leave the 'i' untouched, or set one up that spans the (fdisk) DOS partition, the ofwboot gets installed to the right place too. So my conclusion is that you _need_ to have this partition in your disklabel; right? And the hd/cd confusion of my OpenFirmware has nothing to do with this, right? That would make the following paragraph from INSTALL.macppc not entirely accurate: For dedicated disks, macppc port boots off a boot program in an MSDOS filesystem. This is set up by the install program and no special setup is required. If I am right, should the 'i' partition that seems to be needed for a proper copy of the ofwboot be mentioned in INSTALL.macppc or perhaps http://www.openbsd.org/faq/faq4.html#InstProb ? Would other architectures that require some special partition to boot be affected similarly? Jan
Re: panic: ext2fs_dirbadentry
On Wed, Jul 17, 2013 at 12:11, Sergey Bronnikov wrote: > Bug was catched by fsfuzzer. Probably that bug cannot be > found in real life with real usecase, but anyway it is a bug. Sorry, but I don't think these bugs are interesting. The filesystem code panics when it encounters a broken filesystem. That is by design. Attempting to continue given that we know the filesystem is inconsistent would only make things worse.
Re: Java on OpenBSD 5.3
On 20. juli 2013 at 5:34 PM, "Jan Stary" wrote: > >Why are you building the (huge) port, >instead of simply installing the package? Whoa. When did that get there? Thanks man! O.D.
Re: current/macppc on Mac Mini
On Jul 20 11:23:01, kwesterb...@rogers.com wrote:
> On Sat, Jul 20, 2013 at 11:45:07AM +0200, Jan Stary wrote:
> > > What troubles me is that whatever device (device name) I try,
> > > it is the 'ofwboot' which is not found.
> > > I don't mind calling my disk 'cd' in the boot sequence
> > > or altering the devaliases, or "setenv boot-device cd:,ofwboot",
> > > but that doesn't work either, as shown above.
> > > How can I make sure that the installer
> > > has actually put the ofwboot on my disk?
> >
> > I mean, the ofwboot is supposed to be _somewhere_
> > on my disk, right? Where? In the small DOS partition
> > at the beginning of the disk?
> >
>
> Yes. From macppc install.md:
>
> md_installboot() {
> local _disk=$1
>
> # If there is an MSDOS partition on the boot disk, copy ofwboot
> # into it.
> if fdisk $_disk | grep -q 'Signature: 0xAA55'; then
> if fdisk $_disk | grep -q '^..: 06 '; then
> if mount /dev/${_disk}i /mnt2 >/dev/null 2>&1; then
> # Use cat to avoid holes created by cp(1)
> cat /mnt/usr/mdec/ofwboot > /mnt2/ofwboot
> umount /mnt2
> fi
> fi
> fi
> }
>
Ha! This seems to assume that the (fdisk) DOS partition
is the 'i' partition in the disklabel - it is not;
I created a [c]ustom disklabel.
When in the install sequence is this copy of ofwboot done?
Even my real wd0i partition, which is /usr/xobj
(untouched since install) does not contain ofwboot.
That leads me to speculate that this ofwboot copy
is performed _before_ the installing user edits
the disklabel; but perhaps at that moment,
wd0i _is_ really the DOS partiton, and later
I can make the disklabel what I want?
Or did I miss it somewhere in the macppc install documentation
to leave 'i' alone so that ofwboot gets copied to the right place?
Anyway, I tried getting to that copy ofwboot now, as follows:
I enlarged the disklabel-maintained area to the whole disk ('b')
and created a partion for the DOS piece of the disk. Looking at
Disk: wd0 geometry: 155061/16/63 [156301488 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start:size ]
---
*0: 06 0 0 2 - 2 0 33 [ 1:2048 ] DOS > 32MB
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
3: A6 4 1 2 - 155060 15 63 [4096: 156297392 ] OpenBSD
I made the DOS partition start at 512 (and then 1024
and then everything under 4096 wherethe obsd part starts),
but never could I mount that DOS partition ...
I will reinstall again, leaving the [a]uto disklabel untouched.
Re: current/macppc on Mac Mini
On Sat, Jul 20, 2013 at 11:45:07AM +0200, Jan Stary wrote:
> > What troubles me is that whatever device (device name) I try,
> > it is the 'ofwboot' which is not found.
> > I don't mind calling my disk 'cd' in the boot sequence
> > or altering the devaliases, or "setenv boot-device cd:,ofwboot",
> > but that doesn't work either, as shown above.
> > How can I make sure that the installer
> > has actually put the ofwboot on my disk?
>
> I mean, the ofwboot is supposed to be _somewhere_
> on my disk, right? Where? In the small DOS partition
> at the beginning of the disk?
>
Yes. From macppc install.md:
md_installboot() {
local _disk=$1
# If there is an MSDOS partition on the boot disk, copy ofwboot
# into it.
if fdisk $_disk | grep -q 'Signature: 0xAA55'; then
if fdisk $_disk | grep -q '^..: 06 '; then
if mount /dev/${_disk}i /mnt2 >/dev/null 2>&1; then
# Use cat to avoid holes created by cp(1)
cat /mnt/usr/mdec/ofwboot > /mnt2/ofwboot
umount /mnt2
fi
fi
fi
}
Ken
Re: Java on OpenBSD 5.3
On 20. juli 2013 at 3:54 PM, "Amit Kulkarni" wrote: >> >> Nope, plenty of disk space left in /usr/local (my ports are in >> /usr/local/ports). > >why are ports inside /usr/local. it should be /usr/ports. Some >ports may fail. Maybe, yeah. I updated PORTSDIR in /etc/mk.conf though. Anyway I just gotta work on freeing up some space and I should be good. Thanks. O.D.
Re: Java on OpenBSD 5.3
On 19. juli 2013 at 9:13 PM, "Miod Vallat" wrote: > >> Pretty sure it takes more than 1.7G to build Java. > >But then how can java people pretend it has any usefulness, besides >filing disks? They say Android apps are just an excuse for Java devs to keep programming in Java. Now that HTML5 can access the phone's camera, microphone etc., it's just a matter of time before native mobile apps become obsolete. O.D.
Re: current/macppc on Mac Mini
> What troubles me is that whatever device (device name) I try, > it is the 'ofwboot' which is not found. > I don't mind calling my disk 'cd' in the boot sequence > or altering the devaliases, or "setenv boot-device cd:,ofwboot", > but that doesn't work either, as shown above. > How can I make sure that the installer > has actually put the ofwboot on my disk? I mean, the ofwboot is supposed to be _somewhere_ on my disk, right? Where? In the small DOS partition at the beginning of the disk?
Re: current/macppc on Mac Mini
The saga continues: I tried to reinstall with 5.4-beta, and have a similar, but different problem now. To recall the previous situation: the kernel was confused about what 'cd0' and 'hd0' is, and I had to hardcode the bootpath into the kernel config. A patch from mpieuc...@nolizard.org solved it for me, but it is still considered not quite the right thing: On Dec 26 20:54:34, m...@online.fr wrote: > I think I understand what goes wrong. The code responsible for matching > the boot device to the actual kernel device on macppc is quite crude, > especially for non-SCSI disks. > > Your bootpath specifies `disk@1' because the disk drive is the second > device (slave) on the ATA channel, the cdrom drive being master. > However, the kernel wants to match this information against a `wd1' > device (as if there were two hard disks on the ATA channel). > > The kernel code needs to be fixed to use device_register() to match the > boot path against actual attachment information, instead of walking the > device tree at the end of autoconf. If nobody beats me to do this, I'll > try to cook a diff in a few days. On May 23 09:29:25, h...@stare.cz wrote: > On May 23 08:41:50, mpieuc...@nolizard.org wrote: > > Were you thinking of something like that? It works for me (c) tm, with > > my PowerBooks (disk@0/wd0), I haven't tried NFS boot yet. > > Jan, does it improve something for you? > > Yes it does: with this patch, I don't need to hardcode > config bsd root on wd0a > into my kernel, it figures the bootpath itself. > > [ using 500872 bytes of bsd ELF symbol table ] > console out [ATY,RockHopper2_A]console in [keyboard] , using USB > using parent ATY,RockHopper2Paren:: memaddr 9800 size 800, : consaddr > 9c008000, : ioaddr 9002, size 2: memtag 8000, iotag 8000: width 1280 > linebytes 1280 height 1024 depth 8 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org > > OpenBSD 5.3-current (GENERIC.MP) #5: Thu May 23 09:02:44 CEST 2013 > r...@www.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC.MP > real mem = 1073741824 (1024MB) > avail mem = 1032151040 (984MB) > mainbus0 at root: model PowerMac10,2 > cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache > mem0 at mainbus0 > spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 > memc0 at mainbus0: uni-n rev 0xd2 > "hw-clock" at memc0 not configured > kiic0 at memc0 offset 0xf8001000 > iic0 at kiic0 > mpcpcibr0 at mainbus0 pci: uni-north > pci0 at mpcpcibr0 bus 0 > pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 > appleagp0 at pchb0 > agp0 at appleagp0: aperture at 0x0, size 0x1000 > vgafb0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01, mmio > wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) > mpcpcibr1 at mainbus0 pci: uni-north > pci1 at mpcpcibr1 bus 0 > pchb1 at pci1 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 > bwi0 at pci1 dev 18 function 0 "Broadcom BCM4318" rev 0x02: irq 52, address > 00:11:24:bf:cb:2a > macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 > openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE > macgpio0 at macobio0 offset 0x50 > "modem-reset" at macgpio0 offset 0x1d not configured > "modem-power" at macgpio0 offset 0x1c not configured > macgpio1 at macgpio0 offset 0x9 irq 47 > "programmer-switch" at macgpio0 offset 0x11 not configured > "gpio5" at macgpio0 offset 0x6f not configured > "gpio6" at macgpio0 offset 0x70 not configured > "extint-gpio15" at macgpio0 offset 0x67 not configured > "escc-legacy" at macobio0 offset 0x12000 not configured > zsc0 at macobio0 offset 0x13000: irq 22,23 > zstty0 at zsc0 channel 0 > zstty1 at zsc0 channel 1 > aoa0 at macobio0 offset 0x1: irq 30,1,2 > audio0 at aoa0 > "timer" at macobio0 offset 0x15000 not configured > adb0 at macobio0 offset 0x16000apm0 at adb0: battery flags 0x0, 0% charged > piic0 at adb0 > iic1 at piic0 > maxtmp0 at iic1 addr 0xc8: max6642 > kiic1 at macobio0 offset 0x18000 > iic2 at kiic1 > wdc0 at macobio0 offset 0x2 irq 24: DMA > ohci0 at pci1 dev 24 function 0 "Apple Intrepid USB" rev 0x00: couldn't map > interrupt > ohci1 at pci1 dev 25 function 0 "Apple Intrepid USB" rev 0x00: couldn't map > interrupt > ohci2 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, > version 1.0, legacy support > ohci3 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 > ohci4 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 > ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 > usb1 at ohci2: USB revision 1.0 > uhub1 at usb1 "Apple OHCI root hub" rev 1.00/1.00 addr 1 > usb2 at ohci3: USB revision 1.0 > uhub2 at usb2 "NEC OHCI root hub" rev 1.00/1.00 addr 1 > usb3 at ohci4: USB revision 1.0 > uhub3
Re: [Question] Building whitelists so that spamd greylisting can work without users perceiving delivery delays...
On Mar 28 12:52:46, s.casw...@protocol6.com wrote: > Hi all, > > I had a question about greylisting (with spamd) in production. > > I've successfully run spamd on firewalls (as a frontend to either barracuda > or SpamAssassin) and have really liked the reduction in SPAM volume. > > Unfortunately my employer's wife does not like the delays that this > introduces into our mail delivery, since she uses email for quick turn-around > communication. > > The main problem occurs with senders like Gmail, yahoo, hotmail, etc. ...i.e. > all the senders that have large farms of smtp servers from which they can > retry delivery after initial greylisting delay. > > I know this means I'm not doing proper whitelisting of those major sender > domains, but I'm at a loss on how to best construct and maintain such a > whitelist. > Are there any up-to-date lists that already track > the MTAs of these large mail providers? For e.g. google, I did dig -t txt _netblocks.google.com | grep spf and put the following in /etc/mail/nospamd 173.194.0.0/16 209.85.128.0/17 74.125.0.0/16 12.31.165.64/27 208.48.95.16/28 216.34.181.0/24 I left out 64.18.0.0/20 and 207.126.144.0/20 as they were sending me a lot of spam. These lists could change of course, but I never got to automatizing it. Jan
