4 ms·

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 ch

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.

zaarn 5y ago
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.
- otterlicious 5y ago
  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 /`
  - zaarn 5y ago
    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.
- viseztrance 5y ago
  It tried when the mounting failed, saying it would drop me to a shell and then said "it fail to open up a shell".
  - zaarn 5y ago
    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).
ATsch 5y ago
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-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... elaborates on, which is independent of systemd
- viseztrance 5y ago
  Thanks for sharing this.
ajross 5y ago
> 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.
- viseztrance 5y ago
  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.

zaarn 5y ago

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.

otterlicious 5y ago
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 /`
- zaarn 5y ago
  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.
viseztrance 5y ago
It tried when the mounting failed, saying it would drop me to a shell and then said "it fail to open up a shell".
- zaarn 5y ago
  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).

ATsch 5y ago

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-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... elaborates on, which is independent of systemd

viseztrance 5y ago
Thanks for sharing this.

ajross 5y ago

> 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.

viseztrance 5y ago
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.