Throwing this out there for discussion ... and hopefully a place of knowledge in case it happens to someone else
I did an update yesterday to the www/v-ger server that is home to secondary apps that supports VSIDO. The update was to bring it to the 3.13 kernel and systemd and was done the same as I have done several other machines, nothing out of the ordinary debian apt-get install blah blah blah...
All went well until I rebooted to just a login screen... No X, just tty
I wanted to first eliminate a delay on the boot and knew the issue was a faulty swap setting in fstab and off to nano I went...
The first sign of 'dafuq is this? ' was trying to save fstab and being told that the file system was read only.. WELL NO SHIT!... I was su so whats the fucking problem? ... checking around, I confirmed on everything I tried, the system was locked down.. I searched and found several things that could cause this and even ran a few things (remount of / and fsck) but nothing worked...
I went back to fstab on a hunch and found the issue.... There was no statement there for / at all! This line had been totally removed:
/dev/sdb4 / ext4 relatime,errors=remount-ro 0 1
I put that back and the system booted to X immediately...
Looking back on the past couple of weeks, both jedi and I had similar issues where we did new updates and was faced with no X and just a login. We both attacked it as a X / nouveau / nVidia issue on the update and nothing really solved my issues... I just got 'lucky' and fixed it with the right settings of xorg.conf.
Now I am not so sure it had anything to do with luck or timing at all and that it may have been a systemd cycle (process) that was not completed and eventually did. The only variable to all of the issues I have seen was adding systemd to a setup and then been met with no X and a login only. Did Jedi and I both misdiagnose that these were X issues and not access issues?
Open for debate and discussion...
That's good idea.
Thanks, VastOne. No issues with my last updates two days ago. Going to update right now and report back.
Update: All good in three different installs.
Quoteit may have been a systemd cycle (process) that was not completed and eventually did. The only variable to all of the issues I have seen was adding systemd to a setup and then been met with no X and a login only.
Would systemd alter fstab and xorg.conf by itself? If yes, it's becoming really invasive.
I do not think systemd did / would / could alter fstab
I do think mistakes in code can be found all through this great world of FOSS.. some never reported and quietly fixed and a process that is no different than how any project is run
(It would seem we let a bot open a can of worms more than a year old)