firefox ignores my temporary directory setting
by Eyal Lebedinsky
firefox 100.0.2
I set up a temp dir in about:config
browser.cache.disk.parent_directory /data/Firefox_temp
At no point did I see any activity there but if I empty that directory then FF creates it on launch, so it knows about it.
Here is what I do:
Open the URL
http://www.gnu.org/software/gzip/manual/
Click on
PDF file (304K bytes)
A popup asks "What should Firefox do with this file?"
- I have "always ask" set for this file type in Settings/General/Applications
at this point I see a new file in my home directory
-rw------- 1 eyal eyal 308839 May 14 17:33 _qBdbX0t.pdf.part
I now select
Open with xpdf
and click
OK
The above random file disappeared and another file appears
-rw-r--r-- 1 eyal eyal 308839 May 14 17:33 gzip.pdf
I now close firefox and this file remains.
I restart FF and it is still there.
On another machine the file is created in ~/Download.
How do I get FF to use the nominated directory?
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
1 year, 10 months
trip report: upgrading to Fedora 36 (fwd)
by D. Hugh Redelmeier
[I wrote this for the Greater Toronto Area Linux Users Group but it might
be of interest to this list.]
I just upgraded several systems to from Fedora 34 or 35 to Fedora 36 over
the last week. This process is mostly uneventful. Here are some notes.
There are two ways to upgrade:
- use the GNOME "software" GUI and tell it to just do it.
- use the "dnf" technique
<https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/>
I like the dnf technique because I can see what's going on (and perhaps
see what is going wrong, if anything). Superstition. The "software"
program has worked fine when I've used it.
Another superstition: after step 1 in the dnf technique, I like to do
sudo dnf autoremove
This removes leaf packages that were installed due to dependencies but are
no longer used. Theory: those orphans may have no upgrade path; it is
better to ditch them that to try to upgrade them.
I did run into three problems:
- one system's grub could not see any new kernels so I could only boot
with the last f35 kernel. I fixed this by doing a clean re-install.
Here's what I think went wrong (only a theory):
+ the latest kernel and a rescue kernel + initrd are installed in the
ESP (/boot/efi). This is new. I didn't see it documented.
+ this requires more free space in the ESP than my system had
+ kernel installation silently failed! Even when I tried to fix
things by installing kernels after the upgrade
It looks like some others have hit this:
<https://ask.fedoraproject.org/t/f36-kernel-wont-install-due-to-running-ou...>
<https://bugzilla.redhat.com/show_bug.cgi?id=2071034>
Make sure that you have enough free space in /boot/efi. 300MiB should
be plenty -- those files currently take 130MiB on my system.
- On some systems, I use kernel driver modules from RPMFusion. In
particular, the NVidia proprietary driver and the broadcom-wl driver.
After update, they didn't work. The fix:
sudo depmod
It is listed as the first Common Bug on rpmfusion.org
<https://rpmfusion.org/CommonBugs#System-upgrade%20and%20kmod(-nvidia)%20i...>
- after the upgrade, some WiFi passwords were forgotten and needed to be
re-entered. If you upgraded using WiFi, that connection's password was
retained. I didn't do careful observations so I may be wrong.
1 year, 10 months
Fedora 36 update vs broadcom-wl
by D. Hugh Redelmeier
I have an 11-year-old netbook. The WiFi hardware needs the broadcom-wl
driver from RPM Fusion.
The Fedora upgrade from 35 to 36 worked fine, including keeping/updating
broadcom-wl.
But WiFi didn't work. The desktop didn't even see the device. I needed
to issue the command
sudo depmod
I've had to do this in previous upgrades too.
This is pretty easy to do but not at all obvious (I leave notes to myself
so that I don't have to rediscover the solution).
My guess is that this is a simple oversight in packaging. If so, it is an
RPMFusion problem, not a Fedora problem.
1 year, 10 months