This flag enables 'at_console' policy support using logind. I don't
think we actually have a use for that and having it disabled hasn't
caused anything weird that I know of so far so leave it disabled.
Enabling this flag causes a circular dependency between systemd and dbus
which is resolved in catalyst bootstrapped builds like the SDK but for
target builds this is a problem.
No need for me to maintain a similar profile in two entirely different
ways. This is also one tiny step towards cleaning up our profiles in
general. Original here: https://github.com/marineam/systemd-only-overlay
As part of this change the baselayout dependency on openrc is now
handled via a use flag instead of package.provided. We didn't previously
include a virtual/init package but Gentoo has one and I needed it for my
generic systemd-only overlay so might as well include it here if it is
needed in the future.
No source directory exists so change the value of S, otherwise the
implied cd $S prior to src_install fails. This isn't an issue in oem-ami
which I was using as reference because it declares EAPI=2 which doesn't
make errors fatal by default.
ACPI power buttons are input devices! Without this it isn't possible to
trigger a graceful shutdown via qemu's command 'system_powerdown' or
whatever libvirt and similar APIs that are layered on top of it.
Probably applicable to other things too that we just don't know about.
Create a meta-ebuild for the SDK based on the packages currently listed
explicitly in bootstrap_sdk.sh and a buildhost ebuild that expands on
that, adding packages that are required in containers used by build
slave instances.
Creating a new category for this, coreos-base is overused and dev-python
didn't seem right for custom infrastructure tools. Going forward I'd
like to put SDK and build host specific stuff in this category when
previously coreos-base would be used. Things that actually land in
images would stick with coreos-base.
Important notice to all using curl: by default a 404 is not an error!
I noticed that instances created without any user data were attempting
to connect to a *lot* of random IP addresses and failing. After
attempting the curl command c10n uses to fetch user data it would seem
we have lots of virtual machines using the following as a secret key:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Not Found</title>
</head>
<body>
<h1>404 - Not Found</h1>
</body>
</html>
ᕙ(⇀‸↼‶)ᕗ
The --fail option is required for curl to behave responsibly.
thie patch does a few things
1) Add the etcd user and run etcd as that user
2) Add the /var/lib/etcd directory and have it owned by the etcd user
3) Move /media/state/etcd/* files into /var/lib/etcd/ and chown them to
etcd
Test-plan: Build an AMI and ensure this all works with the
bootstrapping.
1) Make default.target be multi-user.target instead of the default,
graphical.target
2) Move daemons out of coreos-startup and just have them wantedby
default.target
3) Have update-engine not rely on coreos-startup and add itself to
default.target.wants
4) Grab the new init code that does the above
5) Add the local-enable.service which will add /media/state/units to
/run/systemd/system and start local.target
