Re: [Libguestfs] [PATCH v7 01/12] nbd/server: Support a request payload

2023-09-30 Thread Vladimir Sementsov-Ogievskiy 

On 25.09.23 22:22, Eric Blake wrote:

Upcoming additions to support NBD 64-bit effect lengths allow for the
possibility to distinguish between payload length (capped at 32M) and
effect length (64 bits, although we generally assume 63 bits because
of off_t limitations).  Without that extension, only the NBD_CMD_WRITE
request has a payload; but with the extension, it makes sense to allow
at least NBD_CMD_BLOCK_STATUS to have both a payload and effect length
in a future patch (where the payload is a limited-size struct that in
turn gives the real effect length as well as a subset of known ids for
which status is requested).  Other future NBD commands may also have a
request payload, so the 64-bit extension introduces a new
NBD_CMD_FLAG_PAYLOAD_LEN that distinguishes between whether the header
length is a payload length or an effect length, rather than
hard-coding the decision based on the command.

According to the spec, a client should never send a command with a
payload without the negotiation phase proving such extension is
available.  So in the unlikely event the bit is set or cleared
incorrectly, the client is already at fault; if the client then
provides the payload, we can gracefully consume it off the wire and
fail the command with NBD_EINVAL (subsequent checks for magic numbers
ensure we are still in sync), while if the client fails to send
payload we block waiting for it (basically deadlocking our connection
to the bad client, but not negatively impacting our ability to service
other clients, so not a security risk).  Note that we do not support
the payload version of BLOCK_STATUS yet.

Signed-off-by: Eric Blake 
---

v7: another try at better logic [Vladimir]

v5: retitled from v4 13/24, rewrite on top of previous patch's switch
statement [Vladimir]

v4: less indentation on several 'if's [Vladimir]
---
  nbd/server.c | 37 +
  nbd/trace-events |  1 +
  2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 7a6f95071f8..1eabcfc908d 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -2322,9 +2322,11 @@ static int coroutine_fn 
nbd_co_receive_request(NBDRequestData *req,
 Error **errp)
  {
  NBDClient *client = req->client;
+bool extended_with_payload;
  bool check_length = false;
  bool check_rofs = false;
  bool allocate_buffer = false;
+bool payload_okay = false;
  unsigned payload_len = 0;
  int valid_flags = NBD_CMD_FLAG_FUA;
  int ret;
@@ -2338,6 +2340,13 @@ static int coroutine_fn 
nbd_co_receive_request(NBDRequestData *req,

  trace_nbd_co_receive_request_decode_type(request->cookie, request->type,
   nbd_cmd_lookup(request->type));
+extended_with_payload = client->mode >= NBD_MODE_EXTENDED &&
+request->flags & NBD_CMD_FLAG_PAYLOAD_LEN;
+if (extended_with_payload) {
+payload_len = request->len;
+check_length = true;
+}
+
  switch (request->type) {
  case NBD_CMD_DISC:
  /* Special case: we're going to disconnect without a reply,
@@ -2354,6 +2363,15 @@ static int coroutine_fn 
nbd_co_receive_request(NBDRequestData *req,
  break;

  case NBD_CMD_WRITE:
+if (client->mode >= NBD_MODE_EXTENDED) {
+if (!extended_with_payload) {
+/* The client is noncompliant. Trace it, but proceed. */
+trace_nbd_co_receive_ext_payload_compliance(request->from,
+request->len);
+}
+valid_flags |= NBD_CMD_FLAG_PAYLOAD_LEN;
+}
+payload_okay = true;
  payload_len = request->len;
  check_length = true;
  allocate_buffer = true;
@@ -2395,6 +2413,14 @@ static int coroutine_fn 
nbd_co_receive_request(NBDRequestData *req,
 request->len, NBD_MAX_BUFFER_SIZE);
  return -EINVAL;
  }
+if (payload_len && !payload_okay) {
+/*
+ * For now, we don't support payloads on other commands; but
+ * we can keep the connection alive by ignoring the payload.
+ */
+assert(request->type != NBD_CMD_WRITE);
+request->len = 0;


So, for sure, after this we go to

if (requests->flags & ~valid_flags)... and return -EINVAL.

Why we need to set request->len to 0? Just to not return "operation past EOF" instead of 
"unsupported flags", if len is too big? Maybe, that worth a comment.

Anyway, I now see nothing wrong in it, so:
Reviewed-by: Vladimir Sementsov-Ogievskiy 


+}
  if (allocate_buffer) {
  /* READ, WRITE */
  req->data = blk_try_blockalign(client->exp->common.blk,
@@ -2405,10 +2431,13 @@ static int coroutine_fn 
nbd_co_receive_request(NBDRequestData *req,
  }
  }
  if (payload_len) {
-/* WRITE */
-assert(req->data);
-ret = nbd_read(client->ioc,

Re: [Libguestfs] [PATCH v7 12/12] nbd/server: Add FLAG_PAYLOAD support to CMD_BLOCK_STATUS

2023-09-30 Thread Vladimir Sementsov-Ogievskiy 

On 25.09.23 22:22, Eric Blake wrote:

Allow a client to request a subset of negotiated meta contexts.  For
example, a client may ask to use a single connection to learn about
both block status and dirty bitmaps, but where the dirty bitmap
queries only need to be performed on a subset of the disk; forcing the
server to compute that information on block status queries in the rest
of the disk is wasted effort (both at the server, and on the amount of
traffic sent over the wire to be parsed and ignored by the client).

Qemu as an NBD client never requests to use more than one meta
context, so it has no need to use block status payloads.  Testing this
instead requires support from libnbd, which CAN access multiple meta
contexts in parallel from a single NBD connection; an interop test
submitted to the libnbd project at the same time as this patch
demonstrates the feature working, as well as testing some corner cases
(for example, when the payload length is longer than the export
length), although other corner cases (like passing the same id
duplicated) requires a protocol fuzzer because libnbd is not wired up
to break the protocol that badly.

This also includes tweaks to 'qemu-nbd --list' to show when a server
is advertising the capability, and to the testsuite to reflect the
addition to that output.

Of note: qemu will always advertise the new feature bit during
NBD_OPT_INFO if extended headers have alreay been negotiated
(regardless of whether any NBD_OPT_SET_META_CONTEXT negotiation has
occurred); but for NBD_OPT_GO, qemu only advertises the feature if
block status is also enabled (that is, if the client does not
negotiate any contexts, then NBD_CMD_BLOCK_STATUS cannot be used, so
the feature is not advertised).

Signed-off-by: Eric Blake 
---



[..]



+/*
+ * nbd_co_block_status_payload_read
+ * Called when a client wants a subset of negotiated contexts via a
+ * BLOCK_STATUS payload.  Check the payload for valid length and
+ * contents.  On success, return 0 with request updated to effective
+ * length.  If request was invalid but all payload consumed, return 0
+ * with request->len and request->contexts->count set to 0 (which will
+ * trigger an appropriate NBD_EINVAL response later on).  Return
+ * negative errno if the payload was not fully consumed.
+ */
+static int
+nbd_co_block_status_payload_read(NBDClient *client, NBDRequest *request,
+ Error **errp)


[..]


+payload_len > (sizeof(NBDBlockStatusPayload) +
+   sizeof(id) * client->contexts.count)) {
+goto skip;
+}
+
+buf = g_malloc(payload_len);
+if (nbd_read(client->ioc, buf, payload_len,
+ "CMD_BLOCK_STATUS data", errp) < 0) {
+return -EIO;
+}
+trace_nbd_co_receive_request_payload_received(request->cookie,
+  payload_len);
+request->contexts->bitmaps = g_new0(bool, nr_bitmaps);
+count = (payload_len - sizeof(NBDBlockStatusPayload)) / sizeof(id);
+payload_len = 0;
+
+for (i = 0; i < count; i++) {
+id = ldl_be_p(buf + sizeof(NBDBlockStatusPayload) + sizeof(id) * i);
+if (id == NBD_META_ID_BASE_ALLOCATION) {
+if (request->contexts->base_allocation) {
+goto skip;
+}


should we also check that base_allocation is negotiated?


+request->contexts->base_allocation = true;
+} else if (id == NBD_META_ID_ALLOCATION_DEPTH) {
+if (request->contexts->allocation_depth) {
+goto skip;
+}


same here


+request->contexts->allocation_depth = true;
+} else {
+int idx = id - NBD_META_ID_DIRTY_BITMAP;
+


I think, we also should check that idx >=0 after this operation.


+if (idx > nr_bitmaps || request->contexts->bitmaps[idx]) {
+goto skip;
+}
+request->contexts->bitmaps[idx] = true;
+}
+}
+
+request->len = ldq_be_p(buf);
+request->contexts->count = count;
+return 0;
+
+ skip:
+trace_nbd_co_receive_block_status_payload_compliance(request->from,
+ request->len);
+request->len = request->contexts->count = 0;
+return nbd_drop(client->ioc, payload_len, errp);
+}
+


[..]


diff --git a/nbd/trace-events b/nbd/trace-events
index 8f4e20ee9f2..ac186c19ec0 100644
--- a/nbd/trace-events
+++ b/nbd/trace-events
@@ -70,6 +70,7 @@ nbd_co_send_chunk_read(uint64_t cookie, uint64_t offset, void 
*data, uint64_t si
  nbd_co_send_chunk_read_hole(uint64_t cookie, uint64_t offset, uint64_t size) "Send structured read 
hole reply: cookie = %" PRIu64 ", offset = %" PRIu64 ", len = %" PRIu64
  nbd_co_send_extents(uint64_t cookie, unsigned int extents, uint32_t id, uint64_t length, int last) 
"Send block status reply: cookie = %" PRIu64 ", extents = %u, context = %d (extents cover 
%" PRIu64 " bytes, last chunk = %d)"

Re: [Libguestfs] libguestfs kernel panic

2023-09-30 Thread Clark, Dennis 
Hi Richard,

Thank you !

I was not aware of 'supermin' before, but that definitely pointed me in the 
right direction ...

Looking at the supermin packages, I was running the latest package, from 
'ol8_appstream' repo ... not from the 'ol8_kvm_appstream' repo.

[root@ol-kvm-h01]# yum --showduplicates list supermin
Last metadata expiration check: 1:45:46 ago on Sat 30 Sep 2023 09:32:40 AM GMT.
Installed Packages
supermin.x86_64  
5.2.1-2.module+el8.8.0+20990+60c1530a 
@ol8_appstream
Available Packages
supermin.x86_64  
5.1.19-10.module+el8.5.0+20635+d56619be   
ol8_kvm_appstream
supermin.x86_64  
5.2.1-1.module+el8.6.0+20842+e9607200 
ol8_kvm_appstream
supermin.x86_64  
5.2.1-1.module+el8.7.0+20916+50473d5a 
ol8_kvm_appstream
supermin.x86_64  
5.2.1-1.module+el8.7.0+21035+a8208c98 
ol8_kvm_appstream

When trying to obtain the header file you requested, I ended up installing the 
supermin-devel package ... which warned me that it wanted to downgrade my 
existing supermin package - so I let it ...

[root@ol-kvm-h01 dennis]# yum install supermin-devel

 PackageArchitecture Version
  Repository   Size

Installing:
 supermin-devel x86_64   
5.2.1-1.module+el8.7.0+21035+a8208c98ol8_kvm_appstream  
  26 k
Installing dependencies:
 annobinx86_64   10.94-1.0.1.el8
  ol8_appstream   965 k
 dwzx86_64   0.12-10.el8
  ol8_appstream   109 k
 efi-srpm-macrosnoarch   3-3.0.1.el8
  ol8_appstream22 k
 gcc-plugin-annobin x86_64   8.5.0-18.0.5.el8   
  ol8_appstream44 k
 ghc-srpm-macrosnoarch   1.4.2-7.el8
  ol8_appstream   9.3 k
 go-srpm-macros noarch   2-17.el8   
  ol8_appstream13 k
 ocaml-srpm-macros  noarch   5-4.el8
  ol8_appstream   9.3 k
 openblas-srpm-macros   noarch   2-2.el8
  ol8_appstream   7.9 k
 patch  x86_64   2.7.6-11.el8   
  ol8_baseos_latest   139 k
 perl-srpm-macros   noarch   1-25.el8   
  ol8_appstream11 k
 python-rpm-macros  noarch   3-45.el8   
  ol8_appstream16 k
 python-srpm-macros noarch   3-45.el8   
  ol8_appstream16 k
 python3-rpm-macros noarch   3-45.el8   
  ol8_appstream15 k
 qt5-srpm-macrosnoarch   5.15.3-1.el8   
  ol8_appstream11 k
 redhat-rpm-config  noarch   131-1.0.1.el8  
  ol8_appstream91 k
 rpm-build  x86_64   4.14.3-26.el8  
  ol8_appstream   174 k
 rust-srpm-macros   noarch   5-2.el8
  ol8_appstream   9.2 k
 zstd   x86_64   1.4.5-6.el8
  ovirt-4.4-extra 617 k
Downgrading:
 supermin   x86_64   
5.2.1-1.module+el8.7.0+21035+a8208c98ol8_kvm_appstream  
 713 k

Transaction Summary

Re: [Libguestfs] libguestfs kernel panic

2023-09-30 Thread Richard W.M. Jones 
On Sat, Sep 30, 2023 at 10:42:55AM +, Clark, Dennis wrote:
> Ok, Looking at my original installation procedure, including the slight tweaks
> to get libvirt-7 loaded, and checking the current server … it appears the
> libvirt-7 packages mention the O/S version (eg el8.7), and there are packages
> for several versions, but not for el8.8 … and yet my server (after patching) 
> is
> now running OL 8.8 … is that the issue ?

No I don't think so.

The main thing is to try to find out which part of init.c
is crashing (and later, why).

> > [0.845792] traps: init[1] general protection fault ip:43faa8
> 
> > sp:7ffe9b9904b0 error:0 in init[40+a7000]

As I don't have OEL, could you try extracting the init binary.  It's
buried in the supermin executable, so it's best to get it from the
debug sources:

(1) debuginfo-install supermin

(2) rpm -ql supermin-debugsource | grep src/format-ext2-init-bin.h

(eg. it will print something like /src/format-ext2-init-bin.h )

(3) Attach the copy of /src/format-ext2-init-bin.h or send
it to me by email if it's too big for the list.  You might have
to compress it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] libguestfs kernel panic

2023-09-30 Thread Clark, Dennis 
Ok, Looking at my original installation procedure, including the slight tweaks 
to get libvirt-7 loaded, and checking the current server ... it appears the 
libvirt-7 packages mention the O/S version (eg el8.7), and there are packages 
for several versions, but not for el8.8 ... and yet my server (after patching) 
is now running OL 8.8 ... is that the issue ?

[root@ol-kvm-h01 tmp]# yum --showduplicates list libvirt
Installed Packages
libvirt.x86_64  7.10.0-2.module+el8.7.0+21035+a8208c98 
@ol8_kvm_appstream
Available Packages
libvirt.x86_64  7.10.0-2.module+el8.5.0+20635+d56619be 
ol8_kvm_appstream
libvirt.x86_64  7.10.0-2.module+el8.6.0+20842+e9607200 
ol8_kvm_appstream
libvirt.x86_64  7.10.0-2.module+el8.7.0+20916+50473d5a 
ol8_kvm_appstream
libvirt.x86_64  7.10.0-2.module+el8.7.0+21035+a8208c98 
ol8_kvm_appstream

Regards,
Dennis

From: Clark, Dennis
Sent: Saturday, 30 September 2023 11:37 PM
To: Richard W.M. Jones 
Cc: libguestfs@redhat.com
Subject: RE: [Libguestfs] libguestfs kernel panic


Yes, it is unmodified OL 8.8, and I have not (manually) compiled, or recompiled 
anything (including supermin or libguestfs)



[root@ol-kvm-h01 tmp]# cat /etc/*rele*

Oracle Linux Server release 8.8

NAME="Oracle Linux Server"

VERSION="8.8"

ID="ol"

ID_LIKE="fedora"

VARIANT="Server"

VARIANT_ID="server"

VERSION_ID="8.8"

PLATFORM_ID="platform:el8"

PRETTY_NAME="Oracle Linux Server 8.8"

ANSI_COLOR="0;31"

CPE_NAME="cpe:/o:oracle:linux:8:8:server"

HOME_URL="https://linux.oracle.com/;

BUG_REPORT_URL="https://github.com/oracle/oracle-linux;



ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"

ORACLE_BUGZILLA_PRODUCT_VERSION=8.8

ORACLE_SUPPORT_PRODUCT="Oracle Linux"

ORACLE_SUPPORT_PRODUCT_VERSION=8.8

Red Hat Enterprise Linux release 8.8 (Ootpa)

Oracle Linux Server release 8.8

cpe:/o:oracle:linux:8:8:server



[root@ol-kvm-h01 tmp]# uname -a

Linux ol-kvm-h01 5.15.0-105.125.6.2.2.el8uek.x86_64 #2 SMP Tue Sep 19 21:02:08 
PDT 2023 x86_64 x86_64 x86_64 GNU/Linux



FYI: The KVM Host was installed/configured using the below process (I mention 
this since I needed to perform some additional repo/module configuration in 
order to get libvirt-7 installed):

  # Install the Oracle Linux Virtualization Manager Release 4.4 package
  yum install oracle-ovirt-release-el8 -y
 Required oVirt 4.4 Yum Channels enabled.
 Installed: oracle-ovirt-release-el8.x86_64   1.0-1.0.3.el8
 Dependency Installed:  oracle-gluster-release-el8.x86_64 1.0-2.el8

  yum clean all; yum repolist

repo id
ol8_UEKR6
ol8_UEKR7
ol8_addons
ol8_appstream
ol8_baseos_latest
ol8_gluster_appstream
ol8_kvm_appstream
ovirt-4.4
ovirt-4.4-extra

  # Remove any unwanted repos
  dnf config-manager --disable "ol8_UEKR6"

  # Ensure libvirt-7 package is available
  #   Disable virt:ol and enable virt:kvm_utils2 (this will make the libvirt-7 
package available)
  #   Ref: 
https://docs.oracle.com/en/virtualization/oracle-linux-virtualization-manager/getstart/getstarted-manager-install.html#manager-prep-kvm
  if ! yum --showduplicates list libvirt | grep "libvirt.* 7"; then
dnf -y module disable virt:ol
dnf -y module enable  virt:kvm_utils2
yum --showduplicates list libvirt
  fi

  # Make sure all packages are up-to-date
  dnf update -y
  reboot

  # Open the Cockpit port
  firewall-cmd --zone=public --add-port=9090/tcp




Regards,

Dennis



-Original Message-
From: Richard W.M. Jones mailto:rjo...@redhat.com>>
Sent: Saturday, 30 September 2023 7:20 PM
To: Clark, Dennis mailto:dclar...@dxc.com>>
Cc: libguestfs@redhat.com
Subject: Re: [Libguestfs] libguestfs kernel panic



On Thu, Sep 28, 2023 at 12:30:28PM +, Clark, Dennis wrote:

> [root@ol-kvm-h01 work]# LIBGUESTFS_BACKEND=direct libguestfs-test-tool

...

> libguestfs: launch: version=1.44.0rhel=8,release=

> 5.0.1.module+el8.7.0+21035+a8208c98,libvirt

>

> \x1b[2J[0.00] Linux version 5.15.0-105.125.6.2.2.el8uek.x86_64 
> (mockbuild at host-100-100-224-56) (gcc (GCC) 11.2.1 20220127 (Red Hat 
> 11.2.1-9.1.0.6), GNU ld version 2.36.1-2.0.1.el8) #2 SMP Tue Sep 19 21:02:08 
> PDT 2023



^ Looks like OEL.



> [0.843934] Run /init as init process



^ This messsage come from the kernel.



> [0.845792] traps: init[1] general protection fault ip:43faa8

> sp:7ffe9b9904b0 error:0 in init[40+a7000]

>

> [0.849636] Kernel panic - not syncing: Attempted to kill init! exitcode=

> 0x000b



Then the supermin embedded init process appears to crash.  That's

somewhere probably very early on in this code:

Re: [Libguestfs] libguestfs kernel panic

2023-09-30 Thread Clark, Dennis 
Yes, it is unmodified OL 8.8, and I have not (manually) compiled, or recompiled 
anything (including supermin or libguestfs)



[root@ol-kvm-h01 tmp]# cat /etc/*rele*

Oracle Linux Server release 8.8

NAME="Oracle Linux Server"

VERSION="8.8"

ID="ol"

ID_LIKE="fedora"

VARIANT="Server"

VARIANT_ID="server"

VERSION_ID="8.8"

PLATFORM_ID="platform:el8"

PRETTY_NAME="Oracle Linux Server 8.8"

ANSI_COLOR="0;31"

CPE_NAME="cpe:/o:oracle:linux:8:8:server"

HOME_URL="https://linux.oracle.com/;

BUG_REPORT_URL="https://github.com/oracle/oracle-linux;



ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"

ORACLE_BUGZILLA_PRODUCT_VERSION=8.8

ORACLE_SUPPORT_PRODUCT="Oracle Linux"

ORACLE_SUPPORT_PRODUCT_VERSION=8.8

Red Hat Enterprise Linux release 8.8 (Ootpa)

Oracle Linux Server release 8.8

cpe:/o:oracle:linux:8:8:server



[root@ol-kvm-h01 tmp]# uname -a

Linux ol-kvm-h01 5.15.0-105.125.6.2.2.el8uek.x86_64 #2 SMP Tue Sep 19 21:02:08 
PDT 2023 x86_64 x86_64 x86_64 GNU/Linux



FYI: The KVM Host was installed/configured using the below process (I mention 
this since I needed to perform some additional repo/module configuration in 
order to get libvirt-7 installed):

  # Install the Oracle Linux Virtualization Manager Release 4.4 package
  yum install oracle-ovirt-release-el8 -y
 Required oVirt 4.4 Yum Channels enabled.
 Installed: oracle-ovirt-release-el8.x86_64   1.0-1.0.3.el8
 Dependency Installed:  oracle-gluster-release-el8.x86_64 1.0-2.el8

  yum clean all; yum repolist

repo id
ol8_UEKR6
ol8_UEKR7
ol8_addons
ol8_appstream
ol8_baseos_latest
ol8_gluster_appstream
ol8_kvm_appstream
ovirt-4.4
ovirt-4.4-extra

  # Remove any unwanted repos
  dnf config-manager --disable "ol8_UEKR6"

  # Ensure libvirt-7 package is available
  #   Disable virt:ol and enable virt:kvm_utils2 (this will make the libvirt-7 
package available)
  #   Ref: 
https://docs.oracle.com/en/virtualization/oracle-linux-virtualization-manager/getstart/getstarted-manager-install.html#manager-prep-kvm
  if ! yum --showduplicates list libvirt | grep "libvirt.* 7"; then
dnf -y module disable virt:ol
dnf -y module enable  virt:kvm_utils2
yum --showduplicates list libvirt
  fi

  # Make sure all packages are up-to-date
  dnf update -y
  reboot

  # Open the Cockpit port
  firewall-cmd --zone=public --add-port=9090/tcp





Regards,

Dennis



-Original Message-
From: Richard W.M. Jones 
Sent: Saturday, 30 September 2023 7:20 PM
To: Clark, Dennis 
Cc: libguestfs@redhat.com
Subject: Re: [Libguestfs] libguestfs kernel panic



On Thu, Sep 28, 2023 at 12:30:28PM +, Clark, Dennis wrote:

> [root@ol-kvm-h01 work]# LIBGUESTFS_BACKEND=direct libguestfs-test-tool

...

> libguestfs: launch: version=1.44.0rhel=8,release=

> 5.0.1.module+el8.7.0+21035+a8208c98,libvirt

>

> \x1b[2J[0.00] Linux version 5.15.0-105.125.6.2.2.el8uek.x86_64 
> (mockbuild at host-100-100-224-56) (gcc (GCC) 11.2.1 20220127 (Red Hat 
> 11.2.1-9.1.0.6), GNU ld version 2.36.1-2.0.1.el8) #2 SMP Tue Sep 19 21:02:08 
> PDT 2023



^ Looks like OEL.



> [0.843934] Run /init as init process



^ This messsage come from the kernel.



> [0.845792] traps: init[1] general protection fault ip:43faa8

> sp:7ffe9b9904b0 error:0 in init[40+a7000]

>

> [0.849636] Kernel panic - not syncing: Attempted to kill init! exitcode=

> 0x000b



Then the supermin embedded init process appears to crash.  That's

somewhere probably very early on in this code:



  
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibguestfs%2Fsupermin%2Fblob%2Fmaster%2Finit%2Finit.c=05%7C01%7Cdclark66%40dxc.com%7Cb14f2c9313694dcc237d08dbc17d42ea%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C638316515975840513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=j55BHS3h4R%2BdR2xifxQ3iPoq%2BKdMsxKBFRV1ufOqXFM%3D=0



Before I look further at this, is this unmodified OEL 8.7.0?

And you didn't recompile supermin or libguestfs?



Rich.



--

Richard Jones, Virtualization Group, Red Hat 
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.redhat.com%2F~rjones=05%7C01%7Cdclark66%40dxc.com%7Cb14f2c9313694dcc237d08dbc17d42ea%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C638316515975840513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=XSOVmF7WWu9AA0OGf0KHJuQ0i8WBQFeWlcM6BA1jkww%3D=0

Read my programming and virtualization blog:

Re: [Libguestfs] libguestfs kernel panic

2023-09-30 Thread Richard W.M. Jones 
On Thu, Sep 28, 2023 at 12:30:28PM +, Clark, Dennis wrote:
> [root@ol-kvm-h01 work]# LIBGUESTFS_BACKEND=direct libguestfs-test-tool
...
> libguestfs: launch: version=1.44.0rhel=8,release=
> 5.0.1.module+el8.7.0+21035+a8208c98,libvirt
> 
> \x1b[2J[0.00] Linux version 5.15.0-105.125.6.2.2.el8uek.x86_64 
> (mockbuild at host-100-100-224-56) (gcc (GCC) 11.2.1 20220127 (Red Hat 
> 11.2.1-9.1.0.6), GNU ld version 2.36.1-2.0.1.el8) #2 SMP Tue Sep 19 21:02:08 
> PDT 2023

^ Looks like OEL.

> [0.843934] Run /init as init process

^ This messsage come from the kernel.

> [0.845792] traps: init[1] general protection fault ip:43faa8
> sp:7ffe9b9904b0 error:0 in init[40+a7000]
> 
> [0.849636] Kernel panic - not syncing: Attempted to kill init! exitcode=
> 0x000b

Then the supermin embedded init process appears to crash.  That's
somewhere probably very early on in this code:

  https://github.com/libguestfs/supermin/blob/master/init/init.c

Before I look further at this, is this unmodified OEL 8.7.0?
And you didn't recompile supermin or libguestfs?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] libguestfs kernel panic

2023-09-30 Thread Clark, Dennis 
[root@ol-kvm-h01 work]# LIBGUESTFS_BACKEND=direct libguestfs-test-tool
 
 *IMPORTANT NOTICE
 *
 * When reporting bugs, include the COMPLETE, UNEDITED
 * output below in your bug report.
 *
 
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: trace: set_backend "direct"
libguestfs: trace: set_backend = 0
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
LIBGUESTFS_BACKEND=direct
LIBGUESTFS_TRACE=1
LIBGUESTFS_DEBUG=1
PATH=/usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
SELinux: Enforcing
libguestfs: trace: add_drive_scratch 104857600
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: disk_create "/tmp/libguestfsTuyhmZ/scratch1.img" "raw" 
104857600
libguestfs: trace: disk_create = 0
libguestfs: trace: add_drive "/tmp/libguestfsTuyhmZ/scratch1.img" "format:raw" 
"cachemode:unsafe"
libguestfs: trace: add_drive = 0
libguestfs: trace: add_drive_scratch = 0
libguestfs: trace: get_append
libguestfs: trace: get_append = "NULL"
guestfs_get_append: (null)
libguestfs: trace: get_autosync
libguestfs: trace: get_autosync = 1
guestfs_get_autosync: 1
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
guestfs_get_backend: direct
libguestfs: trace: get_backend_settings
libguestfs: trace: get_backend_settings = []
guestfs_get_backend_settings: []
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
guestfs_get_cachedir: /var/tmp
libguestfs: trace: get_hv
libguestfs: trace: get_hv = "/usr/libexec/qemu-kvm"
guestfs_get_hv: /usr/libexec/qemu-kvm
libguestfs: trace: get_memsize
libguestfs: trace: get_memsize = 1280
guestfs_get_memsize: 1280
libguestfs: trace: get_network
libguestfs: trace: get_network = 0
guestfs_get_network: 0
libguestfs: trace: get_path
libguestfs: trace: get_path = "/usr/lib64/guestfs"
guestfs_get_path: /usr/lib64/guestfs
libguestfs: trace: get_pgroup
libguestfs: trace: get_pgroup = 0
guestfs_get_pgroup: 0
libguestfs: trace: get_program
libguestfs: trace: get_program = "libguestfs-test-tool"
guestfs_get_program: libguestfs-test-tool
libguestfs: trace: get_recovery_proc
libguestfs: trace: get_recovery_proc = 1
guestfs_get_recovery_proc: 1
libguestfs: trace: get_smp
libguestfs: trace: get_smp = 1
guestfs_get_smp: 1
libguestfs: trace: get_sockdir
libguestfs: trace: get_sockdir = "/tmp"
guestfs_get_sockdir: /tmp
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
guestfs_get_tmpdir: /tmp
libguestfs: trace: get_trace
libguestfs: trace: get_trace = 1
guestfs_get_trace: 1
libguestfs: trace: get_verbose
libguestfs: trace: get_verbose = 1
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: trace: launch
libguestfs: trace: max_disks
libguestfs: trace: max_disks = 255
libguestfs: trace: version
libguestfs: trace: version = 
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: program=libguestfs-test-tool
libguestfs: launch: 
version=1.44.0rhel=8,release=5.0.1.module+el8.7.0+21035+a8208c98,libvirt
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfsTuyhmZ
libguestfs: launch: umask=0022
libguestfs: launch: euid=0
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: begin building supermin appliance
libguestfs: run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
supermin: version: 5.2.1
supermin: rpm: detected RPM version 4.14
supermin: rpm: detected RPM architecture x86_64
supermin: package handler: fedora/rpm
supermin: acquiring lock on /var/tmp/.guestfs-0/lock
supermin: if-newer: output does not need rebuilding
libguestfs: finished building supermin appliance
libguestfs: begin testing qemu features
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: checking for previously cached test results of 
/usr/libexec/qemu-kvm, in /var/tmp/.guestfs-0
libguestfs: loading previously cached test results
libguestfs: qemu version: 6.2
libguestfs: qemu mandatory locking: yes
libguestfs: qemu KVM: enabled
libguestfs: trace: get_backend_setting "force_tcg"
libguestfs: trace: get_backend_setting = NULL (error)