<stenur>
And hey by sheer luck my vserver had a kernel bug caused stop by 16:55, when twenty minutes later i went online and tried to connect.
<stenur>
Actually the log entries are from yesterday: watchdog: BUG: soft lockup - CPU#0 stuck for 288s! [swapper/0:0]
<stenur>
CPU#1 stuck for 370s!, RIP: 0010:native_safe_halt+0xb/0x10, etc etc
<stenur>
That started "Nov 29 15:26:39"; last entry "Nov 29 15:27:42 kernel: [228052.774017] NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xb/0x10
<stenur>
that was yesterday! But "all fine" until 16:55 on Nov 30 which gives last entries for lighttpd and postfix, rest total silence
<stenur>
hmm, not a kernel guy, see no changes in 5.15.79-.80, 'think it's bugzilla i look for
<SiFuh>
Maybe hardware
<SiFuh>
99% certain will probably some form of software error
<stenur>
There were quite some of these sort on scheduling/other.
<stenur>
Added a new one nonetheless. By sheer luck, it could have stuck for many hours instead.
ty3r0x has joined #crux
sandman187[m] has quit [Quit: Bridge terminating on SIGTERM]
<SiFuh>
Cool, all good then. See what happens
sandman187[m] has joined #crux
<chrcav>
I've been trying to switch from using grub2 to syslinux for my bootloader and I followed the handbook for uefi and syslinux and have an identical config. Syslinux loads says that it's booting crux then vmlinuz-5.15.55 ok goes black and reboots.
<SiFuh>
chrcav: Do you have a line that says INITRD or however it is spelled?
<SiFuh>
Then it may be a kernel compilation issue. Something missing.
<SiFuh>
You using your own config yes?
<SiFuh>
Kernel config I mean..
emmett1_ has quit [Ping timeout: 256 seconds]
<chrcav>
yes. It was based on the one I was using from 3.6 and the same kernel works with grub.
<jaeger>
I've had trouble getting uefi syslinux working in the past :/
<SiFuh>
I do know that something did change but I never found out what changed.
<SiFuh>
SYSLINUX and UEFI is super easy. The fact you got a 'vmlinuz-* ok' means UEFI, SYSLINUX and found an dloaded the kernel means that was a fine setup.
<jaeger>
Maybe the issue isn't syslinux but the kernel config, somehow
<SiFuh>
jaeger: Yep
<jaeger>
Not sure, like I said syslinux was flaky for me with UEFI... but it's been a while, I should give it another shot sometime
<SiFuh>
It can be that (Possible video), or wrong partition. I am guessing it is a kernel issue. Nothing to do with us but to do with the changes between 5.15.XX
<jaeger>
One cause for the black screen could be missing firmware for a GPU driver but that doesn't cause a reboot
<jaeger>
You might try booting with 'vga=0 nomodeset' to see if you can see anything before the reboot, maybe
<SiFuh>
Another guy had a similar issue a while back. I told him to try my kernel and build his kernel from that and he came back a couple of days later and said it worked.
<stenur>
boot managers are overcome. except maybe refind, if you really need it. (On UEFI all that, of course.)
<stenur>
And truly -- i do not miss it.
<stenur>
And i never understood why this is such a mess. lilo was the easiest and best i ever used with Linux.
<chrcav>
I'll try those options, jaeger. and also double check my config.
<jaeger>
technology marches on and UEFI is staying :)
<SiFuh>
jaeger: 100% true
<SiFuh>
chrcav: if the 'vga=0 nomodeset' does work let us know. Might be something to look into at a later date.
<stenur>
"if you use nomodeset you do not know what you are doing", wasn't it so? I would never know what else to do.
<jaeger>
It's useful for troubleshooting framebuffer issues sometimes
<jaeger>
But I wouldn't leave it permanently
<stenur>
It is not even documented no more in kernel-parameters. Grep finds it in admin-guide/edid.rst talking about "good old days". Sadly, i must have missed those
<chrcav>
yeah. that unfortunately didn't show me anything new. I'll take a look at that config SiFuh
<SiFuh>
chrcav: It's the exact same config under kernel/contrib/ on the CD
fdsfsgg has joined #crux
<SiFuh>
I noticed when I moved somewhere into the 5.?.X range of kernels a while back that my old kernels would either go black screen or reboot. Not sure exactly what it iwas, I just worked on making a new modular kernel from scratch again.
<SiFuh>
When I started to look into it, I didn't find anything new. However, I do beleive something was changed or removed.
<fdsfsgg>
Hi, on my musl-based distro with busybox init iwould like to use the crux style initscripts. so: (kernel init=/bin/xyz.init) +xyz.init points to the first rc.script .tried sinit =fail. minit=nocompile.any suggestions for a simple init-binary that loads crux style scripts ? thanks A
<SiFuh>
I though 'init=...' was binary so therefore can't be a script. If so, then the '-...' needs to be built against musl first.
<jaeger>
It can be a script. The one on the CRUX ISO is, in fact.
<SiFuh>
jaeger: wow, that's actually pretty cool and unexpected ;-)
<jaeger>
fdsfsgg: we're just using sysvinit
<fdsfsgg>
e.g. sinit :can be called as init=/bin/sinit and loads the first script .but then you need another getty etc
<stenur>
If it is executable
<stenur>
Though on EFI partition anything is executable for Linux
<fdsfsgg>
my first dive into init .so a running system to copy would be nice .there seems to be a million options . eg to set up the gettys with or without inittab ...
<jaeger>
I wrote a little C program to be an init for the ISO way back years ago but replaced it with a script as it was much simpler... but it just sets some stuff up and then pivots to a real init
<fdsfsgg>
rephrasing :so how to adapt rc.boot to be loaded from a) sinit et al b) direvt via "init=" bootparam ... didnt know a one page script could do the trick
<fdsfsgg>
yes finit is in your ports , has a lot of options
<fdsfsgg>
just to load the crux.rc with minimal overhead would be nice
<stenur>
i mean, i do have a fallback configuration where an EFI_STUB kernel is booted without kexec, it does pivot-root then, doing normal init.
<stenur>
i do not have a finit port
<fdsfsgg>
i guess i saw finit in crux portbrowser
<stenur>
Ie it does so and does 'exec $bb chroot . sbin/init' where $bb is a path to busybox
<stenur>
(needs to do it step by step because real root filesystem is encrypted)
<stenur>
i mean /sbin/init is ~50 KB (dynamic)
<SiFuh>
fdsfsgg: Probably and older port.
<stenur>
ah i thought he means me personally
<stenur>
You need "a PID 1", no? busybox's runit thing that VoidLinux i think still offers is a super-minimal interesting alternative.
<stenur>
But CRUX has voted against using it.
<SiFuh>
runit?
<stenur>
That reminds me that VoidLinux has updated its distribution ISO, and i wanted to install a Void system when that is the case.
<stenur>
SiFuh: yes. When start-stop-daemon was imported.
<fdsfsgg>
busybox can emulate runit behavior
<SiFuh>
i do like runit but I also didn't like it as much as the CRUX init scripts
<fdsfsgg>
so you use sv start dnsmasq , without having runit installed
<SiFuh>
I hated the mistakenly configured leading to endless loops
maledictium has quit [Ping timeout: 265 seconds]
<stenur>
Well i think i would. systemd uses that symlink mess thing too!! No, but .. i also like CRUX. I use the manually-driven watchdog to check that services alive, via my scripts; even on the AlpineLinux vserver which now I THINK offers supervising capabilities via OpenRC.
maledictium has joined #crux
<fdsfsgg>
i guess i got it now: you dont use bsd-style init . you use sysv-init (pkg= sysvinit) with reconfigured scripts ala bsd (pkg=rc) so ill try to build crux.sysv on my distro .if that init works than i can use pkg =rc -> crux-style rc-scripts .thanks
<mnkydeth>
So, been running sway and wayland for a little bit now. I seem to have most stuff working as I want. But, I finally decided to try steam and that uses x11 not wayland. It tells me to check my DISPLAY environment variable and that I have X enabled. I guess I'm not sure how to start xwayland but I do have it installed. I assume my start_sway.sh script is lacking. But having a hard time finding relevant info.
<mnkydeth>
I do have enable xwayland in my config file for sway.