Hacker News Reader

Comment by viseztrance | Hacker News Reader

I ignored systemd because I thought it didn't affect me, as I only run linux (fedora) on my desktop, and hardly had any issues at that.

But recently, when I changed my fstab file to mount a drive at boot, I made a typo. My system wouldn't boot at all and it wouldn't even drop to a shell so I can chroot the file system like you would with init.d.

I thought that there's some arcane command I don't know about. But there wasn't. You're locked off, and expected to boot off something else to fix your system. Horrible.

Having this said, I honestly expected way more on the section about benefits to users.

View on HN

> But recently, when I changed my fstab file to mount a drive at boot, I made a typo. My system wouldn't boot at all

I don't know exactly what went wrong in your case, but killing Unix systems by messing with fstab has been a rite of passage for more than four decades. Systemd certainly didn't invent that. Hell, I broke a chromebook not 48 hours ago messing with the boot setup.

But FWIW: managing a recovery image is, amusingly, not historically a job systemd has tried to take on. This is what your live image is for.

I've been using linux on my desktop for almost 20 years. This was the first time I couldn't get a shell to fix my problem.

It sounds like what you ran into are the effects of the general trend of doing more in early boot, as https://freedesktop.org/wiki/Software/systemd/separate-usr-i... elaborates on, which is independent of systemd

Thanks for sharing this.

Atleast on Arch, Systemd should drop you into the Emergency shell if it cannot mount a device that isn't defined as optional. IIRC it might require a root password to be set, however.

Otherwise, edit the kernel commandline to add "systemd.unit=emergency.target" to the end, which triggers systemd to straight boot into this console without trying anything that it doesn't need to bring up the console.

Or if you're blocked by the root password prompt add `init=/bin/bash` and make your filesystem writable if necessary with `mount -oremount,rw /`

This will block systemd however. The nice thing about the emergency shell is that you can use systemd things like trying to mount filesystems. And you can later isolate multi-user to continue the boot when you finished your fix. /bin/bash would be atleast useful to try to get a root password set.

It tried when the mounting failed, saying it would drop me to a shell and then said "it fail to open up a shell".

That usually indicates something is very wrong and might need an init=/bin/bash instead, as a last resort, to find out why it couldn't open the shell (usually, because there is no root password or it couldn't find any shell binary to run).

Reply on news.ycombinator.com