systemd no longer starts; sysV still ok [Solved]

[j2mcgreg]

When was the WD HDD purchased? My research shows that the WD3200LPVX-75V0TT0 model came on the market in 2013 and any age over 7 years is archaic for an HDD.

https://www.donordrives.com/wd3200lpvx- ... drive.html

[Charlie Brown]

... also see post #6

... or if you like you can post:

Code: Select all

cat /etc/fstab

[quackser]

I did run @Charlie Brown 's reinstall command line. All that seemed to work fine.

I've attached a copy of /etc/fstab here

fstab.txt

I have been wondering whether nginx.service file might have a problem; not sure how to know about that.
There are at least 3 files with that name; one is zero length. I'm attaching 'ls -l' output for all 3 and also .txt copies ofthe 2 with content.

nginxsvc.txt

etc_nginx_svc.txt

usrlib_nginx_svc.txt

[quackser]

@j2mcgreg re: HDD, it came from a Dell laptop (replaced by SSD). FSCK says it's ok, and since sysV works with 2 kernels and the only known problem is with systemd startup, is the HDD actually a reasonable suspect?

[Charlie Brown]

... I have disabled both (I think)...

How did you do that?

Though you say you run fsck: Live session: GParted , right-click on MX partition(s) ( sdb1 , then sdb2 just while you're at it): "Check".

[j2mcgreg]

My concern would be that the code that initialises SystemD is on one or more bad blocks (which can't be reallocated because the reserve blocks have all been used due to the drives age or that weren't enough left in reserve to repair all the damage after your system lock up)). Bad blocks on the HDD would answer why SysV init still works but SystemD doesn't. My advice is to make a snapshot of your system now while you still can.

[dolphin_oracle]

and

Code: Select all

blkid

if you want to try it you can disable the nginx.service

Code: Select all

sudo systemctl disable nginx.service

should do it. that will work from your sysVinit boot too.

[quackser]

@Charlie Brown I used the same systemctl to disable/re-enable it before, trying systemd while it was disabled. I'll give it another try in case I didn't do it exactly right.

And for @j2mcgreg as well:

So far as the HDD is concerned: S.M.A.R.T. says it's ok. I'm currently running the "long" test beneath GSmartControl; maybe it'll show something.
I would have thought fsck would show up whatever errors.
And I can't find gparted on my system - I'm running KDE. I can install it, I suppose, but I don't know exactly what "Live Session" in your post means in terms of "what I need to do".

I have no pressing reason not to change out the HDD. I can get a 500GB SSD for almost nothing these days, and it'd run a LONG time for sure. I hate to start over on the system, but maybe the snapshot / Live USB i created a few days ago would put me back in business on the SSD?

[ADDENDA]
The extended offline test in GSmartControl passed without errors.

[j2mcgreg]

@quackser wrote:

I have no pressing reason not to change out the HDD. I can get a 500GB SSD for almost nothing these days, and it'd run a LONG time for sure. I hate to start over on the system, but maybe the snapshot / Live USB i created a few days ago would put me back in business on the SSD?

That's the idea, but how much time you have to spend configuring stuff at the other end will largely depend on how complete you made the snapshot.
If it was my system, I would replace the drive for two reasons:
-- it's age puts it on borrowed time, and
-- replacing it now will take far less time than doing a recovery from a dead drive

[Charlie Brown]

With "live session" I mean when booted with a live media (live usb etc.)

You can simply do this in a terminal (same command that GParted uses, but again, it needs to be a live session):

Code: Select all

sudo e2fsck -fyvC0 /dev/sdb1

Code: Select all

sudo e2fsck -fyvC0 /dev/sdb2

P.S. When on live session you can first check whether they are still sdb etc..

Code: Select all

lsblk -f

... If not, change the sdb1 etc. according to that, say sda1 ...