Loud PC speaker beep during reboot, sometimes
by Kamil Paral
Completely randomly, my laptop sometimes emits a loud PC speaker beep while
rebooting/powering off Fedora 37. The beep is very strong, and as a PC
speaker sound, it of course ignores any configured volume level, mute
status, and even headphones plugged in. I fortunately am in a different
room than the rest of my family sleeps in, but if I were in the same room,
and were I just a regular user, this would probably be the last day of
Fedora on that laptop. The beep is that loud and uncomfortable, especially
at night.
I wonder if somebody else running F37 noticed it as well? Any hints what
might cause it and how we can fix it? It never happened on F36 on the same
laptop.
Thanks,
Kamil
1 year, 7 months
First glance issues after upgrade (Nautilus & display properties)
by A fox
After upgrading from Fedora 36 testing to Fedora 37 testing the following first glance issues appeared:
Display: The desktop wallpaper was lost; monitor refresh rate had to be readjusted.
Nautilus (43.0-1.fc37): Column settings were lost; there seems to be a scrolling issue; the star column can´t be hidden with the "visible columns" menu.
1 year, 7 months
F37 seems to require a reboot after updates of firmware packages in
order for firefox to run.
by stan
I'm running an actual install of F37. I have had this experience twice
now. I run the updates in a virtual console using dnf, they
complete successfully, they have a firmware package among the updates.
I then start X to run LXDE, and it starts without complaint. But when
I try to run either nightly from /usr/local or firefox from /usr/bin in
a terminal, they start and just hang. There are no messages in the
journal or in the terminal, and when I look at them using ps they are
in interruptable sleep.
In both cases, I killed them, and exited X, restarted X, and tried to
run them again. No change. But, when I reboot the computer,
everything starts working again the way I would expect; firefox starts.
Is this a change in F37 that requires a reboot after the install of
firmware packages? I know that Gnome, and I think KDE, now require a
reboot after every update. Has it moved to other desktops? Can I
turn it off, if it has? Is there a command I can run from the command
line to do the equivalent of a reboot? Or is it all just coincidence,
and there is another reason?
1 year, 7 months
Upgrade blocker /usr/bin/WebKitWebDriver
by RS
When trying to upgrade to Fedora 37 Beta with the system-upgrade Plugin like so:
sudo dnf system-upgrade download --releasever=37
I get the following error:
Error: Transaction test error:
file /usr/bin/WebKitWebDriver from install of webkit2gtk4.1-2.37.91-1.fc37.x86_64 conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64
file /usr/bin/WebKitWebDriver from install of webkit2gtk5.0-2.37.91-1.fc37.x86_64 conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64
1 year, 7 months
Heads up: GNOME 43.0 megaupdate is in testing
by Kalev Lember
Hi all,
Just a quick heads up that the GNOME 43.0 final release megaupdate is
now in F37 updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0bd68bbb43
This is the GNOME version that's we'll be shipping F37 Final with, so
please make sure to test it and file issues for things that would need
fixing before F37 GA. I'd suggest starting upstream at gitlab.gnome.org
for most issues, and then letting me (and other people) know in
#fedora-workstation if anything needs backporting to Fedora (since there
won't be any more upstream releases before F37 Final). If anything looks
to be release blockery, then please also file issues downstream at
bugzilla.redhat.com as soon as possible and mark them as blockers using
the blockerbugs page,
https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist
At the same time, please don't block the update with -1 karma unless
there's something really amiss: We need the megaupdate to go stable and
we can iterate from there.
It all passed my own smoke testing and things were calm upstream and
it's mostly just bug fixes at this point, compared to 43.rc.
Thanks everybody and let's make this a good release!
--
Kalev
1 year, 7 months
Extensions information
by pmkellly＠frontier.com
Good morning everyone,
I know Gnome Shell Extension issues are not considered bugs. This is
just information.
Earlier when the discussion was going on about not being able to install
extensions I sent an e'mail to this list that mentioned this and said I
would check it out more when Gnome had a version number. Now that Gnome
is 43.0 I went ahead with my checks.
Three of the extensions used here are Freon, NetSpeed, and System
Monitor. To this point these would not run reporting an error of not
being compatible with the current Gnome version. Today I patched that
and verified the patches as follows:
sudo sed -i 's/40.0/43.0/g'
/usr/share/gnome-shell/extensions/freon(a)UshakovVasilii_Github.yahoo.com/metadata.json
sudo sed -i 's/42/43.0/g'
/usr/share/gnome-shell/extensions/netspeed(a)hedayaty.gmail.com/metadata.json
sudo sed -i 's/42/43.0/g'
/usr/share/gnome-shell/extensions/system-monitor(a)paradoxxx.zero.gmail.com/metadata.json
cat
/usr/share/gnome-shell/extensions/freon(a)UshakovVasilii_Github.yahoo.com/metadata.json
cat
/usr/share/gnome-shell/extensions/netspeed(a)hedayaty.gmail.com/metadata.json
cat
/usr/share/gnome-shell/extensions/system-monitor(a)paradoxxx.zero.gmail.com/metadata.json
Now Freon and Net Speed seem to be working fine. If someone could update
the Gnome version in their metadata.jason files in the RPM they should
be fine as installed. Should these be reported as Gnome issues?
System Monitor now shows a different error "StatusArea aggregateMenu is
undefined". Is this a Gnome Issue or do extension issues get reported at
another location?
Have a Great Day!
Pat (tablepc)
1 year, 7 months
Re: Release criteria proposal: except BitLocker-enabled installs from Windows
dual-boot criterion bootloader requirement
by Chris Murphy
On Tue, Sep 20, 2022, at 9:50 AM, Brian C. Lane wrote:
> On Mon, Sep 19, 2022 at 12:16:33PM -0700, Adam Williamson wrote:
>> "The installer must be able to install into free space alongside an
>> existing clean Windows installation and install a bootloader which can
>> boot into both Windows and Fedora."
>>
>> to say:
>>
>> "The installer must be able to install into free space alongside an
>> existing clean Windows installation. As long as the Windows
>> installation does not have BitLocker enabled, the installer must also
>> install a bootloader which can boot into both Windows and Fedora."
>
> We have reached a point where boot security is important enough that
> Windows is now only allowing their bootloader to be used. With bitlocker
> enabled this is working exactly how it was designed so I'd change the
> wording to require that grub2 doesn't prevent windows from continuing to
> boot via their preferred method and leave it at that.
>
> And while there may be a possible solution using BootNext, until someone
> does the work and tests it there is no point in requiring grub2 to do
> something it cannot do.
An additional topic is having boot entries for Windows (and macOS) that don't work in the meantime. While we could just remove the scripts that create these entries to chainload another bootloader, they're still needed for BIOS systems which don't support bootnext.
--
Chris Murphy
1 year, 7 months
