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.
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 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 > 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 >
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: 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. +1 250 762-7675http://www.planix.com/ n pgp9YSIS22_L6.pgp Description: PGP signature
daily CVS update output
Updating src tree: P src/distrib/atari/floppies/install/Makefile P src/distrib/hp300/miniroot/list P src/distrib/mac68k/miniroot/list P src/distrib/mvme68k/miniroot/list P src/external/bsd/wpa/dist/src/p2p/p2p.c P src/games/wtf/wtf.6 P src/lib/libc/sys/intro.2 P src/sbin/ifconfig/af_inet6.c P src/sbin/ifconfig/ifconfig.c P src/sbin/ifconfig/util.h P src/sbin/route/Makefile P src/share/misc/Makefile P src/share/misc/acronyms P src/share/mk/bsd.README P src/share/mk/bsd.own.mk P src/sys/arch/evbarm/conf/std.awin P src/sys/arch/i386/include/types.h P src/sys/arch/mips/ingenic/ingenic_regs.h P src/sys/fs/puffs/puffs_compat.c P src/sys/kern/init_sysctl.c P src/sys/kern/kern_clock.c P src/sys/net/if.c P src/sys/netinet6/in6.c P src/sys/netinet6/in6.h P src/sys/netinet6/in6_proto.c P src/sys/rump/Makefile.rump P src/sys/rump/dev/lib/libraidframe/Makefile P src/sys/rump/include/machine/cpu.h P src/sys/rump/kern/lib/libtty/Makefile P src/sys/rump/librump/rumpkern/Makefile.rumpkern P src/sys/rump/librump/rumpkern/emul.c P src/sys/rump/librump/rumpkern/intr.c P src/sys/rump/librump/rumpkern/rump.c P src/sys/rump/librump/rumpkern/rump_private.h P src/sys/rump/librump/rumpkern/scheduler.c P src/sys/rump/librump/rumpkern/arch/alpha/Makefile.inc P src/sys/rump/librump/rumpkern/arch/arm/Makefile.inc P src/sys/rump/librump/rumpkern/arch/generic/Makefile.inc U src/sys/rump/librump/rumpkern/arch/generic/rump_generic_abi.c P src/sys/rump/librump/rumpkern/arch/generic/rump_generic_cpu.c P src/sys/rump/librump/rumpkern/arch/mips/Makefile.inc P src/sys/rump/librump/rumpkern/arch/powerpc/Makefile.inc P src/sys/rump/librump/rumpkern/arch/x86/Makefile.inc U src/sys/rump/librump/rumpkern/arch/x86/rump_x86_abi.c P src/sys/rump/librump/rumpkern/arch/x86/rump_x86_cpu.c P src/sys/rump/librump/rumpvfs/Makefile.rumpvfs cvs update: `src/sys/rump/librump/rumpvfs/compat.c' is no longer in the repository U src/sys/rump/librump/rumpvfs/rumpvfs_compat50.c P src/sys/rump/net/lib/libnet/Makefile P src/sys/sys/domain.h P src/sys/ufs/ffs/ffs_vfsops.c P src/tests/lib/libc/time/t_strptime.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Thu Apr 23 03:04:41 2015 SUP Scan for current completed at Thu Apr 23 03:06:02 2015 SUP Scan for mirror starting at Thu Apr 23 03:06:02 2015 SUP Scan for mirror completed at Thu Apr 23 03:08:25 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 46089820 Apr 23 03:20 ls-lRA.gz
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."
