Link to Release Candidates
Maybe it’s just me, but putting an announcement of the availability of a Release Candidate at the top of the NetBSD Home Page without having a link to where it can be found seems highly inconvenient. Having to dig thru three or four links and pages to find it doesn’t seem to be helpful in encouraging people to actually download and test it. It’s understandable that there are no links to it on the Port specific web pages as it hasn’t bee released yet. And I guess it’s understandable that there aren’t any links to it in the Developer web pages that offer links to the daily builds and such.
ssh into NetBSD 10.0 from older systems
I installed the latest version of NetBSD 10.0 BETA and tried to ssh into it from an older system, in my case Mac OS X running 9.5 (Mavericks). I got an error “no hostkey alg”. Never saw anything like this when I was running 9.2, and I was able to ssh into the new system from another system running 10.0. After some research and experimentation I discovered that I needed to add this line to the NetBSD /etc/ssh/sshd_config file: HostKeyAlgorithms +ssh-rsa,ssh-dss I mention it here in case someone else stumbles into the problem. Might be nice to add this to the default sshd_config file with a comment that it might be needed to allow older systems to connect. -bob
Re: nvmm users - experience
I haven’t done any testing of NVMM under 10.x or -current, so my observations may be a bit dated. I’m also making an assumption, maybe an incorrect one, that KVM in Linux is very similar to NVMM in NetBSD. Based on that I’d expect to see similar responsiveness and support in both, which hasn’t been what I’ve observed. My testing has all been done on the same machine and I’ve tried to use the same setups in both cases, i.e. the basic change was which type of acceleration is used. (BTW, assuming that KVM and NVMM are indeed quite similar then a test for the completeness of NVMM would seem to be can it install, run and offer the same level of performance as KVM does on identical HW running the same guest systems. The acid test(s) seem to be OS X which generally installs and runs on KVM but won't with NVMM, although most are probably not interested in these systems. One interesting observation in this regard is that OS X 10.6 (Snow Leopard) installs and runs with KVM but doesn’t install with NVMM. However the KVM installed OS will run with NVMM.) For those systems which ran in both setups I’d generally see poorer mouse and keyboard response in NVMM than I did in KVM. In some cases I’d have to change the mouse/keyboard emulation from PS2 to USB or visa versa to get them to work or be a bit more responsive. I’m not sure it this is a problem with NVMM, the way it interfaces with the kernel or the NetBSD kernel itself though. In all my tests I was interfacing to the guest OS from the actual keyboard on my system, not using networking access. Commenting on your follow-up on Xen startup and how I considered doing this in NVMM. I have a rudamentory script that I use to define/create guest systems which also includes some hooks for starting up guest systems. There’s not currently any way I found in NVMM to send in shutdown commands or instructions though which seem to be available in Xen and KVM. I did put hooks in my script to backup and restore guest systems. -bob On May 23, 2023, at 8:11 AM, Mathew, Cherry G.* wrote: > Hi Robert, Matthias, > > (taking current-users@ off Cc:) > > > Thank you so much for your respective replies. Replying further inline > below. > >>>>>> "bob" == Robert Nestor writes: > >bob> My experience with nvmm is limited and was mainly trying to use >bob> it on 9.x, but I have the feeling that development on it has >bob> pretty much ceased and there’s very little interest in >bob> improving it. I’ve been running a comparison experiment seeing >bob> what it takes to get as many systems as possible running in >bob> various environments - NVMM, plain qemu, Linux KVM and >bob> eventually Xen. For the time being I’ve given up on NVMM and >bob> have been concentrating on Linux KVM as I’ve found a number of >bob> systems that seem to install and run fine there which don’t >bob> under NVMM. > > Ok, so it looks like there might be some emulation completeness issues > (related to your variety of workloads) - but I was wondering if you saw > any difference in the "responsiveness" of the guest OS - for eg: when > you login using ssh, have you ever noticed jitter on your keystrokes, or > intermittent freezes, for eg: - I'm specifically asking about the > NetBSD/nvmm case. > > > [...] > > >>>>>> "MP" == Matthias Petermann writes: > > > [...] > > >MP> I came across Qemu/NVMM more or less out of necessity, as I had >MP> been struggling for some time to set up a proper Xen >MP> configuration on newer NUCs (UEFI only). The issue I encountered >MP> was with the graphics output on the virtual host, meaning that >MP> the screen remained black after switching from Xen to NetBSD >MP> DOM0. Since the device I had at my disposal lacked a serial >MP> console or a management engine with Serial over LAN >MP> capabilities, I had to look for alternatives and therefore got >MP> somewhat involved in this topic. > >MP> I'm using the combination of NetBSD 9.3_STABLE + Qemu/NVMM on >MP> small low-end servers (Intel NUC7CJYHN), primarily for classic >MP> virtualization, which involves running multiple independent >MP> virtual servers on a physical server. The setup I have come up >MP> with works stably and with acceptable performance. > > I have a follow-on question about this - Xen has some config tooling > related to startup - so you can say something like > > 'xendomains = dom1, dom2' in /etc/rc.conf, and these domains will be > started during bootup. > > If you did want that for nvmm, what do you use ? > > Regarding the hardware issues, I think I sa
Re: nvmm users - experience
My experience with nvmm is limited and was mainly trying to use it on 9.x, but I have the feeling that development on it has pretty much ceased and there’s very little interest in improving it. I’ve been running a comparison experiment seeing what it takes to get as many systems as possible running in various environments - NVMM, plain qemu, Linux KVM and eventually Xen. For the time being I’ve given up on NVMM and have been concentrating on Linux KVM as I’ve found a number of systems that seem to install and run fine there which don’t under NVMM. The systems I’ve been using to test with are Windows-95, Windows-98, Windows-XP, Windows-10, FreeBSD, FreeDOS, MSDOS, Kubuntu/Ubuntu, LinuxMint, OpenSUSE, NetBSD, Solaris, Haiku, RavynOS and various versions of OS X. Most of these will install and run with LinuxMint in KVM, but fewer than half of them work (even partially) in NVMM. Some of the issues are probably related to host processor speed as is the case with Window-95. Others though appear to be issues in either NetBSD keyboard/mouse handling or how NVMM interfaces with NetBSD for those services. -bob
Re: NetBSD_10.0_BETA boot issues
), class 9/0, rev 2.00/0.00, addr 2
[ 3.127638] uhub5: single transaction translator
[ 3.147638] uhub5: 8 ports with 8 removable, self powered
[ 3.927636] uhub6 at uhub4 port 5: vendor 0557 (0x0557) product 7000
(0x7000), class 9/0, rev 1.10/1.00, addr 3
[ 3.927636] uhub6: 4 ports with 4 removable, self powered
[ 4.817633] uhidev0 at uhub6 port 1 configuration 1 interface 0
[ 4.817633] uhidev0: ATEN (0x0557) CS-1734A V4.2.419 (0x2213), rev
1.10/1.00, addr 4, iclass 3/1
[ 4.837633] ukbd0 at uhidev0
[ 4.837633] wskbd0 at ukbd0: console keyboard
[ 4.847970] uhidev1 at uhub6 port 1 configuration 1 interface 1
[ 4.847970] uhidev1: ATEN (0x0557) CS-1734A V4.2.419 (0x2213), rev
1.10/1.00, addr 4, iclass 3/1
[ 4.867632] ums0 at uhidev1: 5 buttons and Z dir
[ 4.867632] wsmouse0 at ums0 mux 0
[ 4.867632] swwdog0: software watchdog initialized
[ 4.987632] WARNING: 1 error while detecting hardware; check system log.
[ 5.007631] boot device: wd2
[ 5.037631] root on dk3 dumps on dk1
[ 5.067632] root file system type: ffs
[ 5.087631] kern.module.path=/stand/amd64/10.0/modules
[ 5.113455] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.113455] [drm] Driver supports precise vblank timestamp query.
[ 5.113455] i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0)
[ 5.127632] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
[ 5.177631] intelfb0 at i915drmkms0
[ 5.197631] [drm] DRM_I915_DEBUG enabled
[ 5.217631] [drm] DRM_I915_DEBUG_GEM enabled
[ 5.237630] intelfb0: framebuffer at 0xd0005000, size 1920x1200, depth 32,
stride 7680
[ 5.317631] {drm:netbsd:intel_cpu_fifo_underrun_irq_handler+0x64} *ERROR*
CPU pipe A FIFO underrun
[ 5.317631] {drm:netbsd:intel_set_pch_fifo_underrun_reporting+0x14e}
*ERROR* uncleared pch fifo underrun on pch transcoder A
[ 5.317631] {drm:netbsd:cpt_irq_handler+0x1dd} *ERROR* PCH transcoder A
FIFO underrun
[ 5.327631] no data for est. mode 640x480x67
[ 5.937628] wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100
emulation), using wskbd0
[ 6.007627] wsmux1: connecting to wsdisplay0
[ 7.017625] entropy: ready
[ 7.957620] tap0: Ethernet address f2:0b:a4:74:8f:dd
[ 7.967621] tap1: Ethernet address f2:0b:a4:48:14:14
[ 7.977620] tap2: Ethernet address f2:0b:a4:4f:d6:f7
[ 7.987620] tap3: Ethernet address f2:0b:a4:f4:70:26
[16.537588] no data for est. mode 640x480x67
[16.537588] wsdisplay0: screen 1 added (default, vt100 emulation)
[16.537588] no data for est. mode 640x480x67
[16.537588] wsdisplay0: screen 2 added (default, vt100 emulation)
[16.537588] no data for est. mode 640x480x67
[16.537588] wsdisplay0: screen 3 added (default, vt100 emulation)
[16.537588] no data for est. mode 640x480x67
[16.537588] wsdisplay0: screen 4 added (default, vt100 emulation)
[ 1544.481732] ehci0: missed microframe, TT reset not implemented, hub might
be inoperational
On Jan 5, 2023, at 7:02 AM, Martin Husemann wrote:
> On Thu, Jan 05, 2023 at 06:43:32AM -0600, Robert Nestor wrote:
>> Yes it is, but getting a dmesg during the failure seems to be
>> difficult since I haven?t seen a failure when booting with serial
>> console and most of the details of the failure scroll off the screen
>> before the boot crashes.
>
> We don't need the dmesg from the failure case, the working one is fine.
>
> Martin
Re: NetBSD_10.0_BETA boot issues
Martin, Yes it is, but getting a dmesg during the failure seems to be difficult since I haven’t seen a failure when booting with serial console and most of the details of the failure scroll off the screen before the boot crashes. However I may have stumbled across something that could be causing this. The performance improvements between 9.2 and 10.0 are impressive and very noticeable, especially the boot up time. The HP6200 has a fairly fast CPU and all the disks I’m seeing the boot problems on are 5,400 RPM disks. Some are inexpensive 3.5” and some are 2.5” pulls from old laptops installed into 3.5” sleds. All have identical creatures - 16-sector PIO, LBA48 addressing, PIO Mode 4, DMA Mode 2, Ultra DMA Mode 6, Write DMA FUA NCQ 32. On a hunch I dug up a 7,200 RPM disk and installed 10.0 onto it. That disk has never failed to boot and runs 10.0 just fine. So far I’ve booted it up about a dozen times using both BIOS and UEFI and have yet to see any failure. With the 5,400 disks I’d probably be lucky to see one successful boot in a dozen tries, so something is certainly different here! My hunch is that with the performance improvements the code runs a tad bit faster (my guess is something like 10-20% faster) and on a fast enough CPU with slow ATA attached disks sometimes the code gets ahead of the disk in completing a disk request. That might also explain why booting with a serial console never seems to fail as well, as outputting the console log at 9,600 Baud vs dumping it to the attached monitor slows the boot down just enough to succeed. I’m going to try setting the speed on the serial port to the highest I can to see if that tickles the boot issue. -bob On Jan 5, 2023, at 1:35 AM, Martin Husemann wrote: > On Wed, Jan 04, 2023 at 02:07:04PM -0600, Robert Nestor wrote: >> Be happy to try and provide more info if someone has suggestions. > > Is this the same machine as in https://gnats.netbsd.org/56737 ? > As Rin asked there: we need the full dmesg output of the machine. > > Martin
NetBSD_10.0_BETA boot issues
The old problem of IDENTIFY failed and WDCTL_RST failed on the boot disk doesn’t seem to be completely fixed in the current 10.0_BETA builds. When I try to capture the boot output on a serial console it never seems to show up, but when the boot output is sent to the main monitor it seems to fail about 90% of the time. The HW I’m using boots and runs fine with Windows 10, Linux and NetBSD 9.2 using the same disks that show the error in 10.0_BETA, so I’m pretty sure it’s not a disk or other HW problem with my system. Sometimes the boot log shows the “auto configuration error: IDENTIFY failed” and then can’t find any of the partitions on the disk. When this happens it stops because it can’t locate the boot device. Other times it reports this error but then goes on to find the partitions and seems to boot up and run successfully. Usually during boot it reports WDCTL_RST failed and never configures the disk then crashes during the boot sequence. I’ve seen this booting with either BIOS or UEFI, but only with 10.0_BETA and never with 9.2. The system is an HP 6200 with 3 SATA ports. Windows 10 is on a disk on SATA port 0. The boot problem happens regardless of which SATA port the NetBSD disk is attached to. Be happy to try and provide more info if someone has suggestions.
NetBSD 10.0_BETA observations
I’m in the process of installing 10.0_BETA on a system and I’ve seen some transient errors which appear to be related. If a disk contains GPT wedges that I want to destroy and replace with new ones and I script the commands to do this, I often see errors indicating the disk doesn’t contain the information the previous command should have created. Executing the same commands in the same sequence manually always seems to succeed. It’s almost as if the preceding command didn’t have enough time to complete, or the changes weren’t written out to the disk in time for the subsequent command to execute correctly. This occurs more on slower speed devices such as USB 2.0 attached disks or memory sticks. While building some packages under the newly installed 10.0_BETA system on a SATA HD, I’ve occasionally seen a build fail with “directory not found”. But the directory does exist and re-executing the package build command (without first cleaning the work build tree) always succeeds. Again, it seems like the command that created the directory to be used in the build process didn’t complete before the directory needed to be accessed. In building about 400 packages I’ve seen this happen twice, the last time being in the build of seamonkey. Attempting to install from a USB stick using the pre-built Installer image, or attempting to install a new system onto a USB disk isn’t always successful. It often hangs during installation or can’t boot the new USB disk after installation says it has completed successfully. Usually what I see is a screen full of memory ranges printed out and that’s it. I wonder if these issues are also caused by delayed file system updates. Installing from a SATA attached HD to another SATA attached HD worked fine for me though, other than the package build issue noted above. BTW, all the HW and disks used in these attempts work fine under NetBSD 9.2 and Linux, even to the point that both systems can boot and run off SATA HDs, USB disks or USB Geek Sticks.
Re: More floppy oddities
I’ve had floppies that weren’t usable and couldn’t be formatted under Windows, but would format and become usable under OS X. After that they were usable under Windows and NetBSD, and could even be re-formatted under Windows. All the systems used the same HW floppy disk which was a USB drive. Formatting a real floppy or creating an on-disk image of a 2.88M floppy doesn’t seem to be all that straight-forward either. The only way I’ve been able to do it is under Windows (or MSDOS) making sure I had the right version of the MSDOS format utility. Some of the formatting and file structures used in Windows can also lead to other problems as well. For instance, it appears that the ExFAT format can be easily hacked to create disks which appear to have significantly more storage capacity then they actually contain. It’s easy to find devices on Amazon and eBay which claim to have 20, 30,60 TB of storage but in fact are built on a single 32 GB chip. One telltale sign of a fake device like this is when they say the device will become “damaged” if reformatted into NTFS, OS X or and Linux file structure. However the best way to determine if the device is fake is to run the “f3probe” utility on the device in question. (BTW - This would be a nice addition to pkgsrc.)
Re: qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xfffffff0]
Mario, No, I haven’t fixed the problems in NVMM as they’re a bit beyond my capabilities. I’ve been running various tests comparing Linux/KVM to NetBSD/nvmm though (when I’m not otherwise occupied with other activities). So far it appears that there are some systems that run fine with Linux/KVM which have problems in NetBSD/nvmm like the ones you’ve discovered. I’ve been trying to use the same setups with the only difference being the “-accel” parameter. I’m hoping to continue my testing and include NetBSD/xen as well, but that introduces some issues with screen resolution and such. The OVMFX64 file can be found in the package system under sysutil/ovmf. I could be mistaken, but I think the Linux community is now favoring KVM over Xen. I built a script to generate the startup files for both Linux/KVM and NetBSD/nvmm from a the same system configuration definitions to try to keep everything as similar as possible for my tests, and when I figure out what I need for Xen I’ll have it generate those startup files as well. So far I’ve managed to do tests with FreeBSD, FreeDOS, LinuxMint, MSDOS, OpenSUSE, Windows (95, 98, XP) and raynOS. Also had limited success with OS X 10.6 (Snow Leopard) and 10.9 (Mavericks). (It should also be possible to run all Intel based versions of OS X from 10.10 upwards with Linux/KVM building on Simple-KVM.) Using LinuxMint as my Linux test system I’ve also managed to import all my KVM configurations into Virtual Manager which allows me to start/stop and manage the running VMs with a GUI interface which I’ve not been able to do with NetBSD/nvmm. -bob On Jul 16, 2022, at 8:43 PM, Mario Marietto wrote: > Hello. > > I'm here to try to use netbsd with my current graphic hardware. Ascertained > that my GPUs are too new to be used with NetBSD 9.2,I have installed the > OS108 derivative "distribution" based on NetBSD 9.1-stable. I think that it > worked. Now I'm using xfce4 at 1024x768 resolution,but for now it's good > because I can't do this with the 9.2. Anyway,now I could do what I wanted to > try for a long time : some experimentation with qemu and nvmm on netbsd. > Below you can see what are the parameters that I've used to boot a linux vm. > > On NetBSD 9.1-STABLE / OS108 : > > qemu-system-x86_64 -accel nvmm \ > -cpu max -smp cpus=4 -m 8G \ > -drive > if=pflash,format=raw,readonly=on,file=/usr/pkg/share/qemu/edk2-x86_64-code.fd > \ > -drive > id=cdrom,if=none,media=cdrom,file=/home/marietto/Downloads/vm/ubuntu-22.04-desktop-amd64.iso > \ > -drive file=/home/marietto/Downloads/vm/jammy.img,if=none,id=disk0 \ > -object rng-random,filename=/dev/urandom,id=viornd0 \ > -device virtio-rng-pci,rng=viornd0 \ > -netdev user,id=vioif0 -device virtio-net-pci,netdev=vioif0 \ > -audiodev oss,id=oss,out.dev=/dev/audio,in.dev=/dev/audio \ > -device ac97,audiodev=oss \ > -display sdl,gl=on -vga vmware \ > -usb -device usb-mouse,bus=usb-bus.0 > > WARNING: Image format was not specified for > '/home/marietto/Downloads/vm/jammy.img' and probing guessed raw. > Automatically detecting the format is dangerous for raw images, > write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > NetBSD Virtual Machine Monitor accelerator is operational > > Unfortunately here it crashes : > > qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xfff0] > qemu-system-x86_64: NVMM: Failed to execute a VCPU. > [1] Abort trap (core dumped) qemu-system-x86_64 -accel nvmm -cpu max -smp > c... > > Surfing on the net a little bit,I found an interesting post regarding shit > specific bug : > > http://mail-index.netbsd.org/current-users/2020/08/24/msg039417.html > > Robert Nestor says : "with -bios /usr/pkg/share/ovmf/OVMFX64.fd \ it boots > just fine. > > @Robert Nestor : have you been able to fix this bug ? > > I would like to try to do the same as you,but I don't know where I can grab > the file "OVMFX64.fd" because it is not stored in any place on my system. > Thanks. > > -- > Mario.
Re: NVMM issues
On Jun 18, 2021, at 3:43 PM, Chavdar Ivanov wrote: > On Fri, 18 Jun 2021 at 19:36, Robert Nestor wrote: >> >> Playing with FreeDOS 1.2 and 1.3 under nvmm on a NetBSD 9.1-amd64 system and >> ran into some issues. Basically I can do an install from the FreeDOS-1.2 CD >> and run the system afterwards without an issue, but trying to install >> FreeDOS-1.3 the same way aborts in nvmm. If the FreeDOS 1.3 install is done >> on actual hardware it succeeds and the resulting disk image file will boot >> and run fine under nvmm. I’ve also tried running an old copy of Norton >> Symantec Ghost 2003 under both versions (to recover some old files). It >> runs find on real hardware but aborts under nvmm. >> >> Oh, to avoid the system reboot during the installation after FreeDOS >> partitions and formats the new disk, I do this beforehand using qemu-image >> create, vndconfig, fdisk, and newfs_msdos. >> >> # >> # This works for a FreeDOS 1.2 install >> # >> qemu-system-x86_64 -accel nvmm -cpu 486 -smp 1 -m 768 -cdrom ./FD12LGCY.iso >> -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device >> rtl8139,netdev=nd0 -drive file=./FreeDOS-1.2.dsk,media=disk,format=raw >> >> # >> # This fails for a FreeDOS 1.3 install >> # >> qemu-system-x86_64 -accel nvmm -cpu 486 -smp 1 -m 768 -cdrom ./FD13LIVE.iso >> -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device >> rtl8139,netdev=nd0 -drive file=./FreeDOS-1.3.dsk,media=disk,format=raw >> # >> # Error displayed when install fails: >> # >> NetBSD Virtual Machine Monitor accelerator is operational >> qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xb018f] >> qemu-system-x86_64: NVMM: Failed to execute a VCPU. > > I got the same running the newest available qemu-nvmm under today's > -current (well, I prepared the volume myself after the first boot from > the cdrom and started the actual installation after the reboot; the > error takes place after the installation script starts copying data on > the disk); my backing store was a zvol and the command line was c/p-ed > from my other vm's, displaying over vnc. That’s where I saw the error as well - in the file copy which seems like it should be a pretty benign operation. In my case the volumes and such were all on a local disk, so nothing out of the ordinary. Since the abort happens during the installation of the copy of the files to the new disk I tried just doing an xcopy of everything on the boot disk to a new disk and that works OK which makes the error seem even stranger. > I think it is worth a pr. I've looked at the gdb trace, but it doesn't > tell me a lot, to be honest OK, I’ll file a PR against NVMM then assuming that were the problem might lie. > >> >> # >> # However, if the FreeDOS 1.3 system is installed using actual hardware >> # the resulting disk image file boots and runs successfully under nvmm. >> # >> >> # >> # Attemping to run an old copy of Norton Symantec Ghost 2003 in nvmm >> # produces the following error under either FreeDOS 1.2 or FreeDOS 1.3: >> # Note: Ghost 2003 runs fine on real hardware on both versions of FreeDOS >> # on systems with 32-bit (i386) or 64-bit (amd64). >> # >> qemu-system-x86_64: NVMM: Unexpected VM exit code 0x [hw=0x9] >> qemu-system-x86_64: NVMM: Failed to execute a VCPU. >> >> I suspect this is all caused by some bug in nvmm (or qemu). Is this worthy >> of filing a PR and if so should it be against nvmm, qemu or both? >> >> Thanks >> > > > -- >
NVMM issues
Playing with FreeDOS 1.2 and 1.3 under nvmm on a NetBSD 9.1-amd64 system and ran into some issues. Basically I can do an install from the FreeDOS-1.2 CD and run the system afterwards without an issue, but trying to install FreeDOS-1.3 the same way aborts in nvmm. If the FreeDOS 1.3 install is done on actual hardware it succeeds and the resulting disk image file will boot and run fine under nvmm. I’ve also tried running an old copy of Norton Symantec Ghost 2003 under both versions (to recover some old files). It runs find on real hardware but aborts under nvmm. Oh, to avoid the system reboot during the installation after FreeDOS partitions and formats the new disk, I do this beforehand using qemu-image create, vndconfig, fdisk, and newfs_msdos. # # This works for a FreeDOS 1.2 install # qemu-system-x86_64 -accel nvmm -cpu 486 -smp 1 -m 768 -cdrom ./FD12LGCY.iso -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device rtl8139,netdev=nd0 -drive file=./FreeDOS-1.2.dsk,media=disk,format=raw # # This fails for a FreeDOS 1.3 install # qemu-system-x86_64 -accel nvmm -cpu 486 -smp 1 -m 768 -cdrom ./FD13LIVE.iso -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device rtl8139,netdev=nd0 -drive file=./FreeDOS-1.3.dsk,media=disk,format=raw # # Error displayed when install fails: # NetBSD Virtual Machine Monitor accelerator is operational qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xb018f] qemu-system-x86_64: NVMM: Failed to execute a VCPU. # # However, if the FreeDOS 1.3 system is installed using actual hardware # the resulting disk image file boots and runs successfully under nvmm. # # # Attemping to run an old copy of Norton Symantec Ghost 2003 in nvmm # produces the following error under either FreeDOS 1.2 or FreeDOS 1.3: # Note: Ghost 2003 runs fine on real hardware on both versions of FreeDOS # on systems with 32-bit (i386) or 64-bit (amd64). # qemu-system-x86_64: NVMM: Unexpected VM exit code 0x [hw=0x9] qemu-system-x86_64: NVMM: Failed to execute a VCPU. I suspect this is all caused by some bug in nvmm (or qemu). Is this worthy of filing a PR and if so should it be against nvmm, qemu or both? Thanks
Re: SSD errors
Preliminary test results based on your suggestions look very promising. The latest BIOS for this HP machine is 2.28A, but during refurb version J2.31 was installed. No clue what the differences are though. And as Penny might say, I swapped the high tech-techy looking SATA cable for a low tech-techy looking one (actually one of the original HP cables) and ran a pkgsrc update and build on the disk. This usually generates some of the errors, but this time not a one was seen. Guess time will tell if it was just a poor SATA cable or a poorly seating cable. Anyway, thanks for the great suggestions! -bob On Mar 3, 2021, at 8:53 AM, Greg Troxel wrote: > > Robert Nestor writes: > >> Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0: drive supports PIO mode >> 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) >> Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0(ahcisata0:0:0): using PIO >> mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) > > I am not aware of any general problems with NetBSD and SSDs. Lots of > people use them and I don't hear about trouble (other than that SSDs > work great until they fail so you better have backups, just like any > other disk). > > I have a netbsd-9 system with a 2T SSD. My dmesg looks like: > > wd0 at atabus2 drive 0 > wd0: > wd0: drive supports 1-sector PIO transfers, LBA48 addressing > wd0: 1863 GB, 3876021 cyl, 16 head, 63 sec, 512 bytes/sect x 3907029168 > sectors > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), > NCQ (32 tags) > wd0(ahcisata0:2:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), NCQ (31 tags) > > which is just about the same. It works with zero problems. > > My guess is that either your SATA controller is not happily working with > NetBSD, or you have a bad cable or marginal power. I would check BIOS > settings and see if your BIOS is up to date. > > I would also run smartctl, but my experience is that device timeout is a > SATA bus/controller issue and that bad disks get uncorrectable media > errors instead.
Re: SSD errors
Thanks! This is a refurb HP system but this is the only issue I’ve seen with it in the past few years. Last time I check the BIOS was as up to date as HP would take it, but it could be so far out of support that it’s too old for any new updates. I just plugged the SSD into the controller using the same cable where the spinning disk was, but I’ll try using a different cable and moving to another controller to see if that helps. -bob On Mar 3, 2021, at 8:53 AM, Greg Troxel wrote: > > Robert Nestor writes: > >> Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0: drive supports PIO mode >> 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) >> Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0(ahcisata0:0:0): using PIO >> mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) > > I am not aware of any general problems with NetBSD and SSDs. Lots of > people use them and I don't hear about trouble (other than that SSDs > work great until they fail so you better have backups, just like any > other disk). > > I have a netbsd-9 system with a 2T SSD. My dmesg looks like: > > wd0 at atabus2 drive 0 > wd0: > wd0: drive supports 1-sector PIO transfers, LBA48 addressing > wd0: 1863 GB, 3876021 cyl, 16 head, 63 sec, 512 bytes/sect x 3907029168 > sectors > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), > NCQ (32 tags) > wd0(ahcisata0:2:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), NCQ (31 tags) > > which is just about the same. It works with zero problems. > > My guess is that either your SATA controller is not happily working with > NetBSD, or you have a bad cable or marginal power. I would check BIOS > settings and see if your BIOS is up to date. > > I would also run smartctl, but my experience is that device timeout is a > SATA bus/controller issue and that bad disks get uncorrectable media > errors instead.
cp hangs on copies from USB stick
I’m running NetBSD 9.1 on an amd64k system. Wanted to preserve some files from an old Windows-XP system so I initialized a USB stick on Windows and copied the files to it - well most of them. One file was too large to fit so the copy of that file failed when it “ran of the end of the USB stick”. No problem I thought, I’d just copy what was on the USB stick, delete all the files from it and go back and copy that one file that initially didn’t fit. I should have removed the failed file from the USB first but I didn’t and just took it to my NetBSD system to do a “cp -r /usb /archive”. When it got to the one file that had failed to copy correctly it copied all the bytes that were there then “cp” hung and couldn’t or wouldn’t move to the next file it should have found on the USB. At that point I couldn’t kill the “cp” process and the only way I was able to clear it out was to reboot the entire system. Known issues with NetBSD 9.1, or is this something new and if so should I file a PR? Thanks, -bob
SSD errors
I’m running NetBSD 9.1 on an amd64k system. When I run it on a spinning disk I don’t see any errors, but when I install it on an SSD is see a lot of timeout and write errors. Initially I thought it was a failing SSD as the one I’d first used was quite old, so I bought a new Samsung 870. Right out of the box I’m seeing the same errors with it as well. Here’s a short example of the two types of errors I’m seeing: Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags) Feb 26 09:50:59 amd64k /netbsd: [ 8.2150350] boot device: wd0 Feb 26 09:53:07 amd64k /netbsd: [ 90.242252[ 39.4525563] wd0d: device timeout reading fsbn 132143104 of 132143104-132143135 (wd0 bn 132143104; cn 131094 tn 5 sn 37), xfer d0, retry 0 Feb 26 09:53:07 amd64k /netbsd: [ 39.4525563] wd0d: device timeout reading fsbn 19051424 of 19051424-19051455 (wd0 bn 19051424; cn 18900 tn 3 sn 35), xfer 38, retry 0 Feb 26 09:53:07 amd64k /netbsd: [ 39.4525563] wd0d: device timeout reading fsbn 76091008 of 76091008-76091039 (wd0 bn 76091008; cn 75487 tn 1 sn 49), xfer 168, retry 0 Feb 26 09:53:07 amd64k /netbsd: [ 40.0232381] wd0: soft error (corrected) xfer 170 Feb 26 09:53:07 amd64k /netbsd: [ 40.0232381] wd0: soft error (corrected) xfer d8 Is this a known issue with NetBSD running on SSD? Is there some parameter I need in a kernel build that’s not in GENERIC that addresses this? Thanks, -bob
Re: Booting CDs in Qemu
If you’re saying you think the rEFInd CD is expecting to find Apple HW that doesn’t explain why it boots on my Intel PC. I haven’t tried booting it on a Mac. If you’re saying that the CD is incompatible with qemu because qemu is expecting to see or be emulating Mac HW that doesn’t seem to be the case either since I'm running qemu on a PC (not Mac) and haven’t specified anything in my qemu parameters that might be Mac related. I’m basically using the setup you provided in your first message for my qemu setup that works to boot up NetBSD CDs. I can understand that the bootx64.efi file on the CD and in the zip file may be different, but again that doesn’t explain why the CD can boot on real HW but not under qemu. I agree the problem probably isn’t in the OVMF code - I’ve tried various files from different sources which work fine in booting disks under qemu, but given similar results trying to boot CDs. -bob On Aug 7, 2020, at 12:10 PM, Chavdar Ivanov wrote: > On Fri, 7 Aug 2020 at 14:21, Robert Nestor wrote: >> >> Thanks again! Your patience and suggestions have helped a lot and (I think) >> I have a much better understanding of the whole process now. >> >> As Martin wrote, it appears to be an issue or limitation in qemu with UEFI >> booting CDs. Probably that the OVMF code is very specific in where it looks >> for the UEFI boot files whereas the real implementation (on my PC at least) >> is much more forgiving. > > I don't think it is anything to do with the OVFM code. If you are > using the same ISO file I tried to use - which hangs on boot - the ISO > file is perfectly readable by the EFI shell. I attached that > refind.iso to the VM and got into the internal efi shell; it can see > the cdrom as fs1:, one can see there the usual file structure - > EFI\boot and EFI\tools. The tools folder contains stuff relevant only > to Apple installations - gdisk etc. - which can be started, but are > not functional. The boot folder contains the necessary boot_x64.efi > file, which is different from the one coming from the zip file; if you > run it, you get a stuck system as when you try to boot from the iso > file. So as far as the iso file I am trying, it is only incompatible > with the qemu machine, expecting to see an Apple hardware perhaps. > > Now if someone has any idea how to configure the mouse in -current to > get it properly running with the wsfb graphics... It kinda works, but > a very small rectangle in the top left corner covers the movement on > the screen. It may be a problem with the VNS client, of course - mine > is RealVNC under Windows 10 at the moment. > >> >> -bob >> >> On Aug 7, 2020, at 7:02 AM, Chavdar Ivanov wrote: >> >>> On Fri, 7 Aug 2020 at 12:54, Robert Nestor wrote: >>>> >>>> OK, I tried doing this with just the rEFInd CD and it still didn’t boot - >>>> just get a blank screen. Since you did this by copying the rEFInd files >>>> over to a bootable NetBSD CD (or did you copy them to an installed NetBSD >>>> disk?) the two CD aren’t configured the same way. Neither CD has an >>>> MSDOS partition/wedge for EFI and I can’t find where the files for UEFI >>>> booting are on the NetBSD CD. My understanding of UEFI is that the boot >>>> files must live in an MSDOS/FAT partition, though that doesn’t explain how >>>> or why the rEFInd CD boots on real HW via UEFI. >>> >>> As I said, I couldn't do anything with refind.iso either. >>> >>> I created a vm with the UEFI selected, installed yesterday's -current >>> - which, as you know, installs both on BIOS and UEFI. I selected GPT >>> scheme for the disk, this obviously creates a MS-DOS formatted EFI >>> slice, where I later placed the requisite files from rEFInd, edited a >>> bit refind.conf to show the NetBSD menu clearly, rebooted into the >>> boot management environment and set the bootx64.efi from the refind >>> directory to be the primary option. So no iso involvement, the files >>> for the rEFInd tree were copied from the .zip file. >>> >>>> >>>> So I’m even more confused now. >>>> >>>> -bob >>>> >>>> On Aug 7, 2020, at 2:58 AM, Chavdar Ivanov wrote: >>>> >>>>> On Fri, 7 Aug 2020 at 02:35, Robert Nestor wrote: >>>>>> >>>>>> OK, thanks! I’m not sure I fully understand what you mean by “moved >>>>>> the relevant file to the top”. Do you mean you moved the >>>>>> \EFI\boot\bootx64.efi file to \EFI\bootx64.efi? >>>>> >>>>> I
Re: Booting CDs in Qemu
Thanks again! Your patience and suggestions have helped a lot and (I think) I have a much better understanding of the whole process now. As Martin wrote, it appears to be an issue or limitation in qemu with UEFI booting CDs. Probably that the OVMF code is very specific in where it looks for the UEFI boot files whereas the real implementation (on my PC at least) is much more forgiving. -bob On Aug 7, 2020, at 7:02 AM, Chavdar Ivanov wrote: > On Fri, 7 Aug 2020 at 12:54, Robert Nestor wrote: >> >> OK, I tried doing this with just the rEFInd CD and it still didn’t boot - >> just get a blank screen. Since you did this by copying the rEFInd files >> over to a bootable NetBSD CD (or did you copy them to an installed NetBSD >> disk?) the two CD aren’t configured the same way. Neither CD has an MSDOS >> partition/wedge for EFI and I can’t find where the files for UEFI booting >> are on the NetBSD CD. My understanding of UEFI is that the boot files must >> live in an MSDOS/FAT partition, though that doesn’t explain how or why the >> rEFInd CD boots on real HW via UEFI. > > As I said, I couldn't do anything with refind.iso either. > > I created a vm with the UEFI selected, installed yesterday's -current > - which, as you know, installs both on BIOS and UEFI. I selected GPT > scheme for the disk, this obviously creates a MS-DOS formatted EFI > slice, where I later placed the requisite files from rEFInd, edited a > bit refind.conf to show the NetBSD menu clearly, rebooted into the > boot management environment and set the bootx64.efi from the refind > directory to be the primary option. So no iso involvement, the files > for the rEFInd tree were copied from the .zip file. > >> >> So I’m even more confused now. >> >> -bob >> >> On Aug 7, 2020, at 2:58 AM, Chavdar Ivanov wrote: >> >>> On Fri, 7 Aug 2020 at 02:35, Robert Nestor wrote: >>>> >>>> OK, thanks! I’m not sure I fully understand what you mean by “moved the >>>> relevant file to the top”. Do you mean you moved the >>>> \EFI\boot\bootx64.efi file to \EFI\bootx64.efi? >>> >>> I wrote this too late in the night. I mean I got into the EFI menu >>> setup, Boot Management and moved the last entry - for rEFInd - to the >>> top; the next entry was the one from the disk, which I can still >>> select to boot NetBSD directly. >>> >>>> >>>> There was an old reference I found in my search that seemed to imply this >>>> was a solution, but then I don’t see how the NetBSD CD booted. Doesn’t >>>> it’s bootx64.efi file live in \EFI\boot\bootx64.efi just like it does on >>>> the rEFInd CD? >>> >>> Yes. >>> >>> nbsdu# mount -t msdos /dev/dk0 /mnt/efi/ >>> nbsdu# find /mnt/efi/ | egrep -v icons/ >>> /mnt/efi/ >>> /mnt/efi/EFI >>> /mnt/efi/EFI/boot >>> /mnt/efi/EFI/boot/bootia32.efi >>> /mnt/efi/EFI/boot/bootx64.efi >>> /mnt/efi/EFI/refind >>> /mnt/efi/EFI/refind/refind_x64.efi >>> /mnt/efi/EFI/refind/refind.conf >>> /mnt/efi/EFI/refind/icons >>> ... >>> /mnt/efi/NvVars >>>> >>>> -bob >>>> >>>> On Aug 6, 2020, at 7:26 PM, Chavdar Ivanov wrote: >>>> >>>>> On Fri, 7 Aug 2020 at 01:11, Chavdar Ivanov wrote: >>>>>> >>>>>> On Fri, 7 Aug 2020 at 01:05, Robert Nestor wrote: >>>>>>> >>>>>>> Just dawned on me, I’m betting the NetBSD CD is configured to boot >>>>>>> either via BIOS or UEFI and Qemu is probably trying BIOS first since >>>>>>> that’s its default. >>>>>> >>>>>> No, it definitely says that it is booting in EFI mode. if you >>>>>> interrupt it and drop to the command prompt, you can see the efivars. >>>>>> The graphics is also wsfb and the console looks like the NetBSD >>>>>> console after a UEFI boot; X -configure makes the relevant xorg.conf >>>>>> file (however, modesetting does not work, one has to change it to >>>>>> wsfb; also in my case - over VNC - the mouse driver has to be changed >>>>>> to 'ws', although even this way it works incorrectly). >>>>>> >>>>>> I tried to boot the rEFInd.iso file, I presume the same you've tried - >>>>>> of v. 0.12 - and got the same result as you - just the logo in the >>>>>> middle of the screen. >>>>>> >
Re: Booting CDs in Qemu
Yes, that’s what I’m now suspecting. But when I started I didn’t know enough about qemu and the CD booting process with UEFI to know if it was my error or a bug someplace. Plus my system isn’t running 9.99.69 with current packages, so it could be that I’m missing something that’s already been fixed. I’m updating my system and installed packages to verify that the issue is still there, and if so, I’ll file a an issue with the qemu folks. -bob On Aug 7, 2020, at 7:44 AM, Martin Husemann wrote: > On Fri, Aug 07, 2020 at 06:54:08AM -0500, Robert Nestor wrote: >> OK, I tried doing this with just the rEFInd CD and it still didn't boot - >> just get a blank screen. Since you did this by copying the rEFInd files >> over to a bootable NetBSD CD (or did you copy them to an installed NetBSD >> disk?) the two CD aren?t configured the same way. Neither CD has an MSDOS >> partition/wedge for EFI and I can?t find where the files for UEFI booting >> are on the NetBSD CD. My understanding of UEFI is that the boot files must >> live in an MSDOS/FAT partition, though that doesn't explain how or why the >> rEFInd CD boots on real HW via UEFI. >> >> So I'm even more confused now. > > Isn't this a plain QEMU (or more likely: qemu firmware) issue? > I would suggest to report it upstream. > > Martin
Re: Booting CDs in Qemu
OK, I tried doing this with just the rEFInd CD and it still didn’t boot - just get a blank screen. Since you did this by copying the rEFInd files over to a bootable NetBSD CD (or did you copy them to an installed NetBSD disk?) the two CD aren’t configured the same way. Neither CD has an MSDOS partition/wedge for EFI and I can’t find where the files for UEFI booting are on the NetBSD CD. My understanding of UEFI is that the boot files must live in an MSDOS/FAT partition, though that doesn’t explain how or why the rEFInd CD boots on real HW via UEFI. So I’m even more confused now. -bob On Aug 7, 2020, at 2:58 AM, Chavdar Ivanov wrote: > On Fri, 7 Aug 2020 at 02:35, Robert Nestor wrote: >> >> OK, thanks! I’m not sure I fully understand what you mean by “moved the >> relevant file to the top”. Do you mean you moved the \EFI\boot\bootx64.efi >> file to \EFI\bootx64.efi? > > I wrote this too late in the night. I mean I got into the EFI menu > setup, Boot Management and moved the last entry - for rEFInd - to the > top; the next entry was the one from the disk, which I can still > select to boot NetBSD directly. > >> >> There was an old reference I found in my search that seemed to imply this >> was a solution, but then I don’t see how the NetBSD CD booted. Doesn’t >> it’s bootx64.efi file live in \EFI\boot\bootx64.efi just like it does on the >> rEFInd CD? > > Yes. > > nbsdu# mount -t msdos /dev/dk0 /mnt/efi/ > nbsdu# find /mnt/efi/ | egrep -v icons/ > /mnt/efi/ > /mnt/efi/EFI > /mnt/efi/EFI/boot > /mnt/efi/EFI/boot/bootia32.efi > /mnt/efi/EFI/boot/bootx64.efi > /mnt/efi/EFI/refind > /mnt/efi/EFI/refind/refind_x64.efi > /mnt/efi/EFI/refind/refind.conf > /mnt/efi/EFI/refind/icons > ... > /mnt/efi/NvVars >> >> -bob >> >> On Aug 6, 2020, at 7:26 PM, Chavdar Ivanov wrote: >> >>> On Fri, 7 Aug 2020 at 01:11, Chavdar Ivanov wrote: >>>> >>>> On Fri, 7 Aug 2020 at 01:05, Robert Nestor wrote: >>>>> >>>>> Just dawned on me, I’m betting the NetBSD CD is configured to boot either >>>>> via BIOS or UEFI and Qemu is probably trying BIOS first since that’s its >>>>> default. >>>> >>>> No, it definitely says that it is booting in EFI mode. if you >>>> interrupt it and drop to the command prompt, you can see the efivars. >>>> The graphics is also wsfb and the console looks like the NetBSD >>>> console after a UEFI boot; X -configure makes the relevant xorg.conf >>>> file (however, modesetting does not work, one has to change it to >>>> wsfb; also in my case - over VNC - the mouse driver has to be changed >>>> to 'ws', although even this way it works incorrectly). >>>> >>>> I tried to boot the rEFInd.iso file, I presume the same you've tried - >>>> of v. 0.12 - and got the same result as you - just the logo in the >>>> middle of the screen. >>>> >>>> I'll install manually rEFInd in the vm I just spun up to see if it can >>>> be recognized. >>> >>> I was able to install rEFInd manually in the efi partition of that >>> NetBSD installation and boot it under OVMF (I rebooted the machine and >>> just hit 'escape' in the VNC window, which got me to the EFI setup >>> menu, where I located the relevant efi file and moved it to the top). >>> >>> Chavdar >>> >>>> >>>>> >>>>> -bob >>>>> >>>>> On Aug 6, 2020, at 6:20 PM, Chavdar Ivanov wrote: >>>>> >>>>>> With: >>>>>> >>>>>> >>>>>> /usr/pkg/bin/qemu-system-x86_64 \ >>>>>> -device qemu-xhci \ >>>>>> -device usb-tablet \ >>>>>> -machine q35 \ >>>>>> -bios /usr/pkg/share/ovmf/OVMFX64.fd \ >>>>>> -m 4096 \ >>>>>> -k en-gb \ >>>>>> -smp 2 \ >>>>>> -accel nvmm \ >>>>>> -vnc :1 \ >>>>>> -drive format=raw,file=/dev/zvol/rdsk/pail/testu-new \ >>>>>> -net tap,fd=3 3<>/dev/tap1 \ >>>>>> -net nic \ >>>>>> -cdrom /iso/NetBSD-9.99.69-amd64.iso >>>>>> >>>>>> >>>>>> I was able to boot today's -current in efi mode, no problem. >>>>>> Obviously, I access the console over vnc. >>>>>> >>>>>> Chav
Re: Booting CDs in Qemu
OK, thanks! I’m not sure I fully understand what you mean by “moved the relevant file to the top”. Do you mean you moved the \EFI\boot\bootx64.efi file to \EFI\bootx64.efi? There was an old reference I found in my search that seemed to imply this was a solution, but then I don’t see how the NetBSD CD booted. Doesn’t it’s bootx64.efi file live in \EFI\boot\bootx64.efi just like it does on the rEFInd CD? -bob On Aug 6, 2020, at 7:26 PM, Chavdar Ivanov wrote: > On Fri, 7 Aug 2020 at 01:11, Chavdar Ivanov wrote: >> >> On Fri, 7 Aug 2020 at 01:05, Robert Nestor wrote: >>> >>> Just dawned on me, I’m betting the NetBSD CD is configured to boot either >>> via BIOS or UEFI and Qemu is probably trying BIOS first since that’s its >>> default. >> >> No, it definitely says that it is booting in EFI mode. if you >> interrupt it and drop to the command prompt, you can see the efivars. >> The graphics is also wsfb and the console looks like the NetBSD >> console after a UEFI boot; X -configure makes the relevant xorg.conf >> file (however, modesetting does not work, one has to change it to >> wsfb; also in my case - over VNC - the mouse driver has to be changed >> to 'ws', although even this way it works incorrectly). >> >> I tried to boot the rEFInd.iso file, I presume the same you've tried - >> of v. 0.12 - and got the same result as you - just the logo in the >> middle of the screen. >> >> I'll install manually rEFInd in the vm I just spun up to see if it can >> be recognized. > > I was able to install rEFInd manually in the efi partition of that > NetBSD installation and boot it under OVMF (I rebooted the machine and > just hit 'escape' in the VNC window, which got me to the EFI setup > menu, where I located the relevant efi file and moved it to the top). > > Chavdar > >> >>> >>> -bob >>> >>> On Aug 6, 2020, at 6:20 PM, Chavdar Ivanov wrote: >>> >>>> With: >>>> >>>> >>>> /usr/pkg/bin/qemu-system-x86_64 \ >>>> -device qemu-xhci \ >>>> -device usb-tablet \ >>>> -machine q35 \ >>>> -bios /usr/pkg/share/ovmf/OVMFX64.fd \ >>>> -m 4096 \ >>>> -k en-gb \ >>>> -smp 2 \ >>>> -accel nvmm \ >>>> -vnc :1 \ >>>> -drive format=raw,file=/dev/zvol/rdsk/pail/testu-new \ >>>> -net tap,fd=3 3<>/dev/tap1 \ >>>> -net nic \ >>>> -cdrom /iso/NetBSD-9.99.69-amd64.iso >>>> >>>> >>>> I was able to boot today's -current in efi mode, no problem. >>>> Obviously, I access the console over vnc. >>>> >>>> Chavdar >>>> >>>> On Thu, 6 Aug 2020 at 23:33, Robert Nestor wrote: >>>>> >>>>> Something simple I must be missing here. I downloaded the CD image of >>>>> rEFInd from: >>>>> >>>>> http://sourceforge.net/projects/refind/files/0.12.0/refind-cd-0.12.0.zip/download >>>>> >>>>> Burned it to a CD and tried booting that CD on my PC. It doesn’t boot >>>>> using BIOS, but it does boot using UEFI. So I know the CD is good. I >>>>> saved the ISO file that I used to burn the CD. >>>>> >>>>> Tried booting the ISO file in qemu with: >>>>> qemu-system-x86_64 -boot d -cdrom refind.iso -m 512 >>>>> >>>>> And got an error that it couldn’t boot with error code 0009. Ok this >>>>> appears to mean that qemu tried booting it with a default BIOS boot which >>>>> the CD isn’t configured for. The recommended solution is to either add >>>>> the BIOS boot code to the CD or specify a OVMF/UEFI boot file to Qemu. >>>>> >>>>> Installed the OVMF package and tried booting again with: >>>>> qmeu-system-x86_64 -bios /usr/pkg/share/ovmf/OVMFX64.bin —m 512 \ >>>>> -boot d -cdrom refind.iso >>>>> >>>>> Got the Tianocore splash screen then the UEFI shell. Entered “exit” at >>>>> the shell prompt and got a message "Graphics Console Started" and then >>>>> nothing. Also tried the OVMFIA32.fd file with identical results. Adding >>>>> “-vga std” to the command line didn’t change things either. >>>>> >>>>> For grins I added “-accel mvmm” to the command line and got the error: >>>>> Failed to execute a VCPU >>>>> >>>>> So I have three questions: First, what am I missing to get this bootable >>>>> CD to boot up in qemu? And second, is there a limitation in NVMM that >>>>> prevents it from running this boot sequence? And finally, if I get the >>>>> magic sequence that allows the CD to boot with qemu, is there a way of >>>>> booting without getting the UEFI shell prompt? >>>>> >>>>> Thanks >>>> >>>> >>>> >>>> -- >>>> >>> >> >> >> -- >> > > > > -- >
Re: Booting CDs in Qemu
Just dawned on me, I’m betting the NetBSD CD is configured to boot either via BIOS or UEFI and Qemu is probably trying BIOS first since that’s its default. -bob On Aug 6, 2020, at 6:20 PM, Chavdar Ivanov wrote: > With: > > > /usr/pkg/bin/qemu-system-x86_64 \ >-device qemu-xhci \ >-device usb-tablet \ >-machine q35 \ >-bios /usr/pkg/share/ovmf/OVMFX64.fd \ >-m 4096 \ >-k en-gb \ >-smp 2 \ >-accel nvmm \ >-vnc :1 \ >-drive format=raw,file=/dev/zvol/rdsk/pail/testu-new \ >-net tap,fd=3 3<>/dev/tap1 \ >-net nic \ >-cdrom /iso/NetBSD-9.99.69-amd64.iso > > > I was able to boot today's -current in efi mode, no problem. > Obviously, I access the console over vnc. > > Chavdar > > On Thu, 6 Aug 2020 at 23:33, Robert Nestor wrote: >> >> Something simple I must be missing here. I downloaded the CD image of >> rEFInd from: >> >> http://sourceforge.net/projects/refind/files/0.12.0/refind-cd-0.12.0.zip/download >> >> Burned it to a CD and tried booting that CD on my PC. It doesn’t boot using >> BIOS, but it does boot using UEFI. So I know the CD is good. I saved the >> ISO file that I used to burn the CD. >> >> Tried booting the ISO file in qemu with: >>qemu-system-x86_64 -boot d -cdrom refind.iso -m 512 >> >> And got an error that it couldn’t boot with error code 0009. Ok this >> appears to mean that qemu tried booting it with a default BIOS boot which >> the CD isn’t configured for. The recommended solution is to either add the >> BIOS boot code to the CD or specify a OVMF/UEFI boot file to Qemu. >> >> Installed the OVMF package and tried booting again with: >>qmeu-system-x86_64 -bios /usr/pkg/share/ovmf/OVMFX64.bin —m 512 \ >> -boot d -cdrom refind.iso >> >> Got the Tianocore splash screen then the UEFI shell. Entered “exit” at the >> shell prompt and got a message "Graphics Console Started" and then nothing. >> Also tried the OVMFIA32.fd file with identical results. Adding “-vga std” >> to the command line didn’t change things either. >> >> For grins I added “-accel mvmm” to the command line and got the error: >>Failed to execute a VCPU >> >> So I have three questions: First, what am I missing to get this bootable CD >> to boot up in qemu? And second, is there a limitation in NVMM that prevents >> it from running this boot sequence? And finally, if I get the magic sequence >> that allows the CD to boot with qemu, is there a way of booting without >> getting the UEFI shell prompt? >> >> Thanks > > > > -- >
Re: Booting CDs in Qemu
This helps a bit but still not quite there. Adding the “-device qemu-xhci -device usb-tablet -machine q35” gets me to the BIOS menu screen, but even after setting the boot device to the CDROM it still doesn’t boot up to the rEFInd screen. Also adding “-accel mvmm” didn’t hurt but didn’t get me any further in the boot. So I’m assuming that there’s something uniquely special about the rEFInd CDROM and how it’s configured for UEFI booting that doesn’t agree with Qemu? -bob On Aug 6, 2020, at 6:20 PM, Chavdar Ivanov wrote: > /usr/pkg/bin/qemu-system-x86_64 \ >-device qemu-xhci \ >-device usb-tablet \ >-machine q35 \ >-bios /usr/pkg/share/ovmf/OVMFX64.fd \ >-m 4096 \ >-k en-gb \ >-smp 2 \ >-accel nvmm \ >-vnc :1 \ >-drive format=raw,file=/dev/zvol/rdsk/pail/testu-new \ >-net tap,fd=3 3<>/dev/tap1 \ >-net nic \ >-cdrom /iso/NetBSD-9.99.69-amd64.iso
Booting CDs in Qemu
Something simple I must be missing here. I downloaded the CD image of rEFInd from: http://sourceforge.net/projects/refind/files/0.12.0/refind-cd-0.12.0.zip/download Burned it to a CD and tried booting that CD on my PC. It doesn’t boot using BIOS, but it does boot using UEFI. So I know the CD is good. I saved the ISO file that I used to burn the CD. Tried booting the ISO file in qemu with: qemu-system-x86_64 -boot d -cdrom refind.iso -m 512 And got an error that it couldn’t boot with error code 0009. Ok this appears to mean that qemu tried booting it with a default BIOS boot which the CD isn’t configured for. The recommended solution is to either add the BIOS boot code to the CD or specify a OVMF/UEFI boot file to Qemu. Installed the OVMF package and tried booting again with: qmeu-system-x86_64 -bios /usr/pkg/share/ovmf/OVMFX64.bin —m 512 \ -boot d -cdrom refind.iso Got the Tianocore splash screen then the UEFI shell. Entered “exit” at the shell prompt and got a message "Graphics Console Started" and then nothing. Also tried the OVMFIA32.fd file with identical results. Adding “-vga std” to the command line didn’t change things either. For grins I added “-accel mvmm” to the command line and got the error: Failed to execute a VCPU So I have three questions: First, what am I missing to get this bootable CD to boot up in qemu? And second, is there a limitation in NVMM that prevents it from running this boot sequence? And finally, if I get the magic sequence that allows the CD to boot with qemu, is there a way of booting without getting the UEFI shell prompt? Thanks
Re: Recent web page changes
As I recall there used to be a link to the mailing lists on the main web page under the Support category along with the ones that are still listed on the new web page. Finding the link to “Release engineering” used to be a treasure hunt, but now it’s much easier with the link under Developers on the new main web page. -bob On Jul 31, 2020, at 7:18 AM, Greg Troxel wrote: > Clay Daniels writes: > >> No one seems to have this fixed yet as far as I can see. However, majordomo >> still works. I just sent an email to majord...@netbsd.org with the word >> "lists" in the body of the mail, and it returned a list of mailing lists >> and other helpful info. > > At: > > http://wiki.netbsd.org/community/ > > mailinglists are the first thing. But they didn't have an obvious > header, so I can see how they would be missed. > > >> I like the new look of the website, but we do need to make it a little >> easier for folks not familiar with NetBSD to join a list. Maybe we are >> trying to phase out the lists in favor of the forums? > > "We" are definitely not doing that.
Re: Use network printer from NetBSD
For a simple test you could do something like “cat && printf “\00c"
>test_print” then lpr test_print where is the plain text file your want
printed.
My newer printer also supports the 9100 feature, but I don’t use it. My print
cap file just contains:
# Default handler
lp:
:sh:lp=:mx#0:rm=192.168.1.2:rp=TEXT_P1:lf=/var/log/lpd-errs:sd=/var/spool/output/lpd:
The filter I used to convert everything to Postscript to send to the printer:
#\!/bin/sh
# Check to see if input is PostScript. If not, pass through enscript.
read firstline
firstchars=`expr "$firstline" : "\(..\)"`
if [ "$firstchars" = "%!" ]
then
# PostScript file; pass through $firstline and rest of file
echo "$firstline" && cat && printf "\004"
exit 0
else
# Not PostScript file; use enscript to process
(echo "$firstline"; cat) | /usr/pkg/bin/enscript -p- -L 66 &&
printf "\004"
exit 0
fi
But if you do something like that you’ll probably want to change your print cap
file to send output to the POSTSCRIPT_P1 queue instead of the TEXT_P1 queue
since everything should be in Postscript format after applying this filter.
And of course you need to add the reference to the filter in your printcap file.
Hope this helps,
-bob
On Jul 4, 2020, at 9:07 AM, Rocky Hotas wrote:
> On giu 26 6:45, Robert Nestor wrote:
>> It’s been a few years since I set up my HL-1270N, but as I recall I found
>> the information on the internal queues and the requirement for sending the
>> EOT at the end of a document in the User’s Manual. And I think they get
>> listed when I ask the printer to print out a configuration report which can
>> be done from the BRAdmin utility, logging into the printer via web browser
>> or holding down the test button in the back of the printer.
>
> After (literally) days of attempts, I found something very similar,
> also thanks to what you suggested here. In the web configuration
> interface, I found (as mentioned in a previous message from today):
>
> Enabled Services
>BRN3C2AF4E874A2
>BINARY_P1
>TEXT_P1
>POSTSCRIPT_P1
>PCL_P1
>BRN3C2AF4E874A2_AT
>
> Each of them has a minimum possible configuration. For example,
>
> TEXT_P1
> Service Name TEXT_P1
> Service Port P1
> Protocols TCP/IPIPP
> FilterText Substitution
> Control Strings Beginning of Job1)
> End of Job 11)\0C
> Raw TCP Port 9100
> Service Options Bi-Directional
>
> `1)' and `11)' are just the lines of a list menu. It seems (but it's
> just a guess from me) that a plain text stream must not be introduced by
> any character and that must be concluded by `\0c'.
>
> I tried
>
> { printf 'test \014%%'; sleep 5; } | telnet 9100
>
> with no success.
>
> How did you append `\004' to the end of your files with your old Brother
> HL-1270N?
>
>> I scanned thru the manual on your printer and didn’t find any of the same
>> information, but it looks like that printer has more features than a moon
>> rocket, so I could have missed something though.
>
> It seems so to me too :).
>
> Bye!
>
> Rocky
Re: Trouble installing NetBSD 9.0 amd64
Reading this thread it appears to me Ahi was booting up from NetBSD 8.0 on a USB stick and then trying to install 9.0 on his hard drive. I’m not sure, but that could be part of his problem. I seem to recall running into problems with GPT partitioning and UEFI booting when I tried doing this some time ago. The second problem would be running the Installer in this setup as it isn’t clear which version of the Installer he’s running, the 8.0 one or the 9.0 one. Third was trying to follow installation instructions from sources other than the NetBSD guides and Wiki from the NetBSD site. I’ve suggested he download the 9.0 USB image and try using it to install 9.0. On the issue of his system going back to the BIOS screen even after setting up the system for UEFI booting, there are at least two possibilities I’ve seen on my system. First, if the firmware is configured to prefer BIOS booting over UEFI or if the UEIF booting is disabled in the firmware this can happen. Second, he states he had GPT partitions on the disk previously so I’d assume he had a UEFI bootable system installed at some point. If that was Windows or almost any version of Linux those installations would have set the UEFI variables for booting such as which system to boot. If those variables no longer apply to the setup on his newly installed system the UEFI boot will most likely fail and fall back to a BIOS boot. The UEFI variables are normally managed by a utility such as efibootmgr which doesn’t exist (yet) in NetBSD though. So getting rid of them or reconfiguring them can be a problem. In my system I can boot into the BIOS to manage boot sources, enable/disable UEFI booting and also reset the firmware. Resetting the firmware removes all the currently defined UEFI variables. I’ve also managed the UEFI boot variables by booting up a Linux CDROM and running its efibootmgr. However, to do this the CDROM has to be booted up via UEFI; booting it up via BIOS doesn’t load the components necessary to run efibootmgr.
Re: NetBSD install experiences
Not knocking the tremendous work Martin has done maintaining and extending the Installer, but the GPT handling in 9.x/-current did seem a bit confusing to me. It could be just me and my understanding, but the last time I tried it there seemed to be a disconnect between the way an MBR disk is set up and the way it’s done with GPT. Being used to the MBR setup I was looking for a similar setup with GPT. What I thought I saw was that with MBR partitioning one selected the disk, then defined or redefined the partitions. This seemed to be true regardless of what type of previous MBR partitioning was done on the disk. (Although a previous MBR setup for a non-NetBSD system on the disk sometimes caused problems.) With GPT, at least on a disk that already has some GPT wedges, it seems one selects GPT wedges to “partition”, not the disk. At least it seemed to me that all the existing GPT wedges were displayed and I don’t recall seeing an option that allowed me to select the raw disk and define or redefine the GPT partitions on it. Not sure about the UEFI or BIOS booting as I do that manually on my installs, but I know Martin did fix some issues that I was originally having with that.
RE: NetBSD install experiences
I’m not sure if this is still true, but it was in the past. The NetBSD installer used to get confused about partitioning if one was trying to install a new NetBSD system on a disk that had previously contained an installation of some other system like OpenBSD, FreeBSD or Linux. This was on MBR partitioned disks the last time I ran into it. The simple solution was to zero out the first 1000 blocks of the disk before attempting the NetBSD installation at which point everything worked smoothly. If this is still an issue it may be even more difficult with a disk that was set up using GPT as it takes more than just zeroing out the first few blocks on the disk to totally wipe out the GPT setup. It might be nice to have an option in the Installer to “reset” a disk to an acceptable state for a NetBSD installation. As for the packaging system, it has generally gotten more difficult to do a simple installation of packages on a new NetBSD system now that the package system supports so many other systems. In the old days packages were built and maintained for a particular NetBSD release. Now the package builds are in quarterly archives designed for building and installation on multiple systems. That’s nice because it greatly expands the number of people working on packages, but the downside is that the quarterly archives are not all built from source on a regular schedule so the package inter-dependencies can get all messed up. An update in one package may cause installation issues for other packages that depend on it and haven’t been rebuilt in the archive. I guess there are multiple solutions: 1) doing a regular rebuild of everything in an archive, 2)having some utility that would check for packages that are no longer installable from the archive, 3)building packages yourself which takes time and computer resources. Pkg_comp is a nice utility for doing the third option. I have updated documentation on how this can be done such that a user need only build the packages they’re interested in installing on their system I contributed that documentation to the WiKi some time ago, but I’m not sure it was ever accepted and posted.
Re: Another NVMM question
No, this is an old Windows-95C that I’m trying to install under NVMM. It did install and run under XEN and I tried using the same parameters in NVMM. Had to specify no more than 768Meg of RAM, Pentium class CPU and VCPU=1 (which I assume would be SMP 1). So I suspect it’s either a bug or a missing feature in NVMM. I can’t try Windows 10/64 (or 32) as I don’t have a license or CD for it. On Oct 9, 2019, at 11:15 AM, Chavdar Ivanov wrote: > Any chance you are trying to install Windows 10/64 ? AFAIK it still > doesn't run with nvmm. The 32-bit version is fine. though. > > On Wed, 9 Oct 2019 at 16:47, Kamil Rytarowski wrote: >> >> On 09.10.2019 17:37, Robert Nestor wrote: >>> Got a few systems installed and running under NVMM in NetBSD 9.0, but ran >>> into this playing with a Windows installation. It appears to be coming >>> from NVMM and I’m curious if this is a current limitation in NVMM or are >>> there some QEMU parameters which can be used to circumvent this. >>> >>> NetBSD Virtual Machine Monitor accelerator is operational >>> qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xb8040] >>> qemu-system-x86_64: NVMM: Failed to execute a VCPU. >>> >> >> I would need to check into the code, but it could miss a cpu instruction >> in the decoder. >> >> Please file a bug report for it. There will be need for a proper >> reproduction steps and specification of your hardware and Window image. >> > > > -- >
Another NVMM question
Got a few systems installed and running under NVMM in NetBSD 9.0, but ran into this playing with a Windows installation. It appears to be coming from NVMM and I’m curious if this is a current limitation in NVMM or are there some QEMU parameters which can be used to circumvent this. NetBSD Virtual Machine Monitor accelerator is operational qemu-system-x86_64: NVMM: Mem Assist Failed [gpa=0xb8040] qemu-system-x86_64: NVMM: Failed to execute a VCPU.
Re: Install problems with LinuxMint in mvmm
Hmm, couldn’t get the noapic option to work. Not blaming nvmm in any way - it’s quite a piece of work and very impressive! I did get the LinuxMint DVD to boot under nvmm by selecting the “Compatibility boot option” in the LinuxMint menu. On Oct 8, 2019, at 4:15 PM, Kamil Rytarowski wrote: > Once you get a grub menu, you need to specify 'noapic'. > > Linux runs aggressive hw checks that fail under hypervisors (NVMM is not > to be blamed). > > The right solution is to patch the Linux kernel and disable the checks > for NVMM and HAXM. > > On 08.10.2019 18:20, Robert Nestor wrote: >> Thanks! I tried adding “-no-acpi” to the QEMU command line and that >> eliminated the messages from QEMU, but the Linux installer still failed. I >> then tried using “-append noacpi” on the QEMU command line, but that is only >> available with one also uses “-kernel”. So I guess one can’t boot an >> installation CD this way. >> >> >> On Oct 8, 2019, at 9:40 AM, Kamil Rytarowski wrote: >> >>> On 08.10.2019 16:31, Robert Nestor wrote: >>>> Playing with nvmm in an Oct 9 NetBSD 9.0 build. Sucessfully installed >>>> a version of NetBSD 8.0 but ran into problems tryuing to install a >>>> LinuxMint 19.2 64-bit system. Nvmm throws these errors: >>>> >>>> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1c9 [val=0x3], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1c9 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a6 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1a6 [val=0x11], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a6 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a7 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1a7 [val=0x11], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a7 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x3f6 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x3f6 [val=0x11], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x3f6 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x186 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x187 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x188 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x189 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x38d [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0xc4 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected WRMSR 0xc4 [val=0x], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0xc4 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x140 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0xce [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x140 [val=0x0], ignored >>>> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x34 [val=0x0], ignored >>>> >>>> And the Linux installer panics. >>>> >>>> Qemu was invoked with: >>>> >>>> qemu-system-x86_64 -m 256 -accel nvmm -cdrom >>>> /home/linuxmint-19.2-xfce-64bit.iso -name "LinuxMint-19.2 Install" -smp 2 >>>> -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device >>>> rtl8139,netdev=nd0 -drive >>>> file=/home/LinuxMint-19.2.dsk,media=disk,format=raw >>>> >>>> Any ideas, or am I missing some important qmeu option here? NetBSD runs >>>> fine with this set of options in qemu. >>>> >>> >>> Ignore the warnigs and set 'noapic' on boot in the bootloader. >>> >> > >
Re: Install problems with LinuxMint in mvmm
Thanks! I tried adding “-no-acpi” to the QEMU command line and that eliminated the messages from QEMU, but the Linux installer still failed. I then tried using “-append noacpi” on the QEMU command line, but that is only available with one also uses “-kernel”. So I guess one can’t boot an installation CD this way. On Oct 8, 2019, at 9:40 AM, Kamil Rytarowski wrote: > On 08.10.2019 16:31, Robert Nestor wrote: >> Playing with nvmm in an Oct 9 NetBSD 9.0 build. Sucessfully installed >> a version of NetBSD 8.0 but ran into problems tryuing to install a >> LinuxMint 19.2 64-bit system. Nvmm throws these errors: >> >> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1c9 [val=0x3], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1c9 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a6 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1a6 [val=0x11], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a6 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a7 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1a7 [val=0x11], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a7 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x3f6 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x3f6 [val=0x11], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x3f6 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x186 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x187 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x188 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x189 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x38d [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0xc4 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected WRMSR 0xc4 [val=0x], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0xc4 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x140 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0xce [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected WRMSR 0x140 [val=0x0], ignored >> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x34 [val=0x0], ignored >> >> And the Linux installer panics. >> >> Qemu was invoked with: >> >> qemu-system-x86_64 -m 256 -accel nvmm -cdrom >> /home/linuxmint-19.2-xfce-64bit.iso -name "LinuxMint-19.2 Install" -smp 2 >> -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device >> rtl8139,netdev=nd0 -drive >> file=/home/LinuxMint-19.2.dsk,media=disk,format=raw >> >> Any ideas, or am I missing some important qmeu option here? NetBSD runs >> fine with this set of options in qemu. >> > > Ignore the warnigs and set 'noapic' on boot in the bootloader. >
Install problems with LinuxMint in mvmm
Playing with nvmm in an Oct 9 NetBSD 9.0 build. Sucessfully installed a version of NetBSD 8.0 but ran into problems tryuing to install a LinuxMint 19.2 64-bit system. Nvmm throws these errors: qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1c9 [val=0x3], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1c9 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a6 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1a6 [val=0x11], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a6 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a7 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1a7 [val=0x11], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x1a7 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x3f6 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected WRMSR 0x3f6 [val=0x11], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x3f6 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x186 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x187 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x188 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x189 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x38d [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0xc4 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected WRMSR 0xc4 [val=0x], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0xc4 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x140 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0xce [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected WRMSR 0x140 [val=0x0], ignored qemu-system-x86_64: NVMM: Unexpected RDMSR 0x34 [val=0x0], ignored And the Linux installer panics. Qemu was invoked with: qemu-system-x86_64 -m 256 -accel nvmm -cdrom /home/linuxmint-19.2-xfce-64bit.iso -name "LinuxMint-19.2 Install" -smp 2 -netdev tap,id=nd0,ifname=tap0,script=no,downscript=no -device rtl8139,netdev=nd0 -drive file=/home/LinuxMint-19.2.dsk,media=disk,format=raw Any ideas, or am I missing some important qmeu option here? NetBSD runs fine with this set of options in qemu.
NVMM and NetBSD 9.0
Confused about mvmm and NetBSD 9.0 BETA. I did build and install the version
of qemu-nvmm from pkgsrc-wip, then tried running it and it gives:
qemu-system-x86_64: NVMM: No accelerator found, error=6
qemu-system-x86_64: failed to initialize NVMM: No space left on device
I thought mvmm was in 9.0, but when I do a modstat I don’t see it listed and
there’s no mvmm.kmod file in the modules folder under /stand. So I tried
building the module in /usr/src/sys/modules/nvmm and get this:
make: "/etc/mk.conf" line 298: Malformed conditional ((${OPSYS} == "OpenBSD" ||
${OPSYS} == "Bitrig"))
make: "/etc/mk.conf" line 626: Malformed conditional (${OPSYS} == "IRIX")
make[1]: "/etc/mk.conf" line 298: Malformed conditional ((${OPSYS} == "OpenBSD"
|| ${OPSYS} == "Bitrig"))
make[1]: "/etc/mk.conf" line 626: Malformed conditional (${OPSYS} == "IRIX")
make[1]: Fatal errors encountered -- cannot continuemake:
"/usr/share/mk/bsd.own.mk" line 208: warning: "cd "/usr/src" && make -V
.OBJDIR" returned non-zero status
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/src/sys/modules/nvmm
This is with the standard /etc/mk,conf file that comes with 9.0_BETA
installation. The kernel, installation files and sources are from the Release
Engineering Sept 29 build.
Obviously I’m doing something wrong or don’t understand something. Can anybody
enlighten me here?
Installing 9.0_BETA on GPT disk
I’m sure I’m doing something wrong, but don’t have a clue what it might be. I downloaded the amd64 9.0_BETA ISO yesterday and burned it to a CD. Booted the CD and attempted installation onto a disk that already has a GPT structure set up with an earlier version of 9.0 on it. The disk was configured to contain both BIOS and UEFI boot, although I usually boot with BIOS since on this system UEFI booting hasn’t worked in the past. When I get to the part where I select the installation target it shows the disk(s) and the GPT partitions on those disks. I select the disk, OK the geometry and then specify I want to use the existing GPT partitions on the disk. At this point when I attempt to proceed with the installation I’m given a message there there’s “no boot code” on the disk and the installation fails. I have tried configuring the GPT partitions in the Installer specifying that I want them to be newfs’d, marking the root partition as where I want the installation to go and that it’s bootable. Nothing seems to get me past this point in the Installer. So what simple little step did I miss? Thanks, -bob
Re: xfce4 startup issue
A follow up for anyone else seeing the same problems with dbus, hal and avahi starting up xfce4. Finally isolated the problem to a build error in the packages using pkg_comp - it doesn’t happen with builds done in a typical pbulk build environment. It appears that when pkg_comp bootstraps its pbulk environment it sets the ABI option to match the host, in my case an amd64 system. The packages build ok, but they then have the errors I was seeing when they execute. Overriding the ABI parameter in the extra.mk.conf file used by pkg_conf fixes the problem. Also, with the ABI parameter set as it is in the default setup for pkg_comp causes it to build a non-functional version of pkgin as well. When pkgin is built this way it emits some obscure SQL errors trying to access its database. I’ve written up a HOW-TO on getting pkg_comp set up so that it properly builds packages that match the ones on the server as well as ones built in a pbulk build environment. I’ll send it in as soon as I finish tracking down a couple of other things like trying to isolate the funky mouse movements in xfce4 seen in the 2018Q4 and -current pkgsrc archives.
Re: Fun with SSD and GPT wedges
the man page for gpt on NetBSD 8.0_STABLE in the example section shows: Booting from GPT on an BIOS system. This creates a bootable partition that can be manually installed to. Note that sysinst(8) does not yet properly support this setup. xotica# gpt create wd1 xotica# gpt add -b 1024 -l bootroot -t ffs -s 1g wd1 /dev/rwd1: Partition 1 added: 49f48d5a-b10e-11dc-b99b-0019d1879648 1024 2097152 xotica ~# dmesg | tail -2 wd1: GPT GUID: 660e0630-0a3f-47c0-bc52-c88bcec79392 dk0 at wd1: "bootroot", 2097152 blocks at 1024, type: ffs xotica# gpt biosboot -L bootroot wd1 => xotica# newfs dk0 xotica# installboot /dev/rdk0 /usr/mdec/bootxx_ffsv1 xotica# mount /dev/dk0 /mnt xotica# cp /usr/mdec/boot /mnt On Feb 13, 2019, at 12:25 AM, John Nemeth wrote: > On Feb 12, 7:03pm, Robert Nestor wrote: > } > } Somewhat related, but the man page on GPT in the example on how > } to set up a BIOS boot indicates that one should newfs dk?, not > } rdk?. A number of people have pointed out to me that I should > } be running newfs on rdk?, NOT dk?. This was probably the source > > What manpage? From what version of NetBSD? I just looked at > the manpage for gpt(8) on a NetBSD 7.1 system and a NetBSD -current > system, neither of them said anything about that. > > } of a lot of my problems, but in my defense I was just following > } the documentation. :-) > } > }-- End of excerpt from Robert Nestor
Re: Fun with SSD and GPT wedges
Somewhat related, but the man page on GPT in the example on how to set up a BIOS boot indicates that one should newfs dk?, not rdk?. A number of people have pointed out to me that I should be running newfs on rdk?, NOT dk?. This was probably the source of a lot of my problems, but in my defense I was just following the documentation. :-) -bob On Feb 12, 2019, at 6:57 PM, Greg Troxel wrote: > Robert Elz writes: > >> | but wiping the GPT header doesn’t seem to always immediately >> | free the corresponding wedges. >> >> It doesn't. You need to be aware of the logical separation here. >> GPT is a disc partitioning scheme (as are MBR and disklabel) which >> divides drives into multiple pieces. Wedges are an OS software >> reference device which map a range of blocks on a particular device >> to a /dev name (ie: give a handle by which a piece of disc can be >> referenced). >> >> Normally, when a drive (which already contains a label) is scanned, >> any GPT partitions (of suitable types) are connected to wedges so >> they can be referenced - but you can always just create a wedge for >> any random piece of a drive without any GPT back end if you like. >> >> With a new drive, as it was originally coded, you would add a new >> GPT partition, and the gpt command would tell you what you needed >> to type (or cut) as a dkctl command to create a wedge for the >> new partition (if you wanted one). >> >> But since just about everyone wants one, that's why they created >> the partition usually, and since having one command spit out instructions >> for running another command is kind of weird, when it could just >> run the command itself, the gpt command was changed to create a >> wedge when it creates a new partition (that is the in kernel data >> struct, whether or not it has a /dev/dkN entry available). >> >> Apart from that one concession, the gpt command and wedges are two >> separate things (and so are MBR and wedges and disklabel and wedges >> if you use them that way - most people don't as it isn't traditional.) > > I can see how we got here, but the situation seems wrong from a logical > consistency point of view. If gpt(8) is going to create wedges on > adding a new partition, it should delete the wedge corresponding to a > partition that it removes. And when destroying a GPT label, it should > first remove each partition, and thus remove each wedge. > > With disklabels, when the label is scanned then the various abcdefgh > partitions can be used. Ideally, when writing the block with the > disklabel it would be rescanned. > >> That means, that when you no longer want to keep a wedge, you need >> to dkclt delwedge it to cause the kernel to lose the mapping. What >> you do (if anything) with the GPT map on the drive is unrelated. >> But certainly keeping wedges when you're about to remap the drive >> space in some different way would cause you all kinds of weirdness. > > Agreed that currently you must, because gpt remove does not drop the > wedge, one has to do it manually.
Fun with SSD and GPT wedges
I’ve noticed on my system that building packages is very much I/O bound rather than CPU limited. So in an effort to try and speed things up I decided to install a cheap SSD as a system disk. While doing that I noticed some things and I wonder if they point to problems in NetBSD. I am using GPT partitions, so some of what I’m seeing is probably related to how wedges are installed, used and processed. I use a home-brew script to install the NetBSD system, make my local changes in /etc and install a selected set of packages. So sysinst isn’t an issue for me here. In my script I destroy any existing GPT partitions on the target disk, zero out the first couple of disk blocks and then create new GPT partitions. After creation I newts them and mount them so I can load NetBSD from the tar files. I’ve been doing this for some time on spinning disks without any problems, but as soon as I tried to target the SSD I run into interesting issues. *) GPT and DKCTL merrily allow me to create wedges that can’t be mapped because the /dev nodes don’t exist. There aren’t any warnings or errors in the process, but trying to use them later in newts or mount commands does produces some strange errors. Not sure if this is a problem or not, just a bit confusing. Wedges appear to be created in ascending numerical order with lower numbered slots used first, but wiping the GPT header doesn’t seem to always immediately free the corresponding wedges. So after destroying the GPT header I used DKCTL to (re)make the wedges. This removes the old wedges. I do this after creating my new wedges too. *) The SSD is so fast that after creating wedges and even listing them, I find I can’t newts them until the buffers get flushed which dkctl does with the synccache command. This also happens after completing the newts operation; the newly formatted wedge can’t be mounted until the disk cache is flushed. This seems to be a possible file system buffering problem - if there are dirty disk buffers in memory created by gpt/dkctl and newts, why doesn’t the system access them instead of reading them from disk when doing the newts process? (At least that’s what I assume is happening based on what I’m seeing.) Is this an error? *) GPT and DKCTL happily allow me to destroy, recreate (or mis-create) wedges on disk(s) with wedges that are currently mounted in the running system. (Well it was running up to the point I did this.) I would think this is maybe something the system should at least issue a warning about, so is this a bug? *) I had been using the “name=“ parameter in both newts and mount with the wedges. This worked fine for spinning disks, but I see all sorts of random failures when the wedges are on SSD. Maybe this is related to a disk block buffering issue, not sure. My workaround is to figure out which DKn wedge corresponds to the name using dkctl, and specify the wedge by /dev/dk? for newts and mount. So, is any of what I’m seeing a real issue that requires a PR? Oh, this is running on NetBSD 8.0_STABLE on amd64. All my filesystem are FFS V2.
Re: xfce4 startup issue
Got a bit further on this problem. Tried a clean install of 8.0_STABLE and downloading the packages from the 8.0 archives. Xfce comes up and allows me to create terminal sessions and most functions seem to work, although I’m still seeing the “funky mouse” and window move problems. There are no errors in any logs for bringing up dbus, hal or avahi. So the errors I’m seeing using my locally built packages must be my build issue probably related to wxGTK. I’m rebuilding everything without the wxGTK changes I had to test that out with -current and with the 2018Q4 sources. Hopefully that works and the “funky mouse” and window move problems get isolated somewhere between the 2018Q4 and -current pkgsrc sources. If not I guess I’ll have to keep stepping back thru 2018Q3 all the way to 2017Q4 where the problem doesn’t seem to exist.
Re: xfce4 startup issue
Interesting that others have seen the mouse and window move problem under xfce. My system is an amd64 with Intel driver and I’m using X from the base distribution. I have been building the packages myself and using them for the installation and I always do a clean system install of 8.0_STABLE followed by an install of the packages. I do this to make sure I’m not inadvertently relying on some left over setup from an earlier installation. The reason I was doing my own package builds is that the set I wanted to install weren’t all available until very recently for 2018Q4 and current. The closest matching archive was 2017Q4 so I was building them along with some that would build but weren’t in the 2017Q4 binaries. But based on what Chavdar reports about being successful using currently built packages from the server, I’m going to add that to my test matrix. Also interesting that others aren’t having the same problems on similar system setups. Maybe there’s something in the way the packages are built on my system that’s different from the ones on the server, although as far as I know I don’t have anything that special in my build setup. I did have problems building seamonkey until I forced it to use python 2.7, and I’ve been building wxGTK with gtk2 instead of gtk3 so I could get code blocks to build. I’ll run a few more tests to document what works and what doesn’t with my currently built set of packages and then go back and rebuild all of them using the default wxGTK setup as that might be where the problem I’m seeing is coming from. In my setup I start xfce from xdm, but my .xsession script just issues a startxfce4 so I don’t think my problem is related to how xfce gets started.
Re: xfce4 startup issue
I’m still trying to isolate the problem I’m seeing. Did notice that hal is no longer dragged in when I install xfce4 from current or 2018Q4, so I’ve eliminated it in my install. Avahi was being pulled in when I installed seamonkey, so I’ve disabled it for the time being. Where I am now is testing with 2018Q4 packages. With dbus disabled xfce comes up and more or less runs. (Mouse clicks and window movement is really hit or miss.) With dbus enabled xfce hangs at the autostart point but it takes a long time to get there and I’m not finding any errors in the logs. Haven’t tried the same install using current versions of packages, but it’s on my list of things to do.
Re: xfce4 startup issue
As suggested by David Gutteridge, I commented out the startup of the dbus, hal and avahi daemons in rc.conf. When I did this, xfce4 came up and appeared to be working. So that begs the question, why the install of xfce4 also installs these daemons and why aren’t they working in 2018Q4 and current where they do work out of 2017Q4 pkgsrc. Thanks for the tip!
xfce4 startup issue
Running NetBSD 8.0_STABLE on an amd64 system using xfce4 and related packages from pkgsrc-2017Q4 which has been working. But there are some minor nits, so I’ve tried upgrading my installed packages to those found in either pkgsrc-2018Q4 or -current. I see the same problem in both though; xfce4 doesn’t start and I see the same messages during startup on a clean install of the system: dbus-daemon[1027]: [system] Rejected send message, 1 matched rules; type=“method_call”, sender=“:1.0” (uid=0, pid=1135, comm=“/usr/pkg/sbin/hald ”) interface=“org.freedesktop.ConsoleKitManager” member=“GetSeats” errorname=“(nset)” requested_reply=“0” destination=“org.freedesktop.ConsoleKit” (dubs) /etc/rc.d/hald exited with code 1 avadi-daemon[790]: dbus_bus_request_name(): Connection “:1.1” is not allowed to own the service “org.freedesktop.Avahi” due to security policies in the configuration file /etc/rc.d/avahidaemon exited with code 1 Digging into the problem I notice that the directories for hal, dbus and avahi have all moved from /usr/pkg/etc to /etc. Comparing the files in these directories shows changes in the dbus-1/system.d/ConsoleKit.conf file, but using the one from 2017Q4 doesn’t improve or correct the startup problems. In all three setups (2017Q4, 2018Q4 and current) I have hal, dbus and avahidaemon set to YES in /etc/rc.conf. There must be something that’s changed for getting the newer versions of these daemons up and running, but so far I’ve drawn a blank on figuring out what it is. Can someone shed some light on this for me? Thanks,
Re: libstdc++.so.7 is missing
I wonder if the absence of some packages in the archives (like gimp in 2018Q4) are related to what I’m seeing in my builds. Some packages build successfully as individual builds, but fail to build when part of a pbulk build. Both done inside a sandbox. The one I’m trying to figure out right now is go111 in current pkgsrc. If builds fine as an individual build, but fails within a pbulk build with an error trying to execute some go14 commands. When I monitor the build progress of the pbulk build it appears to correctly install go14 since it’s listed as a BUILD_DEPENDS in the go111 Makefile, but then quickly removes it. I’m assuming it gets deinstalled before the go111 build script gets to the point of needing it. I suspected that it might be related to having MAKE_JOBS set to 4 for pbulk, but setting it to 1 didn’t solve the problem. Anyway, I’m pretty sure it has to be some setup in my pbulk that’s causing the problem, but I’m at a loss to figure out what it is. Maybe the same thing is happening for some of the bulk builds that get posted on the server causing some packages to not be available? I did set up my pbulk environment following the instructions posted on the Wiki. -bob On Jan 20, 2019, at 3:11 PM, David H. Gutteridge wrote: > On Sun, 2019-01-20 at 17:34 +0100, Pedro Pinho wrote: >> The symlink was just a test, I've removed it as I got another missing >> library. >> >> Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu >> and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw >> the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not >> supported by device >> >> I see if I get the time to compile midori from pkgsrc later today. > > I looked at the midori package that was uploaded on or after January > 14th, and it has "@blddep gcc6-6.5.0nb2" noted. If you don't have the > package gcc6-libs-6.5.0nb3.tgz from the Q4 build installed, please add > it and report the results. (If that fixes your problem, then there's a > package that needs to be corrected.) > > If not, separately, as Greg noted, we need to disentangle what requires > what. Looking at your ldd output for midori, we see both libstdc++.7 > and .8 get referenced. That on its own isn't enough, because some of > the non-pkgsrc libraries that are referenced there definitely require > .8, e.g. it's pulling in libGL from xbase, which links against .8. > > And, separately again, yes, I see gimp is missing from the Q4 packages. > I guess either it didn't build for some reason or the uploaded packages > are incomplete. Whoever supports those binary pkg builds would have to > comment here. > > Dave > >
Re: libstdc++.so.7 is missing
Did a clean checkout of pkgsrc-2018Q4 and tried building a few of the packages, mainly xfce4. If fails, along with about 122 others in my build, because perl-5.28.1 doesn’t build. but perl-5.28.1 is in the binary archives for amd64/8.0_2018Q4 on the server. So it had to build for someone, just doesn’t build from the checked out pkgsrc source. It errors out with an internal gcc compiler error using the gcc that comes with NetBSD 8.0_STABLE. I’m guessing the builds on the server were done with a different version of gcc but that’s not reflected in the package options for perl in the 2018Q4 source.
Re: libstdc++.so.7 is missing
I’ve noticed inconsistencies with the pre-built package archives since about the time of NetBSD 6.2. Whenever I’ve done a clean install of NetBSD (7.x , 8.x or -current) and then try to install some packages from almost any corresponding package archive, I usually run into issues with incompatible libraries. I’m not sure how it happens that packages in the archive end up this way. One solution I’ve been trying with some success is to checkout the pkgsrc that corresponds to the archive I want to use and build the packages that are of interest to me using a pbulk build setup. However, that exposes another issues that has me completely stumped - some packages that exist in the package archive fail to build on my system. One good example is if I check out the sources for pkgsrc-2018Q4 and try building the meta-pkg xfce4 it fails, but the binary archive for it exists on the server. Assuming the sources are the same for both my build and the one that was posted on the server then the question becomes, what’s different in the two build setups? I’m beginning to suspect that maybe the packages in the 2018Q4 archive on the server were not built under a stock NetBSD 8.0 system, or there are some special setups used that aren’t reflected in the pkg build setup. It might be interesting to compare the contents of mk.conf for example it see if that might explain the differences.
Confusion on GPT wedges
Not sure if this is a NetBSD bug or a cockpit error on my part so some expert guidance would be helpful. I’ve got a system with two hard drives that I’ve installed NetBSD onto, using both NetBSD-8.0 and NetBSD-8.0_STABLE. (Current doesn’t boot on this HP MT 6200 - that’s a different issue but has been reported by myself and others already.) In setting up the disks I’ve used GPT partitions and a Legacy BIOS boot (UEFI booting also doesn’t work on this HP MT 6200). To do this I’ve crafted an install script that basically sets up the target disk the same way regardless of which disk I’m using, and this is where I started running into problems. (Seems that sysinst isn’t quite up to the task of dealing with multiple GPT wedges during an install, but that’s a different problem and the reason I do my installs with a script. Also my script provides a way to ping-pong between the two disks, copying my local files from the current boot disk to the target disk when I do a new install.) When setting up GPT partitions on the target disk I’ve specified a root, swap, var, usr and home wedges. The names are the same regardless of which disk I’m targeting. Since the wedge processing of disks dynamically assigns all the disk wedges to DKn devices on boot I decided to use the NAME= option in my fstab to mount the wedges. That way I don’t have to decode what DKn devices the disk wedges have been assigned to by the system during boot. That works up to a point, that point being until it discovers that the same wedge name exists on multiple disk volumes. At this point the system gets really confused at boot and tries to use (or mount) the first wedge that matches by name, so booting from the second disk now becomes impossible. So a bit further digging and I discover that one can replace the actual wedge name with the unique UUID (actually the wedge GUID value). That works on a system that has already been booted, but fails during boot. Apparently the utilities used during boot haven’t been modified to use either wedge by name or wedge by UUID. Is this a bug or oversight in wedge processing by the components used for booting? My work-around at this point is to uniquely name the wedges on both disk volumes, but I was under the impression that wouldn’t be necessary if I used the UUIDs instead of the wedge names. Is this not true? Thanks, -bob
Re: Problems loading NetBSD on an ANTSLE box
I’ve got one of those boxes and I did have NetBSD loaded on it not long after I got it. I bought one with the minimal internal disk setup, two 120G Kingston SSDs, and installed my own additional disk drives for more storage. I was using an earlier version of NetBSD and bought it to set up some xen images, but then found out the SOC Antsle uses doesn’t support everything needed to run all the modes xen is capable of. Had the same problem with trying to install FreeBSD on it and ended up just putting MintLinux on it instead. I think it works better with MintLinux than the OS they shipped with it, but it still isn’t what I thought when I bought it. It sounds to me like you’ve got a HW problem though. You didn’t by chance open the box to do any upgrades did you? When you pull it apart you have to be very careful of some of the springs, screws and make sure you replace the thermal paste for the CPU. -bob
Re: Problems loading NetBSD on an ANTSLE box
So are you trying to install NetBSD as an Antlet or trying to install to the bare metal? In my installs I totally wiped out AntOS and installed to bare metal. If you’re installing to bare metal have you tried installing to each of the SSDs? AntOS makes the two SSDs look like a single disk using ZFS, but if you install over the top of AntOS then you’ll have two disks and can choose either one to install to. BTW, I found Antsle support to be pretty much useless. They wouldn’t give me any details on almost anything. They really don’t want their customers opening the box, installing their own upgrades or removing AntOS from the box. They’d like to keep you boxed into just using the system the way they intended which is to run everything under AntOS and have them do any HW upgrades for you. On Dec 14, 2018, at 11:44 AM, Palmer, John wrote: > No - I didn't do anything like that (open it up). I have one Linux instance > running on it and its fine. I've installed NetBSD versions 3.0, 4.0.1, 5.0, > 7.0 and 8.0 and they all have the same issue with the file systems. > > I'm not using Xen - just the standard install. > > -Original Message- > From: Robert Nestor > Sent: Friday, December 14, 2018 11:28 > To: Palmer, John ; NetBSD Users > Subject: Re: Problems loading NetBSD on an ANTSLE box > > I've got one of those boxes and I did have NetBSD loaded on it not long after > I got it. I bought one with the minimal internal disk setup, two 120G > Kingston SSDs, and installed my own additional disk drives for more storage. > > I was using an earlier version of NetBSD and bought it to set up some xen > images, but then found out the SOC Antsle uses doesn't support everything > needed to run all the modes xen is capable of. Had the same problem with > trying to install FreeBSD on it and ended up just putting MintLinux on it > instead. I think it works better with MintLinux than the OS they shipped > with it, but it still isn't what I thought when I bought it. > > It sounds to me like you've got a HW problem though. You didn't by chance > open the box to do any upgrades did you? When you pull it apart you have to > be very careful of some of the springs, screws and make sure you replace the > thermal paste for the CPU. > > -bob
Re: i915
The screen auto-configure algorithm in X seems to change a bit with every new update which, on my system, introduces this particular problem. What I’ve noticed is that the algorithm tries to determine what graphics cards are present, what resolutions are supported, etc then sometimes gets confused about which port the monitor is attached to. Usually happens with a monitor that doesn’t do a good job of supporting DPMS. On my system when it gets into this confused state it usually tries to attach the monitor onto the VGA1 port rather than the VGA0 port. (I’m using a VGA monitor and graphics cards that only have a single VGA port.) A similar issue occurs with screen resolution. I’ve seen it determine which resolutions it thinks it can support based on what assumptions it made about the graphics card and/or what it thinks it got for a DPMS response. And in doing so drops a lot of valid resolutions, usually the higher ones, from the list of what it can support. Just adding the modelines to an xorg.conf file doesn’t always work unless they reference the correct port to which the monitor will attach to. The solution is to build your own xorg.conf file to specify which port to use by putting an “Option Monitor…” directive into the Device Section. It used to be pretty easy to discover where the auto-configue was trying to attach the monitor by just scanning the /var/log/Xorg.0.log file, but more recent versions of X no longer emit that bit of useful information no matter how verbose you force X into. So now it just takes a lot of fiddling around and playing with options until you find the right magic. These same problems come up on Linux too, so it isn’t a NetBSD issue. It is, I believe, an auto-configure problem in X itself which is common to both systems. I think it’s mainly the result of trying to make X smarter during startup by utilizing the DPMS info. But when the monitor doesn’t support DPMS or doesn’t get it right X gets itself confused. There is a way to encode and provide your own DPMS file for X to use instead of relying on the monitor to supply one, but I’ve never been able to get that to work correctly on either Linux or NetBSD.
Re: Libreoffice after upgrade to NetBSD 8.0
I wasn’t sure if it was a pkgin issue or something else, but I have run into this problem just installing packages using pkgin without having pkgsrc installed. But if the solution is to run “make deinstall clean” in devel/boost-headers, doesn’t that require that pkgsrc be installed on the system? If that’s the case then what is causing the problem when it occurs while installing from the pre-build binary collections? Is it an inconsistency in the binary collection?
Re: Libreoffice after upgrade to NetBSD 8.0
I’ve run into this a few times using pkgin. Not sure if it’s a problem with pkgin or with the packages and their dependencies. What seems to work for me is to remove the newer version of the package that it’s complaining about, then retrying the installation. In you case, remove boost-headers-1.67.0nb4, then try the install of libreoffice again. This may not be the best or even correct solution, especially if you have lots of packages installed. But in my installation I only have a few packages installed and this seems to get me past that hurdle.
Re: Booting Xen on NetBSD 8.0_RC1 with GPT partitions
Ah ha! I missed that root=dk1 part and I’ll bet with the little bit of magic I should be up and running. Thanks! -bob On Jun 23, 2018, at 12:27 PM, Robert Elz wrote: >Date:Sat, 23 Jun 2018 11:29:25 -0500 >From: Robert Nestor >Message-ID: > > | I don’t see an option in boot.cfg to force it to use the correct wedge. > > I have exactly that setup, this is what I use... > > menu=Boot XEN +NetBSD:load /netbsd-xen root=dk1 console=pc;multiboot /xen > dom0_mem=1024M > > kre >
Booting Xen on NetBSD 8.0_RC1 with GPT partitions
New oddity that I’ve stumbled over with 8.0_RC1. Got it all installed with GPT partitions (wedge 1 is EFI, wedge 2 is root, wedge 3 is swap, etc). Boots up and runs fine, so I moved to the next step and install xen. But when I try to boot up it insists that root is on the first wedge /dev/dk0, not /dev/dk1 where it found the kernel. I don’t see an option in boot.cfg to force it to use the correct wedge. Is it that the xen kernel doesn’t understand wedges? Have I missed it or is this a bug? BTW, booting up with GPT partitions without xen properly selects /dev/dk1 as the root and /dev/dk2 as swap.
NetBSD 8.0_RC1 critical_filesystems_remote oddity
I thought I’d try putting my /home filesystem on a NAS box, so I’ve added the line “critical_filesystems_remote=“OPTIONAL:/home” to /etc/rc.conf but when the system boots up the logs show: [running /etc/rc.d/mountcritremote] [running /etc/rc.d/sysdb] Building databases: devdev_mkdb: not found , devdev_mkdb: not found , utmpinstall: not found , utmpxinstall: not found . [running /etc/rc.d/newsyslog] [running /etc/rc.d/wscons] eval: /usr/sbin/wsconscfg: not found eval: /usr/sbin/wsconscfg: not found eval: /usr/sbin/wsconscfg: not found eval: /usr/sbin/wsconscfg: not found [running /etc/rc.d/syslogd] The man page on rc.conf indicates this might be done with /usr which contains a lot more critical stuff for the system then /home, so I’m surprised it didn’t work as expected. Is this normal, or is this a bug/feature?
RE: NetBSD 8.0_RC1 installation oddities
After three weeks of struggling with this I posted the previous message and as Murphy would dictate, as soon as I posted I found what I think is causing the problem. Seems I had a flaky setup on my internet connection. When I have a solid connection XSM comes up normally as I’d expect; with no internet XSM comes up in the “Failesafe” state. So I could be wrong here, but it seems XSM for some reason needs a good working internet setup on the system otherwise it comes up in the “Failesafe” state. Still don’t understand why the difference in were the entropy-file is located, but that’s a non-issue.
NetBSD 8.0_RC1 installation oddities
Still playing with installation of NetBSD 8.0_RC1 (from 201806180740Z and earlier) and have noticed some strange oddities. I’ve installed the basic system on a disk using both the original/traditional disk partition layout and on a disk with a GPT disk partition layout. The /boot.cfg file is different between the two systems with respect to the “rndseed” file location. On the traditional layout the file path is /etc/entropy-file which is also reflected in the /etc/rc.conf file. On the GPT layout the file path is /var/db/entropy-file in both /boot.cfg and /etc/rc.conf. Doubt this makes any difference, but it is an interesting anomoly. However the real puzzling issue is when xdm is enabled and the system tries to bring up an xsm session. On the traditional disk partition layout it just works and login is successful providing me with an xterm window. On the GPT disk partition layout it doesn’t work and xsm comes up with the “fail-safe” window. This problem was reported on a thread on netbsd-users under the title “Cannot login via xdm after fresh install” back in Sept 2017. I’ve tried all the suggestions in that thread and nothing seems to resolve the problem. I’ve also done a complete filesystem compare of the two installations and they are identical other than the entropy-file location. Switching the entropy-file location on the GPT disk to match the traditional disk layout didn’t change anything (as expected). Most of the times I login to the system with the traditional disk layout the xsm session startup just works, but every once and a while it fails with the “fail-safe” window. Every time I login to the system with the GPT disk layout the xsm session fails. Any clues here?
Re: NetBSD 8.0_RC1 (May 22 build) install on GPT/UEFI system
While digging further into this I discovered that the UEFI install images boot up in Legacy BIOS mode, not in UEFI mode. Disabling Legacy BIOS boot on my system before trying to boot the install image resulted in not being able to boot up at all. So even though the image contains and EFI wedge it doesn’t seem to contain all the bits and pieces necessary to boot. Guess I’ll have to dig a bit into this and see what’s necessary to duplicate this feat on my hard drive where I did the GPT/UEFI install.
