Re: ZFS going forward, on stable/13 vs. main: question
[Just a resend: asking the question on the list less than an hour before the UTC month change might not be all that effective relative to those that just web browse the list to read it.] On 2021-Apr-30, at 16:21, Mark Millard wrote: > Context . . . > > I've been experimenting with ZFS and bectl use recently. > It has been many years since I last used ZFS --and that > was only a short experiment that did not have to deal > with upgrades over time. > > I now have: > > # bectl list > BE Active Mountpoint Space Created > 13S-CA72-nodbg N / 4.02G 2021-04-27 18:55 > 13_0R-CA72-nodbg R - 8.49G 2021-04-28 10:48 > main-CA72-nodbg - - 3.24G 2021-04-30 13:25 > > (so a stable/13 vintage , releng/13.0 as of release/13.0.0 , > and a main vintage for what things are based on). That is > via: > > zroot/ROOT/13S-CA72-nodbg 1.60G 131G 4.10G / > zroot/ROOT/13_0R-CA72-nodbg8.49G 131G 4.59G / > zroot/ROOT/main-CA72-nodbg 1.77G 131G 4.63G / > > For reference: the context is simple in various > other respects: > > # gpart show > => 40 468862048 da0 GPT (224G) > 40 5324801 efi (260M) > 532520 2008 - free - (1.0M) > 534528 251658242 freebsd-swap (12G) > 25700352 251658244 freebsd-swap (12G) > 50866176 4179947523 freebsd-zfs (199G) > 468860928 1160 - free - (580K) > > The USB SSD is used to boot and use any of (all > aarch64): > > An OverDrive 1000 > A MACCHIATObin Double Shot > Various RPi4B's with 8 GiBytes RAM > Potentially various RPI4B's with 4 GiBytes RAM. > > > Question . . . > > Are there any potential future upgrade issues with main > [so: 14] vs. stable/13 and releng/13.0 , say by main > updates involving ZFS updates in a way stable/13 or the > recent releng/13.* might not handle? > > The implication would be that such a mix of boot > environments on the same zpool or media might not > be a good idea over time: main might be better > separated so the ZFS versioning is independent > between 13 and 14. > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS going forward, on stable/13 vs. main: question
Context . . . I've been experimenting with ZFS and bectl use recently. It has been many years since I last used ZFS --and that was only a short experiment that did not have to deal with upgrades over time. I now have: # bectl list BE Active Mountpoint Space Created 13S-CA72-nodbg N / 4.02G 2021-04-27 18:55 13_0R-CA72-nodbg R - 8.49G 2021-04-28 10:48 main-CA72-nodbg - - 3.24G 2021-04-30 13:25 (so a stable/13 vintage , releng/13.0 as of release/13.0.0 , and a main vintage for what things are based on). That is via: zroot/ROOT/13S-CA72-nodbg 1.60G 131G 4.10G / zroot/ROOT/13_0R-CA72-nodbg8.49G 131G 4.59G / zroot/ROOT/main-CA72-nodbg 1.77G 131G 4.63G / For reference: the context is simple in various other respects: # gpart show => 40 468862048 da0 GPT (224G) 40 5324801 efi (260M) 532520 2008 - free - (1.0M) 534528 251658242 freebsd-swap (12G) 25700352 251658244 freebsd-swap (12G) 50866176 4179947523 freebsd-zfs (199G) 468860928 1160 - free - (580K) The USB SSD is used to boot and use any of (all aarch64): An OverDrive 1000 A MACCHIATObin Double Shot Various RPi4B's with 8 GiBytes RAM Potentially various RPI4B's with 4 GiBytes RAM. Question . . . Are there any potential future upgrade issues with main [so: 14] vs. stable/13 and releng/13.0 , say by main updates involving ZFS updates in a way stable/13 or the recent releng/13.* might not handle? The implication would be that such a mix of boot environments on the same zpool or media might not be a good idea over time: main might be better separated so the ZFS versioning is independent between 13 and 14. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Review Request for D25705 and D25711
On Mon, Apr 19, 2021 at 07:44:13PM +, Faraz Vahedi via freebsd-hackers wrote: > Dear hackers and committers, > > I have sent two small patches on freebsd-version(1) and > freebsd-update(8), D25705 and D25711 respectively, to > add -j flag for supporting jails. > I think they are both somewhat ready to either land or > to get some notes for improvements. They have been open > since July 2020, and I know everyone is too busy. > I understand the situation, but I would be very grateful > if anyone could give them a review and help. > > I hope you are all doing well. Stay safe. > > Yours faithfully, > Faraz Dear committers, The aforementioned patches are both tested and ready to either land or get their final review/suggestions. They are meant to improve jail management quality by facilitating the retrieving and upgrading of the userland version of jails. So a user could simply call freebsd-version(1) or freebsd-update(8) from the host, along with the -j flag, to specify which jail to retrieve or upgrade its userland version. So no need to manually set BASEDIR and UNAME_r anymore, just specify the jail name/id. I sincerely request a review, please. These small patches are open since July 2020. I appreciate your time. Cheers, Faraz signature.asc Description: PGP signature
Re: What is OpenZFS doing during boot?
On Fri, Apr 30, 2021 at 7:21 AM Ulrich Spörlein wrote: > Hi folks, this is a stable/13 question but I figured it's still close > enough to -CURRENT to count. > > So I wanted to update my (remote) system with freebsd-update, but that > installed half a kernel and bricked the machine upon reboot. Lucky me I > fixed OOB access just the day before. > > Did the usual world/kernel build and ran etcupdate, merging in my > local changes. This bricked the system again, as it removed the -x bit on > /etc/rc.d/netif, I filed > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255514 for that though > (I > never had such trouble with mergemaster, just even understanding what > etcupdate is trying to do and how to bootstrap it is a mystery to me). > > Anyway, I have a data zpool on 2x encrypted GELI providers that I can only > unlock (and zpool import) with 2 passphrases after the system has booted. > > Color me surprised when some RC script thought otherwise and tried to > import the pool during boot. Why does it do that, that's not supposed to > work and it should not even touch the encrypted bits (yet). > > mountroot: waiting for device /dev/mirror/gm0a... > Dual Console: Serial Primary, Video Secondary > GEOM_ELI: Device gpt/swap0.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: accelerated software > GEOM_ELI: Device gpt/swap1.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: accelerated software > Setting hostuuid: d7902500-4c7c-0706-0025-90d77c4c0e0f. > Setting hostid: 0x8a2b4277. > cannot import 'data': no such pool or dataset > Destroy and re-create the pool fipmi0: Unknown IOCTL 40086481 > ipmi0: Unknown IOCTL 40086481 > rom > a backup source. > cachefile import failed, retrying > nvpair_value_nvlpid 69 (zpool), jid 0, uid ist(nvp, &rv) == 0 (0x16 == 0) > ASSERT at /usr/src/sys/contrib/openzfs/module/nv0: exited on signal 6 > pair/fnvpair.c:586:fnvpair_value_nvlist()Abort trap > cannot import 'data': no such pool or dataset > ipmi0: Unknown IOCTL 40086481 > ipmi0: Unknown IOCTL 40086481 > Destroy and re-cpid 74 (zpool), jid 0, uid 0: exited on signal 6 > reate the pool from > a backup source. > cachefile import failed, retrying > nvpair_value_nvlist(nvp, &rv) == 0 (0x16 == 0) > ASSERT at > > /usr/src/sys/contrib/openzfs/module/nvpair/fnvpair.c:586:fnvpair_value_nvlist()Abort > trap > Starting file system checks: > /dev/mirror/gm0a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0a: clean, 370582 free (814 frags, 46221 blocks, 0.2% > fragmentation) > /dev/mirror/gm0d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0d: clean, 867640 free (1160 frags, 108310 blocks, 0.1% > fragmentation) > /dev/mirror/gm0e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0e: clean, 1267948 free (17228 frags, 156340 blocks, 0.7% > fragmentation) > Mounting local filesystems:. > > > What do I need to do to _not_ have any zpool operations be attempted during > startup? How does it even know of the existence of that pool? > > I guess it's zfs_enable=NO to stop /etc/rc.d/zpool from messing about. But > more importantly, the GELI providers don't exist yet, why does it then > segfault? Shouldn't it be a bit more robust on that front? > > Thanks all > Uli > Your problem is the zpool cache file. As soon as ZFS loads, it tries to import all pools mentioned in /boot/zfs/zpool.cache. If you're using ZFS on top of GELI, then obviously you don't want that. What you should is move the cachefile somewhere else. Do it like this: $ zpool set cachefile=/some/where/else my-data-pool And on every boot, import it like this: $ service geli start $ zpool import -a -c /some/where/else -o cachefile=/some/where/else Hope this helps. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
What is OpenZFS doing during boot?
Hi folks, this is a stable/13 question but I figured it's still close enough to -CURRENT to count. So I wanted to update my (remote) system with freebsd-update, but that installed half a kernel and bricked the machine upon reboot. Lucky me I fixed OOB access just the day before. Did the usual world/kernel build and ran etcupdate, merging in my local changes. This bricked the system again, as it removed the -x bit on /etc/rc.d/netif, I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255514 for that though (I never had such trouble with mergemaster, just even understanding what etcupdate is trying to do and how to bootstrap it is a mystery to me). Anyway, I have a data zpool on 2x encrypted GELI providers that I can only unlock (and zpool import) with 2 passphrases after the system has booted. Color me surprised when some RC script thought otherwise and tried to import the pool during boot. Why does it do that, that's not supposed to work and it should not even touch the encrypted bits (yet). mountroot: waiting for device /dev/mirror/gm0a... Dual Console: Serial Primary, Video Secondary GEOM_ELI: Device gpt/swap0.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: accelerated software GEOM_ELI: Device gpt/swap1.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: accelerated software Setting hostuuid: d7902500-4c7c-0706-0025-90d77c4c0e0f. Setting hostid: 0x8a2b4277. cannot import 'data': no such pool or dataset Destroy and re-create the pool fipmi0: Unknown IOCTL 40086481 ipmi0: Unknown IOCTL 40086481 rom a backup source. cachefile import failed, retrying nvpair_value_nvlpid 69 (zpool), jid 0, uid ist(nvp, &rv) == 0 (0x16 == 0) ASSERT at /usr/src/sys/contrib/openzfs/module/nv0: exited on signal 6 pair/fnvpair.c:586:fnvpair_value_nvlist()Abort trap cannot import 'data': no such pool or dataset ipmi0: Unknown IOCTL 40086481 ipmi0: Unknown IOCTL 40086481 Destroy and re-cpid 74 (zpool), jid 0, uid 0: exited on signal 6 reate the pool from a backup source. cachefile import failed, retrying nvpair_value_nvlist(nvp, &rv) == 0 (0x16 == 0) ASSERT at /usr/src/sys/contrib/openzfs/module/nvpair/fnvpair.c:586:fnvpair_value_nvlist()Abort trap Starting file system checks: /dev/mirror/gm0a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0a: clean, 370582 free (814 frags, 46221 blocks, 0.2% fragmentation) /dev/mirror/gm0d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0d: clean, 867640 free (1160 frags, 108310 blocks, 0.1% fragmentation) /dev/mirror/gm0e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/gm0e: clean, 1267948 free (17228 frags, 156340 blocks, 0.7% fragmentation) Mounting local filesystems:. What do I need to do to _not_ have any zpool operations be attempted during startup? How does it even know of the existence of that pool? I guess it's zfs_enable=NO to stop /etc/rc.d/zpool from messing about. But more importantly, the GELI providers don't exist yet, why does it then segfault? Shouldn't it be a bit more robust on that front? Thanks all Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Undefined compiler behaviour or a compiler bug?
On 4/30/21 12:13 AM, Dimitry Andric wrote: % clang -fsanitize=undefined test.c -o test Thank you! Didn't know about that flag. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mtu setting in rc.conf
I upgraded a 14-CURRENT system from a build about 2 months old to current. In my /etc/rc.conf, I have: cloned_interfaces="lagg0 lagg1 tap0 tap1 tap2 bridge0 bridge1 bridge2 vlan1 vlan2" ifconfig_cxl0="txcsum txcsum6 lso mtu 9000 up" ifconfig_cxl1="txcsum txcsum6 lso mtu 9000 up" ifconfig_cxl2="txcsum txcsum6 lso mtu 9000 up" ifconfig_cxl3="txcsum txcsum6 lso mtu 9000 up" ifconfig_lagg0="laggproto lacp lagghash l3,l4 laggport cxl0 laggport cxl1 laggport cxl2 laggport cxl3 txcsum txcsum6 lso mtu 9000" ifconfig_tap2="mtu 9000" ifconfig_bridge2="inet 203.0.113.101/24 addm lagg0 addm tap2 mtu 9000" ifconfig_bridge2_ipv6="inet6 2001:db8::101/64" ifconfig_bridge2_alias0="inet 203.0.113.10 netmask 255.255.255.255" [ Other interfaces trimmed ] This has worked for years. Now, however, bridge2 & lagg0 aren't getting the mtu 9000 setting, therefore tap2 isn't added to the bridge at startup, and somehow the main IP on bridge2 isn't getting set because of that. Removing "addm tap2" from ifconfig_bridge2 allows everything to come up, including the main IP, but lagg0 & bridge2 are still at mtu 1500. Setting them to 9000 by hand and then adding tap2 by hand works. I tried moving the "mtu 9000" to the beginning of the line, but that didn't seem to fix it. Has something changed recently with this? Thanks! -Dustin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
