Re: SLES 15 disk mount is failing
by Richard W.M. Jones
On Mon, Feb 26, 2024 at 11:41:47AM +0000, Teja Konapalli wrote:
> [ 2024-02-27 03:52:37 ] errno: ( 0 ) : cannot find any suitable libguestfs
> supermin, fixed or old-style appliance on LIBGUESTFS_PATH (search path: /usr/
> lib64/guestfs)
It's a SUSE bug, I suppose. What is the complete output
of libguestfs-test-tool?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
2 months, 3 weeks
Re: SLES 15 disk mount is failing
by Teja Konapalli
++updated mailing address
Regards,
Teja K
From: Teja Konapalli
Sent: Monday, February 26, 2024 5:09 PM
To: Richard W.M. Jones <rjones(a)redhat.com>
Cc: libguestfs(a)redhat.com; Surendra CH <sch2(a)opentext.com>
Subject: SLES 15 disk mount is failing
Hi Richard,
I tried mounting disk using libguestfs with SLES machine getting below error message. Could you please help here .
Command used for Installation:
* zypper install guestfs-tools
* sudo zypper in libguestfs-devel
GuestFS version:
guestfish --version
guestfish 1.48.4
[ 2024-02-27 03:52:37 ] errno: ( 0 ) : cannot find any suitable libguestfs supermin, fixed or old-style appliance on LIBGUESTFS_PATH (search path: /usr/lib64/guestfs)
Note: Same disk am able to mount using RHEL machine.
Thanks in Advance.
2 months, 3 weeks
[nbdkit PATCH] docs: Add example of exporting a variable in --run
by Eric Blake
Rather than changing captive nbdkit to export variables by default
(where we don't know if it will break clients of --run to suddenly
have more things in their environment variables), it is less invasive
to just call attention in our documentation that a run script that
relies on the environment must manually export variables.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
docs/nbdkit-captive.pod | 7 ++++++-
docs/nbdkit-protocol.pod | 4 ++++
docs/nbdkit.pod | 2 ++
server/options.h | 1 +
tests/test-synopsis.sh | 1 +
5 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/docs/nbdkit-captive.pod b/docs/nbdkit-captive.pod
index 4f9740bc..94a9acb2 100644
--- a/docs/nbdkit-captive.pod
+++ b/docs/nbdkit-captive.pod
@@ -48,7 +48,12 @@ Running nbdkit captive under nbdsh for unit testing:
nbdkit memory 1 --run 'nbdsh -u "$uri" -c "print(h.pread(1, 0))"'
-The following shell variables are available in the I<--run> argument:
+Running an fio benchmark:
+
+ nbdkit -f null 1G --run 'export uri; fio fio.git/examples/nbd.fio'
+
+The following shell variables are available in the I<--run> argument
+(local to the run script unless you use C<export>):
=over 4
diff --git a/docs/nbdkit-protocol.pod b/docs/nbdkit-protocol.pod
index 620ea16e..537cc63a 100644
--- a/docs/nbdkit-protocol.pod
+++ b/docs/nbdkit-protocol.pod
@@ -38,6 +38,8 @@ parts of the NBD protocol, with successively larger impacts:
=over 4
+=item B<--no-mc>
+
=item B<--no-meta-contexts>
Force the newstyle protocol to treat all requests for meta context
@@ -51,6 +53,8 @@ emulating nbd-server 3.25.
=item B<--no-sr>
+=item B<--no-structured-replies>
+
Force the newstyle protocol to decline any client request for
structured replies; this is stronger than I<--no-meta-contexts> in
that it also disables the opportunity for sparse reads. This is
diff --git a/docs/nbdkit.pod b/docs/nbdkit.pod
index 4391fc7b..8e82b337 100644
--- a/docs/nbdkit.pod
+++ b/docs/nbdkit.pod
@@ -334,6 +334,8 @@ L<nbdkit-protocol(1)>.
=item B<--no-sr>
+=item B<--no-structured-replies>
+
Do not advertise structured replies. A client must request structured
replies to take advantage of block status and potential sparse reads;
however, as structured reads are not a mandatory part of the newstyle
diff --git a/server/options.h b/server/options.h
index 544f8335..7d0730ba 100644
--- a/server/options.h
+++ b/server/options.h
@@ -86,6 +86,7 @@ static const struct option long_options[] = {
{ "no-mc", no_argument, NULL, NO_MC_OPTION },
{ "no-meta-contexts", no_argument, NULL, NO_MC_OPTION },
{ "no-sr", no_argument, NULL, NO_SR_OPTION },
+ { "no-structured-replies", no_argument, NULL, NO_SR_OPTION },
{ "old-style", no_argument, NULL, 'o' },
{ "oldstyle", no_argument, NULL, 'o' },
{ "pid-file", required_argument, NULL, 'P' },
diff --git a/tests/test-synopsis.sh b/tests/test-synopsis.sh
index 59886847..f8d5bcc4 100755
--- a/tests/test-synopsis.sh
+++ b/tests/test-synopsis.sh
@@ -57,6 +57,7 @@ for i in $(nbdkit --long-options | $nocr); do
--ip-addr) ;; # alias of -i, --ipaddr
--new-style) ;; # alias of -n, --newstyle
--no-mc) ;; # alias of --no-meta-contexts
+ --no-sr) ;; # alias of --no-structured-replies
--old-style) ;; # alias of -o, --oldstyle
--pid-file) ;; # alias of -P, --pidfile
--read-only) ;; # alias of -r, --readonly
--
2.43.2
2 months, 3 weeks
[RFC PATCH] server: Advertise nicer size for NBD_OPT_INFO
by Eric Blake
NBD_OPT_GO either advertises the actual size (possibly with an
override from the command line or config file), the value OFFT_MAX (if
multitree or F_WAIT means computing a real size would take too long),
or the value UINT64_MAX (if size_autodetect fails, such as when fd is
non-seekable); the only time it ever advertises a size of 0 is when it
is serving a regular file that really is empty.
On the other hand, NBD_OPT_INFO had been blindly advertising 0 no
matter what. While we can't always compute a real size, we can do a
lot better by advertising the same sentinels as NBD_OPT_GO.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
Rich has already chimed in on my question about what size SHOULD
nbd-server report when NBD_OPT_GO wants to list an indeterminate size;
if we start changing the spec, then this may be incomplete or need
tweaking. Here, I only tackled the simple case of a single-file (or
block device) export; there are multifile cases where NBD_OPT_GO still
reports a more accurate number than this. There's also the question
of whether we want to address the information leak (right now, the
code can succeed on NBD_OPT_INFO even when it will later fail for
NBD_OPT_GO because the client is not authorized to used the export).
nbd-server.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/nbd-server.c b/nbd-server.c
index 875c16f..f1a0d2f 100644
--- a/nbd-server.c
+++ b/nbd-server.c
@@ -2265,6 +2265,43 @@ static void setup_transactionlog(CLIENT *client) {
}
}
+/**
+ * Probe details on the chosen export
+ *
+ * When a client sends NBD_OPT_INFO, we try to determine the export size.
+ * This function could also verify whether the client is allowed access,
+ * but for now, we do not deem the information leak of NBD_OPT_INFO
+ * succeeding where NBD_OPT_GO would fail to be severe.
+ *
+ * @param client the CLIENT structure
+ * @param server the SERVER structure
+ * @return true if the client is allowed access to the export, false
+ * otherwise
+ */
+static bool probe_client(CLIENT* client, SERVER* server) {
+ int fd;
+ gchar* error_string;
+
+ client->exportsize = server->expected_size ?
+ server->expected_size : OFFT_MAX;
+ if(!(server->flags & (F_MULTIFILE | F_TREEFILES | F_TEMPORARY |
+ F_WAIT))) {
+ DEBUG( "Opening %s\n", server->exportname);
+ fd = open(server->exportname, O_RDONLY);
+ if(fd == -1) {
+ error_string=g_strdup_printf(
+ "Could not open exported file %s: %%m",
+ server->exportname);
+ err_nonfatal(error_string);
+ return server->expected_size > 0;
+ }
+ client->exportsize = size_autodetect(fd);
+ close(fd);
+ }
+ // Is it worth returning false if client is not authorized?
+ return true;
+}
+
/**
* Commit to exporting the chosen export
*
@@ -2612,6 +2649,13 @@ static bool handle_info(CLIENT* client, uint32_t opt, GArray* servers, uint32_t
send_reply(client, opt, NBD_REP_ERR_POLICY, -1, "Access denied by server configuration");
return false;
}
+ } else {
+ if(!probe_client(client, server)) {
+ consume(client, n_requests * sizeof(request), buf,
+ sizeof(buf));
+ send_reply(client, opt, NBD_REP_ERR_POLICY, -1, "Access denied by server configuration");
+ return false;
+ }
}
for(i=0; i<n_requests; i++) {
socket_read(client, &request, sizeof(request));
--
2.43.2
2 months, 3 weeks
