When run in an initrd and no root= argument is set (or is set to
root=gpt-auto) we will automatically look for the root partition on the
same disk the EFI ESP is located on.
Since we look for swap, /home and /srv on the disk the root partition is
located on, we hence have a fully discoverable chain:
Firmware discovers the EFI ESP partition → the initrd discovers the
root partition → the host OS discovers swap, /home, and /srv.
Note that this requires an EFI boot loader that sets the
LoaderDevicePartUUID EFI variable, such as Gummiboot.
This is preparation for a logic to automatically discover the root
partition to boot from if no partition has been configured explicitly.
This makes use of our newly defined GPT type GUIDs for our root disks:
#define GPT_ROOT_X86 SD_ID128_MAKE(44,47,95,40,f2,97,41,b2,9a,f7,d1,31,d5,f0,45,8a)
#define GPT_ROOT_X86_64 SD_ID128_MAKE(4f,68,bc,e3,e8,cd,4d,b1,96,e7,fb,ca,f9,84,b7,09)
We define differen GUIDs for different architectures to allow images
which finde the right root partition for the appropriate arch.
This patch introduces new netlink attribute parsing logic
which is table based lookup and sd_rtnl_message_read_*
methods for reading attributes. By doing this user does not
have to loop for the attribute values . Only providing the
attribute type it gets the attribute values which is optimized
and sd_rtnl_message_read_* methods are simplified.
In addition to checking whether the diestination mount point is
populated, check whether it is already a mount point.
If it is already a mount point, or if it is unpopulated, let's create
the unit.
- Add support for finding and mounting /srv based on GPT data, similar
to how we already handly /home.
- Share the fsck logic between GPT, EFI and fstab generators
- Make sure we never run the EFI generator inside containers
- Drop DefaultDependencies=no from EFI mount units
- Other fixes
Bridges will change their MAC address when other devices are enslaved. We need
the correct MAC address to acquire a DHCP lease, so take note of it whenever
it changes.
If we encounter an inconsistency in a file, let's just
ignore it. Otherwise, after previous patch, we would try,
and fail, to use this file in every invocation of sd_journal_next
or sd_journal_previous that happens afterwards.
With a corrupted file, we can get in a situation where two entries
in the entry array point to the same object. Then journal_file_next_entry
will find the first one using generic_arrray_bisect, and try to move to
the second one, but since the address is the same, generic_array_get will
return the first one. journal_file_next_entry ends up in an infinite loop.
https://bugzilla.redhat.com/show_bug.cgi?id=1047039
The code for parsing these properties is shared with "systemctl
set-property", which means all the resource control settings are
immediately available.
