Re: Daily packages for NetBSD/amd64 current
> I was going to choose 9.0, but I saw that mef@ was already producing > regular bulk builds on that for pkgsrc-current available here: > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_current/ > so went with NetBSD-current instead, though it's quite unreliable so I > may revisit that choice if every bulk build requires manual > intervention and restarts. > Jonathan Perkin - Joyent, Inc. - www.joyent.com What is "quite unreliable"? Do you mean the NetBSD-current base system, or do you mean the ABI that might not hold still, thereby breaking packages following a base-system upgrade? I need to upgrade my NetBSD 8.99.51 system, lean toward current rather than releng 9. In my situation, I will have to rebuild/reinstall all or nearly all packages, even more so if I switch from modular Xorg to native Xorg. There is also the problem of transition from Python 2.7 to 3.x, which has been posing complications not limited to NetBSD. Tom
daily CVS update output
Updating src tree: P src/doc/3RDPARTY P src/sys/arch/mips/include/cpuregs.h P src/sys/crypto/chacha/arch/arm/chacha_neon_32.S P src/sys/ddb/db_lex.c P src/sys/ddb/db_lex.h P src/sys/dev/pci/nvme_pci.c P src/sys/dev/pci/xmm7360.c P src/usr.bin/make/Makefile P src/usr.bin/make/var.c P src/usr.bin/make/unit-tests/Makefile P src/usr.bin/make/unit-tests/moderrs.exp P src/usr.bin/make/unit-tests/moderrs.mk P src/usr.bin/make/unit-tests/modmisc.exp P src/usr.bin/make/unit-tests/modmisc.mk Updating xsrc tree: P xsrc/external/mit/xorg-server/dist/hw/sun/sun.h P xsrc/external/mit/xorg-server/dist/hw/sun/sunKbd.c Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 42999133 Jul 30 03:03 ls-lRA.gz
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
On Wed, Jul 29, 2020 at 06:13:03PM +0100, Chavdar Ivanov wrote: > On Wed, 29 Jul 2020 at 08:33, Matthias Petermann wrote: > > > > Hello Chavdar, > > > > Am 28.07.2020 um 18:48 schrieb Chavdar Ivanov: > > > This being a place people are trying samba4 as a DC, I got a > > > repeatable panic on one of the systems I am trying it on, as follows: > > > > > > crash: _kvm_kvatop(0) > > > Crash version 9.99.69, image version 9.99.69. > > > Kernel compiled without options LOCKDEBUG. > > > System panicked: /: bad dir ino 657889 at offset 0: Bad dir (not > > > rounded), reclen=0x2e33, namlen=51, dirsiz=60 <= reclen=11827 <= > > > maxsize=512, flags=0x2005900, entryoffsetinblock=0, dirblksiz=512 > > > > > > Backtrace from time of crash is available. > > > _KERNEL_OPT_NARCNET() at 0 > > > _KERNEL_OPT_DDB_HISTORY_SIZE() at _KERNEL_OPT_DDB_HISTORY_SIZE > > > sys_reboot() at sys_reboot > > > vpanic() at vpanic+0x15b > > > snprintf() at snprintf > > > ufs_lookup() at ufs_lookup+0x518 > > > VOP_LOOKUP() at VOP_LOOKUP+0x42 > > > lookup_once() at lookup_once+0x1a1 > > > namei_tryemulroot() at namei_tryemulroot+0xacf > > > namei() at namei+0x29 > > > vn_open() at vn_open+0x9a > > > do_open() at do_open+0x112 > > > do_sys_openat() at do_sys_openat+0x72 > > > sys_open() at sys_open+0x24 > > > syscall() at syscall+0x26e > > > --- syscall (number 5) --- > > > syscall+0x26e: > > > > > > > > > that still looks like a file system inconsistency. Before the patch from > > Chuck I also had the case several times that a filesystem that was > > apparently repaired with fsck could no longer be trusted. After > > importing the patched kernel, to be on the safe side, I recreated all > > the file systems previously mounted with posix1eacls with newfs. > > Hard that one, as it was the root file system... Anyway, a couple of > fsck's seem to have sorted out this one. how exactly did you run fsck to fix this? the most reliable way is to boot the machine single-user, then run "fsck -fy ..." from the console shell, then run the same fsck command again to make sure that it says that everything is ok, then reboot. if you have done that and are still crashing due to corruption in your root file system, then we still have another bug in the kernel somewhere. > > Presumably fsck is not prepared for the kind of inconsistency, and only > > a newfs can restore a trustworthy initial state. What is the starting > > point for you? Has the file system been created after the patch, or has > > it only been treated with fsck so far? > > I think it may have been created before the patch to the filesystem > code, but before the second version of the samba4 package. > > > > > In any case, I would advise you - if you have not already done so - to > > use a separate partition or LVM volume for the sysvol with its own file > > system, and to mount only this with the posix1eacls option. It seems the > > ACL code still needs a lot of testingh, so at least you can be sure that > > your root filesystem will not be affected. > > As this was running on a XCP-NG guest, I added a small 1GB disk to the > vm, created the filesystem (-O 2) and mounted it on /var/db/samba4. > > I removed the 'posix1eacls' options from the other existing > filesystems and left it only for the one mounted on /var/db/samba4 . > In this case, the provisioning fails with a message that the > filesystem does not support acls - so it perhaps checks the root > filesystem after all. I then re-added this option to /, newfs'd > /var/db/samba4, rebooted and retried the provisioning. This resulted > in a similar to the above panic, this time after perhaps 10 minutes > work of python8 doing database conversion from v1 to v2 - the third > database in the list. As this was seen on the console of the XCP-NG > guest, I took screenshots of the panic, in case someone is interested. yes, I'd like to see the screenshots please. -Chuck
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
On Wed, 29 Jul 2020 at 08:33, Matthias Petermann wrote: > > Hello Chavdar, > > Am 28.07.2020 um 18:48 schrieb Chavdar Ivanov: > > This being a place people are trying samba4 as a DC, I got a > > repeatable panic on one of the systems I am trying it on, as follows: > > > > crash: _kvm_kvatop(0) > > Crash version 9.99.69, image version 9.99.69. > > Kernel compiled without options LOCKDEBUG. > > System panicked: /: bad dir ino 657889 at offset 0: Bad dir (not > > rounded), reclen=0x2e33, namlen=51, dirsiz=60 <= reclen=11827 <= > > maxsize=512, flags=0x2005900, entryoffsetinblock=0, dirblksiz=512 > > > > Backtrace from time of crash is available. > > _KERNEL_OPT_NARCNET() at 0 > > _KERNEL_OPT_DDB_HISTORY_SIZE() at _KERNEL_OPT_DDB_HISTORY_SIZE > > sys_reboot() at sys_reboot > > vpanic() at vpanic+0x15b > > snprintf() at snprintf > > ufs_lookup() at ufs_lookup+0x518 > > VOP_LOOKUP() at VOP_LOOKUP+0x42 > > lookup_once() at lookup_once+0x1a1 > > namei_tryemulroot() at namei_tryemulroot+0xacf > > namei() at namei+0x29 > > vn_open() at vn_open+0x9a > > do_open() at do_open+0x112 > > do_sys_openat() at do_sys_openat+0x72 > > sys_open() at sys_open+0x24 > > syscall() at syscall+0x26e > > --- syscall (number 5) --- > > syscall+0x26e: > > > > > that still looks like a file system inconsistency. Before the patch from > Chuck I also had the case several times that a filesystem that was > apparently repaired with fsck could no longer be trusted. After > importing the patched kernel, to be on the safe side, I recreated all > the file systems previously mounted with posix1eacls with newfs. Hard that one, as it was the root file system... Anyway, a couple of fsck's seem to have sorted out this one. > Presumably fsck is not prepared for the kind of inconsistency, and only > a newfs can restore a trustworthy initial state. What is the starting > point for you? Has the file system been created after the patch, or has > it only been treated with fsck so far? I think it may have been created before the patch to the filesystem code, but before the second version of the samba4 package. > > In any case, I would advise you - if you have not already done so - to > use a separate partition or LVM volume for the sysvol with its own file > system, and to mount only this with the posix1eacls option. It seems the > ACL code still needs a lot of testingh, so at least you can be sure that > your root filesystem will not be affected. As this was running on a XCP-NG guest, I added a small 1GB disk to the vm, created the filesystem (-O 2) and mounted it on /var/db/samba4. I removed the 'posix1eacls' options from the other existing filesystems and left it only for the one mounted on /var/db/samba4 . In this case, the provisioning fails with a message that the filesystem does not support acls - so it perhaps checks the root filesystem after all. I then re-added this option to /, newfs'd /var/db/samba4, rebooted and retried the provisioning. This resulted in a similar to the above panic, this time after perhaps 10 minutes work of python8 doing database conversion from v1 to v2 - the third database in the list. As this was seen on the console of the XCP-NG guest, I took screenshots of the panic, in case someone is interested. So no provisioning, unfortunately. The second machine I tried it on is my main development box, perhaps I have been a tad too confident with it, so I won't try for now on it, but will spin another box with only samba4 installed via pkgin to make sure there is nothing in the way of testing. My problem may be related to having the 'log' option in the fstab, though. > > Definitely good to know that you also test with Samba - many eyes see > more :-) Sure, it is useful to get it running properly under NetBSD. So far I always maintain a couple of Windows 2019 servers at home as DCs - the evaluation versions come with six months license, but you have I think rearm count of 5, so you can use it for three years, effectively for free; I would like to test all other options, though - with second DC under NetBSD etc. I also can't figure out how to deal with DNS - I have a server in the network, which is setup as a forwarder to the same subnet as the DC; the DC registers in its internal database itself and all added hosts, but the rest of the network can't resolve those - without manually adding them to the other DNS server. > > Best wishes > Matthias Cheers, Chavdar --
Re: Daily packages for NetBSD/amd64 current
* On 2020-07-28 at 23:00 BST, J. Lewis Muir wrote: > On 07/25, Jonathan Perkin wrote: > > I needed a NetBSD-current system for testing pkgin changes, and > > figured I may as well also set it up for daily package builds. > > > > So if anybody would like a repository for the latest packages then > > head over to https://pkgsrc.joyent.com/install-on-netbsd/ to install > > the bootstrap kit. > > I run a stable branch of NetBSD, so I would ideally wish for packages > built for NetBSD 9 stable, but I understand that that wasn't what you > needed. Hey Lewis, I was going to choose 9.0, but I saw that mef@ was already producing regular bulk builds on that for pkgsrc-current available here: https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_current/ so went with NetBSD-current instead, though it's quite unreliable so I may revisit that choice if every bulk build requires manual intervention and restarts. > BTW, the Package Development wiki pages at > > https://github.com/joyent/pkgsrc/wiki > > need to be updated to include NetBSD. Yeh I'll get around to this at some point. Thanks, -- Jonathan Perkin - Joyent, Inc. - www.joyent.com
Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...
Hello Chavdar, Am 28.07.2020 um 18:48 schrieb Chavdar Ivanov: This being a place people are trying samba4 as a DC, I got a repeatable panic on one of the systems I am trying it on, as follows: crash: _kvm_kvatop(0) Crash version 9.99.69, image version 9.99.69. Kernel compiled without options LOCKDEBUG. System panicked: /: bad dir ino 657889 at offset 0: Bad dir (not rounded), reclen=0x2e33, namlen=51, dirsiz=60 <= reclen=11827 <= maxsize=512, flags=0x2005900, entryoffsetinblock=0, dirblksiz=512 Backtrace from time of crash is available. _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_DDB_HISTORY_SIZE() at _KERNEL_OPT_DDB_HISTORY_SIZE sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf ufs_lookup() at ufs_lookup+0x518 VOP_LOOKUP() at VOP_LOOKUP+0x42 lookup_once() at lookup_once+0x1a1 namei_tryemulroot() at namei_tryemulroot+0xacf namei() at namei+0x29 vn_open() at vn_open+0x9a do_open() at do_open+0x112 do_sys_openat() at do_sys_openat+0x72 sys_open() at sys_open+0x24 syscall() at syscall+0x26e --- syscall (number 5) --- syscall+0x26e: that still looks like a file system inconsistency. Before the patch from Chuck I also had the case several times that a filesystem that was apparently repaired with fsck could no longer be trusted. After importing the patched kernel, to be on the safe side, I recreated all the file systems previously mounted with posix1eacls with newfs. Presumably fsck is not prepared for the kind of inconsistency, and only a newfs can restore a trustworthy initial state. What is the starting point for you? Has the file system been created after the patch, or has it only been treated with fsck so far? In any case, I would advise you - if you have not already done so - to use a separate partition or LVM volume for the sysvol with its own file system, and to mount only this with the posix1eacls option. It seems the ACL code still needs a lot of testingh, so at least you can be sure that your root filesystem will not be affected. Definitely good to know that you also test with Samba - many eyes see more :-) Best wishes Matthias
