I use a lot of minimal installs on various ARM devices. They’re good because they’re quick to download and you can test most of the functionality of the device to ensure it’s working or to quickly test specific functionality but of course it doesn’t have a GUI to use the nice graphical tools which are useful to quickly connect to a wifi network or other things.
This where nmcli comes in handy to quickly do anything you can do with the GUI. To connect to a wireless network I do:
Check you can see the wireless NIC and that the radio is enabled (basically “Airplane” mode):
# nmcli radio
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
# nmcli device
DEVICE TYPE STATE CONNECTION
wlan0 wifi disconnected --
eth0 ethernet unavailable --
lo loopback unmanaged --
Then to actually connect to a wireless AP:
# nmcli device wifi rescan
# nmcli device wifi list
# nmcli device wifi connect SSID-Name password wireless-password
And that should be enough to get you connected. You can list the connection with nmcli connection and various other options. It’s pretty straight forward. The only complaint I have is that it doesn’t prompt for a password if you leave it out so it means the AP password is stored on the command line history. Not a major given it’s quite easy to find where it’s stored anyway on the system but it would be a useful addition.
When ever we branch for a new release of Fedora I, and others, end up spending a non trivial amount of time ensuring that there’s a clean upgrade path for packages. From the moment we branch you need to build new versions and bug fixes of packages for rawhide (currently what will become Fedora 26), for the current stabilising release (what will become Fedora 25) as well as what ever stable releases you need to push the fix for. For rawhide you don’t need to submit it as an update but for the current release that’s stabilising you do need to submit it as an update as it won’t just automagically get tagged into the release.
As a packager you should know this, it’s been like it for a VERY LONG TIME! Yet each cycle from the moment of branching right through to when a new release goes GA I still end up having to fix packages that “get downgraded” when people upgrade between releases!!
So far this cycle I’ve fixed about 20 odd with the latest being bash-completion (built but not submitted as an update for F-25) and certmonger (numerous fixes missing from F-25 and master branch).
The other silly packaging bug I end up having to fix quite a bit is NVR downgrades where even though it’s a newer package the way the NVR is handled makes rpm/dnf/yum think the newer package is a lesser version than the current version and hence you’re new shiny fix won’t actually make it to end users. I see this a lot where people push a beta/RC package to a devel (F-25/rawhide) release. Just something to be aware of, there’s lots of good docs around the way rpm/dnf/yum handles eNVR upgrades.
So I’m at Flock in Prague. So far I’ve been to a bunch of interesting talks about Release Engineering, Secondary Architectures, Fedora Workstation, Docker and Infrastructure.
Of course then there’s the hallway track of which I always actively participate and it’s been always fabulous to meet a bunch of people in real life that I’ve been dealing with online on a regular basis, in some cases for years!
I’ll be around for the entire conference and if you’re interested in chatting about secondary architectures (not just ARM), Sugar, Cloud or just about anything else or just to say hi please come and find me!
I have a number of devices that run Fedora and they all get upgraded at various times through out the release process. The eeePC 901 gets upgraded, reinstalled and uses the upcoming release regularly and constantly. My build test VM runs the release from shortly after beta of the previous release. My “stable” devices upgrade times vary depending on the release. These are devices I need to live my life and include my work laptop, my NAS box, my media centre box, my firewall, and two servers. So what releases are they all running 🙂
Work laptop: this was upgraded this week to Verne. It didn’t get upgraded to F-15 for a couple of months after the release. Most of the time it gets upgraded around the beta. I have some issues with it, most are thankfully not major road blocks. I’ll cover this one in a separate post.
NAS: Running F-16. Its solely CIFS/NFSv4 and some other services like Squeeze Centre Server. No major problems as yet.
Build VM: Its a VMWare VM. Has been fine, but for some reason of late its suspending or locking up of late. This is somewhat concerning.
Media Centre: I need to upgrade it, i’ve just not had the time. I’m looking forward to trying out Media Explorer once I’ve finished the package review 🙂
Firewall: Sometime very soon. I wish NetworkManager would add support for native IPv6 on PPPoE connections
Servers: My primary hosted server is still running Fedora 14. It runs a number of websites, mail servers and VMs. I want to upgrade this but it needs a proper backup process first 😐 My other server is running F-15 and I’ll likely push it to F-16 once I’ve worked out why the buildbox VM is suspending/crashing, it is after all my primary mail server.
Overall I’m looking forward to Verne. Its looking to be a very solid release with some great new features and the stabilisation of two of the major changes in F-15 in systemd and gnome-3 with a lot of thanks going to Adam Williamson and the QA team and their tireless work to keep the rest of us in check and on schedule. I believe Adam barely slept in the four days leading up to Verne beta being declared good to go so we didn’t slip another week. Thank you all! I’m looking forward to a great release 🙂