Re: No uefi install in VM
On Thu, Dec 12, 2019 at 07:54:08AM +0100, Martin Husemann wrote: > On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote: > > in efi with gpt; it performs the installation lege artis, but then the > > boot fails - the efi file tries and fails to find netbsd, nebsd.gz, > > onetbsd etc... > > That sounds like a regression in bootx64.efi, checking Yes, it is. I took a bootable UEFI installation (in VirtualBox) and replaced the efi/boot/*.efi files on the MSDOS/EFI partition with the ones from the latest netbsd-9 build and it stopped booting as you describe. Disk layout is GPT on wd0, three partitions (one EFI, one NetBSD FFS and one NetBSD swap), /netbsd on the FFS one is supposed to be booted. bootx64.efi starts and shows its countdown and then goes into a loop like: booting NAME=:netbsd - starting in 0 seconds. open netbsd: No such file or directory [..] booting NAME=:onetbsd - staring in 0 seconds. open onetbsd: No such file or directory [..] Same failure with latest HEAD bootx64.efi. Emmanuel, could you please have a look?
Re: No uefi install in VM
On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote: > in efi with gpt; it performs the installation lege artis, but then the > boot fails - the efi file tries and fails to find netbsd, nebsd.gz, > onetbsd etc... That sounds like a regression in bootx64.efi, checking Martin
Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
On 11.12.2019 23:32, Valery Ushakov wrote: On Wed, Dec 11, 2019 at 23:15:38 +0100, Bodie wrote: FYI https://www.virtualbox.org/ticket/19146 Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not subscribed to list. CPUID values are ... = guest (host): IBRS_IBPB - IA32_SPEC_CTRL.IBRS and IA32_PRED_CMD.IBPB = 0 (1) STIBP - Supports IA32_SPEC_CTRL.STIBP = 0 (1) SSBD - Supports IA32_SPEC_CTRL.SSBD = 0 (1) so the NetBSD guest is told the cpu doesn't support IA32_SPEC_CTRL (0x48), but still the guest tries to read it: NetBSD 8.1 STABLE amd64 on same configuration with same values boots just fine and works. 00:00:11.518912 IEM: rdmsr(0x48) -> #GP(0) 00:00:11.518920 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION' -uwe
daily CVS update output
Updating src tree: P src/lib/libkvm/kvm_proc.c P src/share/man/man4/man4.macppc/platinumfb.4 P src/share/man/man9/condvar.9 P src/sys/arch/amd64/amd64/netbsd32_machdep.c P src/sys/arch/amd64/amd64/netbsd32_machdep_16.c P src/sys/arch/arm/dts/rk3328-rock64.dts P src/sys/arch/arm/dts/rk3328.dtsi P src/sys/arch/emips/emips/interrupt.c P src/sys/arch/macppc/conf/GENERIC_601 P src/sys/arch/macppc/conf/INSTALL_601 P src/sys/arch/macppc/dev/platinumfb.c P src/sys/arch/mips/mips/netbsd32_machdep.c P src/sys/arch/mips/mips/netbsd32_machdep_16.c P src/sys/arch/sparc64/sparc64/netbsd32_machdep.c P src/sys/arch/sparc64/sparc64/netbsd32_machdep_16.c P src/sys/compat/common/bio_30.c P src/sys/compat/common/ccd_60.c P src/sys/compat/common/clockctl_50.c P src/sys/compat/common/compat_sysv_50_mod.c P src/sys/compat/common/ieee80211_20.c P src/sys/compat/common/if43_20.c P src/sys/compat/common/if_43.c P src/sys/compat/common/if_media_80.c P src/sys/compat/common/if_spppsubr50.c P src/sys/compat/common/kern_mod_80.c P src/sys/compat/common/kern_sig_16.c P src/sys/compat/common/kern_uipc_socket_50.c P src/sys/compat/common/rndpseudo_50.c P src/sys/compat/common/rtsock_14.c P src/sys/compat/common/rtsock_50.c P src/sys/compat/common/rtsock_70.c P src/sys/compat/common/sysmon_power_40.c P src/sys/compat/common/tty_43.c P src/sys/compat/common/tty_60.c P src/sys/compat/common/uipc_syscalls_40.c P src/sys/compat/common/uipc_syscalls_50.c P src/sys/compat/common/uipc_usrreq_70.c P src/sys/compat/common/usb_subr_30.c P src/sys/compat/common/vfs_syscalls_10.c P src/sys/compat/common/vnd_30.c P src/sys/compat/common/vnd_50.c P src/sys/compat/netbsd32/netbsd32_compat_50.c P src/sys/compat/netbsd32/netbsd32_compat_80.c P src/sys/compat/netbsd32/netbsd32_kern_proc.c P src/sys/compat/sunos/sunos_mod.c P src/sys/compat/sunos32/sunos32_mod.c P src/sys/dev/dm/device-mapper.c P src/sys/dev/fdt/dwc3_fdt.c P src/sys/dev/i2c/adm1026.c P src/sys/dev/i2c/adm1026reg.h P src/sys/dev/mii/ikphyreg.h P src/sys/dev/mii/inbmphyreg.h P src/sys/dev/pci/if_ixl.c P src/sys/dev/pci/if_wm.c P src/sys/dev/pci/if_wmreg.h P src/sys/dev/pci/if_wmvar.h P src/sys/dev/pci/pci_subr.c P src/sys/dev/pci/pcireg.h P src/sys/dev/raidframe/rf_compat32.c P src/sys/dev/raidframe/rf_compat50.c P src/sys/dev/raidframe/rf_compat80.c P src/sys/dev/usb/ugen.c P src/sys/dev/wscons/wsevent_50.c P src/sys/fs/puffs/puffs_compat.c P src/sys/kern/kern_core.c P src/sys/kern/kern_module.c P src/sys/kern/kern_mutex.c P src/sys/kern/vfs_bio.c P src/sys/net/if_vlan.c P src/sys/opencrypto/ocryptodev.c P src/sys/sys/module_hook.h P src/sys/sys/param.h P src/usr.sbin/pstat/pstat.8 P src/usr.sbin/pstat/pstat.c P src/usr.sbin/sysinst/defs.h P src/usr.sbin/sysinst/disks.c P src/usr.sbin/sysinst/label.c P src/usr.sbin/sysinst/main.c P src/usr.sbin/sysinst/msg.mi.de P src/usr.sbin/sysinst/msg.mi.en P src/usr.sbin/sysinst/msg.mi.es P src/usr.sbin/sysinst/msg.mi.fr P src/usr.sbin/sysinst/msg.mi.pl P src/usr.sbin/sysinst/arch/amiga/md.h P src/usr.sbin/sysinst/arch/cobalt/md.h P src/usr.sbin/sysinst/arch/evbarm/md.c P src/usr.sbin/sysinst/arch/evbarm/menus.md.en P src/usr.sbin/sysinst/arch/evbarm/menus.md.es P src/usr.sbin/sysinst/arch/evbarm/menus.md.fr P src/usr.sbin/sysinst/arch/evbarm/menus.md.pl Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 34768493 Dec 12 03:04 ls-lRA.gz
unable to boot amd64-uefi-install from USB stick on a MacBook2,1
So for various reasons I had recently pulled an old macbook2,1 off the shelf and booted it up, and today I thought I'd try booting NetBSD on it just to see how well it works with NetBSD and vice versa. I built all the various "image" files, including a live image and the uefi-install image, from my not-very-current current source tree. I first tried to get the live image to boot from a USB stick (using rEFInd). But it didn't boot. There was some message about Apple's compatability boot loader not working well with external disks (which was pretty much what I expected given what I've read about booting from USB devices on these old macbooks). Then I moved on to try the uefi-install image on a USB stick. This was detected (with the Option key held) as expected, and it booted when selected, and the boot loader menu appeared as expected. However no matter which option I selected, including a "boot netbsd -vs" from the boot prompt, would do anything more than load the kernel (I see the various section size numbers, with a nearly invisible spinner), then it clears the screen, then hang solid -- just the little un-blinking cursor in the "top middle" of the screen and the keyboard goes unresponsive and a full multi-second press on the power switch is necessary to shut it off. I then tried the following: ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201912110900Z/images/NetBSD-9.99.21-amd64-uefi-install.img.gz with the same results. Does anyone have any hints as to what I could try to debug this further? One nice thing I noticed about this MacBook2,1 is that the firmware works with a bluetooth keyboard, including in the NetBSD boot loader! (Which is lucky for me as this machine has one dead row of keys on the built-in keyboard.) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpG9VuyIiW9K.pgp Description: OpenPGP Digital Signature
Re: Fnatic RUSH mechanical keyboard ignores keypress
Hi, I tested the the keyboard before and after pull-up. Indeed, it actually changed the behavior, results of testing were the following: * Before the pull up keyboard worked in 6KRO mode only. Switching to NKRO was failing to attach the keyboard with the message "ukbd1: attach failed, too many modifier keys". However, it was still possible to switch back to 6KRO without reboot. uhidev0 at uhub5 port 2 configuration 1 interface 0 uhidev0: Fnatic Gear RUSH Mechanical Keyboard, rev 2.00/1.09, addr 3, iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 uhidev1 at uhub5 port 2 configuration 1 interface 1 uhidev1: Fnatic Gear RUSH Mechanical Keyboard, rev 2.00/1.09, addr 3, iclass 3/0 uhid0 at uhidev1: input=4, output=0, feature=0 uhidev2 at uhub5 port 2 configuration 1 interface 2 uhidev2: Fnatic Gear RUSH Mechanical Keyboard, rev 2.00/1.09, addr 3, iclass 3/0 ukbd1 at uhidev2 ukbd1: attach failed, too many modifier keys * After the pull up keyboard started to work in NKRO mode only. However, after switching to 6KRO mode keyboard stops working. Switching back to NKRO doesn't work from NetBSD, keyboard stays in the same mode, reboot is required (or reconnect keyboard to other PC) and mode switch performed in the other OS. dmesg is slightly different between two modes: 6KRO dmesg: uhub4 at uhub1 port 12: Genesys Logic (0x5e3) USB2.0 Hub (0x608), class 9/0, rev 2.00/32.98, addr 17 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered uhidev1 at uhub4 port 2 configuration 1 interface 0 uhidev1: Fnatic Gear (0x195d) RUSH Mechanical Keyboard (0x2029), rev 2.00/1.09, addr 18, iclass 3/1 ukbd0 at uhidev1 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev2 at uhub4 port 2 configuration 1 interface 1 uhidev2: Fnatic Gear (0x195d) RUSH Mechanical Keyboard (0x2029), rev 2.00/1.09, addr 18, iclass 3/0 uhid0 at uhidev2: input=4, output=0, feature=0 NKRO dmesg: uhub4 at uhub1 port 12: Genesys Logic (0x5e3) USB2.0 Hub (0x608), class 9/0, rev 2.00/32.98, addr 19 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered uhidev1 at uhub4 port 2 configuration 1 interface 0 uhidev1: Fnatic Gear (0x195d) RUSH Mechanical Keyboard (0x2030), rev 2.00/1.09, addr 20, iclass 3/1 ukbd0 at uhidev1 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev2 at uhub4 port 2 configuration 1 interface 1 uhidev2: Fnatic Gear (0x195d) RUSH Mechanical Keyboard (0x2030), rev 2.00/1.09, addr 20, iclass 3/0 uhid0 at uhidev2: input=4, output=0, feature=0 uhidev3 at uhub4 port 2 configuration 1 interface 2 uhidev3: Fnatic Gear (0x195d) RUSH Mechanical Keyboard (0x2030), rev 2.00/1.09, addr 20, iclass 3/0 ukbd1 at uhidev3 wskbd2 at ukbd1 mux 1 wskbd2: connecting to wsdisplay0 Linux accordingly: usb 1-12.2: new full-speed USB device number 5 using xhci_hcd usb 1-12.2: New USB device found, idVendor=195d, idProduct=2029, bcdDevice= 1.09 usb 1-12.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-12.2: Product: RUSH Mechanical Keyboard usb 1-12.2: Manufacturer: Fnatic Gear input: Fnatic Gear RUSH Mechanical Keyboard as /devices/pci:00/:00:01.1/:01:00.0/usb1/1-12/1-12.2/1-12.2:1.0/0003:195D:2029.0005/input/input22 hid-generic 0003:195D:2029.0005: input,hidraw1: USB HID v1.11 Keyboard [Fnatic Gear RUSH Mechanical Keyboard] on usb-:01:00.0-12.2/input0 input: Fnatic Gear RUSH Mechanical Keyboard as /devices/pci:00/:00:01.1/:01:00.0/usb1/1-12/1-12.2/1-12.2:1.1/0003:195D:2029.0006/input/input23 hid-generic 0003:195D:2029.0006: input,hidraw2: USB HID v1.11 Device [Fnatic Gear RUSH Mechanical Keyboard] on usb-:01:00.0-12.2/input1 usb 1-12.2: new full-speed USB device number 8 using xhci_hcd usb 1-12.2: New USB device found, idVendor=195d, idProduct=2030, bcdDevice= 1.09 usb 1-12.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-12.2: Product: RUSH Mechanical Keyboard usb 1-12.2: Manufacturer: Fnatic Gear input: Fnatic Gear RUSH Mechanical Keyboard as /devices/pci:00/:00:01.1/:01:00.0/usb1/1-12/1-12.2/1-12.2:1.0/0003:195D:2030.000C/input/input29 hid-generic 0003:195D:2030.000C: input,hidraw1: USB HID v1.11 Keyboard [Fnatic Gear RUSH Mechanical Keyboard] on usb-:01:00.0-12.2/input0 input: Fnatic Gear RUSH Mechanical Keyboard as /devices/pci:00/:00:01.1/:01:00.0/usb1/1-12/1-12.2/1-12.2:1.1/0003:195D:2030.000D/input/input30 hid-generic 0003:195D:2030.000D: input,hidraw2: USB HID v1.11 Device [Fnatic Gear RUSH Mechanical Keyboard] on usb-:01:00.0-12.2/input1 input: Fnatic Gear RUSH Mechanical Keyboard as /devices/pci:00/:00:01.1/:01:00.0/usb1/1-12/1-12.2/1-12.2:1.2/0003:195D:2030.000E/input/input31 hid-generic 0003:195D:2030.000E: input,hidraw3: USB HID v1.11 Keyboard [Fnatic Gear RUSH Mechanical Keyboard] on usb-:01:00.0-12.2/input2 Regards, Andrius V On Thu, Dec 5, 2019 at 11:49 PM Andrius V wrote: > > Now that you mention
Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
On Wed, Dec 11, 2019 at 23:15:38 +0100, Bodie wrote: > FYI https://www.virtualbox.org/ticket/19146 > > Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not > subscribed to list. CPUID values are ... = guest (host): IBRS_IBPB - IA32_SPEC_CTRL.IBRS and IA32_PRED_CMD.IBPB = 0 (1) STIBP - Supports IA32_SPEC_CTRL.STIBP = 0 (1) SSBD - Supports IA32_SPEC_CTRL.SSBD = 0 (1) so the NetBSD guest is told the cpu doesn't support IA32_SPEC_CTRL (0x48), but still the guest tries to read it: 00:00:11.518912 IEM: rdmsr(0x48) -> #GP(0) 00:00:11.518920 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION' -uwe
Re: No uefi install in VM
Just to confirm the same. I still have a NetBSD EFI VirttualBox guest working just fine, built around 9.99.10 or thereabouts, perhaps following the manual installation procedure mentioned above. Upon seeng this thread, I tried to test the installation of a fresh 9.99.21 in efi with gpt; it performs the installation lege artis, but then the boot fails - the efi file tries and fails to find netbsd, nebsd.gz, onetbsd etc... I've kept the log and the generated .sh script, if they are of interest. On Wed, 11 Dec 2019 at 18:36, Martin Husemann wrote: > > On Wed, Dec 11, 2019 at 01:34:27PM -0500, Ron Georgia wrote: > > Thanks for responding Martin. Actually I did both. Selecting GPT did set > > things up but it does not boot. > > OK, it worked for me when I tried last (but that is a bit ago). > > Does the UEFI offer the installed drive as a bootable target? > How far does the boot get? > > Martin --
NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
Hi all, FYI https://www.virtualbox.org/ticket/19146 Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not subscribed to list.
Re: graphical console: limit resolution?
On Wed, Dec 11, 2019 at 04:29:41PM +0100, Thomas Klausner wrote: > > So it looks like radeondrmkmsfb does not (correctly) detect the active > output(s)? Looks like it. There is lots of heuristics in that field. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: No uefi install in VM
On Wed, Dec 11, 2019 at 01:34:27PM -0500, Ron Georgia wrote: > Thanks for responding Martin. Actually I did both. Selecting GPT did set > things up but it does not boot. OK, it worked for me when I tried last (but that is a bit ago). Does the UEFI offer the installed drive as a bootable target? How far does the boot get? Martin
Re: No uefi install in VM
Thanks for responding Martin. Actually I did both. Selecting GPT did set things up but it does not boot. On 12/11/19 1:31 PM, Martin Husemann wrote: On Wed, Dec 11, 2019 at 01:28:31PM -0500, Ron Georgia wrote: I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with GhostBSD as a host. I enabled EFI and booted from the iso image. I did follow the "instructions" on creating a gpt partition for efi I guess you followed the wiki page for NetBSD 8? With 9.0 you should not need to do anyhthing special, the installer knows about EFI and GPT. If you boot the install system via UEFI it will automatically create an EFI boot setup. Martin -- 90% of my problems are due to ignorance, the other 10% is because I just don't know any better.
Re: No uefi install in VM
On Wed, Dec 11, 2019 at 01:28:31PM -0500, Ron Georgia wrote: > I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with > GhostBSD as a host. I enabled EFI and booted from the iso image. I did > follow the "instructions" on creating a gpt partition for efi I guess you followed the wiki page for NetBSD 8? With 9.0 you should not need to do anyhthing special, the installer knows about EFI and GPT. If you boot the install system via UEFI it will automatically create an EFI boot setup. Martin
No uefi install in VM
This feels like this question has been asked before, but I could not find what I was looking for in the mailing list archives. I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with GhostBSD as a host. I enabled EFI and booted from the iso image. I did follow the "instructions" on creating a gpt partition for efi; however, when I exit to the menu and point the install target to dk1 (labeled NetBSD) it just returns me to the menu. I was able to install with mbr and legacy "bios." If I install allowing the gpt option to create the EFI boot it fails to boot with: mem[0x0 ... vbox> 0x11] >> NetBSD/x86 EFI Boot (x64), Revision 1.1... >> Memory: 640/3684184 k Press return to boot now, any other key for boot menu booting Name: netbsd - starting in 0 seconds. open netbsd: No such file or directory ... > ls The ls command is not currently supported for dosfs > If I boot from the iso image again and exit to the prompt I see this: # gpt show wd0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Unused 64 262144 1 GPT part - Windows basic data ... # dkctl wd0 listwedges dk0: some-dashed-number, 262144 blocks at 64, type: ntfs dk1: some-dashed-number, blah, type: ffs dk2: some-dashed-number, blah, type: swap I am sure I am doing something wrong or am not understanding something correctly. Perhaps a friendly pointer, or a link to help me on my way? -- 90% of my problems are due to ignorance, the other 10% is because I just don't know any better.
Re: graphical console: limit resolution?
On Mon, Dec 02, 2019 at 11:35:18PM +0100, Michael van Elst wrote: > On Mon, Dec 02, 2019 at 05:58:44PM +0100, Thomas Klausner wrote: > > > The kernel dmesg now says: > > > > radeondrmkmsfb0: framebuffer at 0xdc0909ca8000, size 1920x1080, depth > > 32, stride 7680 > > > > but I don't get a picture either. > > Then size is probably not the only problem. Maybe it doesn't use the > right monitor port ? That could actually be the problem. I've plugged in a cable into the DVI-I Port that is listed first by xrandr, and then I get a picture. So it looks like radeondrmkmsfb does not (correctly) detect the active output(s)? Thomas
Re: lvm related ioctl?
2019年12月11日(水) 22:54 Patrick Welche : > > On Wed, Dec 11, 2019 at 09:44:23PM +0900, Tomohiro Kusumi wrote: > > https://github.com/NetBSD/src/commit/50df35e2463781823f58628fcce2de6f468b9d2c#diff-d90e1b7e3737158f5dfc517594eb88bdL382 > > > > In above commit, can you try moving back the "cleanup_exit:" location > > to before prop_dictionary_copyout_ioctl() and try again ? > > Basically 1 loc change. > > Yes, lvm is working after that. Will revisit later to see details, but I've reverted the change for now. Sorry for breaking. > > Thanks, > > Patrick
Re: lvm related ioctl?
On Wed, Dec 11, 2019 at 09:44:23PM +0900, Tomohiro Kusumi wrote: > https://github.com/NetBSD/src/commit/50df35e2463781823f58628fcce2de6f468b9d2c#diff-d90e1b7e3737158f5dfc517594eb88bdL382 > > In above commit, can you try moving back the "cleanup_exit:" location > to before prop_dictionary_copyout_ioctl() and try again ? > Basically 1 loc change. Yes, lvm is working after that. Thanks, Patrick
Re: lvm related ioctl?
https://github.com/NetBSD/src/commit/50df35e2463781823f58628fcce2de6f468b9d2c#diff-d90e1b7e3737158f5dfc517594eb88bdL382 In above commit, can you try moving back the "cleanup_exit:" location to before prop_dictionary_copyout_ioctl() and try again ? Basically 1 loc change. 2019年12月11日(水) 20:44 Patrick Welche : > > Taking a working 6 Dec 9.99.19/amd64 box, I see: > > # /etc/rc.d/lvm onestart > Configuring lvm devices. > File descriptor 3 () leaked on lvm invocation. Parent PID 687: > File descriptor 3 () leaked on lvm invocation. Parent PID 687: > Activated Volume Groups: vg0 > > Updating kernel and modules to today's current (9.99.21), I see: > > # /etc/rc.d/lvm onestart > Configuring lvm devices. > File descriptor 3 () leaked on lvm invocation. Parent PID 1270: > A non-block device file at '/dev/mapper/rvg0-distfiles' is already present > A non-block device file at '/dev/mapper/rvg0-packages' is already present > A non-block device file at '/dev/mapper/rvg0-releasedir' is already present > A non-block device file at '/dev/mapper/rvg0-home' is already present > A non-block device file at '/dev/mapper/rvg0-obj' is already present > A non-block device file at '/dev/mapper/rvg0-scratch' is already present > File descriptor 3 () leaked on lvm invocation. Parent PID 1270: > ioctl deps call failed with errno 2 > > _deps: task run failed for (169:0) > Failed to add device (169:0) to dtree > ioctl deps call failed with errno 2 > > _deps: task run failed for (169:0) > Failed to add device (169:0) to dtree > ioctl deps call failed with errno 2 > > _deps: task run failed for (169:0) > Failed to add device (169:0) to dtree > ioctl deps call failed with errno 2 > > _deps: task run failed for (169:0) > Failed to add device (169:0) to dtree > ioctl deps call failed with errno 2 > > _deps: task run failed for (169:0) > Failed to add device (169:0) to dtree > ioctl deps call failed with errno 2 > > _deps: task run failed for (169:0) > Failed to add device (169:0) to dtree > Activated Volume Groups: vg0 > > I don't see which ioctl dep failed in e.g. dmesg > > # ls /dev/mapper/*obj* > /dev/mapper/rrvg0-obj /dev/mapper/rvg0-obj /dev/mapper/vg0-obj > > ^rr ? > > lvm vgs, and lvm lvs appear to be sane, but > > # mount /dev/mapper/vg0-obj /usr/obj > mount_ffs: /dev/mapper/vg0-obj on /usr/obj: Device busy > > Why busy - it isn't mounted... > > Reverting kernel & modules to 9.99.19 and all OK again. > > > Cheers, > > Patrick
lvm related ioctl?
Taking a working 6 Dec 9.99.19/amd64 box, I see: # /etc/rc.d/lvm onestart Configuring lvm devices. File descriptor 3 () leaked on lvm invocation. Parent PID 687: File descriptor 3 () leaked on lvm invocation. Parent PID 687: Activated Volume Groups: vg0 Updating kernel and modules to today's current (9.99.21), I see: # /etc/rc.d/lvm onestart Configuring lvm devices. File descriptor 3 () leaked on lvm invocation. Parent PID 1270: A non-block device file at '/dev/mapper/rvg0-distfiles' is already present A non-block device file at '/dev/mapper/rvg0-packages' is already present A non-block device file at '/dev/mapper/rvg0-releasedir' is already present A non-block device file at '/dev/mapper/rvg0-home' is already present A non-block device file at '/dev/mapper/rvg0-obj' is already present A non-block device file at '/dev/mapper/rvg0-scratch' is already present File descriptor 3 () leaked on lvm invocation. Parent PID 1270: ioctl deps call failed with errno 2 _deps: task run failed for (169:0) Failed to add device (169:0) to dtree ioctl deps call failed with errno 2 _deps: task run failed for (169:0) Failed to add device (169:0) to dtree ioctl deps call failed with errno 2 _deps: task run failed for (169:0) Failed to add device (169:0) to dtree ioctl deps call failed with errno 2 _deps: task run failed for (169:0) Failed to add device (169:0) to dtree ioctl deps call failed with errno 2 _deps: task run failed for (169:0) Failed to add device (169:0) to dtree ioctl deps call failed with errno 2 _deps: task run failed for (169:0) Failed to add device (169:0) to dtree Activated Volume Groups: vg0 I don't see which ioctl dep failed in e.g. dmesg # ls /dev/mapper/*obj* /dev/mapper/rrvg0-obj /dev/mapper/rvg0-obj /dev/mapper/vg0-obj ^rr ? lvm vgs, and lvm lvs appear to be sane, but # mount /dev/mapper/vg0-obj /usr/obj mount_ffs: /dev/mapper/vg0-obj on /usr/obj: Device busy Why busy - it isn't mounted... Reverting kernel & modules to 9.99.19 and all OK again. Cheers, Patrick
amd64 biosboot breakage and fix
Hello Sorry for the incident : my commit on multiboot support for amd64 broke biosboot. The offending change was sys/arch/amd64/conf/kern.ldscript 1.27-1.28 I reverted it in sys/arch/amd64/conf/kern.ldscript 1.28-1.29 amd64 biosboot should work again with 1.29. -- Emmanuel Dreyfus m...@netbsd.org
