Tag Archives: ubuntu

Howto

OpenStack Single-Node Options

Leave a comment

After getting a DevStack node running here, I realized that a DevStack cluster wasn’t going to be as useful as I would like. DevStack is designed for developer testing purposes, and doesn’t recover well in the event of a machine reboot.

I decided to look at some options that would lead to a cluster and, ultimately, a high-availability (HA) configuration.

Canonical conjure-up

A colleague had recommended Canonical’s conjure-up, so I decided to give the Workstation guide a try:

https://ubuntu.com/openstack/install#workstation-deployment

Initially, I hit one of three problems:

  1. neutron-gateway/0 error: hook failed: "config-changed"
    Specifically, neutron-gateway/0 didn’t like the dataport br-ex:eno2, claiming that eno2 didn’t exist. Confirmed. I looked for ways that eno2 might be expected to be generated without much luck.

    This github issue looks like it describes the problem almost perfectly (except for the name of the network interface), but the fix/correction makes no sense to me. It also looks like it was fixed in 2016, so I don’t think this is my problem.

    I took a chance at tweaking the configuration parameters. I set other options for the dataport parameter. Specifying eth1 could allow neutron-gateway/0 to complete installation, but then I typically run into another problem with neutron-api/0. I didn’t get far in investigating this one. If I’m running into these kinds of problems following what should be a straight-forward install guide, then I have no idea how deep the issues go.
  2. Machine locked up and become completely unresponsive. This was only seen on VMs (mostly 18.04), but I didn’t try much on bare metal.
  3. System setup hang: all processes were either active, blocked, or waiting — many just waiting on a machine. This was more rare.

There were regularly blocked-service errors in the conjure-up logs, leading to some confusion about the actual source of the installation error(s).

This is not a good start for Canonical. I tried their guide on 16.04 and 18.04, VMs and hardware — all with no success.

I’ve filed an issue with conjure-up: https://github.com/conjure-up/conjure-up/issues/1612

I asked a question: https://askubuntu.com/questions/1157568/how-to-install-openstack-with-novalxd-on-ubuntu-16-04

A week after filing the conjure-up issue, I’ve not heard back, and my question on askubuntu.com has gotten little attention. Other issues have been filed with exactly the same problems. This one is the most active: https://github.com/conjure-up/conjure-up/issues/1618

It seems odd to me that such simple instructions posted by a major OS vendor would be allowed to get to a state where they fail so completely.

Bottom line, I think the conjure-up OpenStack Workstation install is busted. There was a bit of irony in this struggle due to all of the “works by magic” claims with conjure-up and juju. Their magic lacks some potency.

The only good thing to come out of this was that I figured out how to interact with juju — a service that looks a bit like a Puppet/Chef/Ansible installer/manager. It looks like it has support for all kinds of different cloud types and vendors, but if those integrations work like this busted localhost install, I’m not sure that I’ll get much out of them.

There is still the conjure-up cluster installation (which was the original recommendation to me). More on that coming soon.

PackStack

I mentioned that this was an option in the first article, and I was fed-up with conjure-up, so I decided to look at OpenStack on CentOS.

I’m using CentOS 7 on a 6 core, 24 GB RAM, 128 GB disk VM.

I found this guide: https://linuxhint.com/install_openstack_centos/
The only adjustment needed was to run:

yum install -y yum-utils

so that the yum-config-manager step will work correctly.

I have tried this with both OpenStack versions rocky and stein, but not queens as indicated in the instructions. Just replace rocky or stein wherever queens is mentioned.

Success!

That’s how it should be done. Install time takes around 24 min — faster than the DevStack install.

The system survives reboots out of the box, which might make it a better candidate for more involved tests than DevStack. It would certainly behave better as a test system on hardware.

Unfortunately, when looking closer into clustering and HA configurations with packstack, it starts to look a little weaker.

Mentions

Throughout my investigation some other OpenStack options have popped up:

  • Mirantis – This is a professional OpenStack (and then some) system. It looks like these guys know what they’re doing, and they charge accordingly. There might have been a free evaluation option, but I prefer to try things that are unencumbered by licenses.
  • MicroStack – This name popped up in the AskUbuntu question. I don’t know much about it except that it doesn’t sound like it supports a high-availability configuration. Though they say it’s slated for 2020/2021.

Scripting

A quick test with some scripts written to interact with the DevStack install reveals that I had some things hard-coded to work with the DevStack install. The big adjustment I had to make was in the lookup of OpenStack service endpoints. Given the OpenStack architecture it makes sense that communication points could be different across different clusters. I wrote a bit about that here.

Next Steps

Several months into this project, I have a couple of ways to set up a demonstration installation of OpenStack on a single node, Python scripts to interact with it in some basic ways, and a technique for delivering data for project testing purposes. However, I still don’t have a system that takes advantage of the primary OpenStack capabilities: compute pooling across multiple hardware nodes. More on that to come.

Howto

Ubuntu on Asus Zenbook Flip UX360C – Power Performance

Leave a comment

I spent a few weeks watching a Zenbook Flip drain its battery doing different things via Ubuntu 16.10, and here I present the results.

Charging while idling (screen on):

Trial NumberInitial ChargeFinal ChargeTime (hours)Total Charge Time (hours)
Average2.565
10.1201.0002.4092.737
20.0910.9902.0002.225
30.0410.9902.5342.671
40.0131.0002.5682.602

Admittedly, this has less to do with the OS than the hardware, but it was easy info to collect while running the other tests.

Discharging with video playing and full screen brightness:

Trail NumberInitial ChargeFinal ChargeTime (hours)Total Discharge Time (hours)
Average4.268
11.000.0294.0504.171
21.000.0284.2424.364

I was pulling video from YouTube via Firefox, specifically https://www.youtube.com/watch?v=SrlHtqTL_8o&list=PLU0V6ITiWqjhk5k-7hAasE5oAQspuTYgp. Gaming playlists make a good source of non-stop video.

Discharge passively with screen at 40%:

Trial NumberInitial ChargeFinal ChargeTime (hours)Total Discharge Time (hours)
Average9.733
10.9750.02910.38110.974
21.0000.02910.63010.947
31.0000.0297.0687.279

I’m not sure what happened with the last trial. Nothing should have changed between them. Regardless, I think the picture is clear enough.

I had started to do passive discharge times at full brightness, but later decided against it. The data I gathered is below:

TrialInitial ChargeFinal ChargeTime (hours)Total Discharge Time (hours)
11.0000.0307.4627.693

This looks similar to the odd trial from the previous table, so that might offer an explanation.

The last test I ran was battery rundown while sleeping. This test should be completely independent of Ubuntu, but it’s still useful.

Rundown time: 35 days from 100% to 13%

I only have the patience for one trial, but I’m more than satisfied with the result. Presumably it could go 40+ days before losing state.

It looks like Ubuntu 16.10 will give you anywhere between 4 to 10 hours depending on usage, where 10 hours is barely any usage. I’m inclined to believe Windows performs better, but I haven’t run the tests myself.

Howto

Ubuntu on Asus Zenbook Flip UX360C

Leave a comment

Notes

  • Model: Asus Zenbook Flip UX360C bought from Microsoft Store – link
  • Software: Ubuntu 16.04.2 LTS Desktop via DVD ISO – link

Getting Started

  1. Power up the Zenbook Flip
  2. On the boot-up screen, push ESC
  3. Select “Enter Setup”
  4. Go to Boot menu
  5. Go to “Add New Boot Option”
  6. “Add Boot Option” -> <pick a name> (I used “USB DVD”)
  7. “Path for boot option” ->
    1. Select the option that isn’t the HD (Mine is “PCI(14|0)\USB(0,0)\CDROM(Entry1)”)
    2. “<efi>”
    3. “<boot>”
    4. “bootx64.efi”
  8. Create
  9. OK
  10. ESC key
  11. “Boot Option #1” -> <the name you chose earlier> (I used “USB DVD”)
  12. Go to Save & Exit menu
  13. “Save Changes and Exit”
  14. Yes
  15. From the boot options, choose “Run Ubuntu” (I could not get a direct install to work)
  16. Run “Install Ubuntu 16.04 LTS” found on the desktop
  17. Choose the installation parameters you prefer. I like:
    1. Pull updates while installing
    2. Leave Secure Boot ON
    3. Encrypt the disk
    4. Encrypt the home drive

Out of Box Problems

Big Ones

  • Some lid-close/open suspend-resume cycles bypass the lock screen entirely. This is a security problem. When this happens, the mouse click doesn’t function. However, pressing the Windows key a couple times seems to restore that.
    Try it for yourself: Open a Terminal, System Settings, and Firefox and go through some suspend-resume cycles.
    They say this is the problem: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/49579
    I’m not entirely convinced.
  • Reboots are a gamble. After the main decryption passphrase, Ubuntu (kernel 4.8.0-41) can stop at an arbitrary point and never continue. Using the advanced Ubuntu options to boot with a different kernel (4.8.0-36) seems to get past this. Unfortunately this isn’t the first time I’ve seen this kind of instability with Ubuntu + Zenbook.
  • The touchscreen can become useless after several suspend-resume cycles. It registers a move of the pointer, but no clicks. I couldn’t find a way to restore this short of a reboot.

Annoyances

    • Lots of complaints of problems on startup: 
      System program problem detected
    • Suspend-resume is generally fragile. After many attempts, I find that I can’t connect to wifi. It claims to see one network, not mine. Cycling the Ubuntu networking off and on doesn’t help. Rebooting worked, but this may also help: 
      $ sudo service network-manager restart

      If I see the problem again, I’ll give it a try.

    • The lock screen after suspend-resume also seems to flake out every once in a while with an odd flicker and/or focus change. The password field should always be focused. One odd manifestation of this was auto-starting a guest session on resume. Another was the absence of a password box, leaving me unable to log back in. 
      $ sudo service lightdm restart

      or a machine restart will get you running again, but you will lose your desktop session.

    • Lid-close suspend-resume can result in windows resizing. This might be related to the above problem.
    • Sequences of opening and closing the lid can leave the laptop active while closed. This isn’t new to this model laptop, but it would be nice if it didn’t happen. This generally results in returning to a dead or near dead battery sometime later.
    • The Windows sticker on the back doesn’t come off clean. It leaves behind a sticky residue that seems to prefer the chassis material. Some soft cotton cloth, rubbing alcohol, and elbow grease will clear it up. Be careful to avoid the Serial Number sticker. That may be helpful to have in the future.
    • The brightness function keys don’t function. This is a pretty common Zenbook issue, but it looks like it may be fixed with the 4.10 kernel (17.04?): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890
      Some workarounds are listed with the bug, but you can use the built-in UI controls, xbacklight, or xdotool.

Preferences

  • Power button asks what to do — on this model it should just suspend. This page has the answer 
    $ gsettings set org.gnome.settings-daemon.plugins.power button-power 'suspend'
  • Suspend when inactive for some time (30 min works for me). I hate returning to a dead battery after getting side-tracked for a few hours. 
    $ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
$ gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1800
  • Also, shut down when the battery gets critically low (defaults to 10% battery). A clean shutdown is usually preferable: 
    $ gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action 'shutdown'
  • Lock screen after short period. This is a small usability feature that I like in the event that I see the screensaver kicking on but can’t get to the machine in time to avoid entering a password. It doesn’t need to be long (30 s): 
    $ gsettings set org.gnome.desktop.screensaver lock-delay 'int32 30'

Other Thoughts

Ubuntu on Zenbook hasn’t been the most robust usability combination. Most of the applications work fine. It’s just the edges that could use some polish. The lock screen specifically has been a persistent problem. It looks like it may have gotten worse with this notebook model.

With that said, I prefer having an Open Source option, and Ubuntu seems to be among the best.