@manfred My fail… It is “-systemd-mark” not “–systemd-mark”
Ok fixed, can you try again please ?
About your first screenshot, the command you searched is /sbin/nbd-client, you have to put the full path
Narh, I just spelt it wrong.
It still didn’t work…
It seems like the root parameter is missing a “=”.
can you try to run the script again, when the initrd fallback to the debug console type this
$ set -x $ . /scripts/local-top/ocs-nbd
you should see a command like this
/sbin/nbd-client x.x.x.x yyyy /dev/nbd0 -persist -systemd-mark
then you can try to run the same command with different options (–systemd-mark, -systemd-mark, --help)
I tested that some hours ago, and i was able to mount it… Diffrent commands through… I will tests that commands in 30 min or so…
I can also debug it, but I need an image with systemd
We are working on this image, thanks to your comments
I hope to get it booting so I can debug with you the initrd part, if you need other changes in the initrd, ask us, and don’t hesitate to use the fallback console to try some commands and give me the working ones
It some sort of weird why it worked before you added “-systemd-mark”. Did you change anything else? And I still think the root argument in the kernel cmdline is missing a = …
I added the parameter in the cmdline and upgraded nbd-client to 3.8, nothing else
I will continue to work on my images and try to get the initrd fixed when I will have a systems-based image working
I just dont understand why it says “root/dev/nbd0” in /proc/cmdline, shouldn’t it be " root=/dev/nbd0"??
Cmdline without your initrd tweaks:
earlyprintk=ttyS0 nousb console=ttyS0,9600n8 noplymouth ip=dhcp root=/dev/nbd0 boot=local
Cmdline with your tweak:
earlyprintk=ttyS0 nousb console=ttyS0,9600n8 noplymouth ip=dhcp root/dev/nbd0 boot=local NBD_CLIENT_OPTS=-systemd-mark
There is something wrong with the root argument…
Nooooooooooo, sorry, I though you talked about the =-systemd-mark (so something like ==-systemd-mark).
You are completely right, and I just fixed my typo, you can restart again
It don’t kernal panic now… It just stuck in initramfs on /dev/nbd0 negation (after reboot) Can it be because the server still think it connected? That it won’t allow nbd-client to connect again?
Yes, it is certainly that, do you know if your client sent a disconnection request at the end of the halt process part of the reboot process ?
I’m not sure…
Can I download the initramfs somewhere? Want to try something like this with it… https://github.com/zfsonlinux/dracut/blob/master/modules.d/98systemd/dracut-shutdown.service.8.asc
Edit: Could you add the “-systemd-mark” to 11479084-bb14-4bae-ae8e-37790708f686 also?
Done, can you try again ?
Just tested if Fedora was different, it just stuck in the shutdown process…
The good news is that I successfully manually rebooted the ArchLinux server… Now I just need to make it work automatic…
Edit: Working without user input now… Now just need to figure the right way to do it, need to ask on ArchLinux irc…
I’m new here and I was after an Arch image myself. Currently we can’t still properly get Arch working?
The archlinux support is in progress, we successfully booted on archlinux, but the image is not ready for the community:
We just released the first version a the Arch Linux image
The image contains the standard Online-Labs image requirements (synchronise kernel modules, ssh keys, handle NBD volumes, set hostname, …).
As we are not Arch linux professionals, we need you to qualify this image. You can report bugs on the Github issues page:
https://github.com/online-labs/image-archlinux/issues, or on this community topic.
Known bug: We experienced a kernel panic during a reboot, probably due to the nbd service in the stop sequence order.
If you encounter this behaviour, just click on Hard reboot on the web console.
[OFFICIAL] New linux distributions (Debian, CoreOS, CentOS, Fedora, Arch Linux, ...)