search for: guestfs_list_dm_devices

...Reads and writes to this block device are decrypted from and -encrypted to the underlying C<device> respectively. - -If this block device contains LVM volume groups, then -calling C<guestfs_lvm_scan> with the C<activate> -parameter C<true> will make them visible. - -Use C<guestfs_list_dm_devices> to list all device mapper -devices." }; - - { defaults with - name = "luks_open_ro"; added = (1, 5, 1); - style = RErr, [String (Device, "device"); String (Key, "key"); String (PlainString, "mapname")], []; - optional = Some "luks&quot...

...Reads and writes to this block device are decrypted from and -encrypted to the underlying C<device> respectively. - -If this block device contains LVM volume groups, then -calling C<guestfs_lvm_scan> with the C<activate> -parameter C<true> will make them visible. - -Use C<guestfs_list_dm_devices> to list all device mapper -devices." }; - - { defaults with - name = "luks_open_ro"; added = (1, 5, 1); - style = RErr, [String (Device, "device"); String (Key, "key"); String (PlainString, "mapname")], []; - optional = Some "luks&quot...

..." device mapper device (eg. /dev/mapper/lukstest). Previously there has been no way through the API to list such devices after they have been created. Also they are not revealed when you tab-complete /dev paths in guestfish. These two patches fix this. The first patch adds a new API called guestfs_list_dm_devices which lists all device mapper devices that are not associated with LVs. We don't want to return LVs here because we prefer to use the "/dev/VG/LV" notation for these throughout the rest of the API. The second patch extends guestfish so that tab completion includes /dev/mapper paths....

--- fish/destpaths.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-MD-devices-to-guestfish-device-autocompletion.patch Type: text/x-patch Size: 400 bytes Desc: not available URL: <http://listman.redhat.com/archives/libguestfs/attachments/20111121/b667596b/attachment.bin>

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

...t; respectively. If this block device contains LVM volume groups, then -calling C<guestfs_vgscan> followed by C<guestfs_vg_activate_all> -will make them visible. +calling C<guestfs_lvm_scan> with the C<activate> +parameter C<true> will make them visible. Use C<guestfs_list_dm_devices> to list all device mapper devices." }; @@ -9718,4 +9706,26 @@ before the partition." }; This expands a f2fs filesystem to match the size of the underlying device." }; + { defaults with + name = "lvm_scan"; added = (1, 39, 8); + style = RErr, [Bool "acti...

Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the

These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.

v2: - Changes as suggested by Pino in previous review.

[This email is either empty or too large to be displayed at this time]

Split up the huge generator/actions.ml into several smaller files. Rich.