I guess I fecked up on this build of OS/1337...
need to repackage rootfs.cpio.xz and see if that works....
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837628147
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
For anyone interested, this is how it looks like booting [and panicking] a minimalist #Linux 6.6.4 Kernel on a 46 MHz equivalent i7-6700K:
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837628775
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
But now that rootfs.cpio.xz works, I've to fix the whole init issue...
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837640692
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
@SweetAIBelle no need to...
Instead it complains about the init file...
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837709608
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
@kkarhan
In the screenshot, and with the copy of the image after updating, it did complain about the init... but earlier, in the messages, it said:
"initramfs unpacking failed: input was encoded with settings that are not supported by this XZ decoder"
And when I searched online, I found that not including that --check=crc32 wasn't supported, at least, at that time...
@SweetAIBelle oh... i did overlook this...
DAMN!!!
So I guess I've to look at the parameters for the generation of the rootfs.cpio.xz...
Thanks for having a closer look.
@SweetAIBelle yeah, now I feel stupid...
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837769042
Does it at least display the welcome.txt ?
https://github.com/OS-1337/OS1337/blob/6d7b7e05e0987c53917080fd2185e41369d2640d/build/0.CORE/fdd/fs/welcome.txt
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
@SweetAIBelle that seems to be odd - almost as if calling #toybox without calling sh / bash / toysh will make it spit out all the available "toys"...
I guess it should be
#! /bin/toybox sh
instead of just
#! /bin/toybox
@kkarhan
Yeah, it actually looks like the exact text you get if you just run:
/bin/toybox
with no arguments.
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
@kkarhan
It gave a few errors while booting up, and went to a somewhat broken command prompt. Seems like we're getting there one step at a time.
Though that test was using the kernel and initramfs directly. Haven't rebuilt the whole image.
@SweetAIBelle in theory that initramfs and kernel files should boot on qemu out of the box as @landley would've intended for #Toybox / #Linux to do.
I only tested on #VirtualBox out of lazyness and convenience.
The Flopply-Fill - Script should basically shove those files over.
I merely replaced rootfs.cpio.xz with the new file and booted that up to this point, but if you're pedantic you could literally rebuilt the entire floppy image.
@kkarhan @landley
Testing on qemu's laziness on my part, too, since it's already on here, and if I don't do it with the image, I don't have to rebuild it. :P
I think most of the semibrokenness was just not having all the various symlinks to toybox set up in the filesystem, anyways, so probably not that difficult to fix...
@SweetAIBelle @landley yeah...
That can be fixed based off the #mkroot structure...
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837759032
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
Also regardless if #VirtualBox, #QEMU or whatever [may it be #HyperV, #vmware, #KVM or god forbid #Box86 / #86Box] in all cases it should just work.
After all we ain't playing 2016 DOOM on it, we just want an 80x25 terminal to work...
@[email protected] @[email protected] Testing on qemu's laziness on my part, too, since it's already on here, and if I don't do it with the image, I don't have to rebuild it. :P I think most of the semibrokenness was just not having all the various symlinks to toybox set up in the filesystem, anyways, so probably not that difficult to fix...
Thanks again for your time and feedback...
I've taken notes for the fix, because I'm currently mobile...
https://github.com/OS-1337/OS1337/issues/2#issuecomment-1837782493
As of now, OS/1337 doesn't boot - it just hangs after the I've gotten some cals for help out and some replies were quite helpful, including a different .config for the Kernel... This needs further ...
@SweetAIBelle I guess you too want some minimalist "slate" of a distro to just test stuff with before comsidering to build something for bigger distros if not customize it for those?
Granted OS/1337 should basically be as bare-bones yet extensible as can be...
@kkarhan
Largely last time I reinstalled on that computer, I put some sort of stripped down kde on it that's not really working for me, though it *is* the same computer I installed LFS on at one point.
I had at one point started to try to write some scripts to make a minimal linux install that was less tedious than fs, as an interesting project, though fitting on a floppy wasn't something I had in mind at the time, and being able to get to some sort of graphical environment was. (Part of me says something like OpenBox and IceWM, though X11 is big...)
I could see doing something like once OS/1337's working, building scripts that add a bunch of stuff on top of it that weren't actually part of it.
Whether I'll actually do that is a different question. I start a lot of things, but finish far fewer...
@landley @SweetAIBelle makes sense...
I for once only have i686, amd64, arm5r11 (Pi0) & armv7 (Pi3B) at hand and whilst I wish to support all the platforms #toybox & #linux do support, I only intent to gradually add those I can't test on physical hardware based off demand and once I got the entire build pipeline automated to the point that it's merely an argument to pass down for building those.
I do expect that to take quite some time but I happily accept contributions and welcome testers.
Attached: 1 image For those interested: Here's the 3,5" 1440kB FDD image of #OS/1337 as of now: https://github.com/OS-1337/OS1337/blob/966753e739878e281fb1a2bb5dc250aae753cc9e/build/0.CORE/os1337.img It's still quite broken but it does boot... so feel free to provide feedback and report issues https://github.com/OS-1337/OS1337/issues #Linux #toybox #OS1337 #Embedded #EmbeddedLinux #Distro #Distribution #CLI
Kevin Karhan 
SweetAI Belle 
Rob Landley