lilo and nyla
 

So I finally stopped re-reading docs and planning and actually went and installed bedrock.

Has anyone gotten Bedrock (Nyla) working with lilo? In other words: is bedrock capable of being used with lilo?

The reason I ask is, no matter what, bedrock complains that the / partition is read-only.

The key section of my lilo.conf, note the use both of the "read-write" kernel paremter *and* the "rw" passed as part of the command line to the kernel.
Bedrock does boot and I *can* log in but it's all wrong apparently until bedrock can get early write-access to the partition.

Thank you in advance.

I don't have much experience with lilo. That looks like it should work - no idea why it isn't.

While it's probably better to actually fix that, we can probably work around it. Once you've logged in, try running (as root)

Ideally that should be run before the stratum is enabled, but it's *probably* okay if it runs after. This will run the various bits of code Bedrock Linux wanted to run early on but couldn't. While you'll still see error messages on boot, everything should be good at that point. Consider placing that command in /etc/rc.local so it is run every boot.

If you do figure out why it isn't properly mounting the filesystem as writable, do let me know so I can make a note of it for the future. I do want to ensure options such as lilo are supported.

Background: Bedrock Linux wants to be able to write to the early file system so it can enforce a few standards needed to keep the various distros in sync. For example, some distros use /etc/machine-id while others use /var/lib/dbus/machine-id. Bedrock Linux tries to ensure one of those two locations is a symlink to the other, which naturally requires write access.

For the next release I'd really like to remove the requirement of touching the bootloader at all for hijack installs. I'm planning on removing this read-write requirement by having brn try to figure out which mount points it needs write access, remount with write access, do its stuff, then remount again as read-only to resume prior state. This'll be a non-issue at that time. May take a bit before we get there, though, and it'd be better to understand why this is an issue in the first place.

Thank you for the reply. In the meantime, I thought of something to tell me more of what is going on. What I did was boot into bedrock again, then cat /proc/cmdline to show the parameters in the form they were after being handed off to the kernel from lilo. Now recall that I had a single "rw" parameter in there and also had the lilo "read-write" line. Upon examination of the /proc/cmdline parameter I saw no "read-write" but I *did* see that "rw" was now in there *twice*. Aha: lilo translating its "read-write" into the "rw" kernel parameter.

So that gets lilo off the hook: the kernel is being passed what it ought to be. That leaves (a) randomness (b) an undiscovered problem in bedrock or (c) the initrd is doing something to make the root device mount as read-only.

Next I looked at the unpacked slackware initrd and saw this line near the end of the init script:
It's mounting it read-only. Note: ROOTFS is the file system type (ext4 in this case) and ROOTDEV is the device to mount. Nothing odd there.

The last line of the script:
Aha. Bam. Eureka. And other such sayings. ;) Looks like the slackware initrd is the problem.

So, in conclusion: lilo seems to work with bedrock.

Nice investigation!

I'll need to make a note, then, that Slackware's initrd doesn't respect rw and recommend either people adjust it or use another initrd for the time being. Another point in favor of removing the need for "rw" and other bootloader adjustments.

OK. I am in bedrock right now as I am posting this. Yay! Modifying the slackware initrd to *not* force a read-write mount *is* the solution. :D

HOLY CRAP I'M IN BEDROCK!!!!!!!

Excellent, enjoy it!