-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sysinit.service does not start correctly #1199
Comments
@didacog Regarding the actual issue deleting the line StandartInput=tty or adding TTYPath=/dev/tty inside the sysinit.service works correctly According to As far as I see |
@jsmeix Maybe adding TTYPath=/dev/tty to the sysinit.service will keep backward compatibility and doesn't broke anything. If you are agree, we can send a pull request for it if needed. PD: for you to know of all DRLM team members for future issues and/or contributions to ReaR. Regards, |
I have been using PXE boot method during the last couple of months on a daily basis, and never had this issue. Strange. I'll test it out myself. |
Perhaps a stupid question (I am not at all a systemd expert): If |
@gdha I have now tried in Centos7 VM and works fine for me. I write my steps below versions info.
RESCUE localhost:~ # /usr/sbin/rear -V
RESCUE localhost:~ # cat /etc/rear/os.conf Step by step solution: RESCUE localhost:~ # systemctl start sysinit.service RESCUE localhost:~ # vi /usr/lib/systemd/system/sysinit.service
RESCUE localhost:~ # systemctl daemon-reload |
Could be VBox or maybe something working different with our GRUB2 based NetBoot. We will do more tests to find the root cause, that seems has different results depending on the environment. At least now we know that is working for you and maybe is something in our env that is causing this issue with tty stdin. :) |
@gdha we've tested different things and seems that is VBox and nothing about our GRUB2 netboot. We'll wait for your tests on VBox to confirm this. |
@proura See "systemctl status sysinit.service" and "journalctl -xe" for details. ? We need the reason why sysinit.service fails. Only a blind shot in the dark: [Unit] Description=Simple interactive dialog window After=getty@tty2.service [Service] Type=oneshot ExecStart=/usr/bin/dialog-hello.sh StandardInput=tty TTYPath=/dev/tty2 TTYReset=yes TTYVHangup=yes [Install] WantedBy=default.target therein I noted the "After=getty@tty2.service" In particular because since udev one can no longer rely on |
@jsmeix I will take a look arround you guess, the outputs of systemctl status sysinit.service and journalctl -xn are the next ones: RESCUE rear-deb8:~ # systemctl status sysinit.service RESCUE rear-deb8:~ # journalctl -xn @gdha @didacog I have tried to run the same example in KVM and it works perfectly, so the problem is something related to VirtualBox environment. |
Sorry @jsmeix, before I have attached the journalctl -xn output, there is the journalctl -xe:
|
@proura are you using VirtualBox in combination with vagrant? I've noticed the weirdest things may happen |
@gdha no, not in this case. |
I have found something new about what happens. If the option StandardInput is set to "tty" and there are not specified the TTYPath it defaults to /dev/console. /dev/console and /dev/tty0 should be the same so if I do "echo hello > /dev/console" it will show "hello" into my actual console, as same as "echo hello > /dev/tty0" But what happens if i try to do this in rescue mode in to my VirtualBox VM that has not serial ports activate?
Because of this error the sysinit.service does not start. Without serial ports in rescue mode the /dev/console is not the same as /dev/tty0. I have enabled one serial port on my VM VirtualBox Settings and all runs Ok! Then I come to my KVM VM, that works perfectly, and I deleted the serial port that is enabled by default and I get the same error. ( @gdha can you try booting from PXE in a VM without serial ports, maybe you will reproduce the error ) So something wrong happens if a serial-less machine is trying to get into rescue mode. |
@proura in KVM I deleted the Serial Port (in my recover vm), and the recover worked fine. I interrupted the automatic boot and could still write to /dev/console, /dev/tty0 and /dev/tty1. Reboot was also ok. |
Only FYI in general regarding serial ports see the Perhaps when there is no serial port one must explicitly |
@proura found the problem, I'd mistakenly hardcoded the kernel options in our PXE file when I pushed this part of code for DRLM 2.0 release. Well, I think that this issue can be closed and should never had been opened if I'd reviewed my code at time of preparing the DRLM 2.0 release. I'm sorry for all of you for the waste of your time on this... :-( Regards, |
@didacog |
Relax-and-Recover (rear) Issue Template
Please fill in the following items before submitting a new issue (quick response is not guaranteed with free support):
rear version (/usr/sbin/rear -V):
Test1: Relax-and-Recover 2.00 / Git
OS version (cat /etc/rear/os.conf or lsb_release -a):
Test1:
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.7 (jessie)
Release: 8.7
Codename: jessie
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
DRLM_MANAGED=y
--------DRLM rear-deb0.cfg file--------
CLI_NAME=rear-deb8
SRV_NET_IP=192.168.1.34
OUTPUT=PXE
OUTPUT_PREFIX=$OUTPUT
OUTPUT_PREFIX_PXE=rear-deb8/$OUTPUT
OUTPUT_URL=nfs://192.168.1.34/var/lib/drlm/store/rear-deb8
BACKUP=NETFS
NETFS_PREFIX=BKP
BACKUP_URL=nfs://192.168.1.34/var/lib/drlm/store/rear-deb8
SSH_ROOT_PASSWORD=drlm
USE_DHCLIENT=y
Are you using legacy BIOS or UEFI boot?
BIOS - VirtualBox Network boot PXE
Brief description of the issue:
After boot from network and do the root login the system doesn't have the correct keyboard layout, doesn't get automatically the ip with dhclient and other failures.
Also tryed with Centos7 and ReaR 1.17.2 and happens the same error.
Work-around, if any:
I have found and error when sysinit.service is starting , but deleting the line StandartInput=tty or adding TTYPath=/dev/tty inside the sysinit.service works correctly in boths testings.
The text was updated successfully, but these errors were encountered: