1. 15 Jun, 2017 2 commits
    • Mike Hibler's avatar
      Fix a xenmode() bug exposed by a race condition. · 340f1861
      Mike Hibler authored
      The bug was that, even when the console pty device does not change,
      we still need to re-open the device since our caller has closed it.
      The race is that, on starting a domU, xenstore may briefly report the
      wrong device before finally reporting the correct one.
      On first call to xenmode, we recover from the race because we catch the
      attempt to open the non-existent device, but then when we retry the
      xenmode and we get back the same pty name, we would not do the open
      and the caller would then do a select/read on a closed fd. That is a
      fatal error. Now xenmode will report an error when it trys to reopen
      the bad pty and we will just keep calling xenmode until we finally get
      the right device.
      In theory.
    • Leigh B Stoller's avatar
  2. 14 Jun, 2017 1 commit
  3. 13 Jun, 2017 3 commits
    • David Johnson's avatar
      Make our systemd fstab-generator work with (bad?) systemds. · 58a03627
      David Johnson authored
      It seems that some systemds (i.e. 219) cannot handle by-uuid unitfile
      names (although they are happy to print them out via systemctl
      list-units).  So, in one place in the fstab-generator, just use the raw
      device naming convention.  systemd doesn't care what we use.  From the
        Ok, don't use the by-uuid method (dev-disk-by\\x2duuid-${transuuid}.swap).
        It seems to me that the vintage of systemd on Centos7
        (i.e. 219) doesn't correctly process dev-by-uuid filenames nor
        unitnames (even systemctl status <blah>, where <blah> is a
        by-uuid unit name reported by systemctl list-units, does not
        work!).  systemd 229 on Ubuntu seems happy to use the by-uuid
        unitfilename we generated above.
      (Perhaps I should have done this in all places in this script, but I
      didn't for now :(.  I believe my by-uuid encoding is correct, and I
      really don't want to rock a mostly-working boat.  This fix is enough for
      all the cases we have, I hope.)
    • David Johnson's avatar
      Workaround smart dhclient on centos7; fixes #54. · 095f2ce1
      David Johnson authored
      From the comments:
        Work around dhclient-scripts that forcibly set preferred_lft and
        valid_lft.  We cannot override the lease time sent from the server
        with a real infinite value (our best bet would be UINT32_MAX, and that
        sucks), so we intercept dhclient's name for the new lease time it's
        about to feed to the ip command.  Does this suck any less?  We cannot
        ex post facto run `ip addr change ...` just to reset the preferred_lft
        and valid_lft fields to "forever"; that seems to be tightly coupled
        with assigning an address to an interface (and we don't want to re-add
        the address; that is the whole point of dhclient-script!).  (Some
        dhclients also do not process "expire never" in dhclient.conf
        correctly, so this is what we are left with!)
    • Leigh B Stoller's avatar
  4. 12 Jun, 2017 5 commits
  5. 11 Jun, 2017 1 commit
  6. 09 Jun, 2017 6 commits
  7. 08 Jun, 2017 1 commit
  8. 07 Jun, 2017 6 commits
  9. 06 Jun, 2017 5 commits
  10. 05 Jun, 2017 8 commits
  11. 04 Jun, 2017 2 commits