| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
| |
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
| |
This cleans up the log output a little.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
Rather than creating boot options pre-emptively, in two paths, just do
it once when we see the menuentry option.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
| |
Keep options in the order that we discovered them in; this makes testing
a little easier, as the options appear in the list in the same order
as the config file.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
| |
Currently, when a new UI client connects, we send all boot options to
all clients. This results in existing clients getting duplicate add
events.
Instead, we only want to send existing boot options to the new client.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
The user event parser should be populating the discover_boot_option's
resources, not the strings in struct boot_option.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
| |
We need to define a few structs for the params of resource functions.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't currently handle conf events very well:
user_event remove event:
device: /net/eth0
name => (null)
image => (null)
args => (null)
This change prints the event action properly, and prints all event
params.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
We're not populating d_opt->option, so are returning invalid boot
options from the kboot parser.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
These are a bit of a special-case ("why isn't my boot option
appearing?"), so add a log message.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
| |
`kexec -e` will just call shutdown, which we've already tried, so it's
likely to fail. Add a further fallback to force a kexec with -e -f
options.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
| |
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
| |
We're only dealing with devpath resources at the moment.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
| |
We don't want to call NULL resolve_resource callbacks.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
Now what we have protocol support, send status updates during the boot
process.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
| |
Add a function to the server to notify clients of boot status updates.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
libudev1 changed the symbol udev_get_sys_path to be private, so
remove its use in petitboot.
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
|
|
|
|
| |
With the switch of the discover server to use the libudev
enumeration support the udev_trigger() routine has becone
empty and is no longer needed.
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
|
|
|
| |
Support for 'RUN+="socket:' in udev rules files has been removed
in udev version 183. Update the discover server to use libudev.
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
|
|
|
| |
To avoid symbol clashes with libudev, rename struct udev to
struct pb_udev. No functional changes.
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
| |
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
| |
This change adds a new event type, EVENT_ACTION_CONF. These events
supply a new configuration URL that petitiboot should download and
parse.
With this in place, we can receive DHCP configuration events.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We'd like to be able to download petitboot configurations from other
sources (not just local files), but we'll need some way to indicate to
the parsers that a chunk of config data is from a specific source.
This change adds "configuration methods". At present, we have only one:
CONF_METHOD_LOCAL_FILE. For any incoming configuration data, we only run
parsers that have registered themselves with that configuration method.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we require all parsers to be defined in an array in
parsers.c.
This change removes this requirement, by introducting a
register_parser() macro, which adds a constructor to register the parser
with the core parser infrastructure.
Because each parser no longer resolves an undefined symbol, we need to
use a `ld -r` object for libparser, instead of using libtool, which
creates a .a (and hence has no parsers included).
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds an unresolved resource queue - any unresolved resources
discovered by parsers are added to this queue rather than being reported
to the clients.
When we discover a new device, we try to resolve any resources in the
queue against the new device. If resolution succeeds, we can send the
option to clients.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Once the discover context is committed, we need to turn the resources in
struct discover_boot_option into strings in struct boot_option, so that
the parser can display & edit the boot option.
This may cause assertions if any of the boot options contain unresolved
resources, we'll fix this in the next patch.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
| |
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change switches the parsers over to populate the resources in
discover_boot_option, rather than the string parameters in boot_option.
To do this, we need a few things:
* Add struct resources to discover_boot_option for the boot_image,
initrd and icon data.
* Have the parsers populate the resources, rather than the strings.
Currently, parsers can all use the devpath resource type.
* Add a resolve_resource callback to parsers; this is how the device
handler will attempt to resolve resources.
* Change load_file to load_url, as we should be only accessing
(resolved) resources by URLs.
This then allows us to remove the mount map, and associated lookup code,
as well as the UUID and label links to devices.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
URL resources are simple: the URLs are already resolved, so not much to
do here.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
| |
Add a generic resource type, to handle "dev:path"-style file references.
This creates a duplicate of is_prefix_ignorecase, which we'll switch
over to later.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new type, struct resource, for handling resources such as
kernels and initrds.
This allows the parsers to better describe resources that are required
for booting. Firstly, we enforce all resources to be URLs, rather than
local paths. Also, resources allow us to describe files devices that
have not-yet been hotplugged.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
| |
This change introduces a new type, struct discover_boot_option. Like
struct discover_device adds discover-specific data to struct device,
struct discover_boot_option allows the discover server to store more
than just the boot option strings for a boot option.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a few functions to find devices by various attributes:
* device_lookup_by_name
* device_lookup_by_path
* device_lookup_by_uuid
* device_lookup_by_label
* device_lookup_by_id
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than depending on the event (which is only available during
inital discovery) for UUID and label parameters, this change adds uuid
and label members to struct discover_device.
This means that the label and UUID are available during the device's
lifetime, not just during initial discovery. We can also just pass the
device to some of the device handling code, rather than the discover
context.
Also, fix an issue where we don't use the raw label/uuid (instead of the
encoded one) in setup_device_links.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
Rather than having each of the parsers do their own open(), read(), etc,
use the registered filenames array to find & open parser conf files.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
In preparation of moving file handling to the discover core (rather than
the parsers), include the conf file names in struct parser.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
| |
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
discover/boot.c: In function ‘boot’:
discover/boot.c:153:13: error: ‘local_initrd’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
The processing of events does not modify the event strings, so change the
strings in struct event to const (read-only).
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
| |
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
|
|
|
|
|
|
|
| |
At present, we keep both permanent (eg links/n_links) and temporary
(event) data in struct discover_context.
This change makes discover_context a temporary structure, just used
during actual device discovery. Once discovery is complete, the
permanent data (discover_device) is "committed" to the device handler.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
| |
Currently, we assume all user events are for a new device. This means
that we can never add boot options to an existing device.
This change tries to find an existing (matching by ID) device before
creating a new one in the user event add path.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to cater for situations where boot options may be discovered
some time after we get notificiation about devices. For instance,
discovering boot options from DHCP configuration parameters. In this
case, we'll need to notify UIs of boot options appear some time after
the device (and/or other boot options on the same device) has appeared.
This change adds a new protocol message type,
PB_PROTOCOL_ACTION_BOOT_OPTION_ADD. We also rename
PB_PROTOCOL_ACTION_ADD to make it clear that it is just for devices.
The discover server is updated to send boot option add events at device
discover time, but we are now able to decouple this later.
We also update the clients to handle the boot option add events
separately.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Curently, the protocol deserialise functions are allocating device and
boot_command structures. This (implicitly) makes them responsible for
initialisation of these structures too.
Rather that making the protocol responsible for initialising the devices
and boot commands, this change gives the deserialise functions an
argument to an already-instanciated structure. This means that the
creation is no longer implied by the deserialise.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
| |
Fix typo in boot() routine.
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
|
|
|
|
|
| |
Now that the server does the booting, we should move the --dry-run
argument to the server.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change moves the boot-via-kexec functionality from the UIs to the
discover server.
On the UI side: rather than run kexec directly, we just send a message
to the discover server. Because this is generic discover client
functionality, we no longer need the boot callbacks in the twin- and
ncurses-specific code.
We also remove the kexec and URL-loading code from the UIs, and add it
to the discover server code, in paths.c. We expose this to the server
though a new function:
load_path(void *, const char *, unsigned int *);
On the server side, we simply move hook up the boot() function to use
the load_file and kexec calls.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
|
|
|
| |
This change adds a funtion, device_handler_boot, which processes the
boot command message from the discover server.
We add a new file, discover/boot.c (and a corresponding header) with a
skeleton for the final kexec code.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
|
| |
Add a function in the protocol code to deserialise a boot message, and
use it to extract a boot_command in the discover server.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|