I saw it yesterday.

I agree but if i remember well you can't skip inittab in chapter 7.6 or you can't login.

I'm going beyond, if someone is reading and is thinking to try runit i can say.. do it!!!

When Runit is installed and configured to be the init system, the inittab file plays no role and is not needed.

P.S.: Keep in mind that for the moment we technically have stopped talking about the runit-for-lfs project which installs Runit in a finished traditional LFS system and then removes SysV and lfs-bootscripts components. The current discussion is on the topic of installing Runit while building a new LFS system. Obviously, that is possible and is my preference. In fact, as already mentioned, there are several ways to lay out Runit in an LFS system. But the runit-for-lfs project intentionally ignores all those variations and for simplicity focuses on only one of the ways.

Uhm.. as i said many times i'm not expert so i can be wrong. Anyway i would report a problem on my first runit boot without inittab (sorry for the bad photo); emergency shell and i can't reboot/shutdown the system. Then i created inittab all is ok but i have to delete it and see again if it was the real problem.

Attached Thumbnails

 

Inittab deleted without problems, thx!
No idea what happened.. few bad clusters?

To me, it seems you're having clock and time issues. There is no method for any operating system to discover the time system to which the hardware clock has been set (i.e., UTC or local time). That is why we have to tell the OS what that is. The traditional LFS system uses the /etc/sysconfig/clock file to identify to the OS what system the hardware clock is using. Our runit-for-lfs project does that in /etc/runit.conf (all this is explained in the runit.conf comments, the runit.conf(5) man page, and the README). You currently have it set to 'localtime' in your runit.conf. That may be wrong for you.

Setting the hardware clock to either time system will work. But you must tell the OS what it is. And if you are booting multiple operating systems, then they all must be configured the same way. Otherwise, the hardware clock can get set and reset over and over between UTC and local time. That can produce the "...time is in the future" issue seen in your screenshot.

Generally, Linux systems are configured for UTC. Windows systems generally use local time. For a computer with both Linux and Windows, it's usually simpler to set the hardware clock to the local time for the Windows system, and then configure any Linux systems to use local time. Maybe that is behind your time issue.

P.S.: The 'localtime' setting for HARDWARECLOCK is the default if nothing is entered for it in runit.conf. And, the runit.conf file is initially installed with HARDWARECLOCK="" making 'localtime' the default time system out-of-the-box. That may seem like a bad choice for the default, but it was chosen because it is the default of the hwclock program which does the background work. It just seemed appropriate to bring that same value to the default HARDWARECLOCK parameter in runit.conf.

Once up and running you'll notice the system behaves generally the same, minus the visual aesthetics which look more akin to FreeBSD in the console.

Within the UI environments very little seems different. I have had only minor issues with daemons not wanting to behave themselves, though a quick edit of a run script and effective options and execution handling fixed things. The only package you might have that is known to misbehave is OpenSSH's sshd daemon. I'm still working on this, and I might have a fix soon that will be uploaded.

Because the Runit system functions on the same levels as sysvinit, you'll never have to rebuild any packages specifically to support Runit, which is extremely beneficial to system maintainers. Another plus, is roughly any existing scripts can be ran thorugh rc.local, though if you did call on LFS's init-functions file, you'll need to re-implement the call functions natively in the script.

I wrote UTC=1 in runit.conf but really i need only UTC

Did you mean to say that you entered HARDWARECLOCK="UTC" in runit.conf? Because that is the proper syntax as explained in the documentation. The UTC=1 parameter is what the LFS file /etc/sysconfig/clock uses. The runit-for-lfs project ignores that file (also explained in the documentation).

P.S.: I am not being critical, cynical, or saying RTFM. I have never said that to anyone. Ever. I just want other readers to know that a great deal of time and effort went into writing the runit-for-lfs documentation, config file comments, and man pages. That's all I'm doing.

P.P.S.: Here's something else that I want other readers to realize (even though I already said it once earlier in this thread)... Our runit-lfs-runit project will take an LFS system in a completely new direction concerning the init system. Many things from the old LFS system will be ignored or some even deleted. New things had to replace those things. We had to invent those. This clock and time thing is just one of those. But readers need to understand that it is perfectly possible and reasonable to install Runit by itself (i.e., not with our project) alongside SysVinit of the LFS system and configure Runit to use all of SysV's stuff (including /etc/sysconfig/clock). Why do that? Because Runit is simpler to manage, offers service daemon supervision, and has a reliable logging mechanism. Runit can take SysV's scripts and config files and do a better job with them, IMO. Just FYI and for the record.

Yes now i have:
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Rome"
KEYMAP="it"

The clock now is working well, i don't remember if i did also "date" and "hwclock -w" or if i did it in lfs 7.5 (winter time these days).
I also set LOGLEVEL="1" because i don't like console messages but i don't understand if this line is like dmesg -n 1.

Very well.

That is exactly correct. There is a section of the stage 1 script that uses the LOGLEVEL value with dmesg -n. And if LOGLEVEL happens to be missing or null, the value of 4 is used by default.

P.S.: That is another thing we did differently in the runit-for-lfs project. In a traditional LFS system, the /etc/sysconfig/rc.site file is where the console log message level setting is.

Just a note, but after a few weeks, I plan on returning to do some work on the script sets to get some updates in them to function properly in case some aren't.

If you do know of any scripts that are being problematic, please post which ones, and I'll put them in the TO-DO-LIST. I am researching using chpst (change process state) which can run services in different user modes, to work through some of the system user modes as originally intended.