I’ve made another try
The order below make the system running.
root=LABEL=rootfs rootflags=rw tsc=reliable no_timer_check= rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp= reboot=k console=hvc0 console=hvc1 cryptomgr.notests= net.ifnames=0 pci=lastbus=0
This order of flag makes the system not running
tsc=reliable no_timer_check= rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp= reboot=k console=hvc0 console=hvc1 cryptomgr.notests= net.ifnames=0 pci=lastbus=0 root=LABEL=rootfs rootflags=rw
Problem is that I can’t even see the output. I do not have anything as output in the socket of the chardev
-device virtio-serial-pci,disable-modern=false,id=serial0,romfile= -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=console.sock,server,nowait
Can really be a problem of length? On 14 October 2020 at 21:54:03, Salvatore Mazzarino (apocalipse89@gmail.com) wrote:
It makes sense but I do not find correspondence.
Am I missing anything?
On 14 October 2020 at 21:32:30, Jakob Bohm (jb-gnumlists@wisemo.com) wrote:
On 2020-10-14 20:39, Salvatore
Mazzarino wrote:
I'm facing some interesting issues.
Changing the order of kernel parameters passed to the `-append`,
it changes the outcome.
Running my QEMU VM with the
following works:
-append
"root=/dev/disk/by-id/virtio-rootfs rootflags=rw
flatcar.first_boot=1 tsc=reliable no_timer_check=
rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1
i8042.nopnp=1 i8042.noaux=1 noreplace-smp= reboot=k
console=hvc0 console=hvc1 cryptomgr.notests= net.ifnames=0
pci=lastbus=0"
However, if put the `root=` to
the end then it does not work and the root volume is not found
so not mounted.
So I'm now wondering. the order
does it really matter? And if so there is any logic behind it?
Any rules to follow?
This happens generally with the Linux kernel, probably because
the mechanism for
passing the options to the kernel has a character limit,
causing the last of your
long line to be thrown away.
I suggest looking at the kernel documentation to see if there is a
limit and then
check if you exceed it.
As for qemu, I suspect that qemu uses a generic method of passing
the string into
the VM, which has a much higher limit to support non-Linux
kernels.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded