| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
We default to quiet operation everywhere except for repart, where
we disable quiet and have the mkfs tools write to stdout.
We also make sure --quiet or equivalent is implemented for all mkfs
tools.
|
| | |
|
| |
|
|
|
|
| |
Let's allow users to configure the (logical) sector size of their
image. This is required when building images for a 4k sector size
disk on a 512b sector size host or vice-versa.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
|
| |
|
|
| |
homed LUKS directories
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Let's explicitly flush the kernel's buffer cache on the whole block
device once we ran "mkfs". This is necessary, because partition and
whole block devices maintain separate buffer caches, and thus writing
to one will not be visible on the other if cached there already, until
the latter's cache is explicitly flushed.
This is preparation for later adding support for probing file sytems
also if we have no open partition block devices, and hence want to use
the whole block device instead.
|
| |
|
|
|
|
| |
Let's extend the test further, and try the codepaths where we do not
pin/add the partition block devices (i.e. which is the codepaths we use
when running without privs)
|
| |
|
|
|
| |
Let's verify that we properly created the file systems once we did so.
And tets this way that our dissector works correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DISSECT_IMAGE_OPEN_PARTITION_DEVICES
Curently, these two flags were implied by dissect_loop_device(), but
that's not right, because this means systemd-gpt-auto-generator will
dissect the root block device with these flags set and that's not
desirable: the generator should not cause the partition devices to be
created (we don't intend to use them right-away after all, but expect
udev to find/probe them first, and then mount them though .mount units).
And there's no point in opening the partition devices, since we do not
intend to mount them via fds either.
Hence, rework this: instead of implying the flags, specify them
explicitly.
While we are at it, let's also rename the flags to make them more
descriptive:
DISSECT_IMAGE_MANAGE_PARTITION_DEVICES becomes
DISSECT_IMAGE_ADD_PARTITION_DEVICES, since that's really all this does:
add the partition devices via BLKPG.
DISSECT_IMAGE_OPEN_PARTITION_DEVICES becomes
DISSECT_IMAGE_PIN_PARTITION_DEVICES, since we not only open the devices,
but keep the devices open continously (i.e. we "pin" them).
Also, drop the DISSECT_IMAGE_BLOCK_DEVICE combination flag, since it is
misleading, i.e. it suggests it was appropriate to specify on all
dissected blocking devices, but that's precisely not the case, see the
systemd-gpt-auto-generator case. My guess is that the confusion around
this was actually the cause for this bug we are addressing here.
Fixes: #25528
|
| | |
|
| | |
|
| |\
| |
| | |
Expose various GPT UUIDs as public contants and link them up in docs
|
| | |
| |
| |
| |
| |
| | |
I think those constants are generally useful. It's quite easy to make a mistake
when copying things from the docs, so let's make them easy and convenient to
access.
|
| |/
|
|
|
| |
The caveat is that the caller has to provide a source directory
to initialize the squashfs filesystem from.
|
| |
|
|
|
|
|
|
| |
image name
Follow-up for e374439f4b8def786031ddbbd7dfdae3a335d4d2 (#24322).
This also simplify the logic of generating image name from image path.
|
| |
|
|
| |
It will be used in later commits.
|
| |
|
|
| |
It will be used in later commits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The loading of an extension image from a symlink "NAME.raw" to
"NAME-VERSION.raw" failed because the release file name check worked
with the backing file of the loop device which already resolves the
symlink and thus the found name "NAME-VERSION" mismatched "NAME".
Pass the original filename and use it instead of the backing file
when available. This fixes the loading of "NAME.raw" extensions which
are a symlink to "NAME-VERSION.raw" as, e.g., may be the case when
systemd-sysupdate manages multiple versions.
Fixes https://github.com/systemd/systemd/issues/24293
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's rework how we lock loopback block devices in two ways:
1. Lock a separate fd, instead of the main block device fd. We already
did that for our internal locking when allocating loopback block
devices, but do so for the exposed locking (i.e.
loop_device_flock()), too, so that the lock is independent of the
main fd we actually use of IO.
2. Instead of locking the device during allocation of the loopback
device, then unlocking it (which will make udev run), and then
re-locking things if we need, let's instead just keep the lock the
whole time, to make things a bit safer and faster, and not have to
wait for udev at all. This is done by adding a "lock_op" parameter to
loop device allocation functions that declares the initial state of
the lock, and is one of LOCK_UN/LOCK_SH/LOCK_EX. This change also
shortens a lot of code, since we allocate + immediately lock loopback
devices pretty much everywhere.
|
| |
|
|
|
|
|
|
| |
Fixes build with musl:
| ../git/src/shared/dissect-image.c: In function 'mount_image_privately_interactively':
| ../git/src/shared/dissect-image.c:2986:34: error: 'LOCK_SH' undeclared (first use in this function)
| 2986 | r = loop_device_flock(d, LOCK_SH);
| | ^~~~~~~
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So here's something we should always keep in mind:
systemd-udevd actually does *two* things with BSD file locks on block
devices:
1. While it probes a device it takes a LOCK_SH lock. Thus everyone else
taking a LOCK_EX lock will temporarily block udev from probing
devices, which is good when making changes to it.
2. Whenever a device is closed after write (detected via inotify), udevd
will issue BLKRRPART (requesting the kernel to reread the partition
table). It does this while holding a LOCK_EX lock on the block
device. Thus anyone else taking LOCK_SH or LOCK_EX will temporarily
block udevd from issuing that ioctl. And that's quite relevant, since
the kernel will temporarily flush out all partitions while re-reading
the partition table and then create them anew. Thus it is smart to
take LOCK_SH when dissecting a block device to ensure that no
BLKRRPART is issued in the background, until we mounted the devices.
|
| | |
|
| | |
|
| |
|
|
| |
That's useful when running tests manually.
|
| |
|
|
|
| |
Let's simplify things if we are only supposed to create a single thread.
Makes it easier to debug things with gdb.
|
| |
|
|
|
|
|
|
|
|
|
| |
Same idea as 03677889f0ef42cdc534bf3b31265a054b20a354.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
|
| |
|
|
|
|
|
|
| |
DISKSEQ is a reliable way to find out if we missed a uevent or not, as
it's monotonically increasing. If we parse an event with a smaller or
no sequence number, we know we need to wait longer. If we parse an
event with a greater sequence number, we know we missed it and the
device was reused.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This tries to shorten the race of device reuse a bit more: let's ignore
udev database entries that are older than the time where we started to
use a loopback device.
This doesn't fix the whole loopback device raciness mess, but it makes
the race window a bit shorter.
|
| |
|
|
|
|
|
|
|
|
|
| |
Let's drop all monitor uevent that were enqueued before we actually
started setting up the device.
This doesn't fix the race, but it makes the race window smaller: since
we cannot determine the uevent seqnum and the loopback attachment
atomically, there's a tiny window where uevents might be generated by
the device which we mistake for being associated with out use of the
loopback device.
|
| | |
|
| | |
|
| |
|
