Re: Building ZFS disk images
On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston wrote: > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > > There's this: > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . I > > haven't used it myself. > > Would it be useful to have an rc.d script that can run this, probably > just on the root pool? It could be configured to run only upon the > first boot, like growfs already does. Absolutely! > > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall wrote: > > > > > On 05/08/2021 13:53, Alan Somers wrote: > > > > I don't know of any way to do it using the official release scripts > > > > either. One problem is that every ZFS pool and file system is supposed > > > > to have a unique GUID. So any kind of ZFS release builder would need to > > > > re-guid the pool on first boot. > > > > > > Is there a tool / command to do this? I've hit this problem in the > > > past: I have multiple FreeBSD VMs that are all created from the same > > > template and if one dies I can't import its zpool into another because > > > they have the same UUID. > > > > > > It doesn't matter for modern deployments where the VM is stateless and > > > reimaged periodically but it's annoying for classic deployments where I > > > have things I care about on the VM. > > > > > > David
Re: Building ZFS disk images
On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > There's this: > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . I > haven't used it myself. Would it be useful to have an rc.d script that can run this, probably just on the root pool? It could be configured to run only upon the first boot, like growfs already does. > On Thu, Aug 5, 2021, 9:29 AM David Chisnall wrote: > > > On 05/08/2021 13:53, Alan Somers wrote: > > > I don't know of any way to do it using the official release scripts > > > either. One problem is that every ZFS pool and file system is supposed > > > to have a unique GUID. So any kind of ZFS release builder would need to > > > re-guid the pool on first boot. > > > > Is there a tool / command to do this? I've hit this problem in the > > past: I have multiple FreeBSD VMs that are all created from the same > > template and if one dies I can't import its zpool into another because > > they have the same UUID. > > > > It doesn't matter for modern deployments where the VM is stateless and > > reimaged periodically but it's annoying for classic deployments where I > > have things I care about on the VM. > > > > David
Re: ELF binary type "0" not known. (while compiling buildworld on risc-v/qemu)
On 27 Sep 2021, at 20:22, John Baldwin wrote: > > On 9/27/21 7:40 AM, Karel Gardas wrote: >> Hello, >> I'm playing with compiling freebsd 13 (releng/13.0 2 days ago) and >> current (git HEAD as of today) on qemu-5.1.0/qemu-6.1.0 on risv64 >> platform. The emulator invocation is: >> qemu-system-riscv64 -machine virt -smp 8 -m 16G -nographic -device >> virtio-blk-device,drive=hd -drive >> file=FreeBSD-14.0-CURRENT-riscv-riscv64.qcow2,if=none,id=hd -device >> virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2233-:22 >> -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel >> /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object >> rng-random,filename=/dev/urandom,id=rng -device >> virtio-rng-device,rng=rng -nographic -append "root=LABEL=rootfs >> console=ttyS0" >> and the host is Ubuntu 20.04.x LTS. Both qemu 5.1.0 and qemu 6.1.0 are >> compiled from, source, but both OpenSBI and u-boot for risc-v are Ubuntu >> packages provided (to accompany ubuntu provided qemu 4.2.1) >> My issue while compiling both 13 and current is that compilation after >> some time fails with: >> root@freebsd:/usr/src # time make -j8 buildworld > /tmp/build-j8-2.txt >> ELF binary type "0" not known. >> 17784.134u 21388.907s 1:50:13.83 592.2% 30721+572k 10+2177io 0pf+0w >> I'm curious if this is a know issue either in Qemu or in FreeBSD for >> risc-v or if I'm doing anything wrong here? > > It is a known issue with how we brand FreeBSD/riscv binaries. Jess > (cc'd) has a WIP review with a possible fix IIRC. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258358 and https://reviews.freebsd.org/D31323. The latter needs reworking because GCC doesn’t use all of our CSU files and instead provides its own that we have no control over. The bug report documents a one-line workaround. Jess
Re: ELF binary type "0" not known. (while compiling buildworld on risc-v/qemu)
On 9/27/21 7:40 AM, Karel Gardas wrote: Hello, I'm playing with compiling freebsd 13 (releng/13.0 2 days ago) and current (git HEAD as of today) on qemu-5.1.0/qemu-6.1.0 on risv64 platform. The emulator invocation is: qemu-system-riscv64 -machine virt -smp 8 -m 16G -nographic -device virtio-blk-device,drive=hd -drive file=FreeBSD-14.0-CURRENT-riscv-riscv64.qcow2,if=none,id=hd -device virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2233-:22 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng -nographic -append "root=LABEL=rootfs console=ttyS0" and the host is Ubuntu 20.04.x LTS. Both qemu 5.1.0 and qemu 6.1.0 are compiled from, source, but both OpenSBI and u-boot for risc-v are Ubuntu packages provided (to accompany ubuntu provided qemu 4.2.1) My issue while compiling both 13 and current is that compilation after some time fails with: root@freebsd:/usr/src # time make -j8 buildworld > /tmp/build-j8-2.txt ELF binary type "0" not known. 17784.134u 21388.907s 1:50:13.83 592.2% 30721+572k 10+2177io 0pf+0w I'm curious if this is a know issue either in Qemu or in FreeBSD for risc-v or if I'm doing anything wrong here? It is a known issue with how we brand FreeBSD/riscv binaries. Jess (cc'd) has a WIP review with a possible fix IIRC. -- John Baldwin
Re: [HEADSUP] making /bin/sh the default shell for root
> On Sep 27, 2021, at 5:11 AM, Christian Weisgerber wrote: > > Dirk Meyer: > >> Migration of aliase will be painful as ">&" and "|&" is not supoported. > > cshsh >> & foo >foo 2>&1 > |& foo 2>&1 | foo > Actually, the man page of csh says that this part isn't equivalent to the sh counterpart but this issue have no relation to the original problem in this thread. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com
BTX halted (pxeboot)
Hi, plain old-style pxeboot on amd64 (no EFI) gives me this with a tree at 2e79a216329f62a78dbbc72256e782353e220968 (Sep 16). It seems indepdent of the other issue we are seeing with EFI/arm64 netbooting (and the fix from there doesn't help here). Is anyone else seeing this or can repro? I'd love to avoid debugging two issues at the same time and would hope someone else can help with this one as essentially none of my Lab machines netboot anymore with a plain CURRENT now. /bz Intel(R) Boot Agent GE v1.3.65 Copyright (C) 1997-2010, Intel Corporation CLIENT MAC ADDR: ... CLIENT IP: 192.0.2.102 MASK: 255.255.255.0 DHCP IP: 192.0.2.1 PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 int=0006 err= efl=00010006 eip=830c4592 eax=000d ebx=00032b36 ecx=0001 edx=00062058 esi=3d22d750 edi= ebp=00079b90 esp=00079b6c cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=db fd f2 db af de f7 b6-f9 f6 7f 73 fd 5f f8 ff 1c ba 9f f7 ba 9c d3 ed-ff f6 ff 9d fd ff e9 d9 ss:esp=8c 7f 03 00 4b 20 06 00-50 d7 22 3d 9c 2c 03 00 1a 00 00 00 00 00 00 00-1a 00 00 00 41 1a 03 00 BTX halted -- Bjoern A. Zeeb r15:7
ELF binary type "0" not known. (while compiling buildworld on risc-v/qemu)
Hello, I'm playing with compiling freebsd 13 (releng/13.0 2 days ago) and current (git HEAD as of today) on qemu-5.1.0/qemu-6.1.0 on risv64 platform. The emulator invocation is: qemu-system-riscv64 -machine virt -smp 8 -m 16G -nographic -device virtio-blk-device,drive=hd -drive file=FreeBSD-14.0-CURRENT-riscv-riscv64.qcow2,if=none,id=hd -device virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2233-:22 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng -nographic -append "root=LABEL=rootfs console=ttyS0" and the host is Ubuntu 20.04.x LTS. Both qemu 5.1.0 and qemu 6.1.0 are compiled from, source, but both OpenSBI and u-boot for risc-v are Ubuntu packages provided (to accompany ubuntu provided qemu 4.2.1) My issue while compiling both 13 and current is that compilation after some time fails with: root@freebsd:/usr/src # time make -j8 buildworld > /tmp/build-j8-2.txt ELF binary type "0" not known. 17784.134u 21388.907s 1:50:13.83 592.2% 30721+572k 10+2177io 0pf+0w I'm curious if this is a know issue either in Qemu or in FreeBSD for risc-v or if I'm doing anything wrong here? Thanks! Karel
Re: [HEADSUP] making /bin/sh the default shell for root
Dirk Meyer: > Migration of aliase will be painful as ">&" and "|&" is not supoported. csh sh >& foo >foo 2>&1 |& foo 2>&1 | foo -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: I get odd time reports from poudriere on armv7 system, under a (non-debug) main [so: 14] FreeBSD.
On 2021-Sep-26, at 10:02, Ian Lepore wrote:
> On Sun, 2021-09-26 at 02:27 -0700, Mark Millard via freebsd-current
> wrote:
>> On 2021-Sep-25, at 23:25, Mark Millard wrote:
>>
>>
>> [...]
>> if (argc == 3 && strcmp(argv[2], "-nsec") == 0)
>> printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec);
>
> There are two problems with this, both the seconds and nanos are
> printed incorrectly. The correct incantation would be
>
> printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec);
>
Thanks Ian for looking into more than I did last night.
Based on the following (up to possible e-mail white space issues),
poudriere-devel seems t be working for reporting times:
# more /usr/ports/ports-mgmt/poudriere-devel/files/patch-clock
--- src/libexec/poudriere/clock/clock.c.orig2021-09-26 22:24:54.735485000
-0700
+++ src/libexec/poudriere/clock/clock.c 2021-09-26 11:46:12.076362000 -0700
@@ -24,6 +24,7 @@
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include
#include
#include
#include
@@ -71,8 +72,8 @@
} else
usage();
if (argc == 3 && strcmp(argv[2], "-nsec") == 0)
- printf("%ld.%ld\n", ts.tv_sec, ts.tv_nsec);
+ printf("%jd.%09ld\n", (intmax_t)ts.tv_sec, ts.tv_nsec);
else
- printf("%ld\n", ts.tv_sec);
+ printf("%jd\n", (intmax_t)ts.tv_sec);
return (EXIT_SUCCESS);
}
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
