Bug#992034: installation-guide: Include a note on how to change init system during install
Hi, Could someone merge https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15 please? It's the smaller change that folk asked for :) Thanks, Matthew
Bug#988776: Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On 8/24/2021 7:12 PM, Ben Hutchings wrote: The current limit on the environment of a uevent appears to be 2 KB (UEVENT_BUFFER_SIZE defined in ). That seems like it *might* be easier to change, so long as user-space doesn't have a similar limit. I looked into systemd/udev, and it seems to use an 8 KB buffer for receiving uevents: https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 But as a first step I think increasing the kernel buffer size to 4 KB would be enough. Perhaps someone could test whether this patch to the domU kernel makes udev happier: --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -30,7 +30,7 @@ #define UEVENT_HELPER_PATH_LEN 256 #define UEVENT_NUM_ENVP 64 /* number of env pointers */ -#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */ +#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */ #ifdef CONFIG_UEVENT_HELPER /* path to the userspace helper executed on an event */ --- END --- ? Ben. I tested this patch on my Xen HVM bullseye system and it appears 4k is enough for the UEVENT_BUFFER_SIZE to accommodate the Xen Virtual Keyboard's large modalias. I needed to follow the instructions in the Kernel team's handbook for changing the ABI name of the kernel for the build to succeed with the patch. I just bumped it from 8 to 8.1. Results: 1. No coldplug failure reported at boot time. 2. With the patch the system can write uevent data to sysfs for the Xen Virtual Keyboard device. With the current 5.10.0-8 kernel: chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent chuckz@debian:~$ With the patched kernel with a change to the ABI version from 8 to 8.1: chuckz@debian:~$ uname -r 5.10.0-8.1-amd64 chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent PRODUCT=1/5853//0 NAME="Xen Virtual Keyboard" PHYS="xenbus/device/vkbd/0" PROP=0 EV=3 KEY=7fff ... MODALIAS=input:b0001v5853pe-e0,1,k71,72... really long MODALIAS --- So I think a test of the installation media in a Xen HVM with the 4k buffer in the kernel is the next step. I would also like to test a live CD in a Xen HVM with this patch. It was also reported to fail to boot in a Xen HVM on the debian-user list. BTW, my complements to the Debian Kernel Team for the excellent handbook on building kernels for Debian. It is easy to understand and made it very easy for me to build and test the patch even though I have not built a Linux kernel in many years, and I never built a Debian kernel before. All the best, Chuck
Bug#988776: Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On 8/26/2021 8:01 AM, Chuck Zmudzinski wrote: On 8/24/2021 7:12 PM, Ben Hutchings wrote: The current limit on the environment of a uevent appears to be 2 KB (UEVENT_BUFFER_SIZE defined in ).� That seems like it *might* be easier to change, so long as user-space doesn't have a similar limit. I looked into systemd/udev, and it seems to use an 8 KB buffer for receiving uevents: https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 But as a first step I think increasing the kernel buffer size to 4 KB would be enough.� Perhaps someone could test whether this patch to the domU kernel makes udev happier: --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -30,7 +30,7 @@ � � #define UEVENT_HELPER_PATH_LEN������� 256 � #define UEVENT_NUM_ENVP����������� 64��� /* number of env pointers */ -#define UEVENT_BUFFER_SIZE������� 2048��� /* buffer for the variables */ +#define UEVENT_BUFFER_SIZE������� 4096��� /* buffer for the variables */ � � #ifdef CONFIG_UEVENT_HELPER � /* path to the userspace helper executed on an event */ --- END --- ? Ben. I tested this patch on my Xen HVM bullseye system and it appears 4k is enough for the UEVENT_BUFFER_SIZE to accommodate the Xen Virtual Keyboard's large modalias. I needed to follow the instructions in the Kernel team's handbook for changing the ABI name of the kernel for the build to succeed with the patch. I just bumped it from 8 to 8.1. Results: 1. No coldplug failure reported at boot time. 2. With the patch the system can write uevent data to sysfs for the Xen Virtual Keyboard device. With the current 5.10.0-8 kernel: chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent chuckz@debian:~$ With the patched kernel with a change to the ABI version from 8 to 8.1: chuckz@debian:~$ uname -r 5.10.0-8.1-amd64 chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent PRODUCT=1/5853//0 NAME="Xen Virtual Keyboard" PHYS="xenbus/device/vkbd/0" PROP=0 EV=3 KEY=7fff ... MODALIAS=input:b0001v5853pe-e0,1,k71,72... really long MODALIAS --- So I think a test of the installation media in a Xen HVM with the 4k buffer in the kernel is the next step. I would also like to test a live CD in a Xen HVM with this patch. It was also reported to fail to boot in a Xen HVM on the debian-user list. BTW, my complements to the Debian Kernel Team for the excellent handbook on building kernels for Debian. It is easy to understand and made it very easy for me to build and test the patch even though I have not built a Linux kernel in many years, and I never built a Debian kernel before. All the best, Chuck Results of more tests with the patched kernel: 1. Boot on dom0 - works normally, can create VMs, run Liinux container, etc. 2. Boot in Xen PV - works normally 3. Boot on bare hardware - works normally I do not see any issues with the patched kernel on my system. Cheers, Chuck
Bug#992034: installation-guide: Include a note on how to change init system during install
On Thu, 26 Aug 2021 22:45:17 +0200 Holger Wansing wrote: > I wonder if "the easiest time to select an alternative init system is > during the installation process" is correct English. > > Maybe better "the best time ... " ? Much better, although both are literally true. From an native American speaker. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Bug#992034: installation-guide: Include a note on how to change init system during install
Hi, Am 26. August 2021 09:24:58 MESZ schrieb Matthew Vernon : >Hi, > >Could someone merge >https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15 >please? > >It's the smaller change that folk asked for :) I wonder if "the easiest time to select an alternative init system is during the installation process" is correct English. Maybe better "the best time ... " ? Asking debian-l10n-english for advise. @debian-l10n-english: Hi all, could someone please comment on the merge request mentioned above? Thanks Holger -- Sent from /e/ OS on Fairphone3
Bug#992034: installation-guide: Include a note on how to change init system during install
Holger Wansing wrote: > I wonder if "the easiest time to select an alternative init system is during > the > installation process" is correct English. > > Maybe better "the best time ... " ? > > Asking debian-l10n-english for advise. > > @debian-l10n-english: > Hi all, could someone please comment on the merge request > mentioned above? There's nothing wrong with the English of "the easiest time to do X is during Y"; "best" is also okay but asserts something different (which is slightly more a matter of subjective opinion). -- JBR (still away from my normal keyboard) Ankh kak! (Ancient Egyptian blessing)
