Re: Installation in a Xen guest (pvgrub)
Am 24.07.2020 17:30, schrieb Theo de Raadt: [...] non-OpenBSD bootloaders will do a shitty job of booting OpenBSD. I'm not going to bother explaining the situation in detail. People who try to go that way have already decided they don't care about the consequences. Ok. Thanks. Are you talking about biosboot or 2nd stage boot? But would it be in theory possible to program a (1) specialized "bootloader" which is bootable by linux-cmd of grub and (2) this specialized "bootloader" continues with the BSD boot code? At the moment I'm thinking of 2nd stage boot. So going from grub 2nd stage via fake-linux-kernel to 2nd stage OpenBSD boot... Part 1 should be doable. But what is about part 2? Would it be possible or are there technical system restrictions making it impossible e.g. like CPU operating modes or restrictions to access the BIOS? And so any further thinking and investigation in this way is waste of time...
Re: Installation in a Xen guest (pvgrub)
Am 21.07.2020 15:51, schrieb Pierre-Philipp Braun: [...] GRUB2 should be able to boot an OpenBSD kernel natively *2. Thing is, PVGRUB works for PV, not PVH nor PVHVM. However you might get NetBSD XEN/PV up and running at your XEN ISP *3, by leveraging PVGRUB indeed *3. And in case UFS is not built-into their PVGRUB binary (that would be weird, as one usually builds pvgrub with all possible modules within), you would still be able to boot it on EXT2 with poor disk performance *4. *1 http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#Direct-Kernel-Boot *2 https://www.gnu.org/software/grub/manual/grub/html_node/Supported-kernels.html *3 https://pub.nethence.com/booting/grub *4 https://pub.nethence.com/bsd/malabar The filesystem modules are available in the pvgrub. But no modules for booting openbsd or netbsd. So "kopenbsd" or "knetbsd" or "multiboot" is not available. Only "linux". Grub does not support this modules for the xen builds (pvgrub). I've checked it in the sources. There is only code for BSD for the hardware build targets of grub and not the xen targets.
Re: Installation in a Xen guest (pvgrub)
Am 10.07.2020 23:30, schrieb Demi M. Obenour: [...] For me, OpenBSD boots fine in HVM mode (with an I/O emulator). I have not tried PVH mode and would not expect it to work. PV mode definitely won’t work, and should be avoided anyway for both security and performance reasons. Is HVM mode okay, or do you need PVH? I'd like to install and boot it in a remote service provider environment. There I have only Linux systems available to install and a Linux rescue system to switch over. The installation is not the problem. I could also use a disk image. For boot I can only rely on a bunch of provided Linux kernels or the pvgrub stuff to boot from the disks. So the only chance to get it running would be the way with the "Xen-grub" I think, if there is no possibility that Linux has learned to boot (not virtual) BSD ;-) Would there be a chance to hack on the Linux-bootcode to boot the BSD-kernel? Makes it sense to look into how this boot works or doesn't it make sense at all?!
Installation in a Xen guest (pvgrub)
Hi, is there a possibility to install/boot OpenBSD in a Xen guest which is booted by pvgrub1 or pvgrub2? The pvgrub is configured to use a /boot/grub/grub.cfg of the guest in the 1st partition. In a non-Xen-grub there is a bsd-module which can boot the installer bsd.rd, but this bsd-module is not available in the xenhost-builds of grub. There is also no chain-module for chainloader configs. Any ideas? Thanks Markus
Re: Xen PV DomU with OpenBSD?
Am 2015-02-23 15:59, schrieb Joel Roberts: My recent experience with OpenBSD under Xen ran into some problems. First, SMP didn't work. At the point in kernel boot where it brings up the other CPUs it would die. Installation of the OS worked because it used a non-SMP kernel. Second, once I was booted I untarred the ports tree. This destroyed the file system. Third is a wish and not a problem per se, I'd like to see PV drivers for disk and network. I'm not a competent kernel developer, but I am willing to offer some monetary compensation for work on these problems. I know the reasons why not to trust EC2, but I'd really like to be able to use OpenBSD on EC2. If you're interested in doing the work, contact me. --Joel On Sat, Feb 21, 2015 at 8:31 PM, Markus Kolb wrote: Hi, there isn't any support for Xen PV DomU in OpenBSD, isn't it? What happened with Christoph Egger's work he is talking about in https://archive.org/details/bsdtalk069 ? Do you have some contact info for Christoph? Is this the same guy http://www.christoph-egger.org/ ? I'd like to join with getting this to work. But my knowledge about BSD kernel is very basic and ends with patching and compiling. I've done some Linux kernel driver fixing and embedded device development. So I would be happy if some more experienced OpenBSD (wo)man could join or at least doing some mentoring to shorten the "educational trail".
Re: Xen PV DomU with OpenBSD?
Am 2015-02-21 22:52, schrieb Raimundo Santos: On 21 February 2015 at 10:31, Markus Kolb wrote: there isn't any support for Xen PV DomU in OpenBSD, isn't it? No, there is not such support. But you can run it in HVM mode without effort. Well, may be some effort in XenServer, where there is no easy way to chose the type of emulated hardware. Another "problem" when using Xen: the shutdown. Every OS that can not communicate with xenstore will suffer from that. You will have to edit some scripts in your environment to make it work with ACPI. Ok. Thanks. But the hoster doesn't support HVM.
Re: spamd whitelist
Am 2015-02-21 23:51, schrieb F Bax: In this archived message; Peter explains here how to get ip address for various gmail servers - which can then be added to whitelist... http://marc.info/?l=openbsd-misc&m=136449396910976&w=2 When I try this process for yahoo.com; I get Why you'd like to whitelist yahoo.com or gmail.com or any other non-related smtp? I think whitelisting makes only sense for smtps you control or are somehow in relation to your network. Is your "smapcop" so heavy on duty that you need to shorten the processing for some mails?
Xen PV DomU with OpenBSD?
Hi, there isn't any support for Xen PV DomU in OpenBSD, isn't it? What happened with Christoph Egger's work he is talking about in https://archive.org/details/bsdtalk069 ? Thanks. Markus
Re: CPU criteria for OpenBSD firewall
Am 2015-02-19 10:51, schrieb Peter Hessler: :choose the CPU with higher Frequency and less cores or for a CPU with :lower frequency but more cores? Higher frequency. Period. Right now, network and PF processing is limited to CPU0. You want that as fast as possible. Additionally, you want as fast memory transfers (from CPU to RAM) as possible. That will give you the most performance. Is it as simple as "Higher frequency."? Shouldn't there be a view on the instruction sets mostly used in network traffic handling and cycle usage of these instructions? Or is this equivalent at the up-to-date processors? If not, it is possible that lower frequency is faster.
Re: Installing OpenBSD 5.6 using a USB Flash drive
Am 2015-02-17 17:27, schrieb A Y: dmesg|grep ^.d0 returns only "sd0" sysctl hw.disknames returns "sd0" and "rd0" my machine is a 10.1 inch netbook Lenovo E10-30 running Intel Celeron N2830 Dual Core 64 bit. Do you think I should have used amd64 installation instead of i386? Will depend mostly on your available RAM. i386 is 32 bit. See https://en.wikipedia.org/wiki/RAM_limit#32-bit_x86_RAM_limit
Re: Installing OpenBSD 5.6 using a USB Flash drive
Am 2015-02-16 15:36, schrieb A Y: Did anyone install OpenBSD 5.6 from a USB Flash drive? Please help... You have already booted from drive, now you only need to select this drive device during installation. You need help exactly with what?
Re: Legacy Laptop stops working with OpenBSD GENERIC >= 5.5
Am 2015-02-11 12:25, schrieb Markus Kolb: Hello, what is your policy for legacy hardware? I'd like to reactivate an old laptop for special purpose with OpenBSD. But I've problems to run supported releases on it. The latest working version is OpenBSD 5.4. Since 5.5 you can read in dmesg (dmesg.boot is attached): cbb0 at pci0 dev 4 function 0 "TI PCI1420 CardBus" rev 0x00: irq 10, CardBus support disabled cbb1 at pci0 dev 4 function 1 "TI PCI1420 CardBus" rev 0x00: irq 10, CardBus support disabled At least since 5.6: When plug-in or -out a network adapter the system freezes mostly. It freezes also when plug-in usb flash stick. Both works with OpenBSD 5.4. Ok, I've remembered ACPI and given it a try to disable in UKC. Now, the stuff works. :-) Thanks.
Legacy Laptop stops working with OpenBSD GENERIC >= 5.5
Hello,
what is your policy for legacy hardware?
I'd like to reactivate an old laptop for special purpose with OpenBSD.
But I've problems to run supported releases on it.
The latest working version is OpenBSD 5.4.
Since 5.5 you can read in dmesg (dmesg.boot is attached):
cbb0 at pci0 dev 4 function 0 "TI PCI1420 CardBus" rev 0x00: irq 10,
CardBus support disabled
cbb1 at pci0 dev 4 function 1 "TI PCI1420 CardBus" rev 0x00: irq 10,
CardBus support disabled
At least since 5.6:
When plug-in or -out a network adapter the system freezes mostly.
It freezes also when plug-in usb flash stick.
Both works with OpenBSD 5.4.
Maybe some additional information. In version 5.3 (no dmesg available)
there was a rev 0x20 or 0x02 what I can remember. Versions greater-equal
5.4 reports always rev 0x00.
But it works with 5.4. So it might not be related to the disabled thing.
thx and br,
Markus
OpenBSD 5.6 (GENERIC) #274: Fri Aug 8 00:05:13 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 128KB L2 cache) 598 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF
real mem = 66547712 (63MB)
avail mem = 53055488 (50MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/12/01, BIOS32 rev. 0 @ 0xfd8a0, SMBIOS
rev. 2.3 @ 0xe4010 (32 entries)
bios0: vendor TOSHIBA version "V1.40" date 06/12/01
bios0: TOSHIBA S1710
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP BOOT
acpi0: wakeup devices PWBN(S4) COM1(S4) MIN0(S4) MIN1(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PWBN
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "PXBAS008" serial 3658Q type NiMH oem "TOSHIBA"
bios0: ROM list: 0xc/0x1 0xe4000/0x4000!
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe000, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Mobility 1" rev 0x64
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
cbb0 at pci0 dev 4 function 0 "TI PCI1420 CardBus" rev 0x00: irq 10, CardBus
support disabled
cbb1 at pci0 dev 4 function 1 "TI PCI1420 CardBus" rev 0x00: irq 10, CardBus
support disabled
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 5729MB, 11733120 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 10
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x03: SMI
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 32MB SDRAM non-parity PC100CL2
clct0 at pci0 dev 8 function 0 "Cirrus Logic CS4281 CrystalClear" rev 0x01 irq 5
ac97: codec id 0x43525914 (Cirrus Logic CS4297A rev 4)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D
audio0 at clct0
"AT&T/Lucent LTMODEM" rev 0x00 at pci0 dev 16 function 0 not configured
cbb0: bad Vcc request. sock_ctrl 0xf000ff00, sock_status 0xf000e2c3
cardslot0 at cbb0 slot 0 flags 0
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
pcmcia1 at cardslot1
isa0 at piixpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (884c3a9652af4325.a) swap on wd0b dump on wd0b
syncing disks... done
cbb0: bad Vcc request. sock_ctrl 0xf000ff00, sock_status 0xf000e2c3
rebooting...
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 128KB L2 cache) 598 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF
real mem = 66580480 (63MB)
avail mem = 54087680 (51MB)
mainbus0 at root
bi
Re: Problems with CPU/ARCH specific compilation!?
Theo de Raadt wrote on Thu, Jun 02, 2005 at 08:51:58 -0600: > Fine, talk what you want about. > > But something you should think about is this: > > It is a good idea if OpenBSD developers read these mailing lists too, > for ideas as to what to change or fix. But if the lists are just > yammerings by idiots, do you think they will read it? Many OpenBSD > developers in fact have unsubscribed from these lists because of the > yammering idiots. Hey, I've posted a nice and friendly request to talk and got flamed by an official OBSD developer. So who is yammering? They attack me and I defend. > So go ahead, talk about what you want to, set your own agenda for the > lists, and drive the developers away. Which agenda? "Miscellaneous discussion about OpenBSD"? That's what I've wanted to do. But don't think about. This is my last post to any of your lists and it was my last OBSD installation. I will never buy any of your CDs again. I regret that I've financed with CDs a value of a nice holiday trip. The work you do is quite good but your mentality has no compatibility with ours. I got it that I am using the wrong OS. Your OS is only useable for things you think about. So nothing free at all when you hate people doing stuff you don't like.
Re: Problems with CPU/ARCH specific compilation!?
[EMAIL PROTECTED] wrote on Thu, Jun 02, 2005 at 11:47:49 +1000: > Quoting Markus Kolb <[EMAIL PROTECTED]>: > > > You don't know after 2 mails that it will be only noise. > > The noise starts when the person who brings up the FAQ, decides to > pursue an issue which developers have already decided on long ago. > > This is OpenBSD. If you don't trust the developers but want to use > OpenBSD in a way which they are not willing to support, then take it, > make your own changes and support yourself. I know this but here are reading other peoples not only developers of OBSD. You can ignore people like me but you have to accept that there are people who wants to talk about this. And because it is not forbidden by any usage limitation of your public available mailinglist you may not official offend those people. Where is your respect. Think about it in real life. You are in a pub and discuss for example political stuff which the owner hears and doesn't like. Do this owner offend you or even kick you out of his pub? No. You do it here.
Re: Problems with CPU/ARCH specific compilation!?
Otto Moerbeek wrote on Wed, Jun 01, 2005 at 17:10:44 +0200: > If we feel that certain posts just add noise and nothing else, we say so. You don't know after 2 mails that it will be only noise. And with your flaming you kill a thread before it starts to become interesting. I have already written: Moderate your lists. Then only for you interesting things are posted and only the OBSD.org guys quarrel. If a moderated list is interesting for other people is another point. If you behave like you've done it is unacceptable and totalitarian.
Re: Problems with CPU/ARCH specific compilation!?
Brad wrote on Wed, Jun 01, 2005 at 09:18:54 -0400: > > There are no "compilation limitations" of OBSD. There are. Have a look at the net/ser port for example. And I will show you in core after I've had a deeper look.
Re: Problems with CPU/ARCH specific compilation!?
Shane J Pearson wrote on Wed, Jun 01, 2005 at 15:49:55 +1000: > Markus, > > On 01/06/2005, at 1:17 AM, Markus Kolb wrote: > > > >Well, if OBSD would done the compiler flagging right then I wouldn't > >have to do it myself. > > I believe OpenBSD has done it right. The official stance is that they > won't support many different custom systems, just to let people blindly > tinker with options which have shown to get little performance boost. At least not in the ports. And although the reponsibility is something else, the conclusion that there might be problems in core is fair. > You have come in here, asked a FAQ, received the standard answer and > think you know better than the developers? If you want to push buttons, I don't want to ask OpenBSD.org-developers because they always think they are right. I want to have a talk with developing users which have experience with compiling to subarchitectures. Next I have asked a FAQ because the answer is nearly as old as OBSD and an unobjective evasion.
Re: Problems with CPU/ARCH specific compilation!?
Otto Moerbeek wrote on Wed, Jun 01, 2005 at 08:10:42 +0200: > > On Tue, 31 May 2005, Markus Kolb wrote: > > > And maybe you should return from anarchy to democracy a little bit. > > If have no idea what political term fits best, but OpenBSD is not a > democracy. We value some people's opinions more than other people's. I don't belong to OpenBSD as a simple OpenBSD mailing list user. I have the right of free speech and it doesn't matter if my speech is valued bad or good but there is no basis to request me to stop writing about OBSD related which doesn't offend against others rights. If OpenBSD.org guys think it is "bad behavior" to talk about compilation limitations of OBSD then it is as oldfashioned as to forbid women to go to work.
Re: Problems with CPU/ARCH specific compilation!?
[EMAIL PROTECTED] wrote on Tue, May 31, 2005 at 15:13:50 +0200: > Markus Kolb <[EMAIL PROTECTED]> writes: > > The OpenBSD mailing lists are for dicussing OpenBSD issues. It has > been repeatedly stated that fiddling with compiler flags is something > that is not done in OpenBSD. Hence, this is not an OpenBSD issue and > should not be dicussed on OpenBSD mailing lists. Well, if OBSD would done the compiler flagging right then I wouldn't have to do it myself. Next I am pretty sure that it is not the fault of GCC but of the code in OBSD. It is quite simple to say it is the fault of someoneelse if you have no idea what is wrong. > The particular issue you mention has also already been discussed on > various mailing lists, including source-changes. If you check the > archives it's been discussed there. OpenBSD mailing lists are not for > people who are not competent enough to do a search in mailing lists > archives. Which issue do you mean? I have searched a lot in the mailing lists and usenet about my special problem and I am not alone with my problem but I could not find a solution. Then there is an unclosed bug report to my issue with aha isa since OBSD 3.4 I think. > The fact that I'm not interested is a very good indication that this > is not something that should be discussed on our mailing lists. Notice > "our", not "your". Maybe you should moderate your lists if it is not welcome when obsd users write things related to obsd in YOUR lists. And maybe you should return from anarchy to democracy a little bit. I don't want to get personal emails from anarchists. Bye
Re: Problems with CPU/ARCH specific compilation!?
Peter Hessler wrote on Mon, May 30, 2005 at 14:39:12 -0700: > > Because gcc generates broken code for -march=i486. The above link *is* > an informative answer, just not what you were looking for. Is it a bug in gcc version implemented in OpenBSD or why I've never seen this in any other architecture optimized compilations? > What problem are you trying to solve with -march=i386 vs -march=i386? > Here's a hint: it doesn't matter. Well, to say it doesn't matter is a bit ignorance. I am pretty sure that an optimised compilation is measureable and feelable faster on restricted hardware. Mostly it works well but the adaptec aha isa driver breaks the loading when optimised compiled. By the way parts of obsd kernel is compiled for i486 by default and future GCC releases will compile i486 code without any compiler options by default. For example SUSE compiled their older SUSE Linux for i486, later for i586 without problems. I have no problems with other BSDs. I don't talk about any speed optimising O flags and so on. It is simple processor instruction optimised code. The ser port is compiled by default with a really stupid march option for athlon: gcc -fPIC -DPIC -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -malign-double -falign-loops -march=athlon -fno-stack-protector -DNAME='"ser"' -DVERSION='"0.8.10"' -DARCH='"i386"' -DOS='"openbsd"' -DCOMPILER='"gcc 3.3"' -D __CPU_i386 -DCFG_DIR='"/etc/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DADAPTIVE_WAI T -DADAPTIVE_WAIT_LOOPS=1024 -DDNS_IP_HACK -DUSE_IPV6 -DDBG_QM_MALLOC -DFAST_LO CK -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SOCKADDR_SA_LEN -DDLSYM_PREFI X='"_"' -I/include -c xjab_jcon.c -o xjab_jcon.o So it has to be just luck that it works everywhere. Simple to say if something doesn't work, it is the fault of anyoneelse isn't good style. So maybe there are a few people who knows about and want to have a technical talk. Markus
Re: Problems with CPU/ARCH specific compilation!?
Joel Dinel wrote on Mon, May 30, 2005 at 14:51:04 -0400: > On 5/30/05, Markus Kolb <[EMAIL PROTECTED]> wrote: > > Hi, > > > > do you have any information why there are problems in OBSD kernel if > > using -march=i486 GCC option for GENERIC kernel compilation? > > > > Parts of the kernel are unuseable. > > Read this; > > http://www.openbsd.org/faq/faq5.html#Why Lol. I knew that this FAQ link will be posted, but it is no informative answer, only lost bandwidth. I want to know why OpenBSD can be succesful compiled with arch i386 and not with i486. A link to a responsible code line would be nice.
Problems with CPU/ARCH specific compilation!?
Hi, do you have any information why there are problems in OBSD kernel if using -march=i486 GCC option for GENERIC kernel compilation? Parts of the kernel are unuseable. Thank you Markus
