IRC channel logs

<solid_black>Debian question: I'm booting with "ro" on the gnumach command line, but I'm still finding the root ext2fs mounted with --writable when the system boots

<solid_black>the responsible file for remounting appears to be /etc/init.d/checkroot.sh, but I don't see where $rootmode is assigned from

<solid_black>this used to work, I believe?

<solid_black>'s' or '1' seem to have no effect either

<solid_black>is anything even reading the cmdline?

<youpi>see /lib/init/*

<solid_black>okay, so /lib/init/mount-functions.sh sets rootmode=rw, and tries to parse it from fstab

<solid_black>there are some bits where it tries to parse cmdline, but not anywhere that it would look for "ro" or "s" or "1"

<youpi>the initial state of the mount is parsed by ext2fs / libdiskfs itself iirc

<youpi>then the initscript runs fsck and remounts rw

<solid_black>the initial state, as passed on the multiboot module command line, is --readonly

<solid_black>but then init (seemlingly between mount-functions.sh setting rootmode=rw, and checkroot.sh running 'mount -o remount,$rootmode') remounts it read-write

<solid_black>at no point this whole thing consults the kernel command-line to see if 'ro' was passed?

<youpi>ah, indeed, it's possibly just the --readonly parameter given to ext2fs

<solid_black> https://wiki.gentoo.org/wiki/Sysvinit#boot does mention 'emergency', 's', and numeric modes as being something you can pass to sysv init via the kernel cmdline, so i'm not just hallucinating that

<solid_black>what I was actually trying to do is boot up with a read-only root fs, to enable the journal, as your recent mail suggested

<youpi>the recovery mode still runs the initial init startup

<youpi>it just stops before running daemons

<youpi>you'd want to use init=/bin/sh to avoid that

<solid_black>yes, but the recovery mode should drop me into a single-user shell on the Hurd console

<youpi>it does

<solid_black>instead it (well, I tested 's' and '1' rather) boots the whole multi-user system, and I can long in via ssh

<solid_black>let me try 'recovery'

<solid_black>nope, booted the full system too

<youpi>really, on my debian system, adding -s to the gnumach command line yields me to a root password prompt to get a single-user shell

<youpi>ah, it also drops --readonly in ext2fs

<youpi>I don't knwo the rationale behind that last bit

<solid_black>something might be wrong about this installaiton here then

<solid_black>but let me also try '-S' with a minus

<solid_black>also a full system

<solid_black>$ cat /proc/cmdline

<solid_black>gnumach root=part:5:device:wd0 -S

<youpi>-S or -s ?

<solid_black>capital

<youpi>here it's -s

<solid_black>let me try that

<solid_black>aha, that worked!

<solid_black>and no echo on the console

<solid_black>that must be the mach console?

<youpi>no daemon = no hurd console, so the mach console yes

<youpi>possibly there's a missing tty configuration in the boot process

<youpi>or simply the default tty configuration has no echo, which is odd as a default

<youpi>or some bug drops the value for whatever reason

<youpi>it didn't happen so in the past, as far as I know

<solid_black>there was no echo when fsck failed for as long as I can remember

<youpi>the bug can possibly have been introcued a long time ago

<youpi>I do remember not having the issue in the past

<youpi>ok, mounting readonly is not enough for tune2fs

<youpi>it doesn't want to mangle the fs while it's mounted read-only, and can't create the /.journal file since it's read-only

IRC channel logs

2026-06-24.log