| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 560f9ca983d743cc42701c24546ac8c2080a13fe introduced a regression
in that a lot of variables got autovivificated
This results in a bug for some of them, at least for 'compssListLevel'
The solution is to store options values in a hash (which actually
simplifies here):
http://perldoc.perl.org/Getopt/Long.html#Storing-options-values-in-a-hash
Thanks Martin Whitaker for the suggestion
|
|
|
|
|
|
| |
commit 560f9ca983d743cc42701c24546ac8c2080a13fe introduced this small
regression, which is important to fix for next commit, else
s/compsslistlevel/compssListLevel/ won't work as intended
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Thus fixing too big translations that make the partition window to be
too big (mga#20360)
This was a side effect of commit 947ab9bb0fb06611b5bd54465f98545ff175afb2
which itself partially reverted commit 8e187d972ed59909271d48915eef4af34e7fe068
|
|
|
|
|
|
|
|
|
| |
Thus fixing too big translations that make the partition window to be
too big (mga#20360)
This was a side effect of commit 947ab9bb0fb06611b5bd54465f98545ff175afb2
Adjust translations accordingly
(note that some translators have already done so)
|
| |
|
|
|
|
|
| |
basically enabling it ti skip the rpmdb access like ensure_*() too.
needed for next commit
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
diskdrake allows the user to clear all partitions even when some of those
partitions are currently mounted. partition_table::dos::need_to_tell_kernel()
must return true in this case, as the automatic reread of the partition table
triggered by udevd will fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids unnecessary udev events, which in some cases were causing
udevd to trigger a kernel partition table reread, causing the kernel
to get out of sync with drakx.
In order to do so, the libparted bindings are enhanced so that we
manipulate a 'ped_disk' object:
- disk_open() returns such an object
- set_disk_type() is removed
- disk_commit() writes back the partition table and tell the kernel
about it
if we fails to write the partition table, we let
partition_table::write() fire an exceptionc
if we only have succeed in writing the partition table, we let
partition_table::write() try harder (umounting partitions before
trying againt to tell the kernel again)
- need_to_tell_kernel() is overrided
The last change is needed because we now tell the kernel about the new
partition layout in partition_table::gpt::write() when calling
disk_commit() while previously we were deferring that to
partition_table::write() which after having called the gpt's write()
calls tell_kernel() -> c::tell_kernel_to_reread_partition_table()
So we must tell partition_table::write() that telling the kernel to
reread the partition_table is not needed if we already succeeded in
that.
|
| |
|
| |
|
|
|
|
|
|
| |
Now we force the kernel to reread the partition table when we initialise
it, there's no need to also inform it that we've deleted all the existing
partitions.
|
|
|
|
|
|
|
|
| |
When performing an automatic install that uses the clear or clearall
option, we don't read the current partition table, so the current
partition table type was not getting recorded in $hd->{pt_table_type}.
This information is needed to determine whether a BIOS boot partition
is required.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 532fd1d60df306e204bae79c5158ca2302739966, which
introduced a new bug when clearing GPT partitions in an interactive
session (mga#20264), and replaces it with a new solution.
When a partition table is initialised, we now add an 'init' action to
the $hd->{will_tell_kernel} list. This is used both by gpt::write()
(to clear the partition table) and by partition_table::tell_kernel()
(to force the kernel to reread the partition table). Previous changes
stored in $hd->{will_tell_kernel} are discarded, as they are no longer
of interest.
This also removes support for the will_tell_kernel 'force_reboot'
action, as nothing uses that any more.
|
| |
|
| |
|
| |
|