On 08/11/2024 15.37, Thomas Huth wrote:
...
And in case you're interested (it's maybe not so important since it's rather
unlikely that the users will do this), there is another issue when trying to
boot from multiple network devices where the first one has a DHCP server but
no bootfile:
qemu-
On 07/11/2024 21.42, Jared Rossi wrote:
On 11/6/24 6:10 AM, Thomas Huth wrote:
On 05/11/2024 17.42, Jared Rossi wrote:
Hi Thomas, Sebastian,
It looks like this is simply caused by the "is_cdrom" value only ever
being set
to true. I think it is a one-line fix that just makes sure to initial
On 11/6/24 6:10 AM, Thomas Huth wrote:
On 05/11/2024 17.42, Jared Rossi wrote:
Hi Thomas, Sebastian,
It looks like this is simply caused by the "is_cdrom" value only ever
being set
to true. I think it is a one-line fix that just makes sure to
initialize the
value to false each time we tr
On 05/11/2024 17.42, Jared Rossi wrote:
Hi Thomas, Sebastian,
It looks like this is simply caused by the "is_cdrom" value only ever being set
to true. I think it is a one-line fix that just makes sure to initialize the
value to false each time we try a new device:
diff --git a/pc-bios/s390-ccw
Hi Thomas, Sebastian,
It looks like this is simply caused by the "is_cdrom" value only ever
being set
to true. I think it is a one-line fix that just makes sure to
initialize the
value to false each time we try a new device:
diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
inde
On 20/10/2024 03.29, jro...@linux.ibm.com wrote:
From: Jared Rossi
changes v4 -> v5:
- Fix a bug with per-deice loadparm support:
The machine loadparm is no longer overwritten by device values, which now
allows an empty machine loadparm to propagate to later devices even if
the p
From: Jared Rossi
changes v4 -> v5:
- Fix a bug with per-deice loadparm support:
The machine loadparm is no longer overwritten by device values, which now
allows an empty machine loadparm to propagate to later devices even if
the primary boot device set an initial loadparm
- Fix two i
