More tire kicking to come, but I wanted to share my first genuine Heisenbug experience with F20 with you!
First, let me note that this didn't happen on the same system that I'd blogged about before - on that one I'd installed Fedora 20 Beta from scratch. This system is my "floortop" computer at home that was running Fedora 19 and which I just recently upgraded to F20 using FedUp.
Anyway, I was trying to open an existing account at mail.office365.com (yeah, I know) and FireFox 26.0 crashed 3 times in a row at the "loading your mailbox" point after logging in. I figured I'd be clever and start FF from a command line in a terminal, piping its console output to a file:
$ firefox &>office365FFdump.txt
Firefox "fired" up just fine. I pointed it to mail.office365.com, entered the login info and... found myself looking at the inbox, just as I did not expect. Just to be sure of what I witnessed, I logged out, closed FF and repeated the process. Again, success. So, attempting to observe Firefox fail, failed. So far it looks just like a Heisenbug!
Next things to (sanity) check:
- what does the default launcher pass to firefox's command line?
- what happens if I pass those same parameters (if any) to firefox when launched in a terminal?
I suppose there are a myriad of more aggressive debugging approaches I could take, but hey. This is just a passing chuckle so far - a demonstrative nod to this distro's codename.
Good night.
Followup:
When run from the default launcher, the only difference I can see between it and my running '$ firefox' from a terminal in my home directory is that the path to firefox in the launcher is explicit. Here's the result of me running it in my home directory but with the full path specified:
$ /usr/lib/firefox/firefox
(process:2465): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Segmentation fault (core dumped)
$
Hmmm, crashy.
Wednesday, December 18, 2013
Monday, December 9, 2013
Fedora 20 - Kicking the tires, pt 1
I've been playing with Fedora 20 (codename: Heisenbug) Beta and thought I'd share a few observations and impressions. As an aside, a heisenbug is an error in software code that can be difficult to track down because its buggy behavior changes or appears to just go away when you try to debug it. Let's hope the Fedora Project isn't saying their latest distro release is full of freaky, hard to track bugs!
Error: Package: boost-chrono-1.54.0-5.fc20.i686 (fedora)
Requires: boost-system = 1.54.0-5.fc20
Installed: boost-system-1.54.0-7.fc20.i686 (@updates-testing)
To correct those dependency problems, I had to do a couple of things. First replace the "newer" packages with the right stuff:
# yum distro-sync
Next was to disable the updates-testing repository for my machine so I wouldn't get into that kind of mess again:
# rm /etc/yum.repos.d/fedora-updates-testing.repo
A couple of friendly bits of advice: If you don't want to run into weird problems and just want a stable Fedora box, don't install a Beta release! The other thing is, if you do run into trouble, Google it first and if nothing turns up, you can hop on over to #fedora at irc.freenode.net and ask for help nicely. That's where I learned about "distro-sync".
Enabling a WiFi hotspot is a snap:
updates-testing
My first trip-up happened when I tried to install some software, specifically the "3D Printing" package group. By default when a Beta (not the final release) version of Fedora is installed, the "updates-testing" repository is enabled and when I did my first "# yum update", some packages were updated from the testing repo. When I tried to install the 3D printing group, boost (one of its dependencies) failed to install because it wanted specific versions of some other packages that had been replaced with "newer" versions from the updates-testing repo. Example:Error: Package: boost-chrono-1.54.0-5.fc20.i686 (fedora)
Requires: boost-system = 1.54.0-5.fc20
Installed: boost-system-1.54.0-7.fc20.i686 (@updates-testing)
To correct those dependency problems, I had to do a couple of things. First replace the "newer" packages with the right stuff:
# yum distro-sync
Next was to disable the updates-testing repository for my machine so I wouldn't get into that kind of mess again:
# rm /etc/yum.repos.d/fedora-updates-testing.repo
A couple of friendly bits of advice: If you don't want to run into weird problems and just want a stable Fedora box, don't install a Beta release! The other thing is, if you do run into trouble, Google it first and if nothing turns up, you can hop on over to #fedora at irc.freenode.net and ask for help nicely. That's where I learned about "distro-sync".
Wi-Fi Hotspot
Fedora 20 comes with a brand-new release of NetworkManager from the fine folks at gnome.org. One feature that I was interested in was the ability to easily create a WiFi hotspot. That turned out to be quite simple and "just worked". This nice thing about this latest release is that the hotspot is brought up in AP (master) mode if your Wi-Fi adapter supports it. Previously NM used adhoc mode, which most smartphones won't connect to because of security concerns. The Wi-Fi hotspot that NM creates for you does have a worrying security limitation in that it uses 40 bit WEP security. It takes just a few minutes to crack 40 bit WEP encryption. I popped into #nm at irc.freenode.net and mentioned this limitation. Immediately one of the devs there opened an issue in their bug tracker. Ain't Open Source great?Enabling a WiFi hotspot is a snap:
- Click in the upper left corner of the display
- Click on "Wi-Fi"
- Select "Wi-Fi Settings"
- Click "Use as Hotspot..."
- Click "Turn On"
- Done.
Subscribe to:
Posts (Atom)