similar to: [PATCH 0/2] Add /dev/mapper/* paths to guestfish tab completion.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506 This small set covers the new /dev/mapper/VG-LV "--key" ID format in the libguestfs LUKS-on-LVM inspection test. Thanks, Laszlo Laszlo Ersek (3): update common submodule LUKS-on-LVM inspection test: rename VGs and LVs LUKS-on-LVM inspection test: test /dev/mapper/VG-LV translation common

On Fri, May 19, 2023 at 04:08:49PM +0200, Laszlo Ersek wrote: > In the LUKS-on-LVM inspection test, call the "check_filesystems" function > yet another time, now with such "--key" options that exercise the recent > "/dev/mapper/VG-LV" -> "/dev/VG/LV" translation (unescaping) from > libguestfs-common. > > Bugzilla:

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506 This small set covers the new /dev/mapper/VG-LV "--key" ID format in the LUKS-on-LVM virt-inspector test. Thanks, Laszlo Laszlo Ersek (3): update common submodule inspector: rename VGs and LVs in LUKS-on-LVM test inspector: test /dev/mapper/VG-LV translation in LUKS-on-LVM test common

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

libguestfs is tools and a library for accessing and modifying virtual machine disk images. Home page: http://libguestfs.org/ Source: http://libguestfs.org/download/ I'm pleased to announce the latest stable release of libguestfs 1.6.0 which is available immediately from the website and through Fedora. This represents an enormous amount of work over the last 4-5 months and

On Tuesday 11 February 2014 20:16:56 Richard W.M. Jones wrote: > If calling guestfs_list_filesystems with a disk image containing a > corrupt btrfs volume, the library would segfault. There was a missing > check for a NULL return from guestfs_btrfs_subvolume_list. > > This adds a check, returning the real error up through the stack and > out of guestfs_list_filesystems. >

If calling guestfs_list_filesystems with a disk image containing a corrupt btrfs volume, the library would segfault. There was a missing check for a NULL return from guestfs_btrfs_subvolume_list. This adds a check, returning the real error up through the stack and out of guestfs_list_filesystems. This is potentially a denial of service if processing disk images from untrusted sources, but is

I'm sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab. I only found this with grep -i luks /var/log/anaconda/anaconda.*: /var/log/anaconda/anaconda.storage.log:20:47:55,959 DEBUG blivet: LUKS.__init__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: LUKS.__init__:

On Thu, Mar 5, 2015 at 10:25 PM, Tim <lists at kiuni.de> wrote: > Hi Chris, > > thanks for your answer. > > It is the first time I decided to encrypt my lvm. I choosed to encrypt the > volume group, not every logical volume itself, because in case of doing lvm > snapshots in that group they will be encrypted too? Yes, anything that's COW'd is also encrypted in

The development branch (1.5) contains some major performance improvements over the current stable branch (1.4). Furthermore nearly 3 months have passed since we branched 1.4, which is about the same time that separated 1.4 from 1.2. Thus I think around the first or second week of October we ought to start the new stable and development branches (1.6 and 1.7 resp.) At this time we should decide

On Mon, Jan 20, 2014 at 04:39:42PM +0100, Olaf Hering wrote: > > Is "luks-format" supposed to work with guestfish? Like guestfish <<EOF > luks-format /dev/sda4 0 > EOF > > Appearently it lacks an option to give the passphrase programmatically. > Was this option skipped on purpose? The underlying API takes a passphrase parameter, ie:

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

Is "luks-format" supposed to work with guestfish? Like guestfish <<EOF luks-format /dev/sda4 0 EOF Appearently it lacks an option to give the passphrase programmatically. Was this option skipped on purpose? Olaf

The old vgscan API literally ran vgscan. When we switched to using lvmetad (in commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this stopped working because lvmetad now ignores plain vgscan commands without the --cache option. We documented that vgscan would rescan PVs, VGs and LVs, but without activating them. I have introduced a new API (lvm_scan) which scans or rescans PVs, VGs and LVs. It

Cédric pointed out this problem we have: $ guestmount -a /var/lib/libvirt/images/sles12sp1-pv.img -m '/dev/sda1:/:subvol=.snapshots/2/snapshot:btrfs' /mnt libguestfs: error: mount_vfs: /dev/sda1 on / (options: 'subvol=.snapshots/2/snapshot'): mount: mount(2) failed: No such file or directory guestmount: '/dev/sda1' could not be mounted. guestmount: Check mount(8) man page

Hi, my test host is running Debian/GNU Linux unstable and has virt-manger 0.9.5 and libvirt 1.2.1. I am using encryption and thus have devices in /dev/mapper that are not LVs, for example called /dev/mapper/myvirtualdisk. I'd like to configure libvirt in a way that allows me to directly assign such devices to a VM. This does not work when I create a filesystem directory storage pool in

When checking for the existance of /dev/mapper devices found in the fstab of a filesystem, using guestfs_exists means they are checked as files in the guest, while they really appear as devices on the appliance. Resort using a debug API to check whether a file in the appliance exists, instead. Fixes commit 96b6504b09461aeb6850bb2e7b870a0a4c2f5edf. --- src/inspect-fs-unix.c | 15 ++++++++++++++-

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

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.