Re: Removal of acorn26 port
acorn26 was moved to Tier III last week and unless someone steps forward it will be removed sometime in Mid-October 2015. To quote http://www.netbsd.org/ports/ : “The reasons can range from lack of community interest to the hardware becoming so rare that it is simply not available any more. Both are true. Removing arm26 support from the common arm code will make maintain arm code easier.
why does dk(4) take precedence in boot device selection???
I had the occasion to reboot one of my shiny new Xen servers today for the first time in a month and I found that it failed to boot because of the appearance since the previous successful boot of a new dk(4) attachment created for a GPT partition on another drive. boot device: dk0 root on dk0 Supported file systems: union umap tmpfs smbfs puffs ptyfs procfs overlay null ntfs nfs msdos mfs lfs kern cd9660 no file system for dk0 (dev 0xa800) cannot mount root, error = 79 root device (default dk0): The problem here is that the system boots from sd0 and root is on sd0a!!! Worse yet, dk0 is not even on sd0, it's a wedge on sd1: sd1 at scsibus1 target 1 lun 0: DELL, PERC 6/i, 1.11 disk fixed sd1: fabricating a geometry sd1: 1861 GB, 1905664 cyl, 64 head, 32 sec, 512 bytes/sect x 3902799872 sectors sd1: fabricating a geometry sd1: GPT GUID: e171fce5-0937-49de-ab2a-399ac308a695 dk0 at sd1: percraid0 dk0: 3902795776 blocks at 2048, type: The server is running a recent-ish NetBSD 7.99.5 XEN3_DOM0 kernel (from Feb. 20), under Xen-4.5. I used the following commands to put a GPT label on sd1 and make a wedge there for the dk0 device that I then use for LVM: dd if=/dev/zero of=/dev/rsd1d bs=8k count=1 gpt create sd1 gpt add -a 512k -l percraid0 sd1 dkctl sd1 makewedges As far as I know this should not make the wedge appear bootable, and I would not expect the kernel to treat this wedge as special in any way -- i.e. especially not to override the boot device specified by the loader. # dkctl sd1 listwedges /dev/rsd1d: 1 wedge: dk0: percraid0, 3902795776 blocks at 2048, type: Note the wedge type is blank. The manual doesn't seem to list a wedge type that would be valid for LVM use, though maybe ccd or swap or unused would suffice, but except for this boot problem it works with no type. I didn't do anything special to not select a type -- just the makewedges. I'm able to work around this with a bootdev=sd0 in /boot.cfg, but that doesn't seem like the right way, and I don't think it should be necessary. Google searches suggest I'm not the only person who has been tripped up by this issue. Am I missing something here that I could do to change the wedge configuration to avoid this issue? Is it still so difficult to discover which device the boot loader booted the kernel from on such a semi-modern amd64 machine that the kernel can make such mistakes as this? If dk(4) is auto-configuring can it not at least look to see if there's a valid filesystem on the device before it shoves itself in the front of the line as the supposed boot device? Should there be a wedge type for LVM? -- Greg A. Woods Planix, Inc. wo...@planix.com +1 250 762-7675http://www.planix.com/ n pgp9YSIS22_L6.pgp Description: PGP signature
Re: modules on -current
Yes, the command line (for i386, obviously) is ./build.sh -D/home/sysbuild/Sysbuild/i386/destdir -M/home/sysbuild/Sysbuild/i386/obj -N2 -R/home/sysbuild/Sysbuild/release -T/home/sysbuild/Sysbuild/i386/tools -U -X/home/sysbuild/xsrc -j6 -mi386 -u -x release iso-image (I use pkgsrc/sysbuild). Chavdar (but yesterday evening failed because /usr/shae/misc/acronyms-o was missing...). On Tue, 21 Apr 2015 at 14:38 Hisashi T Fujinaka ht...@twofifty.com wrote: Do you use -u? On Tue, 21 Apr 2015, Chavdar Ivanov wrote: Both my 7.99.10 overnight builds (i386 and amd64) were successful. Chavdar On Tue, 21 Apr 2015 at 03:30 Paul Goyette p...@vps1.whooppee.com wrote: Is it only the amd64-xen modules that aren;t handled properly? Or are both amd64 and amd64-xen affected? This used to work correctly (in the pre-7.0 days) - but of course, that was before the had the @OSRELEASE@ variants of the modules for amd64, i386, and powerpc... :) On Mon, 20 Apr 2015, Hisashi T Fujinaka wrote: I think you just have to delete the stand directory. For some reason the 7.99.10 don't get regenerated until the 7.99.9 is gone. On Mon, 20 Apr 2015, bch wrote: This has been the case nearly all day, so I'll report it: # ./build.sh -j4 -x -u distribution [...] ./stand/amd64-xen/7.99.10/modules/xc3028/xc3028.kmod ./stand/amd64-xen/7.99.10/modules/xc5k ./stand/amd64-xen/7.99.10/modules/xc5k/xc5k.kmod ./stand/amd64-xen/7.99.10/modules/zfs ./stand/amd64-xen/7.99.10/modules/zfs/zfs.kmod ./stand/amd64-xen/7.99.10/modules/zl10353 ./stand/amd64-xen/7.99.10/modules/zl10353/zl10353.kmod ./stand/amd64-xen/7.99.10/modules/zlib ./stand/amd64-xen/7.99.10/modules/zlib/zlib.kmod end of 388 missing files == *** [checkflist] Error code 1 nbmake[1]: stopped in /usr/src/distrib/sets 1 error nbmake[1]: stopped in /usr/src/distrib/sets *** [distribution] Error code 2 nbmake: stopped in /usr/src 1 error [...] -- Hisashi T Fujinaka - ht...@twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | - -- Hisashi T Fujinaka - ht...@twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Re: why does dk(4) take precedence in boot device selection???
wo...@planix.ca (Greg A. Woods) writes: Am I missing something here that I could do to change the wedge configuration to avoid this issue? Is it still so difficult to discover which device the boot loader booted the kernel from on such a semi-modern amd64 machine that the kernel can make such mistakes as this? If dk(4) is auto-configuring can it not at least look to see if there's a valid filesystem on the device before it shoves itself in the front of the line as the supposed boot device? The device drivers, including dk, do not 'shove itself' anywhere. There are several, ugly, heuristics to guess which device and partition was used to boot from, so that it be mounted as root. Some of this could, in particular for x86, could be just removed. But it might affects some edge cases. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
