daily CVS update output
Updating src tree: P src/distrib/sets/lists/tests/mi P src/etc/root/dot.profile P src/share/man/man4/ess.4 P src/share/man/man4/options.4 P src/share/man/man4/sf2r.4 P src/share/man/man4/sony.4 P src/share/man/man4/viomb.4 P src/share/man/man4/wss.4 P src/share/man/man4/man4.i386/elansc.4 P src/share/man/man4/man4.i386/spic.4 P src/share/man/man8/afterboot.8 P src/sys/arch/arm/sunxi/sunxi_nand.c P src/sys/arch/i386/pnpbios/pciide_pnpbios.c P src/sys/arch/i386/pnpbios/pnpbios.c P src/sys/arch/i386/stand/lib/netif/am7990.c P src/sys/dev/acpi/acpi_i2c.c P src/sys/dev/mii/ciphy.c P src/sys/dev/mii/mii_physubr.c P src/sys/dev/mii/miivar.h P src/sys/dev/mii/urlphy.c P src/sys/dev/pci/btvmei.c P src/sys/dev/pci/if_wm.c P src/sys/dev/pci/pciide_common.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/dev/vme/vme.c P src/tests/lib/libc/gen/t_siginfo.c P src/tests/lib/libc/sys/t_getrandom.c P src/usr.bin/make/enum.c P src/usr.bin/make/enum.h P src/usr.bin/make/make.c P src/usr.bin/make/make.h P src/usr.bin/make/targ.c P src/usr.bin/make/var.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 44213341 Aug 25 03:04 ls-lRA.gz
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Mon, 24 Aug 2020 at 15:08, Robert Nestor wrote: > > > On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: > > > On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: > >> > >> I received a couple of messages off list that suggested a few things and > >> it prompted me to try investigating further with just components found in > >> NetBSD. > >> > >> This test was run on a fairly recent NetBSD build of 9.99.70. I > >> downloaded the amd64 images for 9.99.71 (the ISO and IMG files), and tried > >> booting them with qemu using -nvmm and the OVMF binaries currently in > >> pkgsrc with the following: > >> > >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > > > -accel nvmm > > > >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > > > the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but > > perhaps this is a typo. Anyway. I have no idea about this particular > > way of specifying the bios; anyway, with > > > > > > -bios /usr/pkg/share/ovmf/OVMFX64.fd \ > > > > it boots just fine. Otherwise I get the same crash as you. > > > > > >>-device ich9-ahci,id=sata \ > >>-device ide-cd,bus=sata.0,drive=disk \ > >>-drive > >> id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso > >> > >> This produces an immediate “failed to start VCPU” and results in a core > >> dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: > > > >> > >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ > >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > >>-device ich9-ahci,id=sata \ > >>-device ide-hd,bus=sata.0,drive=disk \ > >>-drive > >> id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img > >> > >> And it provides the same results - “failed to start VCPU” and a core dump. > >> > >> Removing the “-accel=nvmm” from both of the scripts allows the boot to > >> proceed, but the OVMF code fails to find the CD or HD image and boot falls > >> back to attempting to boot over the network. This appears to be a bug in > >> the version of OVMF found in pkgsrc which is based on stable2018. > >> Replacing the OVMF with binaries obtained from a build of stable202005 > >> fixes the disk access issue and the boot then succeeds brining up the > >> NetBSD installer. > >> > >> I then proceeded to do two installations of NetBSD under qem; one using > >> the defaults for an MBR setup and one for a GPT setup. The resulting MBR > >> disk doesn’t boot under qemu; the GPT disk does boot however. In the case > >> of the MBR disk it appears the problem is that OVMF can’t find the disk or > >> anything bootable on it. > >> > >> I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and > >> PR-55582 for the OVMF issue. > >> > > Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the > NVMM crash and it does boot up the NetBSD CD ISO file. From there I was able > to do two installations of NetBSD, one specifying an MBR partition setup and > one with GPT taking the defaults for both. However, neither of the created > disk image files will boot with the OVMFX64.fd file. Using a newer version > from a stable202005 OVMF build and one from a build done in the last week or > so does boot up the GPT created disk image but not the newly created MBR disk > image. I haven't tried an MBR installation, but my GPT one boots just fine with OVMFX86 - qemu-system-x86_64 \ -m 3072 \ -machine q35 \ -accel nvmm \ -device qemu-xhci \ -device usb-tablet \ -device usb-mouse \ -k en-gb \ -smp 2 \ -net tap,fd=3 3<>/dev/tap1 \ -boot menu=on \ -vnc :1 \ -net nic \ -bios /usr/pkg/share/ovmf/OVMFX64.fd \ -drive format=raw,file=/dev/zvol/rdsk/tank/ztest This is the system I installed yesterday on a fresh zvol, it boots fine. As I have said previously, the same system can't boot if I use X server / gtk output - it boots only if I use vnc. So there is a problem, but I can't figure out who to blame in this case > > So it appears there is a bug in NVMM that causes an abort and dump when any > OVMF file is configured as a pflash device rather than a BIOS. From what I > can see the primary difference in the setup of the use of OVMF is how it > stores any EFI variables it might need or use. Using it as a BIOS option is > the most restrictive for storing and saving UEFI variables. (This may no > longer be true and current versions of OVMF may actually store EFI variables > in a NuVars file in the boot path though.) Using the OVMF file that contains > the read-only
Re: "wireguard" implementation improperly merged and needs revert
Hi Nia, On Mon, Aug 24, 2020 at 5:57 PM nia wrote: > > Hi Jason, > > > We still need to protect the unique identity and reputation of > > WireGuard (our "brand"). This ensures that when people see the > > WireGuard name or logo, they know it is something we, the > > WireGuard developers, have worked on." > > Personally, I would be in favour of entirely rebranding the NetBSD > implementation to avoid this, because it's only introducing ourselves > to potential legal problems. > > It's important that the NetBSD tree remains as free as possible, and > that nobody introduce themselves to potential legal pain by modifying > any part of it. > > We have also had a similar discussion with Mozilla's lawyers and > simply opted to unbrand all of their software which we distribute. > > If only certain people can develop implementations of this protocol, > this is not an open protocol. Please read the reply I just wrote to Maya on tech-net: https://mail-index.netbsd.org/tech-net/2020/08/24/msg007855.html where I basically covered this already. I think you've been misled by others' comments into somehow thinking this is related to trademark stuff, when it isn't at all. And this isn't a situation with "Mozilla's lawyers" or something either; there's no comparison, simply because a "trademark" is simply not part of this discussion here -- i.e. were the question to come up when we're all ready to go here about NetBSD using the name WireGuard to describe its implementation, the answer would be an "of course" and if the question were then, "can you put that in writing?" the answer would be, "yea, sure, why not." This also doesn't have anything to do with "who implements the protocol". Rather, the issue here is that NetBSD doesn't actually implement WireGuard and its protocol. There's a lot more to WireGuard than just crafting some packets that sometimes have the right crypto. I'm afraid that Ozaki-san's code has been picked up with too much haste and not enough study, and we're going to get into an ugly situation if we don't put the breaks on now, before expectations run too high, and reevaluate/restudy. And just to put this discussion back into perspective, I *like* the NetBSD project and I *want* to have everything work as smoothly as possible, and I'm volunteering my *own development time* into helping to make that happen. All I'm asking is that this trajectory here is slowed so that we can do it right. Because I care about getting it right. Jason
Re: "wireguard" implementation improperly merged and needs revert
>> We still need to protect the unique identity and reputation of >> WireGuard (our "brand"). If someone feels this way about it, in my opinion it should be summarily yanked out and never, ever, EVER let back in - at least if there is any legal force behind that attitude. NetBSD's users already have enough of legal morass to navigate; making it worse only, well, makes it worse. Maybe unbranding is enough. Personally, I'm not confident that it is, and it's NetBSD's users' necks - in many jursidctions - on the legal line, not the Foundation's or the Project's. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: "wireguard" implementation improperly merged and needs revert
Hi Jason, > We still need to protect the unique identity and reputation of > WireGuard (our "brand"). This ensures that when people see the > WireGuard name or logo, they know it is something we, the > WireGuard developers, have worked on." Personally, I would be in favour of entirely rebranding the NetBSD implementation to avoid this, because it's only introducing ourselves to potential legal problems. It's important that the NetBSD tree remains as free as possible, and that nobody introduce themselves to potential legal pain by modifying any part of it. We have also had a similar discussion with Mozilla's lawyers and simply opted to unbrand all of their software which we distribute. If only certain people can develop implementations of this protocol, this is not an open protocol.
Re: QEMU booting of non-NetBSD CDs and virtual HDs
On Aug 23, 2020, at 1:57 PM, Chavdar Ivanov wrote: > On Sun, 23 Aug 2020 at 15:41, Robert Nestor wrote: >> >> I received a couple of messages off list that suggested a few things and it >> prompted me to try investigating further with just components found in >> NetBSD. >> >> This test was run on a fairly recent NetBSD build of 9.99.70. I downloaded >> the amd64 images for 9.99.71 (the ISO and IMG files), and tried booting them >> with qemu using -nvmm and the OVMF binaries currently in pkgsrc with the >> following: >> >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ > > -accel nvmm > >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ > > the OVMFX64.fd file is actually in /usrpkg/share/ovmf directory, but > perhaps this is a typo. Anyway. I have no idea about this particular > way of specifying the bios; anyway, with > > > -bios /usr/pkg/share/ovmf/OVMFX64.fd \ > > it boots just fine. Otherwise I get the same crash as you. > > >>-device ich9-ahci,id=sata \ >>-device ide-cd,bus=sata.0,drive=disk \ >>-drive >> id=disk,if=none,media=cdrom,format=raw,file=NetBSD-9.99.71-amd64.iso >> >> This produces an immediate “failed to start VCPU” and results in a core >> dump. Also tried the NetNSD-9.99.71-amd64-install.img file with: > >> >> qemu-system-x86_64 -m 4096 -machine q35 -accel=nvmm -boot menu=on \ >>-device qemu-xhci -device usb-tablet -device usb-mouse -smbios type=2 \ >>-drive if=pflash,format=raw,readonly,file=/usr/pkg/share/OVMFX64.fd \ >>-device ich9-ahci,id=sata \ >>-device ide-hd,bus=sata.0,drive=disk \ >>-drive >> id=disk,if=none,media=disk,format=raw,file=NetBSD-9.99.71-amd64-install.img >> >> And it provides the same results - “failed to start VCPU” and a core dump. >> >> Removing the “-accel=nvmm” from both of the scripts allows the boot to >> proceed, but the OVMF code fails to find the CD or HD image and boot falls >> back to attempting to boot over the network. This appears to be a bug in >> the version of OVMF found in pkgsrc which is based on stable2018. Replacing >> the OVMF with binaries obtained from a build of stable202005 fixes the disk >> access issue and the boot then succeeds brining up the NetBSD installer. >> >> I then proceeded to do two installations of NetBSD under qem; one using the >> defaults for an MBR setup and one for a GPT setup. The resulting MBR disk >> doesn’t boot under qemu; the GPT disk does boot however. In the case of the >> MBR disk it appears the problem is that OVMF can’t find the disk or anything >> bootable on it. >> >> I’ve opened two PRs for these issues. PR-55582 for the NVMM issues and >> PR-55582 for the OVMF issue. >> Indeed, using the OVMFX64.fd file as a -bios parameter does eliminate the NVMM crash and it does boot up the NetBSD CD ISO file. From there I was able to do two installations of NetBSD, one specifying an MBR partition setup and one with GPT taking the defaults for both. However, neither of the created disk image files will boot with the OVMFX64.fd file. Using a newer version from a stable202005 OVMF build and one from a build done in the last week or so does boot up the GPT created disk image but not the newly created MBR disk image. So it appears there is a bug in NVMM that causes an abort and dump when any OVMF file is configured as a pflash device rather than a BIOS. From what I can see the primary difference in the setup of the use of OVMF is how it stores any EFI variables it might need or use. Using it as a BIOS option is the most restrictive for storing and saving UEFI variables. (This may no longer be true and current versions of OVMF may actually store EFI variables in a NuVars file in the boot path though.) Using the OVMF file that contains the read-only code and the read-write variable space is less restrictive, and using a separate OVMF code and variable files provides the most flexibility but only the BIOS usage seems compatible withe NVMM at this point. And it seems there’s a bug in all versions of OVMF at this time that prevents some disk images from booting even though they will boot on real HW. Or there’s something strange about the way the NetBSD installer creates these disks that is incompatible with OVMF at present - or both. -bob
