Re: Updated to 13-STABLE in VirtualBox; on shutdown stuck after uhub[01] being detached

[Guido Falsi via freebsd-stable]

On 28/04/21 00:12, parv wrote:

Hi there,

I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
12-STABLE
to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
testing with 13 GENERIC kernel.


You mean you enabled EFI inside virtualbox? Why do you need that? EFI 
support in VirtualBox is experimental and is available for OSes unable 
to boot without EFI. FreeBSD is perfectly able to boot in virtualbox 
without EFI so no need for it.


Now I understand reconfiguring the VM to not use EFI can be annoying, 
but you should really verify if the problem goes away without EFI.


Also can you try installing another FreeBSD VM and verify the problem 
happens for that one too? This could help understand if the problem is 
with virtualization or specific to the VM.




Now on shutdown, "shutdown -p now" (in single user mode, after manually
unmounting
ZFS datasets via "zfs unmount -a"), the shutting down process gets stuck,
and
CPU use jumps to 80% (Intel i5 6300U, 3 CPUs given to VM, of Thinkpad
X260). Last
few lines are ...

...
All buffers synced.
Uptime: 
uhub0: detached
uhub1: detached


In the end I chose "Power Off" from VirutalBox menu. "Reset" reboots the
machine.
None of these have any effect ...
   - Send the shutdown signal
   - ACPI Shutdown

Help please.


NOt sure even which further information to ask about this, but to be 
sure I understand correctly, FreeBSD is the guest here, correct?


--
Guido Falsi 
___
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: possibly silly question regarding freebsd-update

[Guido Falsi via freebsd-stable]

On 30/03/21 17:38, tech-lists wrote:
On Tue, Mar 30, 2021 at 05:22:30PM +0200, Guido Falsi via freebsd-stable 
wrote:


No, as you can see in the commit in the official git [1] while for
current and stable the new upstream version of openssl was imported for
the release the fix was applied without importing the new release and
without changing the reported version of the library.

So with 12.2p5 you do get the fix but don't get a new version of the
library.


[1]
https://cgit.freebsd.org/src/commit/?h=releng/12.2=af61348d61f51a88b438d41c3c91b56b2b65ed9b 



On this url, near the top, there's this:

"Fix multiple OpenSSL vulnerabilities. Add UPDATING and bump
version." next to that, we have "releng/12.2".

So, I'm expecting the version information pertaining to opensslto be 
bumped. Is this expectation unreasonable? I'm not a developer.




The "bumping verion" part refers to bumping the FreeBSD version, that's 
the p4 -> p5 part of the patch, last hunk referring to file 
sys/conf/newvers.sh


--
Guido Falsi 
___
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: possibly silly question regarding freebsd-update

[Guido Falsi via freebsd-stable]

On 30/03/21 15:35, tech-lists wrote:

Hi,

Recently there was
https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html
about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted.

What I'm unsure about is the openssl version.
Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd  22 Sep 2020

Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd
25 Mar 2021

shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well?



No, as you can see in the commit in the official git [1] while for 
current and stable the new upstream version of openssl was imported for 
the release the fix was applied without importing the new release and 
without changing the reported version of the library.


So with 12.2p5 you do get the fix but don't get a new version of the 
library.



[1] 
https://cgit.freebsd.org/src/commit/?h=releng/12.2=af61348d61f51a88b438d41c3c91b56b2b65ed9b



--
Guido Falsi 
___
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: EFISYS shortcuts on Xfce desktops

[Guido Falsi via freebsd-stable]

On 18/08/20 05:23, O'Connor, Daniel wrote:
> 
> 
>> On 18 Aug 2020, at 11:29, O'Connor, Daniel  wrote:
>> I think it would make sense to patch the port to add another stanza which 
>> matches EFISYS as well as EFI.
>>
>> What do you think?
> 
> I was going to file a bug but bugzilla is having a nap right now.

I agree with the suggestion. I'm not an expert about hal though. If
anyone has links to good documentation that would also be great.

Anyway this requires some coordination with gnome, which maintains the port.

-- 
Guido Falsi 
___
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: EFISYS shortcuts on Xfce desktops

[Guido Falsi via freebsd-stable]

On 08/08/20 04:32, Kyle Evans wrote:
> On Fri, Aug 7, 2020 at 8:57 PM Dmitrii Postolov  wrote:
>>
>> Hi!
>>
>> Recently (I find it difficult to give an exact date), on my computer with 
>> FreeBSD there is a situation when there are 2 EFISYS shortcuts on the 
>> desktop with Xfce 4.14 (without plugged sticks). In other Unix-like 
>> operating systems under Xfce there is no such problem. Is it possible to 
>> solve the problem?
>>
>> dmitrii@nuc7:~ % uname -a
>> FreeBSD nuc7 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC  amd64
>>
>> Intel NUC7PJYH MiniPC.
>>
>> Screenshot: https://yadi.sk/i/4fQZyK_o-yhUdQ
>>
> 
> Applications -> Settings- > Desktop -> Icons tab -> Default Icons ->
> Removable Devices, Unselect "Other Devices"

This would also exclude other useful devices.

> 
> i'm not sure if there's a more granular way to do this. Alternatively,
> you could create a /boot/efi or /boot/msdos or similar and mount it at
> boot so that xfce doesn't even try it. EFISYS = EFI System Partition
> ("ESP"). Unsure why it's identified in the "Removable Device"
> category.

The "granular" way is through hal policies. For example I have this in
/usr/local/etc/hal/fdi/preprobe/20thirdparty/10-ignore-EFI.fdi:



  

true

  
  

true

  



Hope this helps.

BTW there's some documentation here:

https://www.freebsd.org/gnome/docs/halfaq.html

-- 
Guido Falsi 
___
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: FBSD 12.1 - LightDM don't grab keyboard input & Xfce4 window decorator problem

[Guido Falsi via freebsd-stable]

On 11/03/20 16:50, Mario Olofo wrote:
> Hello,
> 
> I configured the full system with pkg and only build the drm-kmod.
> 
> I downloaded the img from the 12.0 stable version, don't know when or why
> it become release for me =X

This depends on how you updated it. I could guess you used
freebsd-update at some point, but only you can know for sure.

> The pkg was downloaded the first time I used it, so I don't know what can
> be wrong with it.

Nothing wrong with it, that's not what I meant.

> May you point me some link to understand better how to see if i'm in
> stable/release and how to migrate from quarter to latest?


To check which version of FreeBSD you are using should be possible with
freebsd-version(1), check it's man page, I'm not using stable versions,
only releases and current, and I'm not sure what the output is on stable.

Migrating from quarterly to latest is done by configuring pkg, you
should read the full pkg.conf(5) man page. The EXAMPLES section has
examples clearly explaining what you are asking for.

> I'll see if I'm in latest and reinstall all with pkg

This all depends on what you did on your system, any suggestion can only
be generic. You need to know your system condition.

You stated that you mixed binary packages installed via pkg from the
official repositories with locally built ports. As I said this is not
really supported, and if you only compiled locally part of Xorg and
mixed it with quarterly packages you have an high risk of having
inconsistent binaries on your system.

Check your logs for useful errors.

-- 
Guido Falsi 
___
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: FBSD 12.1 - LightDM don't grab keyboard input & Xfce4 window decorator problem

[Guido Falsi via freebsd-stable]

On 11/03/20 02:20, Mario Olofo wrote:
> Hello,
> 
> @Guido
> I tried to rebuild the xorg-server but it stoped to recognize all input
> devices even on Xfce4, I think I'm missing something.
> Tried to rebuild the xf86-input-evdev too but didn't work either.
> Had to revert to the pkg version to be able to send this email

Before these rebuilds were you using packages? from quarterly or latest?

AFAIK mixing packages and locally built packages isn't really supported.
I works most of the time, but there are no warranties. Also it is
especially prone to breaking when building parts that work with hardware
drivers.

So to properly upgrade your Xorg server if you're coming from quarterly
packages the safe way is to configure your machine to use latest
packages and perform a pkg upgrade. In rare cases you could need pkg
upgrade -f.

If you want to use ports and have been using packages, only safe way is
to reinstall everything from ports, but I'd really suggest you use
project provided packages or build your own package set using a tool
like poudriere.

Apart from this, new Xorg changes many things and upgrading only the
server will not be enough anyway.

Unluckily if you don't perform a proper upgrade it's difficult to tell
if the problem is caused by a bug in some port or induced by some
misalignment on your system software.

> 
> @Ulf Rudolf 
> Now knowing that the xorg-server is not recognizing any input devices
> after rebuild the latest version, I have a feeling that this problem is
> related, maybe the LightDM expects some specific device?

LightDM uses Xorg for it's input, so, no it should work. Have you tried
using "startx" as root to check that Xorg itself works fine?

-- 
Guido Falsi 
___
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: FBSD 12.1 - LightDM don't grab keyboard input & Xfce4 window decorator problem

[Guido Falsi via freebsd-stable]

On 10/03/20 13:41, Mario Olofo wrote:
> Hello All,
> In the prccess of making the FreeBSD my main OS, I stumbled on an very
> uncommon problem: the LightDM don't accept any keys, and I can't even get
> out to the tty with ctrl+alt+F1...
> 
> I build the drm-kmod from ports, installed Xorg, Xfce4 and LightDM and
> lightdm-gtk-greeter with pkg, and enabled it on rc.conf with
> lightdm_enable="YES".
> On boot, it don't work because the lightdm need to be on video group, so I
> added it to video groups and then the LightDM screen showed up, but only
> the mouse work. If I press a lot of keys and then use the mouse to restart
> the system, I can see some garbage input on the first terminal!
> I didn't create a custom X config, but tried to force a input conf to see
> if it was the problem but it appears that the config is not used at all
> when starting LightDM. I rebuild from source the LightDM, but the problem
> persists. When I use startx to go directly to Xfce4 works like a charm.
> 

I'm sorry I don't have much insight about this, but this one (and the
following problem too) looks like a graphics hardware related problem.

You should share some information about your system, which graphics
adapter and chipset you are using and what driver setup.

> Then comes the second but less important problem that I found, the topbar
> decorator of windows are not displaying correctly. The background img
> behind the title don't stretch to cover the full width. Anyone had this
> problem before?

There is a known problem with xfce 4.14 and window decorations on
certain hardware chipsets:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240887

It has been recently reported that Xorg server 1.20.7 (available with
the latest package set) fixes the issue.

This update will reach quarterly packages at the start of April. If
you're willing you could migrate your machine to latest packages and
confirm if this fixes the issue for you.

-- 
Guido Falsi 
___
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: XScreenSaver must bu rerun as demon on new login in Xfce 4.14

[Guido Falsi via freebsd-stable]

On 19/10/19 05:25, Dmitry Postolov wrote:
> Hi to FreeBSD Community! Sorry for my very bad English...
> 
> FreeBSD-12.1-RC2-amd64. Xfce 4.14 from the "latest" pkg repository.
> XScreenSaver 5.43 (09-Jul-2019).
> 
> XScreenSaver must bu rerun as demon on new login, because
> in other case it dont run as demon (in first start it was run).
> 

Hi,

The new XFCE 4.14 packages install xfce4-screensaver enabling it by
default (unless you compile your packages disabling it explicitly, in
which case it is not installed).

Due to this the xscreensaver startup .desktop file is installed disabled
by default to avoid launching two screensavers at the same time which
could cause conflicts (this has been reported by one user).

Please check the UPDATING entry 20190927 which has steps to address this.

In short you should enable xscreensaver in XFCE Session and Startup
settings application.

-- 
Guido Falsi 
___
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"