ok building curl and wget and openssh, next kernel and then need to copy the grub uefi info over

zedmatrix: gitlab.com/binaryoutcast/snowball-o…5c520d6fe187c39bbb4cb98573067eca27f

and you can call those from an rpm spec file ?

... i suppose I could but it would be nuts

oh so you are just bash building ch5+6 ?

i am moving back and forth

refining

but once you build the chapter5-7, you can save that and use that as a base for building from its only about 130Mb or so

i believe that is how most distros do that is start with there basic setup

i have the rpmbuild part stage3 where i want it to make spec files

atleast gentoo does, you start with a bootable iso, download a stage3 build tar and build

i am now making stage 1 and 2 less annoying

thats y i broke my auto build into 6 parts

this auto build is almost done, just building the kernel

if malina was around it would nice to ask about the /sbin/init as a script

well shoot?

one can specify init=/bin/sh say on the boot line

the scripts in lfs are precisely that, they don't use any auxiliary binaries [almost], except for devices. and so on. but are called from the init script

what is the question zedmatrix ?

well i know you should mknod console and null?

ye, hmm, I do forget a bit how to do that. I recall having a bit issues myself when i was 'mixing' some inits, so t so speak. but using eudev or udevadm thingie should bring them up

the kernel looks for /sbin/init, if that was a bash script to create all the dev nods, instead of sysv, rc systemd

but yes, in the init scripts I think you write in the mknod/null somewhere

to preppoulate some stuff

well init is usually just calling in more scripts (or binaries) . but ye, you coulod write one LONG init in one file or split it up, (sysv style)

ye, you can reeplace syv, with your own init

which would have to take care of the various instnatiations.

just wondering if you have ?

well, I .. I did something like a hybrid from sysv + superman + eudev

I do recall I had to hammer a lot befor getting it going , esp on musl I think

hmm, I had on musl at least issues with devpts or /dev/ptmx not coming up properly iirc

and had to piss about a while before i got it all going

yea i was looking at my musl , used sysv+mdev+skarnet

ye mdev is

ye, sounds good

is that working ok then?

if so, what is the issue?

or not?

yea had no issue building musl+gcc15

(a tad semi afk because I am trading right now)

ye, but init wise

I mean

yea some simple funcs github.com/zedmatrix/ZBuild-System/…ain/LFS-gcc15-musl/stage4/sysv-init

erm, what abt lfs, it has a init script, once can adjust no?

i wanted to trim it

yu0p, so looks like something i did too initially

kinda took some from the lfs sysv book

I kinda used lfs scripts when i first started off, then used superman, my init,

and kinda somehting in between etc. to be honest, when id di the musl I redid a loty but my muisl died out some years ago and so it's still a kinda WIP

not entirely done

and since then I haven't been working on those things becaue ye some months ago id di the bootstrap from the small asm file

there wasnt much needed to patch

and been mostly buy then to do marv 2

ye init isn't hard to do, i mean it's mainly to bring up the physdevs and that's about it

have you checked out suckless.org zed?

I mean, it is a trove of info for making things small, succint and easy

any lfser should really peruse that too

less is more

i remember looking at it briefly

dwm is a very nice simple gui env

mdev might be from it?

I mean my old musl used toybox as the userland

i wrote this 0x0.st/8nsm.sh to simplify LFS

which itself is quite challenging due to so much non posix commands out there

but its fun moving a rootfs onto a usb to boot :)

ye vm,s usb, anything is easy with linux

especially if you start using uuids

but without the testsuites lfs can be done in an afternoon :)

zedmatrix: wish me luck!

rpmbuild?

no stage1 with changes

if i am wrong.. my system dies

:P

.. let me make sure i still have my backup i took a week ago

cd lfs

aren't in a vm ?

why should I be

i have a backup

and fedora cinnamon on a flash drive which can install wimlib and restore if it goes bad but i can do one more test before i pull the trigger

i also have extra pc's around to play with :)

zedmatrix: looks correct to me dpaste.org/ieJLT/raw

I am poor

send me money.. paypal.me/mattatobin

:P

i dont have money :)

as long as mosy things are prefix'd /mnt/lfs and $LFS is properly export'd things for stage1 should work

zedmatrix: gitlab.com/binaryoutcast/snowball-o…b4493e7db25e3c0844e629658632731f235

specifically my chroot script is slightly improved and primed to accept path and command as arguments so i can start it doing something like stage2 and stage3 after stage1 from ./mach build.. later

at the chroot_pre you can just "mkdir -pv $LFS/{dev,proc,sys,run} " its smart enough to make or not :)

or in your case "${TARGET_SYSROOT}" nsITobin

if they don't exist it is an error as it would be created by the filesystem script

you can just mkdir -p

and if the thing ain't mounted

then i have to clean it up

and try again

or if i enter the wrong path

you can check with mountpoint

for empty directories?

i am just not understanding why i would want to make more work for my self in case of erRor

i just like how the amount of hardcoded paths is greatly reduced

right now the lfschroot script will not proceed unless the target sysroot is properly prepped and the target command exists

previously i just let it error out

naturally

i was talking about this gitlab.com/binaryoutcast/snowball-o…ld-aux/lfschroot?ref_type=heads#L24

what about it.. if those directories do not exist it should not continue

Check whether a directory or file is a mountpoint.

how does that help me determine existance

i just mean pre create them

i do..

as the second script in stage1

long before it would be invoked

when i finish option 1 of my build, i just chroot

and i want to use this script for more than one thing

it creates all vfs

and i want it NOT to create things unless it is either existing or prepped

i do that as part of my chapter 7

including the files

yeah i found it redundant to create directories twice for a system that won't even exist after the rpms are built

stage1 and stage2 have no existance after the last rpm is built

just gets deleted

that is why I can cheat so flagrantly.. exclude buildability exclude like a dozen packages

finished building the laptop to the fast 24gb ssd

and tested my packBuild for the grub-uefi files

hmm looks like i can build lua earlyer like right after readline, nsITobin

the only reason I am building so much in stage2 is because i haven't the time to work out how low it can go

i decided a full buildchain rpm deps then rpm was a fine starting point

well most of those will be needed for whatever post-LFS you build

most of those are needed for building ANYTHING AT ALL WITH RPMBUILD

i am still looking at not building rust, sofar Mesa's nouveau seems to be the only one

zedmatrix: well i majorly fucked up my stage1 last night .. not hostwise just exec wise.. hopefully NOW i have fixed it correctly

this makefile is a piece of crap tho i am getting sick of it

until i replace it it will remain fragile

zedmatrix: works again ibb.co/B2nhHJ4Y

./mach build

who needs fedora meta-tools

i have rpm bash and mah brain

nsITobin: eventually you'll come to the dark side :)

zedmatrix: been there and back

I have a better way.. or at least a simpler one

zedmatrix: how different ARE the instructions between sysv and systemd

aside from configuration files and bootscripts

and udev being included of course

like do packages get built differently?

cause I'd love to simply make init system a choice

zedmatrix: how different ARE the instructions between sysv and systemd

aside from configuration files and bootscripts

like do packages get built differently?

cause I'd love to simply make init system a choice

not too diff, but i think you would have to have 2 separate rpmspecs

the sysv has a couple of extra packages sysklogd and sysvinit << those are handled by systemd

well if the configuration is only different in a few other packages.. then a simple %{?_systemd} check would do