<emmett1>
some issues is expected, since I wrote those scripts and installer in short time. Will update from time to time
<emmett1>
dlcusa: The ISO should boot fine same as Official CRUX ISO since it use same kernel config.
<emmett1>
For time from boot prompt to root shell prompt, is it longer than Official CRUX ISO?
<emmett1>
I only tested on qemu. Those longer time also happen on Official CRUX ISO, atleast for me.
<dlcusa>
I'm not sure why, but I had problems with the installed CRUX, which turned out to be improper /etc/fstab initialization. The LABEL= spec solved the rootfs prob, but that doesn't work for swaps.
<dlcusa>
It's complicated by Devuan's GRUB, which is the owner of the MBR.
<dlcusa>
I think nothing has anything to do with MUSL, It sure has that ugly rc that doesn't colorize or enbolden anything.
<dlcusa>
That time to prompt is not unusual in my experience.
<dlcusa>
I guess I should make it build a kernel to see if that heavy workout causes the box to silently wedge like everything except OpenBSD (which treats four of the cores as hyper-threaded). Maybe MUSL will be involved in that?
<SiFuh>
dlcusa: Did you try hw.smt=1 on OpenBSD and compile the OpenBSD kernel?
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-musl
<farkuhar>
dlcusa: "that ugly rc that doesn't colorize or enbolden anything." <- Are you at least getting something to print, with the default USE_COLOR=false? In the initial implementation even USE_COLOR=false might have resulted in incompatible strings being sent to the terminal. But jue's commit made it more compatible with older displays.
<SiFuh>
farkuhar: No it didn't farkuhar. It doesn't work on my older display at all.
<farkuhar>
SiFuh: Hmm, that's interesting.
<SiFuh>
farkuhar: Older style terminals don't handle formatting at all.
<SiFuh>
And I have/had {I think I got rid of it) can't handle any colour either. Because it is dark green background and green foreground.
<SiFuh>
So if I was to use that console as my head today, I'd be carrying a hole heap of useless code around which defeats the purpose of what CRUX actually stood for.
<SiFuh>
What's the point of deleting junk files like doc, INFO, README if I am just going to install a pile of useless code to take up disk space?
<SiFuh>
At least the docs, INFO and README files are valuable in a way. Having useless code, is of no value at all.
<SiFuh>
hole/whole*
<farkuhar>
SiFuh: I was referring to jue's commit https://git.crux.nu/tools/rc/commit/e67822fd154f4ccdaa906a5a9f067114fdcf0f02 which defines BOLD RED RESET as empty strings, when USE_COLOR=false (the default). Are you saying that older terminals have problems rendering even a simple `printf "%s" "[ERROR]"`?
<SiFuh>
BOLD <-- doesn't work on older terminals
<SiFuh>
As I said, older terminals don't generally support text formating. Only colour was available.
<farkuhar>
Yes, the formatting codes were a problem. But the commit I just cited redefines BOLD as the empty string when USE_COLOR=false, so it should be more compatible with older terminals now.
<SiFuh>
I don't really care what jue did, he just compounded the problem by ignoring what others wanted.
<SiFuh>
I don't want colour. It shouldn't be in the RC at all. It should be an insertable module for those who want it.
<SiFuh>
Just like I don't want rc.fix. It should be a module.
<SiFuh>
In fact, why can't rc.fix be in rc.local?
<farkuhar>
Well, I'm planning to open a clean PR, which will address jue's initial feedback and suppress the Gitea complaints about divergent commit histories.
<SiFuh>
Well, I'm planning to continue work on my super rc and if it works, I will use that and not some fancy pansy 15 year old girls messy fscking code.
<farkuhar>
I notice you went back to separate files for rc.{multi,single,shutdown}, rather than a monolithic /etc/rc that inspects $1 to determine the intended runlevel. The latter design is still how OpenBSD does it, right?
<SiFuh>
OpenBSD uses a single rc
<SiFuh>
And I have them separate not because I plan to keep them separate, but it is easier to test them separately. For example. I can still use the original rc script and inject rc.shutdown in ANSI C into the initab script and still be able to boot if the shutdown fails. It's a failsafe.
<SiFuh>
It's also the reason I shoved them in a folder called /etc/init.d/rc.* because I can still manually type /etc/rc on a failed/partially booted terminal with a prompt and the system will boot up fully.
<SiFuh>
Saves me from loading a stupid CRUX rescue disk that takes 5 minutes to boot. :-P
<farkuhar>
jue made a good point about rolling out an update that affects /etc/inittab (which is shielded from automatic upgrades by pkgadd.conf). If users forget to run rejmerge, and runlevel 2 tries to launch a nonexistent /etc/rc.multi rather than the intended command `/etc/rc multi`, then a rescue disk will be needed.
<farkuhar>
So I tend to agree that a bunch of symlinks, and rc inspecting $0 rather than $1, is a more robust way to transition users to a monolithic rc.
<SiFuh>
No it shouldn't. It should still open a prompt if it can't find rc.multi and then at the prompt you can type in /etc/rc multi
<SiFuh>
I get a login prompt here when it failed while I was working on the ANSI C rc.
<SiFuh>
It just doesn't run the services and stuff.
<SiFuh>
Let me test it wit the rc that is all in one.
<farkuhar>
That's a helpful fallback behaviour (dropping you to a prompt), but only for users who are paying attention to the development. If they blindly run `prt-get sysup` and aren't following the "[notify]" announcements, then they won't know how to invoke /etc/rc when they get dropped to a prompt.
<SiFuh>
The more I hear about jue and jaeger since 2018 and the rc script. The more I realise, they have no fucking clue what they are talking about.
<farkuhar>
Why do you single out 2018 as the turning point in rc development? Is that when we stopped getting regular contributions from braewoods and frinnst?
<SiFuh>
Because that would be when I got them to fix the rc script because when I explained it to jaeger and jue, they had no idea what running the command 'init 1' does and then exiting back to 'init 2'. I explained to them that the old rc, you run that it will crash on the way back up. jaeger ask what is it for. I said it is so you can drop down a runlevel and back to multi without rebooting your system. We
<SiFuh>
use it a lot when we run Unix Servers.
<SiFuh>
I bet if I remove rc completely from the inittab the system will still boot.
<SiFuh>
Yep, I deleted /etc/rc completely from inittab and rc multi and the system still boots. But root should be read only.
<SiFuh>
A lot of people are under the misconception that the init scripts are for booting your system. This is not entirely true. It is a list of commands to run whilst the system is coming up.
<farkuhar>
What was dlcusa saying about /etc/fstab having problems when the partitions were specified as device nodes rather than labels? Do different versions of the kernel disagree on the device nodes, making them unreliable for defining entries in /etc/fstab?
<SiFuh>
No idea, I would have been bottling a hundred beers and painting the bash bar for the roof racks.
<farkuhar>
dlcusa said that specifying the rootfs with LABEL= was a workable solution, but somehow it didn't work for activating swap.
SiFuh_ has quit [Remote host closed the connection]
<SiFuh>
farkuhar: Looks like zorz_ is correct CONFIG_CRYPTO_RNG CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_RNG_DEFAULT=y If you have this enabled in the kernel, then you won't need to bother with creating a seed.
<SiFuh>
It seems to only be needed if you have those options disabled. You are running an embedded system, or certain virtual systems
zorz has joined #crux-musl
<dlcusa>
Some swapon commands support labels, others don't--never looked into why.
<dlcusa>
Same for /etc/fstab support. It doesn't matter if non-swap partitions are supported.
<dlcusa>
LABELs are effectively a simpler implementation of UUIDs, and precede UUIDs as well.
<SiFuh>
I like labels
zorz has quit [Quit: leaving]
<dlcusa>
So the kernel build wedged around 45 minutes in. I get it restarted soon, for some value of soon.