[Bug 277442] No microphone input on ALC256
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277442 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|multime...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277469] Installer incorrectly setting up UEFI boot manager
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277469 Bug ID: 277469 Summary: Installer incorrectly setting up UEFI boot manager Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: notbylundzan...@gmail.com This is a consumer bug report. On a new install, setting up with one UFS partition with swap and the rest unparitioned, the OS will fail to boot. In the BIOS boot manager it will list "FreeBSD" and "UEFI OS" - if installed fully partitioned it only lists "UEFI OS" and will successfully boot. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277470] Security Vulnerability: etcupdate incorrectly sets permissions for /var/db/etcupdate/conflicts/etc/master.passwd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470 Bug ID: 277470 Summary: Security Vulnerability: etcupdate incorrectly sets permissions for /var/db/etcupdate/conflicts/etc/master.passwd Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: ch...@cretaforce.gr I've encountered an issue while upgrading systems from 13.2 to 13.3. Upon executing the upgrade process using the following commands: cd /usr/src make buildworld make buildkernel make installkernel etcupdate -p make installworld etcupdate I noticed that during the final step (etcupdate), conflicts were detected in the files /etc/master.passwd and /etc/group. Consequently, I utilized `etcupdate resolve` to rectify these conflicts. Before resolving the conflicts, I checked the file /var/db/etcupdate/conflicts/master.passwd and found that it had insecure permissions: ls -la /var/db/etcupdate/conflicts/etc/master.passwd -rw-r--r-- 1 root wheel 5690 Feb 28 00:05 /var/db/etcupdate/conflicts/etc/master.passwd The file master.passwd contains encrypted root and user passwords, thereby presenting a significant security risk due to its unrestricted read access. Your attention to this matter would be greatly appreciated, and I remain available to provide any additional information or assistance required for troubleshooting. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277470] Security Vulnerability: etcupdate incorrectly sets permissions for /var/db/etcupdate/conflicts/etc/master.passwd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470 Christos Chatzaras changed: What|Removed |Added Product|Base System |Security Component|misc|Base Group||freebsd_committer Version|13.3-RELEASE|unspecified -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277470] Security Vulnerability: etcupdate incorrectly sets permissions for /var/db/etcupdate/conflicts/etc/master.passwd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470 Christos Chatzaras changed: What|Removed |Added Hardware|Any |amd64 CC||cperc...@freebsd.org, ||ema...@freebsd.org, ||j...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277470] Security Vulnerability: etcupdate incorrectly sets permissions for /var/db/etcupdate/conflicts/etc/master.passwd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277470 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|sect...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277469] Installer incorrectly setting up UEFI boot manager
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277469 Mark Linimon changed: What|Removed |Added Keywords||install -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277473] Virtio memory ballooning does not return unused memory to host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473 Bug ID: 277473 Summary: Virtio memory ballooning does not return unused memory to host Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: laurent.char...@gmail.com The memory ballooning in a FreeBSD kvm/qemu guest does not seem to return the unused memory to the host. The ballooning seems to happen correctly within FreeBSD, but the host might not be told properly (that's only my limited understanding as a non-expert). This is true whether setting the current memory size automatically of manually. Here are some scenarios to explain the problem. === Scenario 1 With currentMemory and memory both set to 64GB in the kvm config file $ vmstat procsmemorypage disks faults cpu r b w avm fre flt re pi po fr sr nd0 pa0 in sy cs us sy id 0 0 0 429M 62G 2.3K 0 17 0 3.4K4 0 0 76 2.2K 1.3K 0 1 99 neofetch shows: Memory: 2272MiB / 65495MiB On the Linux host, top shows: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 57685 libvirt+ 20 0 66.8g 64.2g 26112 S 0.0 51.1 1:01.37 qemu-system-x86 This is all as expected === Scenario 2 With currentMemory set to 8G and memory set to 64GB in the kvm config file $ vmstat procsmemorypage disks faults cpu r b w avm fre flt re pi po fr sr nd0 pa0 in sy cs us sy id 0 0 0 429M 5.7G 3.1K 0 23 0 4.6K4 0 0 1381 3.0K 3.5K 0 4 96 and now neofetch shows: Memory: 59607MiB / 65495MiB On the Linux host from the 'top' command: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 57062 libvirt+ 20 0 66.8g 64.2g 26112 S 0.0 51.0 1:32.51 qemu-system-x86 vmstat shows less available memory than in Scenario 1, as expected. The host however sees no difference in memory usage from FreeBSD compared to Scenario 1. Expected: the memory usage on the host should have decreased. Interestingly, neofetch sees much more memory usage than previously. I don't know if it's relevant, but it might be a clue so I'm including this here. === Scenario 3 With currentMemory and memory both set to 64GB in kvm config file, as in Scenario 1. I type 'sudo virsh setmem FreeBSD 8G' on the host. FreeBSD's vmstat initially shows 64G free, and transitions gradually to 5.7G free, as expected. On the host side however, there is no change in the memory utilization of the FreeBSD VM. Expected: the memory usage on the host should have decreased. === Test notes The tests are done on a physical server with 32 cores (2 sockets), 64 threads, 128GB RAM. The OS is Ubuntu 22.04 Other guests such as Windows and Linux behave as expected in kvm/qemu. The memory usage inside the guest matches the memory usage seen from the host. virtio_balloon.ko is compiled in kernel. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277473] Virtio memory ballooning does not return unused memory to host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473 Laurent changed: What|Removed |Added CC||bry...@freebsd.org --- Comment #1 from Laurent --- Adding bry...@freebsd.org because his email in in VIRTIO_BALLOON(4). I hope that's OK. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277473] Virtio memory ballooning does not return unused memory to host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277473 Laurent changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=1983 ||44 --- Comment #2 from Laurent --- Possibly related to, but not duplicate of #198344. Regression? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 Thomas Dreibholz changed: What|Removed |Added CC||thomas.dreibh...@gmail.com --- Comment #14 from Thomas Dreibholz --- I am running tests with automated installations in VirtualBox (https://github.com/simula/nornet-vmimage-builder-scripts). The issue appears with both, 14.0-RELEASE and 14.0-STABLE (20240229, this is the latest ISO at the moment). Used ISOs: * https://download.freebsd.org/releases/ISO-IMAGES/14.0/FreeBSD-14.0-RELEASE-amd64-disc1.iso * https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/14.0/FreeBSD-14.0-STABLE-amd64-20240229-d19769300126-266911-disc1.iso The only difference is that the STABLE version just hangs instead of shutting down, while the RELEASE version shows the message "Khelp module "ertt" can't unload until its refcount drops ..." before hanging. I am going to attach screenshots of both variants. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #15 from Thomas Dreibholz --- Created attachment 248918 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248918&action=edit Screenshot of the issue with 14.0-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #16 from Thomas Dreibholz --- Created attachment 248919 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248919&action=edit Screenshot of the issue with 14.0-STABLE (20240229) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #17 from Michael Tuexen --- Could it be that when using Virtual Box the VM just does not shutdown? So this might be unrelated to the ertt issue? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277450] "poweroff" does not power off the system when EFI is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450 --- Comment #5 from Thomas Dreibholz --- I tried 14.0-STABLE (202040229, i.e. the currently latest ISO available: https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/14.0/FreeBSD-14.0-STABLE-amd64-20240229-d19769300126-266911-disc1.iso): hw.efi.poweroff=1 (the default) => no success, the machine remains running. hw.efi.poweroff=0 => the machine shuts down as intended. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277474] clang crashes with -fzero-call-used-regs when optimization is enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474 Bug ID: 277474 Summary: clang crashes with -fzero-call-used-regs when optimization is enabled Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: dan-free...@berrange.com Updating QEMU's upstream CI to use the latest FreBSD 13.3 gcloud images, we're seeing a SEGV in clang 17: 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '../qobject/qobject.c'. 4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@qobject_destroy' #0 0x05372051 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:602:13 #1 0x053703f5 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18 #2 0x05338ce5 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5 #3 0x05338ce5 CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:390:51 #4 0x00082bd674af handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 #5 0x00082bd66a6b thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:245:1 #6 0x7923 ([vdso]+0x2d3) #7 0x04d94d71 reset /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/BitVector.h:398:30 #8 0x04d94d71 insertZeroCallUsedRegs /usr/src/contrib/llvm-project/llvm/lib/CodeGen/PrologEpilogInserter.cpp:1291:22 #9 0x04d94d71 insertPrologEpilogCode /usr/src/contrib/llvm-project/llvm/lib/CodeGen/PrologEpilogInserter.cpp:1169:3 #10 0x04d94d71 runOnMachineFunction /usr/src/contrib/llvm-project/llvm/lib/CodeGen/PrologEpilogInserter.cpp:263:5 #11 0x04b630b5 runOnFunction /usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:91:13 #12 0x04fc19eb runOnFunction /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1435:27 #13 0x04fc7804 runOnModule /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1481:13 #14 0x04fc2092 runOnModule /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:0:27 #15 0x04fc2092 run /usr/src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:535:44 #16 0x02f5b83e ~TimeTraceScope /usr/src/contrib/llvm-project/llvm/include/llvm/Support/TimeProfiler.h:155:9 #17 0x02f5b83e RunCodegenPipeline /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1116:3 #18 0x02f5b83e EmitAssembly /usr/src/contrib/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1137:3 Although the stack trace is different, based on "insertZeroCallUsedRegs" function in frame #8 which, I'm fairly confident it'll end up being this upstream bug in clang 17: https://github.com/llvm/llvm-project/issues/75168 which should be fixable with https://github.com/llvm/llvm-project/commit/f800c1f3b207e7bcdc8b4c7192928d9a078242a0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277474] clang 17 crashes with -fzero-call-used-regs when optimization is enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474 dan-free...@berrange.com changed: What|Removed |Added Summary|clang crashes with |clang 17 crashes with |-fzero-call-used-regs when |-fzero-call-used-regs when |optimization is enabled |optimization is enabled -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #18 from Thomas Dreibholz --- No, this is a different bug (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450). I have to set sysctl hw.efi.poweroff=0, so that the machine actually should power off as intended. The ertt module unload issue appears always, after a freshly installed machine (including successful "freebsd-update fetch install", "pkg upgrade", and setting hw.efi.poweroff=0 in /etc/sysctl.conf) has been rebooted, then configured via SSH, and finally instructed to shut down. However, the ertt issue module issue seems to not occur later when manually stopping and restarting this machine. On the other hand, the hw.efi.poweroff issue (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450) can always be reproduced on this machine. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #19 from Michael Tuexen --- (In reply to Thomas Dreibholz from comment #18) I'm confused: Assuming you set hw.efi.poweroff=0 in /boot/loader.conf, not /etc/sysctl.conf, are you observing any problem other than an error message showing up? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #20 from Thomas Dreibholz --- No, it is a sysctl: $ sysctl hw.efi.poweroff hw.efi.poweroff: 0 The default is 1. See also: https://forums.freebsd.org/threads/efi-virtualbox-computer-non-stop-after-successful-shutdown-of-freebsd.84856/ . -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277474] clang 17 crashes with -fzero-call-used-regs when optimization is enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474 --- Comment #1 from Ed Maste --- Thanks for the analysis. It's too late to get a fix into the 13.3 release but assuming it is this upstream issue/commit we should be able to include it in a 13.3 errata update prior to 13.2 passing EOL. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277469] Installer incorrectly setting up UEFI boot manager
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277469 --- Comment #1 from Alex Bylund --- This is with Intel RST, and a 512gb nvme and a 2tb ssd. It might just be something to do with multiple drives. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277450] "poweroff" does not power off the system when EFI is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450 Oleksandr Kryvulia changed: What|Removed |Added CC||a...@freebsd.org --- Comment #6 from Oleksandr Kryvulia --- What is a value of hw.acpi.handle_reboot? Added avg@, may be he can help. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277450] "poweroff" does not power off the system when EFI is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450 --- Comment #7 from Thomas Dreibholz --- hw.acpi.handle_reboot: 1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #21 from Michael Tuexen --- (In reply to Thomas Dreibholz from comment #20) I think it is a loader tunable. At least it is listed when you use `sysctl -T`. My question: Do you experience unexpected behavior when you use hw.efi.poweroff=0? If yes, which? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277450] "poweroff" does not power off the system when EFI is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450 --- Comment #8 from Oleksandr Kryvulia --- Seems it is virtualbox-specific. I'll test it under bhyve and hyper-v and report it back. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277450] "poweroff" does not power off the system when EFI is used
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277450 --- Comment #9 from Andriy Gapon --- When hw.efi.poweroff=1, EFI shutdown routine is invoked much earlier than ACPI, so ACPI has no play. It seems that the system hangs in the EFI routine instead of powering off. So it must be a problem with the EFI implementation or something like that. FreeBSD EFI shutdown code is extremely simple: if ((howto & RB_POWEROFF) != 0 && efi_poweroff) (void)efi_reset_system(EFI_RESET_SHUTDOWN); -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #22 from Thomas Dreibholz --- No, with setting hw.efi.poweroff=0, an EFI machine usually shuts down as expected. The exception is the ertt module unload failure. With the default of hw.efi.poweroff=1, an EFI machine never shuts down. I can provide a VirtualBox OVA file, if this is useful. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #23 from Michael Tuexen --- (In reply to Thomas Dreibholz from comment #22) So I think everything you are complaining about is covered in bug 277450. So why reporting here? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #24 from Thomas Dreibholz --- No, the machine does not power off in case of the ertt module unload failure, even with hw.efi.poweroff=0. The patch in STABLE seems to just suppress the ertt error message, but it reproducibly fails to shut off the machine at the same place where it also fails for RELEASE. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271677] ertt module unload error at shutdown
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677 --- Comment #25 from Mike Karels --- I strongly suspect that the ertt issue is unrelated to the failure to power down. The message is printed (in the release) after all related processing is done, so the system must be getting through the ertt code. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277474] clang 17 crashes with -fzero-call-used-regs when optimization is enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277474 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277211] panic: Unhandled external data abort - handle_el1h_sync - --- exception, esr 0x96000410 - wait_fw_init - mlx5_load_one
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277211 --- Comment #8 from John Baldwin --- Created attachment 248936 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248936&action=edit fix.patch Please try this patch. Looking at the dmesg, the address was translated incorrectly. It matches this range which requires no translation: pcib0: PCI addr: 0x101, CPU addr: 0x101, Size: 0x7f, Type: memory (PCI addr == CPU addr), but it was matching on the wrong range and translating the address as if it belonged to the first range: pcib0: PCI addr: 0x0, CPU addr: 0x1001000, Size: 0x1, Type: I/O port The code I changed in commit d79b6b8ec267 expected the end to be >= start, and the end value of 0 in the old code violated this assumption. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277211] panic: Unhandled external data abort - handle_el1h_sync - --- exception, esr 0x96000410 - wait_fw_init - mlx5_load_one
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277211 John Baldwin changed: What|Removed |Added Assignee|b...@freebsd.org|j...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270441] /bin/sh - please implement '!!' support for 'sudo !!' and 'doas !!' usage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270441 Henrich Hartzer changed: What|Removed |Added CC||henrichhart...@tuta.io --- Comment #8 from Henrich Hartzer --- I'm also interested in this, especially now that /bin/sh is the default in FreeBSD 14.0 and is so much improved from where it was. I did not know about !! until now. I had only been aware of !$ which is often useful for me. I agree that we could return some kind of error if history is not compiled in. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 272120] touch(1) -r modifies file's birthtime
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272120 Mark Peek changed: What|Removed |Added CC||m...@freebsd.org --- Comment #2 from Mark Peek --- I looked into this a little bit and here is what I discovered. Running "touch -m" uses utimensat(2) and passes in just the modification date. This system call then calls an internal setutimes() https://github.com/freebsd/freebsd-src/blob/main/sys/kern/vfs_syscalls.c#L3211. In 2002 this change was added: https://github.com/freebsd/freebsd-src/commit/fb36a3d8472e3b7c446b5501635ec34eb1ebaa00 Change utimes to set the file creation time (for filesystems that support creation times such as UFS2) to the value of the modification time if the value of the modification time is older than the current creation time. See utimes(2) for further details. If a birthtime is not passed into setutimes() and the birthtime is younger than the modification time, then the birthtime is set to the modification time. The utimensat(2) man page documents this behavior. This makes a little bit of sense given a modification time usually should not be older than the birthtime of the file. But the utimes man page does talk about the need for a new system call allowing for setting access, modification, *and* birthtime so that might be an alternative. Options: 1. Document this behavior in the touch(1) man page. 2. Add a new system call to allow setting all three times and modify touch(1) to use it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270441] /bin/sh - please implement '!!' support for 'sudo !!' and 'doas !!' usage
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270441 --- Comment #9 from Slawomir Wojciech Wojtczak --- (In reply to Henrich Hartzer from comment #8) I would add '!$' to the list alongside '!!' feature. The !$ is the LAST argument of previous command. Example 1: # pwd / # mkdir asd # cd !$ cd asd # pwd /asd Example 2: # grep hostname /etc/rc.conf hostname='asd' # vi !$ vi /etc/rc.conf Hope that helps. Regards, vermaden -- You are receiving this mail because: You are the assignee for the bug.
