[Bug 264056] mlx4: Fix a resource leak in mlx4_opreq_action()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264056 Mark Linimon changed: What|Removed |Added Attachment #234009|0 |1 is patch|| Attachment #234009|application/mbox|text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264055] null pointer dereference in bhnd_erom_iores_new()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264055 Mark Linimon changed: What|Removed |Added Attachment #234008|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264057] mad: Fix a possible memory leak
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264057 Mark Linimon changed: What|Removed |Added Attachment #234011|application/mbox|text/plain mime type|| Attachment #234011|0 |1 is patch|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264059] Mellanox ConnectX-3 10g ether not working in 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||regression CC||hsela...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264058] Mellanox ConnectX-3 10g ether not working in 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264058 Mark Linimon changed: What|Removed |Added Resolution|--- |DUPLICATE Status|New |Closed --- Comment #1 from Mark Linimon --- *** This bug has been marked as a duplicate of bug 264059 *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264059] Mellanox ConnectX-3 10g ether not working in 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 --- Comment #2 from Mark Linimon --- *** Bug 264058 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264059] Mellanox ConnectX-3 10g ether not working in 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 --- Comment #1 from crb --- ASUS TUF GAMING X570-PRO motherboard AMD 5950 processor -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264059] Mellanox ConnectX-3 10g ether not working in 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 Bug ID: 264059 Summary: Mellanox ConnectX-3 10g ether not working in 13.1 Product: Base System Version: 13.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: c...@chrisbowman.com I had a 13.0 system fully working. It has a Mellanox 10g ether card (ConnectX-3 I think) that worked without issue. I replaced the SSD and installed 13.1 and now the card doesn't work. It shows up in dmesg: mlx4_core0: mlx4_shutdown was called mlx4_core0: mem 0xfb70-0xfb7f,0x7fff80-0x7f irq 30 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021) mlx4_core: Initializing mlx4_core mlx4_core0: Unable to determine PCI device chain minimum BW mlx4_core0: mlx4_shutdown was called mlx4_core0: mem 0xfb70-0xfb7f,0x7fff80-0x7f irq 30 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021) mlx4_core: Initializing mlx4_core mlx4_core0: Unable to determine PCI device chain minimum BW mlx4_core0: mlx4_shutdown was called mlx4_core0: mem 0xfb70-0xfb7f,0x7fff80-0x7f irq 30 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021) mlx4_core: Initializing mlx4_core mlx4_core0: Unable to determine PCI device chain minimum BW But doesn't show up in ifconfig: crb@eclipse:294> ifconfig -a em0: flags=8863 metric 0 mtu 1500 options=481049b ether 00:1b:21:1d:12:ad inet6 fe80::21b:21ff:fe1d:12ad%em0 prefixlen 64 scopeid 0x1 inet6 2600:1700:5430:10b1:21b:21ff:fe1d:12ad prefixlen 64 autoconf inet 192.168.1.190 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=23 igc0: flags=8822 metric 0 mtu 1500 options=4e527bb ether 3c:7c:3f:4e:0b:c6 media: Ethernet autoselect status: no carrier nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 groups: lo nd6 options=21 I'm happy to build kernels, debug what ever is necessary to help fix the problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264058] Mellanox ConnectX-3 10g ether not working in 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264058 Bug ID: 264058 Summary: Mellanox ConnectX-3 10g ether not working in 13.1 Product: Base System Version: 13.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: c...@chrisbowman.com I had a 13.0 system fully working. It has a Mellanox 10g ether card (ConnectX-3 I think) that worked without issue. I replaced the SSD and installed 13.1 and now the card doesn't work. It shows up in dmesg: mlx4_core0: mlx4_shutdown was called mlx4_core0: mem 0xfb70-0xfb7f,0x7fff80-0x7f irq 30 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021) mlx4_core: Initializing mlx4_core mlx4_core0: Unable to determine PCI device chain minimum BW mlx4_core0: mlx4_shutdown was called mlx4_core0: mem 0xfb70-0xfb7f,0x7fff80-0x7f irq 30 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021) mlx4_core: Initializing mlx4_core mlx4_core0: Unable to determine PCI device chain minimum BW mlx4_core0: mlx4_shutdown was called mlx4_core0: mem 0xfb70-0xfb7f,0x7fff80-0x7f irq 30 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v3.7.1 (November 2021) mlx4_core: Initializing mlx4_core mlx4_core0: Unable to determine PCI device chain minimum BW But doesn't show up in ifconfig: crb@eclipse:294> ifconfig -a em0: flags=8863 metric 0 mtu 1500 options=481049b ether 00:1b:21:1d:12:ad inet6 fe80::21b:21ff:fe1d:12ad%em0 prefixlen 64 scopeid 0x1 inet6 2600:1700:5430:10b1:21b:21ff:fe1d:12ad prefixlen 64 autoconf inet 192.168.1.190 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=23 igc0: flags=8822 metric 0 mtu 1500 options=4e527bb ether 3c:7c:3f:4e:0b:c6 media: Ethernet autoselect status: no carrier nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 groups: lo nd6 options=21 I'm happy to build kernels, debug what ever is necessary to help fix the problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264057] mad: Fix a possible memory leak
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264057 Bug ID: 264057 Summary: mad: Fix a possible memory leak Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ruc_gongyuan...@163.com Created attachment 234011 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234011=edit a possible patch If ib_dma_mapping_error, it will jump out of the loop, leaving mad_priv allocated by alloc_mad_private not freed. It will cause a memory leak. Fix it with kfree. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264055] null pointer dereference in bhnd_erom_iores_new()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264055 --- Comment #1 from ruc_gongyuan...@163.com --- Created attachment 234010 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234010=edit a possible patch v2 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264056] mlx4: Fix a resource leak in mlx4_opreq_action()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264056 Bug ID: 264056 Summary: mlx4: Fix a resource leak in mlx4_opreq_action() Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ruc_gongyuan...@163.com Created attachment 234009 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234009=edit a possible patch mailbox allocate by mlx4_alloc_cmd_mailbox(dev) should be released before return. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264055] null pointer dereference in bhnd_erom_iores_new()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264055 Bug ID: 264055 Summary: null pointer dereference in bhnd_erom_iores_new() Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ruc_gongyuan...@163.com Created attachment 234008 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234008=edit a possible patch In bhnd_erom_iores_new(), the failure of malloc can cause a null pointer dereference, fix it with a check. Check the result of bhnd_erom_iores_new when it is called. If malloc fails, bhnd_erom_iores_new returns null and the caller fails. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 JerRatt IT changed: What|Removed |Added CC||cont...@jerratt.com --- Comment #54 from JerRatt IT --- I'm reporting either the same or similar issue, here are my findings, and please let me know if my plans sound correct: Setup: TrueNAS Scale 22.02.0.1 AMD Threadripper 1920X ASRock X399 Taichi 128GB (8x16GB) Crucial CT8G4WFD824A Unbuffered ECC AVAGO/LSI 9400-8i SAS3408 12Gbps HBA Adapter Supermicro BPN-SAS3-743A 8-Port SAS3/SAS2/SATA 12Gbps Backplane 8 x Seagate Exos X18 18TB HDD ST18000NM004J SAS 12Gbps 512e/4Kn 2 x Crucial 120GB SSD 2 x Crucial 1TB SSD 2 x Western Digital 960GB NVME Supermicro 4U case w/2000watt Redundant Power Supply The system is connected with a large APC data-center battery system and conditioner, in a HVAC controlled area. All hard drives have the newest firmware, and in 4k sectors both logical and native. The controller has the newest firmware, both regular and legacy roms, and with the SATA/SAS only mode flashed (dropping the NVME multi/tri-mode option that the new 9400 series cards support). Running any kind of heavy I/O onto the 18TB drives that are connected to the BPN-SAS3-743A backplane and through to the LSI 9400-8i HBA eventually results in the drive resetting. This happens even without the drives assigned to any kind of ZFS pool. This also happens whether running from the shell within the GUI or from the shell itself. This happens on all drives, that are using two separate SFF8643 cables with a backplane that has two separate SFF8643 ports. To cause this to happen, I can either run badblocks on each drive (using: badblocks -c 1024 -w -s -v -e 1 -b 65536 /dev/sdX), or even just running a SMART extended/long test. Eventually, all or nearly all drives will reset, even spin down (according to the shell logs). Sometimes they reset in batches, while others continue chugging along. It's made completing any kind of SMART extended test not possible. Badblocks will fail out, reporting too many bad blocks, on multiple hard drives all at nearly the exact same moment, yet consecutive badblock scans won't report bad blocks in the same areas. SMART test will just show "aborted, drive reset?" as the result. My plan was to replace the HBA with an older LSI 9305-16i, replace the two SFF8643-SFF8643 cables going from the HBA to the backplane just for good measure, install two different SFF8643-SFF8482 cables that bypass the backplane fully, then four of the existing Seagate 18TB drives and put them on the the SFF8643-SFF8482 connections that bypass the backplane, as well as install four new WD Ultrastar DC HC550 (WUH721818AL5204) drives into the mix (some using the backplane, some not). That should reveal if this is a compatibility/bug issue with all large drives or certain large drives on a LSI controller, the mpr driver, and/or this backplane. If none of that works or doesn't eliminate all the potential points of failures, I'm left with nothing but subpar work arounds, such as just using the onboard SATA ports, disabling NCQ in the LSI controller, or setting up a L2ARC cache (or I might try a metadata cache to see if that circumvents the issue as well). Condensed logs when one drive errors out: sd 0:0:0:0: device_unblock and setting to running, handle(0x000d) mpt3sas_cm0: log_info(0x31110e05): originator(PL), code(0x11), sub_code(0x0e05) mpt3sas_cm0: log_info(0x31110e05): originator(PL), code(0x11), sub_code(0x0e05) ~ ~ ~ ~ sd 0:0:0:0: Power-on or device reset occurred ...ready sd 0:0:6:0: device_block, handle(0x000f) sd 0:0:9:0: device_block, handle(0x0012) sd 0:0:10:0: device_block, handle(0x0014) mpt3sas_cm0: log_info(0x3112010c): originator(PL), code(0x12), sub_code(0x010c) sd 0:0:9:0: device_unblock and setting to running, handle(0x0012) sd 0:0:6:0: device_unblock and setting to running, handle(0x000f) sd 0:0:10:0: device_unblock and setting to running, handle(0x0014) sd 0:0:9:0: Power-on or device reset occurred sd 0:0:6:0: Power-on or device reset occurred sd 0:0:10:0: Power-on or device reset occurred scsi_io_completion_action: 5 callbacks suppressed sd 0:0:10:0: [sdd] tag#5532 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s sd 0:0:10:0: [sdd] tag#5532 Sense Key : Not Ready [current] [descriptor] sd 0:0:10:0: [sdd] tag#5532 Add. Sense: Logical unit not ready, additional power granted sd 0:0:10:0: [sdd] tag#5532 CDB: Write(16) 8a 00 00 00 00 00 5c 75 7a 12 00 00 01 40 00 00 print_req_error: 5 callbacks suppressed blk_update_request: I/O error, dev sdd, sector 12409622672 op 0x1:(WRITE) flags 0xc800 phys_seg 1 prio class 0 sd 0:0:10:0: [sdd] tag#5533 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s sd 0:0:10:0: [sdd] tag#5533 Sense Key : Not Ready [current] [descriptor] sd 0:0:10:0: [sdd] tag#5533 Add. Sense: Logical
[Bug 264051] Kernel compile fails with options ACPI_DEBUG without options ddb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264051 Bug ID: 264051 Summary: Kernel compile fails with options ACPI_DEBUG without options ddb Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ema...@freebsd.org Attempting a custom kernel based on MINIMAL and adding: +optionsACPI_DEBUG +optionsBUS_DEBUG (Note MINIMAL does not include options DDB) Build fails with /usr/home/emaste/src/freebsd-git/main/sys/contrib/dev/acpica/components/debugger/dbcmds.c:749:28: error: use of undeclared identifier 'AcpiGbl_DbBuffer' ReturnBuffer.Pointer = AcpiGbl_DbBuffer; ^ and other undeclared identifiers I suspect MINIMAL excluding "options DDB" is itself a bug but acpica should either build or explicitly #error in this case, I think. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261679] libc/locale/xlocale.c: potential NULL pointer dereference in alloc_locale()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261679 phil.st...@gmx.com changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262778] FreeBSD 13.1-RELEASE, FreeBSD 13.1-RELEASE and Ports, FreeBSD Ports 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262778 Glen Barber changed: What|Removed |Added Resolution|--- |DUPLICATE Status|New |Closed --- Comment #2 from Glen Barber --- The 13.1 release manual pages have been made available. *** This bug has been marked as a duplicate of bug 264036 *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262778] FreeBSD 13.1-RELEASE, FreeBSD 13.1-RELEASE and Ports, FreeBSD Ports 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262778 Graham Perrin changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2640 ||36 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264029] [patch] truss(1): add ppoll(2) argument decoding
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264029 Christian Weisgerber changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264029] [patch] truss(1): add ppoll(2) argument decoding
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264029 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9bf4983f54919c38a0e3aae2bea09c04c8ee4421 commit 9bf4983f54919c38a0e3aae2bea09c04c8ee4421 Author: Christian Weisgerber AuthorDate: 2022-05-17 18:20:53 + Commit: Christian Weisgerber CommitDate: 2022-05-17 18:23:25 + truss: add ppoll(2) argument decoding PR: 264029 Approved by:emaste MFC after: 3 days usr.bin/truss/syscalls.c | 3 +++ 1 file changed, 3 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264047] whereis(1) broken with WITHOUT_MAN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264047 Bug ID: 264047 Summary: whereis(1) broken with WITHOUT_MAN Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: bro...@freebsd.org The whereis program exits with an error if the manpath program is not present (as happens with WITHOUT_MAN defined). It should skip searching manual pages instead. # whereis cc sh: manpath: not found whereis: error processing manpath results: No error: 0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263928] sdhci_xenon puts SD card in read-only mode on 13.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263928 --- Comment #9 from mw --- (In reply to Mike Cui from comment #8) For errata I'd go with custom one-liner patch. The MFC is much bigger change and the stable/13 already diverged in this area - I kept these changes out of 13.1 release on purpose, as I considered the MFS as too late (around 13.1-rc1). @koobs what would you advise? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264029] [patch] truss(1): add ppoll(2) argument decoding
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264029 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- Patch LGTM, please go ahead and commit. Or if you wish I can do it on your behalf. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262278] file(1) fails to identify a JAR file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262278 --- Comment #4 from Michael Osipov --- In contrast: $ hexdump -C classes/org/apache/maven/SessionScoped.class ca fe ba be 00 00 00 34 00 12 07 00 0f 07 00 10 |...4| 0010 07 00 11 01 00 0a 53 6f 75 72 63 65 46 69 6c 65 |..SourceFile| 0020 01 00 12 53 65 73 73 69 6f 6e 53 63 6f 70 65 64 |...SessionScoped| Valid JAR: $ hexdump -C maven-core-4.0.0-alpha-1-SNAPSHOT.jar | head 50 4b 03 04 0a 00 00 08 00 00 89 41 85 52 00 00 |PK.A.R..| 0010 00 00 00 00 00 00 00 00 00 00 09 00 00 00 4d 45 |..ME| 0020 54 41 2d 49 4e 46 2f 50 4b 03 04 14 00 00 08 08 |TA-INF/PK...| 0030 00 89 41 85 52 9c ea 73 82 b1 00 00 00 4e 01 00 |..A.R..s.N..| 0040 00 14 00 00 00 4d 45 54 41 2d 49 4e 46 2f 4d 41 |.META-INF/MA| 0050 4e 49 46 45 53 54 2e 4d 46 8d 8f d1 0a 82 30 18 |NIFEST.MF.0.| 0060 85 ef 05 df 61 2f b0 a1 d6 45 78 a7 41 94 60 49 |a/...Ex.A.`I| I don't know whether I understand the C code from the old Java 7 launcher correctly, but it is searching for 0xcafe to make it a valid JAR file. Note: I am Maven PMC member and done a lot on the reproducibility topic. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262278] file(1) fails to identify a JAR file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262278 Michael Osipov changed: What|Removed |Added CC||michael.osi...@siemens.com --- Comment #3 from Michael Osipov --- The 0xcafebabe applies to classes, not to JAR files. Unwritten law how to detect a JAR: Either the first or the second ZIP entry must be the manifest file: > META-INF/ > META-INF/MANIFEST.NF or just > META-INF/MANIFEST.NF Maven produces fully reproducible JARs that those two entries come first: > $ unzip -t maven-core-4.0.0-alpha-1-SNAPSHOT.jar | head > Archive: maven-core-4.0.0-alpha-1-SNAPSHOT.jar > testing: META-INF/OK > testing: META-INF/MANIFEST.MF OK > testing: META-INF/maven/ OK > testing: META-INF/sisu/ OK > testing: org/ OK > testing: org/apache/ OK Don't expect a JAR to contain a class file. It could solely contain resources, still being a JAR file due to the manifest and the first entry of the manifest is fixed to "Manifest-Version: 1.0". This is by spec and guaranteed to be written by Maven libraries. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264040] cannot open /boot/lua/loader.lua: invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264040 Bug ID: 264040 Summary: cannot open /boot/lua/loader.lua: invalid argument Product: Base System Version: 13.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: andros...@pm.me Created attachment 233997 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233997=edit loader error screenshot Failed to upgrade from 13.0-RELEASE to 13.1-RELEASE on zfs-mirror root, amd64, BIOS. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259090] UFS: bad file descriptor: soft update journaling can not be enabled on some FreeBSD-provided disk images – failed to write updated cg
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259090 Matthias Gamsjager changed: What|Removed |Added CC||mgamsja...@gmail.com --- Comment #7 from Matthias Gamsjager --- Tried it on my RPI2 with FreeBSD generic 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm remounted R/O and ran: root@generic:/home/freebsd # tunefs -j enable / Using inode 4872 in cg 0 for 33554432 byte journal tunefs: Failed to write updated cg: Bad file descriptor tunefs: soft updates journaling cannot be enabled tunefs: file system reloaded -- You are receiving this mail because: You are the assignee for the bug.
