[Bug 281332] tzsetup creates broken symlink after 5e16809c953f (main) and fc43a1b6842a (stable/14)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281332 Bug ID: 281332 Summary: tzsetup creates broken symlink after 5e16809c953f (main) and fc43a1b6842a (stable/14) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: herb...@gojira.at tzsetup creates a broken symlink when using with -C option (e.g make installworld DESTDIR=$X). e.g: # jexec -l 1 date Sat Sep 7 10:13:19 CEST 2024 # ls -l /jails/mail/etc/localtime lrwxr-xr-x 1 root wheel 33 Sep 7 10:13 /jails/mail/etc/localtime -> /usr/share/zoneinfo/Europe/Berlin # tzsetup -C /jails/mail -r # ls -l /jails/mail/etc/localtime lrwxr-xr-x 1 root wheel 45 Sep 7 10:14 /jails/mail/etc/localtime -> /jails/mail//usr/share/zoneinfo/Europe/Berlin # jexec -l 1 date Sat Sep 7 08:14:45 UTC 2024 Details here: https://lists.freebsd.org/archives/freebsd-current/2024-September/006355.html https://lists.freebsd.org/archives/dev-commits-src-all/2024-August/044194.html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281218] Quectel LTE MODEM not working anymore
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281218 --- Comment #7 from Franco Fichtner --- (In reply to Warner Losh from comment #4) https://github.com/freebsd/freebsd-src/pull/1410 Could this have something to do with changing the default serial bps in FreeBSD 14? It's quite odd that it only affects a tiny portion of modems. https://cgit.freebsd.org/src/commit/?id=4722ceb7d53e Cheers, Franco -- You are receiving this mail because: You are the assignee for the bug.
[Bug 238733] kvm disk i/o extremely slow
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238733 Jan Catrysse changed: What|Removed |Added CC||jan.catry...@gmail.com --- Comment #7 from Jan Catrysse --- Any updates on this one? In Proxmox the DISK IO is extremely slow. I am now using FreeBSD 14, but the same applies to 13. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255072] boot (legacy): no progress beyond 'BIOS DRIVE D: is disk1'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255072 --- Comment #50 from sp...@itl.ua --- (In reply to Toomas Soome from comment #45) > Unfortunately, with those legacy cases, we really can not fix it just by > reading and changing the code -- we need to understand under which conditions > the problem is appearing and then figure how to fix it. Meaning, debug > printouts need to be inserted and it is long cycle of tests and > unfortunately, those tests need to be performed on that specific hardware. BTW, I had done this investigation already, with all those printouts, long cycle of tests and finally locating the exact point and conditions when boot fails. The issue is obviously in BIOS code and has stochastic behavior as it occurs due to (seems) some race condition. My comprehensive tests had shown that in no way the FreeBSD loader code causes the failure (I've tested 11.2-RELEASE and 12.3-RELEASE). The failure occurs exclusively inside of bd_edd_io() or bd_int13probe(), though far not every call of these functions. This conclusion is based on result of debug printf()'s: right before these calls and right after of them. Sometimes (randomly) these functions do not return (no exit debug message), approximately once per several tens of calls (proved by print()'s with incrementing number after each such call, and this number is always random one), without any regularity, so it is like some race condition. bd_edd_io() and bd_int13probe() call BIOS INT 13H, so it appears to be the cause of the failure. The reason why 11.2 loader seems to not having this issue (it boots normally) is just the fact it calls INT 13H just several times (about 6 or so) and almost always the race condition does not occur and boot goes normally (proved by incrementing count of bd_int13probe() calls - boot fails). Contrarily, 12.3 loader, due to zfs probing, has over hundred of INT 13H calls so earlier or sooner INT 13H runs into the race condition and boot fails. Just to remember, the failure occurs when three conditions are met: 1) Legacy boot 2) AHCI mode 3) USB flash drive inserted In these conditions, boot fails regardless of the device from which boot is preformed, whether it is USB Drive or HDD. So conclusion is: BIOS 13H handler incorrectly handles HDD+FlashDrive combination in AHCI mode. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281340] ex editor global command malfunctions when adding lines to matched lines that are consecutive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281340 Bug ID: 281340 Summary: ex editor global command malfunctions when adding lines to matched lines that are consecutive Product: Base System Version: 14.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: gnu Assignee: b...@freebsd.org Reporter: llaq...@protonmail.com Original buffer for all the commands: lin1 lin2 lin3 lin4 Command: g/[1|3]/ co . Resulting buffer (correct): lin1 lin1 lin2 lin3 lin3 lin4 Command: g/[2|4]/ co . Resulting buffer (correct): lin1 lin2 lin2 lin3 lin4 lin4 Command: g/[2|3]/ co . Resulting buffer (incorrect): lin1 lin2 lin2 lin3 lin4 lin4 Command: g/[3|4]/ co . Error message: Illegal address: only 5 lines in the file Resulting buffer (incorrect): lin1 lin2 lin3 lin3 lin4 Command: g/./ co . Error message: Illegal address: only 6 lines in the file Resulting buffer (incorrect): lin1 lin1 lin2 lin3 lin3 lin4 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #59 from Tomasz "CeDeROM" CEDRO --- here goes the report for drm-515-kmod (on 14.1-RELEASE-p4 AMD64 RX580/8GB GPU): 1. cd /usr/ports/graphics/drm-510-kmod; make deinstall. drm-510-kmod-5.10.163_9. 2. cd /usr/ports/graphics/drn-515-kmod; make install. drm-515-kmod-5.15.160. 3. gpu-firmware-kmod untouched. 4. kldload amdgpu. 5. module loaded correctly, xorg starts, some applications seems to work fine (blender, freecad, kicad, firefox). 6. then i stared obs and system hung right away. then did power off itself after some time (kernel panic?). 7. so i rebooted, loaded amdgpu, started xorg and run obs again with no other applications running, and system hung and powered off itself after some time (kernel panic?). looks like drm-515-kmod(-5.15.16) is still unstable and for sure has problems with hardware acceleration (vaapi?). just to confirm this problem with 5.15.160, i have double checked again, this problem does not occur on 5.10.163 nor 6.1.92. another problem i noticed during this test run is that `kldload amdgpu` breaks the system for drm 5.15 and 6.1: * for 5.10 it leaves computer without screen but responsive there is still a ping reply, i can work over ssh, i can reboot with ctrl+alt+del. * for 5.15 and 6.1 there is a kernel panic (not visible on screen as there is no screen anymore) system powers off after some time. i may now consider upgrading my main os from 13.3 to 14.1 and simply use 5.10 or 6.1 as alternative for 5.15 :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #60 from Tomasz "CeDeROM" CEDRO --- ah i forgot to mention the openarena screen break on drm-510-kmod - it is still here - there is ping reply and i can poweroff the machine over ssh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #61 from f...@fehcom.de --- (In reply to Tomasz "CeDeROM" CEDRO from comment #59) Hi, since I've moved to drm-61-kmod, my system runs without problems. If this bug report and its resolution has helped to improve FreeBSD, I'm happy now. And thanks for everbody involved pushing this ticket to a reliable solution. Time to close it. Tx. Olivier. Regards. --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #62 from Tomasz "CeDeROM" CEDRO --- after short consideration i will stick to 13.3 on my production. i really like to play but i need to work on that particular machine. there is no guarantee a hardware upgrade will remove all of the issues not introducing new ones and i have still some ports here unavailable on modern motherboards. i will keep the additional drive for testing and switch os when there is something to test. my main concern is serious filesystem damage during all those kernel panics: * i did use separate disk and UFS install not to touch production data on ZFS drives. also to test impact on filesystem. * each kernel panic caused UFS corruption. * even though UFS SU+J was not detected on next boot it finally got to point where init asked me to fsck by hand. in that case i had to run `fsck -fy /` several times until no problem was found (!!). then i could not run xorg or reinstall previously compiled drm ports because filesystem was corrupted anyway! * frequent power on/off also impacts hdd lifetime and condition and i have 6 hdd zraid. * it is not a problem for system packages that i can reinstall with pkg but a serious problem for config files or (NN TB of) data files that cannot be that easily restored. * i remember last time i upgraded to 14.0 and had frequent kernel panics from drm and then rolled back to 13.2 just to make sure no damage is done i noticed zfs corruption on big files reported by zpool status. those errors could not be fixed (scrub / resilver) and i had to delete them. luckily i did not upgrade zpool because there would be no way back. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #63 from Tomasz "CeDeROM" CEDRO --- I have reported two new bugs found during testing so this one can be closed: * drm on firmware pkg dependency: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281347 * kldunload issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281348 I will report the "openarena screen break" problem after I make a serial cable and catch it over a serial console. Feh even if the bug is closed now could you please report after two weeks if you encountered any crash on that drm-61-kmod? If no crash I may try upgrading 13.3 -> 14.1 with drm-61-kmod.. and zfs rollback to 13.3 on a first crash ;-) Thank you and have a good weekend folks :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #64 from Tomasz "CeDeROM" CEDRO --- And this bug for gpu-firmware-amd-kmod building only aldebaran firmware by default: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281349 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #65 from f...@fehcom.de --- (In reply to Tomasz "CeDeROM" CEDRO from comment #63) > Feh even if the bug is closed now could you please report after two weeks if > you > encountered any crash on that drm-61-kmod? If no crash I may try upgrading > 13.3 -> 14.1 > with drm-61-kmod.. and zfs rollback to 13.3 on a first crash ;-) Sure. You reach me at f...@fehcom.de. If required, I reopen the issue. But for now - given the lot of noise - lets calm down and close it. --eh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281351] bsdinstall(8) mbr boot freebsd-boot partition over 545KB proceeds with no warning
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281351 Bug ID: 281351 Summary: bsdinstall(8) mbr boot freebsd-boot partition over 545KB proceeds with no warning Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: porok...@gmx.com In handbook/bsdinstall "2.6.3. Manual Partitioning" there is part in tips "There is one exception: the freebsd-boot partition should be no larger than 512K due to current boot code limitations." that is hard to notice. On attempt to boot after install I get "Loadedonly 545kLoadedonly 545kLoadedonly" spam on the screen. FIX: Warn if freebsd-boot partition is over 545K: "freebsd-boot partition must be <= 545K" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281351] bsdinstall(8) mbr boot freebsd-boot partition over 545KB proceeds with no warning
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281351 porok...@gmx.com changed: What|Removed |Added CC||porok...@gmx.com Keywords||install -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281352] bsdinstall(8) Error while extracting lib32.txz with "Can't unlink already-existing object"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281352 Bug ID: 281352 Summary: bsdinstall(8) Error while extracting lib32.txz with "Can't unlink already-existing object" Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: porok...@gmx.com I selected all in distribution select, archive extraction: base.txz kernel.txz base-dbg.txz kernel-dbg.txz lib32-dbg.txz lib32.txz ports.txz src.txz tests.txz Speculation: it was supposed to be either lib32-dbg or lib32 selected, not both. FIX (based on speculation): Make no more than one selectable in group of lib32-dbg, lib32, yet should still be possible to uncheck. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281352] bsdinstall(8) Error while extracting lib32.txz with "Can't unlink already-existing object"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281352 porok...@gmx.com changed: What|Removed |Added CC||porok...@gmx.com Keywords||install -- You are receiving this mail because: You are the assignee for the bug.
