Prior to this patch, the pre-GRUB Solaris x86 bootloader would fail to
load on QEMU with the following screen output:
SunOS Secondary Boot version 3.00
prom_panic: Could not mount filesystem.
Entering boot debugger:
[136419]: _
This occurs because the bootloader issues an ATA IDENTIFY DEVICE
com
and here is the journalctl extract (one hair shorter) of the system started
again with the debug kernel parameter and the script called manually :
00:00:09 kernel: usb 2-3: new SuperSpeed Gen 1 USB device number 4 using
xhci_hcd
00:00:09 systemd-udevd[216]: 2-3: Device is queued (SEQNUM=2255, ACTI
I activated auditd and asked it to monitor /var/lock/qemu-nbd-nbd0 and here
is the result :
audit[1754]: SYSCALL arch=c03e syscall=49 success=yes exit=0 a0=3
a1=7ffe6a0075f0 a2=6e a3=7ffe6a0075e0 items=2 ppid=1752 pid=1754
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
hi,
*as for my other thread posted yesterday (kernel: block nbd0: shutting down
sockets), I don't know if the problem is directly related to qemu-nbd but I
post on this one because it occurs during its use : thank you for
redirecting me if needed.*
my system is a Linux (5.10.83) with SystemD (249
hi,
after several checks, everything seems to be correctly configured...
could it be systemd (udev) that kills qemu-nbd after the script is finished
?
regards, lacsaP.
Le jeu. 19 mai 2022 à 17:09, Eric Blake a écrit :
> On Thu, May 19, 2022 at 04:40:27PM +0200, Pascal wrote:
> > hi,
> >
> > m
On 64-bit platforms, assigning SIZE_MAX to the int64_t max_pdiscard
results in a negative value, and the following assertion would trigger
down the line (it's not the same max_pdiscard, but computed from the
other one):
qemu-system-x86_64: ../block/io.c:3166: bdrv_co_pdiscard: Assertion
`max_pdisca
