Before systemd I could boot using "1 ro" and do whatever I wanted with my root filesystem. Now with systemd I cannot boot into read only root filesystem no matter what I do. # init 1 doesn't work Adding "1 ro" to GRUB kernel boot parameters doesn't work either. I've tried googling and I found nothing relevant. What the hell? Yes, I want to run e2fsck on root FS but with _my_ options, not default options and the options I need are _not_ possible to specify using /etc/e2fsck.conf Please advise.
Well, the "ro" option just tell initrd to mount the root readonly. And to be honest, I am not convinced that this was working either in the past. In fedora 14, centos6 and older the / was remounted to be read-write from rc.sysinit, and that was run in runlevel 1 as well. But anyway. You should either use emergency target (set systemd.unit=emergency.target on kernel cmdline), or I would suggest doing that kind of thing from initramdisk (rd.break on kernel cmdline).
> In fedora 14, centos6 and older the / was remounted to be read-write from rc.sysinit, and that was run in runlevel 1 as well. I can boot my CentOS 6.7 in RO mode just fine by specifying "1 ro" in GRUB kernel parameters. > But anyway. You should either use emergency target (set systemd.unit=emergency.target on kernel cmdline) Doesn't work. Still boots into RW mode. > I would suggest doing that kind of thing from initramdisk (rd.break on kernel cmdline). Please expand on that. Also, that's all besides the point. I request systemd to honor the RO kernel boot parameter because what you're saying basically means that systemd ignores it altogether.
Yes, "ro" just determines what the kernel/initramfs do. In the past almost all systems were booted with "ro" to allow the initramfs to perform file system checks, which couldn't be done on file systems mounted rw, and then the file system was remounted rw. There are other mechanisms to keep the root file system ro, but this isn't it.
I politely request a kernel boot option which makes it possible.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Please use rd.break=pre-mount to break before the root file system is mounted and perform any checks there.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #6) This could work, thanks, however this piece of information is almost impossible to find :( unless someone stumbles upon this bug report.