Re: FreeBSD 13 console stops working under VMware
On 08/05/2021 15:20, Dimitry Andric wrote: On 8 May 2021, at 16:02, Roger Leigh wrote: This might sound like a bit of an odd one, but I’ll try to describe it. When I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work correctly, but randomly stops working. If I focus the VMware window, and press Ctrl-G to grab input focus (or click in the window), I can log into the system using the console. However, if I press Ctrl-Alt to ungrab the input focus, or click outside the window, the block cursor on the console vanishes, and it’s no longer possible to type any input. However… if I grab focus again, I can use Alt-Fn to switch to a different virtual console, log in again and everything is fine… up until I switch focus to something else and the block cursor vanishes in that virtual console. Repeat until you run out of virtual consoles! I can’t reproduce this with FreeBSD 12. It seems to only happen with FreeBSD 13. I’ve had it happen reproducibly when losing focus, but then again sometimes I’ve had a few minutes where it doesn’t happen, until it starts occurring again. While it seems that losing focus is the trigger, there might be something else going on. Has anyone else noticed this or have any suggested workarounds? Press the Scroll Lock key to 'fix' it, if that is possible for you. This is some weird interaction between VMware's input focus grabbing method and our console, which sometimes turns on Scroll Lock accidentally. I have not been able to put my finger on when it happens exactly, but it does happen often. For me, it usually occurs when I use Microsoft Remote Desktop to access a Windows machine running VMware, and switch back and forth between Remote desktop and another application. Something about losing the focus is making the VMware GUI inject a Scroll Lock event. It's pretty tricky to generate Scroll Lock via Remote Desktop though, especially from a Mac, which doesn't have that key at all. :) -Dimitry PS: Note that Scroll Lock is normally used in FreeBSD's console to scroll back in the virtual consoles, as opposed to Linux's shift-PageUp and shift-PageDown. But it is a toggle, not a one-off key. Thanks Dimitry, that certainly makes some sort of sense! I am indeed connecting from a Mac to a beefier Windows 10 PC running VMware workstation using Remote Desktop. Going back to one of the "broken" consoles, I can indeed use PgUp/PgDn to scroll up and down, so it certainly appears as though a Scroll Lock keypress was sent or triggered somehow. While I do have a regular PC keyboard hooked up, I don't find myself able to send that key event through the Remote Desktop session. However, if I physically log into the Windows PC, I can unstick each console with the physical Scroll Lock key, so it seems clear that (somehow) Scroll Lock was triggered in the first place to cause the problem. I have tried to trigger various combinations of grab/ungrab/switch to window inside or outside of the Remote Desktop session, but I've not been able to pinpoint the specific trigger. Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 13 console stops working under VMware
Hi, This might sound like a bit of an odd one, but I’ll try to describe it. When I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work correctly, but randomly stops working. If I focus the VMware window, and press Ctrl-G to grab input focus (or click in the window), I can log into the system using the console. However, if I press Ctrl-Alt to ungrab the input focus, or click outside the window, the block cursor on the console vanishes, and it’s no longer possible to type any input. However… if I grab focus again, I can use Alt-Fn to switch to a different virtual console, log in again and everything is fine… up until I switch focus to something else and the block cursor vanishes in that virtual console. Repeat until you run out of virtual consoles! I can’t reproduce this with FreeBSD 12. It seems to only happen with FreeBSD 13. I’ve had it happen reproducibly when losing focus, but then again sometimes I’ve had a few minutes where it doesn’t happen, until it starts occurring again. While it seems that losing focus is the trigger, there might be something else going on. Has anyone else noticed this or have any suggested workarounds? Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deprecating base system ftpd?
On 3 Apr 2021, at 22:21, Eugene Grosbein wrote: > > 04.04.2021 3:39, Ed Maste wrote: > >> I propose deprecating the ftpd currently included in the base system >> before FreeBSD 14, and opened review D26447 >> (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> I had originally planned to try to do this before 13.0, but it dropped >> off my list. FTP is not nearly as relevant now as it once was, and it >> had a security vulnerability that secteam had to address. >> >> I'm happy to make a port for it if anyone needs it. Comments? > > I'm strongly against remove of stock ftpd. FTP is fastest protocol for both > testing > and daily file transfer for trusted isolated segments, and even for WAN > wrapped in IPSec. > > Our stock ftpd has very short backlog of security issues comparing with other > FTP server implementations, > mostly linked with libc or other libraries and not with ftpd code itself. > > Please don't fix what ain't broken. Please. How would you draw the line between something that must be part of the base system vs. something that would be better off as part of the ports tree? What bar should ftpd have to meet to warrant remaining in base vs moving to ports? Personally, I’ve never enabled it nor had any desire to. FTP is, at this point in time, thoroughly obsolescent, and I cannot imagine that it is something that most people enable, if they are even aware of its existence. Why can’t it simply be installed from the ports for the occasional user who still requires it? Why should the base system contain obsolete stuff that few people will use? Surely the ports tree serves this need better? Can I ask, for those who do enable it, why isn’t “sftp” acceptable (or “scp”)? Both provide a similar function, securely, which also works with a basic installation without any ports. SSHFXP, the protocol underlying sftp is better specified, less ambiguous and more fault tolerant and safe than the FTP protocol ever was. The client is better than most ftp clients, and the server (/usr/libexec/sftp-server) is started on demand on a per-connection basis. What makes FTP more desirable than a service over SSH which is (from a technical and usability point of view) a better FTP than FTP ever was? Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI boot failure with VMware Workstation 16 and 12.2Beta3
On 30/09/2020 17:44, Roger Leigh wrote: Hi folks, I've been testing FreeBSD 12.2Beta3 (amd64) with VMware Workstation 16 on Windows 10, and encountered an issue which looks to be related to the UEFI console (see attached screenshot). It's quite possible this is a VMware UEFI bug rather than a FreeBSD bug, and I've mentioned this to VMware here: https://communities.vmware.com/thread/643481 but I wanted to mention it here in case it's triggered by the FreeBSD UEFI support doing something slightly incorrect which triggers this misbehaviour. I also tested with the latest 12.1 release image and this behaviour is not triggered with 12.1p1 or p10. One additional detail to mention. The installer didn't trigger the bug. It booted from UEFI perfectly and the installer ran to completion. This issue was only triggered after I booted into the new installation. Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
UEFI boot failure with VMware Workstation 16 and 12.2Beta3
Hi folks, I've been testing FreeBSD 12.2Beta3 (amd64) with VMware Workstation 16 on Windows 10, and encountered an issue which looks to be related to the UEFI console (see attached screenshot). It's quite possible this is a VMware UEFI bug rather than a FreeBSD bug, and I've mentioned this to VMware here: https://communities.vmware.com/thread/643481 but I wanted to mention it here in case it's triggered by the FreeBSD UEFI support doing something slightly incorrect which triggers this misbehaviour. I also tested with the latest 12.1 release image and this behaviour is not triggered with 12.1p1 or p10. Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 12.0-BETA2 Now Available
On 29/10/2018 13:40, Mark Dixon wrote: On Mon, 29 Oct 2018 at 13:24, Lars Engels wrote: On Mon, Oct 29, 2018 at 07:59:32AM +, Mark Dixon wrote: Same, FreeBSD update doesn't seem to be working: $ sudo freebsd-update upgrade -r 12.0-BETA2 IIRC freebsd-update only works for RCs, not ALPHA and BETA versions. The release notes for the beta (this thread) provide instructions for it, and it certain has done for previous releases. If this has changed, the instructions should be removed from the release notes. I've likewise tried and failed to follow these instructions. Assuming that it is supported, will it be possible to upgrade from BETA2 to RCs and then the final RELEASE? Thanks, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On 07/10/2018 05:40, Warner Losh wrote: I'd like to request as many people as possible submit their current dmesg to the service at http://dmesgd.nycbug.org/index.cgi so that we have a better basis for future preliminary lists of drivers for other parts of the tree. This one-liner works to submit, though you'll need to change username, email and maybe tweak the description if your system doesn't have decent smbios entries. It's also x86 centric, since other systems won't have this information as readily available. Out of interest, has FreeBSD considered implementing an equivalent of Debian's "popularity-contest" package, which periodically submits anonymised lists of installed packages? On FreeBSD this could be from the pkg database, and could also include hardware information. In Debian, it's opt-in at install time, or installable afterward. If FreeBSD had a similar package and installer opt-in, this could potentially provide useful usage statistics without any privacy concerns. Regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ephemeral /var/run and creating port-specific subdir at service startup time
On 01/09/16 00:12, Mark Martinec wrote: I prefer to have a /var/run file system reside on a tmpfs as its contents is small and ephemeral in its nature (like pid files, lock files, sockets), need not be preserved across reboots, and should not have to depend on any physical disk. The problem is that some programs/services/ports like to create their own subdirectory under /var/run. This works fine if such subdirectory is created (when missing) by their rc.d script, such as salt, dbus, jenkins, clamav-clamd, isc-dhcpd, kibana. Unfortunately there are other ports which create a subdirectory under /var/run at the installation time (pkg install). In this case their subdirectory is missing on a reboot when /var/run is re-created afresh, and they fail to start. So my question is: are such ports (like influxdb, grafana3) which do not create their subdirectory at a startup time in error and a bug report is warranted, or am I wrong in expecting that /var/run may be ephemeral and is such a setup (as is common in Linux) unsupported? I can't speak for FreeBSD policies, but as the person who implemented /run on Debian GNU/Linux for sysvinit (/var/run on tmpfs essentially), we had to audit every package and ensure that all packages created the directories they needed if they weren't present. We retained the cleaning of /var/run on boot to ensure a clean slate, so having it on tmpfs was never mandatory, but if you did then it would just work. However, we did have boot-time cleaning of /var/run for a while before we introduced the tmpfs, so I can't recall doing anything but a handful of minor tweaks. Doing the same for FreeBSD wouldn't be too hard if you can automatically scan the ports tree or build package contents to identify and fix any packages which are providing static files. Regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSH Chroot FreeBSD 10.1 and 10.2
On 22/08/2015 15:01, Brandon Allbery wrote: On Sat, Aug 22, 2015 at 10:54 AM, Rainer Duffner rai...@ultra-secure.de wrote: I found it’s much easier to have actual chroot’ed ssh users once the users themselves are in an LDAP-directory. Also, for doing anything useful on that shell, it turned out you need a some more devices in /dev than the usual chroot (like a chroot’ed PHP-FPM, that just needs the dev-set of jail(4)). And a couple of symlinks. Yep; chroots are always a pain to deal with. I have seen utilities to manage them, but only for Linux. For your information, I'm in the process of porting my schroot chroot management tool to FreeBSD. https://github.com/codelibre-net/schroot This was traditionally a Linux (Debian) chroot tool for building source packages, but it's worked on Debian GNU/kFreeBSD for a good while so it already supported nullfs filesystem mounts e.g. of home directories and devices, and now the work to build it on FreeBSD proper is done--I was blocked on toolchain/linker bugs for the last 18 months until 10.2 came out (C++11 nullptr_t was broken) The master branch is current development work, and I got it all building on FreeBSD 10.2-RELEASE just yesterday. It's not yet actually *tested* on FreeBSD other than the unit tests pass. So it might not be production-ready right now, but it should be fairly soon. Now it's building, I'll also look at adding some FreeBSD-specific features to it as well, like ZFS snapshots, jail support, etc. While the compiled binaries should be fine, there may be residual Debianisms/GNU libc-isms in the setup scripts. They are likely trivial to fix though. If anyone wants to give it a try and provide some feedback, or if you have any suggestions or feature requests, please just let me know either by mail or at https://github.com/codelibre-net/schroot/issues Instructions for building on FreeBSD are in the README https://github.com/codelibre-net/schroot/blob/master/README.md Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
