daily CVS update output
Updating src tree: P src/distrib/sets/lists/man/mi P src/distrib/utils/x_gzip/Makefile P src/doc/CHANGES P src/sbin/mount/mount.8 P src/share/man/man4/Makefile P src/share/man/man4/pci.4 U src/share/man/man4/udl.4 P src/share/man/man4/usb.4 P src/share/mk/bsd.subdir.mk P src/sys/arch/macppc/stand/ofwboot/loadfile_machdep.c P src/sys/compat/common/tty_43.c P src/sys/external/bsd/drm2/linux/linux_hdmi.c P src/sys/kern/kern_physio.c P src/sys/kern/sys_generic.c P src/sys/kern/sys_process_lwpstatus.c P src/sys/kern/sys_ptrace.c P src/sys/sys/cpuio.h P src/usr.bin/make/unit-tests/varmod-head.exp P src/usr.bin/make/unit-tests/varmod-head.mk P src/usr.sbin/installboot/evboards.c P src/usr.sbin/installboot/installboot.8 P src/usr.sbin/installboot/installboot.c P src/usr.sbin/installboot/installboot.h P src/usr.sbin/sysinst/defs.h P src/usr.sbin/sysinst/install.c P src/usr.sbin/sysinst/main.c P src/usr.sbin/sysinst/mbr.c P src/usr.sbin/sysinst/menus.mi P src/usr.sbin/sysinst/partman.c P src/usr.sbin/sysinst/util.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 39293862 Jul 11 03:09 ls-lRA.gz
Re: Script to create bootable arm images?
> On Jun 24, 2022, at 4:49 PM, Greg Troxel wrote:
>
> As someone on the outside, I think it would be good to have checked-in
> scripts with comments about what they depend on. I can see that those
> that do this think that's unnecessary, but also that it is documentation
> of the process for almost everybody else.
To pick up this thread, I have never figured out how the images on armbsd.org
are being made. However, it is clear that we can improve the standard build
system to make it automatic to create any set of bootable images. I propose
the patch below to do this, and would greatly appreciate review and comments.
The goal is to allow, but not require, individual developers to automatically
populate ${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg with board-specific
bootable images. This would also allow, but again not require, the build farms
to include those images in official release repositories, which might make it
easier for users to test or adopt NetBSD on platforms that currently do not
provide official bootable images.
Here is my more formal rationale (e.g., likely future commit message):
Release builds for arm platforms create compressed images in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. However, in some
cases, e.g., armv7.img.gz, they are not bootable. Consequently, boot
blocks must be manually installed in the images, which is an extra
barrier for testing systems or adopting NetBSD. This has prompted
creation of external repositories, e.g., armbsd.org, to host a
collection of bootable images. However, this does not ease the burden
on developers compiling their own systems; for them, manual
installation of boot blocks is still required.
For arm platforms, etc/etc.evbarm/Makefile.inc contains the commands
used to create system images. Because installboot(8) can write boot
blocks directly to system images, a loop through possible boards can
create a series of bootable images during the normal build process.
In the case of many arm platforms, installboot(8) uses U-Boot boot
blocks, which are not part of the NetBSD source code. Developers can,
however, install as many U-Boot boot blocks as desired, either in the
default location of /usr/pkg/share/u-boot or in a set of directories
pointed to by the U-Boot search path, the INSTALLBOOT_UBOOT_PATHS
environment variable. For each board with an available boot block, a
board-specific bootable image will be created in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. If a boot block is
not available, which is the typical situation currently, no additional
image will be created.
This facility creates opportunities to build bootable images for any
number of boards within the scope of a standard release build.
However, that is not required and will not occur without the
intervention of installing U-Boot boot blocks prior to the build.
Cheers,
Brook
bootable-images.diff
Description: Binary data
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
m...@eterna.com.au (matthew green) writes: >FWIW, i've been using 64K block *and frag size FFS for over >a decade without any problem, on a file system that almost >always has extremely large files on it. >so, this should be fixed in the manual i guess. The manual just lists the default values as is and does not mention an upper limit.
re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
> (but I'm nots sure 64KB blocksize is valied on FFS because > newfs(8) man page just says 4KB-32KB for it) FWIW, i've been using 64K block *and frag size FFS for over a decade without any problem, on a file system that almost always has extremely large files on it. so, this should be fixed in the manual i guess. .mrg.
Re: iscsi target on a zfs zvol?
ha...@espresso.rhein-neckar.de (Hauke Fath) writes: >Jul 10 22:56:18 pizza istgt[9108]:=20 >istgt_iscsi.c:4165:istgt_iscsi_op_nopout: ***ERROR*** CmdSN(24873146)=20 >error ExpCmdSN=3D24873145=20 >Jul 10 22:56:18 pizza istgt[9108]:=20 >istgt_iscsi.c:5045:istgt_iscsi_execute: ***ERROR*** iscsi_op_nopout()=20 >failed=20 >Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:5731:worker:=20 >***ERROR*** iscsi_execute() failed on=20 >iqn.2007-09.jp.ne.peach.istgt:disk1,t,0x0001(iqn.20 >(initiator is daemon-tools.cc). That is at least something completely different, an ISCSI protocol error.
Re: iscsi target on a zfs zvol?
On Sun, 10 Jul 2022 19:40:56 - (UTC), Michael van Elst wrote: >> I would like to set up an iscsi target backed by a zfs zvol, to serve=20 >> as a Mac time machine volume. > > Independent of your problem you should use 'istgt' from pkgsrc. Thanks. Different, but not (much) better. While iscsi-target(8) gave me at least one run with 20 GB, before it started erroring out, istgt(8) goes away once a minute with Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:4165:istgt_iscsi_op_nopout: ***ERROR*** CmdSN(24873146) error ExpCmdSN=24873145 Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:5045:istgt_iscsi_execute: ***ERROR*** iscsi_op_nopout() failed Jul 10 22:56:18 pizza istgt[9108]: istgt_iscsi.c:5731:worker: ***ERROR*** iscsi_execute() failed on iqn.2007-09.jp.ne.peach.istgt:disk1,t,0x0001(iqn.20 (initiator is daemon-tools.cc). Pity - it's such a nice idea... Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: iscsi target on a zfs zvol?
On 10 July 2022 20:40:56 (+01:00), Michael van Elst wrote: > ha...@espresso.rhein-neckar.de (Hauke Fath) writes: > > >I would like to set up an iscsi target backed by a zfs zvol, to serve=20 > >as a Mac time machine volume. I have been using iSCSI target backed by a zvol for quite some time. Initially I tried the built-in target (always on -current, whatever was the version at the time), but found it to be less reliable than the pkgsrc version. > > Independent of your problem you should use 'istgt' from pkgsrc. > > > 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/= >disk.c:720:=20 > >***ERROR*** error reading "target0" > ># hexdump -C -n 512 /dev/zvol/rdsk/tank/time_machine_1=20 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =20 > >at which point > >DISK: LUN 0: 2097152 MB disk storage for "target0" I would check the permissions of /dev/zvol/rdsk... (that is from elsewhere - I also use zvol-backed disks for my NVMM virtual machines, the default wouldn't work if I start the VM as a user). I can't verify the exact setup unfortunately - the laptop I was using for all that finally packed yesterday after some 9 years of faithful work and I will have to look for another suitable hardware to get my daily NetBSD fix... > > > >Looks like an initialization issue on behalf of iscsi-target. Does that=20 > >ring a bell for anyone? > > Probably unrelated to ZFS, this reminds me of: > > # stat -s /dev/rvnd0a > st_dev=43010 st_ino=65103 st_mode=020640 st_nlink=1 st_uid=0 st_gid=5 st_rdev=10496 st_size=0 st_atime=1590051866 st_mtime=1590051866 st_ctime=1590051866 st_birthtime=1590051866 st_blksize=65536 st_blocks=0 st_flags=0 > > # hexdump -C /dev/rvnd0a | head -1 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > > # stat -s /dev/rvnd0a > st_dev=43010 st_ino=65103 st_mode=020640 st_nlink=1 st_uid=0 st_gid=5 st_rdev=10496 st_size=10485760 st_atime=1657481715 st_mtime=1590051866 st_ctime=1590051866 st_birthtime=1590051866 st_blksize=65536 st_blocks=0 st_flags=0 > > Before opening the device with hexdump, the st_size field is 0. > > The size is cached in the vnode, but only determined when you open the > device. The information gets lost again when the vnode is expired, > which only happens when there is a memory shortage. > > -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
Re: iscsi target on a zfs zvol?
ha...@espresso.rhein-neckar.de (Hauke Fath) writes: >I would like to set up an iscsi target backed by a zfs zvol, to serve=20 >as a Mac time machine volume. Independent of your problem you should use 'istgt' from pkgsrc. >863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/= >disk.c:720:=20 >***ERROR*** error reading "target0" ># hexdump -C -n 512 /dev/zvol/rdsk/tank/time_machine_1=20 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =20 >at which point >DISK: LUN 0: 2097152 MB disk storage for "target0" >Looks like an initialization issue on behalf of iscsi-target. Does that=20 >ring a bell for anyone? Probably unrelated to ZFS, this reminds me of: # stat -s /dev/rvnd0a st_dev=43010 st_ino=65103 st_mode=020640 st_nlink=1 st_uid=0 st_gid=5 st_rdev=10496 st_size=0 st_atime=1590051866 st_mtime=1590051866 st_ctime=1590051866 st_birthtime=1590051866 st_blksize=65536 st_blocks=0 st_flags=0 # hexdump -C /dev/rvnd0a | head -1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | # stat -s /dev/rvnd0a st_dev=43010 st_ino=65103 st_mode=020640 st_nlink=1 st_uid=0 st_gid=5 st_rdev=10496 st_size=10485760 st_atime=1657481715 st_mtime=1590051866 st_ctime=1590051866 st_birthtime=1590051866 st_blksize=65536 st_blocks=0 st_flags=0 Before opening the device with hexdump, the st_size field is 0. The size is cached in the vnode, but only determined when you open the device. The information gets lost again when the vnode is expired, which only happens when there is a memory shortage.
iscsi target on a zfs zvol?
Hi, I would like to set up an iscsi target backed by a zfs zvol, to serve as a Mac time machine volume. But the attempt to start the target fails with # /etc/rc.d/iscsi_target onestart Starting iscsi_target. Reading configuration from `/etc/iscsi/targets' target0:rw:0.0.0.0/0 extent0:/dev/zvol/rdsk/tank/time_machine_1:0:0 DISK: 1 logical unit (0 blocks, 512 bytes/block), type iscsi fs DISK: LUN 0: pid 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:720: ***ERROR*** error reading "target0" pid 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:886: ***ERROR*** error allocating space for "target0" pid 863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:1990: ***ERROR*** device_init() failed iscsi_target_start() failed # until I do something like # hexdump -C -n 512 /dev/zvol/rdsk/tank/time_machine_1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 fe ff ff ff 00 00 || 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 # at which point # /etc/rc.d/iscsi_target onestart Starting iscsi_target. Reading configuration from `/etc/iscsi/targets' target0:rw:0.0.0.0/0 extent0:/dev/zvol/rdsk/tank/time_machine_1:0:219902322 DISK: 1 logical unit (4294967296 blocks, 512 bytes/block), type iscsi fs DISK: LUN 0: 2097152 MB disk storage for "target0" TARGET: iSCSI Qualified Name (IQN) is iqn.1994-04.org.netbsd.iscsi-target # Looks like an initialization issue on behalf of iscsi-target. Does that ring a bell for anyone? Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: pgdaemon high CPU consumption
Hello Frank, On 01.07.22 14:07, Frank Kardel wrote: Hi Matthias ! See PR 55707 http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55707 , which I do not considere fixed due to the pgdaemon issue. reverting arc.cto 1.20 will give you many xcalls, but the system stays more usable. Frank thanks for this reference... it matches pretty much my observations. I did a lot of attempts to tune maxvnodes during the last days, but the pgdaemon issue remained. Ultimately I suspect it is also responsible for the reproducible system lock-ups during ZFS send. I am about to revert the patch from the PR above on my system and re-try. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
mlelstv@ wrote:
> r...@sdf.org (RVP) writes:
>
> >@@ -255,7 +255,7 @@
> > echo ${bar} Populating ffs filesystem ${bar}
> > ${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
> > -O ${ffsoffset} \
> >--o d=4096,f=8192,b=65536 -b $((${extra}))m \
> >+-o d=8192,f=2048,b=16384 -b $((${extra}))m \
> > -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
>
>
> Sounds like the disklabel is incorrect then. FFS requires that
> the fragment size (not so much the blocksize) is correct, but the
> scripts seem to be inconsistent.
>
> N.B. unset fsize (== 0) defaults to fsize = BLKDEV_IOSIZE (== 2048).
I doubt recent newfs(8) or bootloaders refer bsize and fsize
in disklabel.
IIRC libsa/sa/ufs.c requires large heapsize to read blocksize,
from ffs, so sometimes it fails to load on blocksize=65536 fs.
(but I'm nots sure 64KB blocksize is valied on FFS because
newfs(8) man page just says 4KB-32KB for it)
---
Izumi Tsutsui
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
r...@sdf.org (RVP) writes:
>@@ -255,7 +255,7 @@
> echo ${bar} Populating ffs filesystem ${bar}
> ${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
> -O ${ffsoffset} \
>- -o d=4096,f=8192,b=65536 -b $((${extra}))m \
>+ -o d=8192,f=2048,b=16384 -b $((${extra}))m \
> -F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
Sounds like the disklabel is incorrect then. FFS requires that
the fragment size (not so much the blocksize) is correct, but the
scripts seem to be inconsistent.
N.B. unset fsize (== 0) defaults to fsize = BLKDEV_IOSIZE (== 2048).
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Thu, 7 Jul 2022, br0nko wrote:
I wanted to resurrect an old i386 alix box, and I did follow the
guide to create a custom image trough mkimage
(https://www.netbsd.org/docs/guide/en/chap-inst-media.html#chap-inst-media-creating-live-images).
I did first try on amd64 so that I can first test on my laptop.
Build was successful but when I boot the USB key, I'm stuck on
primary bootstrap ("NetBSD/x86 ffsv1 Primary Bootstrap"), no error.
However I can boot it from grub (installed on the laptop hard-drive),
image is fully functional that way.
Right. After ~10 hours of doing `build.sh release' I have a patch. However,
I'm not at all certain that this script is meant to be used on the x86 arch.
because:
a) It only seems to be used by the evbarm and evbmips builds.
b) `build live-image' already works (better!) than this script.
c) it does very odd things:
1. writes a partition table and an MBR.
2. promptly over-writes it with the primary bootstrap (PBR) and the
disklabel, so the system actually boots directly from the PBR.
Still, here's the patch:
---
diff -urN a/distrib/utils/embedded/mkimage b/distrib/utils/embedded/mkimage
--- a/distrib/utils/embedded/mkimage2021-09-25 08:54:30.0 +
+++ b/distrib/utils/embedded/mkimage2022-07-10 08:18:03.575853000 +
@@ -255,7 +255,7 @@
echo ${bar} Populating ffs filesystem ${bar}
${MAKEFS} -rx ${endian} -N ${release}/etc -t ffs \
-O ${ffsoffset} \
- -o d=4096,f=8192,b=65536 -b $((${extra}))m \
+ -o d=8192,f=2048,b=16384 -b $((${extra}))m \
-F "$tmp/selected_sets" ${image} "${release}" "${mnt}"
fi
---
1. Make sure you pass the `-r sd' or `-r wd' flags, otherwise, the script
defaults to `ld' and builds an /etc/fstab with that baked in.
2. This doesn't produce a very good live image as a) there's hardly any
free space left over, and b) it doesn't grow the root partition like
`build.sh live-image' does.
I'm don't know what this little oddball script is doing in the Guide...
On Sat, 9 Jul 2022, Lloyd Parkes wrote:
63 is a popular offset because the BIOS field for track length can only
hold values 0-63.
Of course--I should've remembered that :)
-RVP
