IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When removing a directory tree as unprivileged user we might encounter
files owned by us but not deletable since the containing directory might
have the "r" bit missing in its access mode. Let's try to deal with
this: optionally if we get EACCES try to set the bit and see if it works
then.
Let's track the "dirty" state of a home directory backed by a LUKS
volume by setting a new xattr "home.home-dirty" on the backing file
whenever it is in use.
This allows us to later user this information to show a home directory
as "dirty". This is useful because we trim/allocate on log-out, and
if we don't do that a home directory will be larger than necessary. This
fact is something we should communicate to the admin.
The idea is that when an admin sees a user with a "dirty" home directory
they can ask them to log in, to clean up the dirty state, and thus trim
everything again.
For discussion around this see: https://pagure.io/fedora-workstation/issue/82
Recovery keys for homed are very similar to regular passwords, except
that they are exclusively generated by the computer, and not chosen by
the user. The idea is that they are printed or otherwise stored
externally and not what users type in every day.
Taking inspiration from Windows and MacOS this uses 256bit keys. We
format them in 64 yubikey modhex characters, in groups of 8 chars
separated by dashes.
Why yubikey modhex? modhex only uses characters that are are located at
the same place in western keyboard designs. This should reduce the
chance for incorrect inputs for a major chunk of our users, though
certainly not all. This is particular relevant during early boot and
recovery situations, where there's a good chance the keyboard mapping is
not correctly set up.
Since 625a164069aff9efb61dcc5916c572f53c2a7ab0 we don't need to update
analyze-condition.c separately anymore, hence drop the comment
suggesting otherwise.
It appears LOOP_CONFIGURE in 5.8 is even more broken than initially
thought: it doesn't properly propgate lo_sizelimit to the block device
layer. :-(
Let's hence check the block device size immediately after issuing
LOOP_CONFIGURE, and if it doesn't match what we just set let's fallback
to the old ioctls.
This means LOOP_CONFIGURE currently works correctly only for the most
simply case: no partition table logic and no size limit. Sad!
(Kernel people should really be told about the concepts of tests and
even CI, one day!)
When assembling a disk image locally, using --size=auto can be used to
generate the minimal image based on the provided definitions. THis is
useful to prepare images that are grown on first boot.
This matches how we handle things everywhere else, i.e. in .mount units,
and similar: when a mount point dir is missing, we create it, let's do
so too when dealing with disk images.
This makes things a lot simpler, more robust, and systematic.
Wiping means writing zero sectors to disk. Hence it's better to do this
before we discard, so that the zeroes we use to overwrite are properly
discarded. If we'd do it the other way round we'd discard the data and
then reallocte it just to write zeroes.
We initialize the partition contents before the partitions actually
exist, hence to reduce confusion let's talk about "future partitions" up
to the point where they are actually realized.
Let's issue the wiping ourselves, so that we know it's done before we
write partition data onto the disk, and before the disk label
is written. Before this commit the writing of the disk label would imply
the wiping step, potentially overriding again what we just wrote into
the disk data section.
(Normally this shouldn't matter, since the partition table metadata
that the wiping process deletes is at the start and end of the disk
while we write our data to the middle, but you never know what kind of
weird signatures might exist that depart from that.)
(And effectively this ends up using the same wiping code, since that's
implemented in libblkkid, and libfdisk just acts as frontend to that
anyway. We now simply call it directly.)
fat is a bit more limited in volume name length and UUID support. Let's
add some special support for it.
This is particularly useful to generate EFI system partitions.
The context_unload_partition_table() call is supposed to remove all
data from the loaded partitions about how we mapped it to existing
partitions on disk, but it should leave everything we parsed from the
definition files in place.
We mostly got this right, except for two cases:
1. new_uuid is parsed from the definition files and should stay
2. current_label is read from the existing partition table and should be
freed
"Linux" conflicts /efi/Linux when /efi is the install location.
/efi/Linux is already reserved for unified kernel images so we can't use
it for type #1 images. Instead, we use "Default".
