<jaeger>
It will be interesting to see if I can build these packages in the container and then actually boot a pi4 from them
<jaeger>
I noticed there's no 3.7 branch for raspberrypi4-arm64 yet
<pitillo>
yeah jaeger, lwt me speak with sepen this morning to prepare the branch at github rpi4 repo (not sure if you are able to create it as we were speaking to add you and beerman_ to that repo maintainers)
guido_rokepo has joined #crux-arm
<pitillo>
my wife is ready to create a user for me and let me the laptop at nights <3 xD
<pitillo>
jaeger: do you run the propietary docker for MAC and there you imported the rootfs as a docker image?
<pitillo>
bash-5.0# crux
<pitillo>
CRUX-ARM 64b version 3.6
<pitillo>
bash-5.0# uname -a
<pitillo>
Linux c7e0fc461e5c 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 aarch64 GNU/Linux
<pitillo>
this is crazy....
<pitillo>
arm64 generic build on the way on the M1....
<pitillo>
this is amazing 8)
<jaeger>
Nice :)
<jaeger>
Yes, I'm running docker desktop for mac currently and imported to that
<jaeger>
Looks like you got it going already :)
<jaeger>
I tried to boot the pi4 with a fresh install last night and it DID boot but for some reason the upstream kernel cannot find any of its modules, even though they exist on the disk
<jaeger>
Might need to compile my own
<pitillo>
veeeery nice news
<pitillo>
that soundss amazing
<jaeger>
well, that's not from the packages I was building on the m1 yet, sorry
<pitillo>
which ones were you using?
<jaeger>
The 3.6 rootfs, wanted to get a native setup on another uSD card
<pitillo>
here the laptop suspended and the container blown up xD
<jaeger>
I DO plan to try the packages from the m1 as well
<jaeger>
doh
<jaeger>
For clarification since this is a new setup, is stage0 just enough packages to build stage1 inside a chroot on the same host?
<pitillo>
well, not bad too...the good point will be the ones built on the M1 upfated to 3.7
<jaeger>
And then stage1 is meant to be installed on the target host?
<pitillo>
yes
<jaeger>
(not cross-compiled, just the pi instead of the m1, for example)
<pitillo>
stage1 will be the final collections of core ports, built with a minimal base (st0), in order
<pitillo>
with minimal deps
<pitillo>
but why not build them with optimized cflags on the m1?
<jaeger>
Maybe a better way to word the question is: I build stage0 and stage1 on the m1 and then use those packages on the pi?
<jaeger>
I am building with optimized cflags :)
<jaeger>
Just trying to understand the workflow since it's new to me
<pitillo>
then yes, of course
<pitillo>
st0 is a minimal base needed to build st1, used to jail and then start buildibg st1 ports
<pitillo>
not sure if I'm explaining right
<jaeger>
ok, so I think I understood it, just making sure :)
<pitillo>
niiiice
<jaeger>
Weird... the upstream kernel couldn't find any modules so I compiled my own (with upstream sources, unmodified) - it also couldn't find modules... until I decompressed them
<jaeger>
I wonder if they left XZ support for modules out of the config accidentally
<pitillo>
grep for it because it smells to that
<beerman>
maybe they use some form of module compression our kmod can not handle?
<jaeger>
Hrmm, CONFIG_NODULE_COMPRESS_XZ=y
<jaeger>
weird
<pitillo>
weird
<pitillo>
rebuild without x compression, may be could be related to kmod version on 3.6
<jaeger>
I added this to the prepare-pkgmkconf target in the Makefile to speed things up :) @echo 'MAKEFLAGS="-j$(shell nproc)"' >> $(PKGMK_CONFIG_FILE)
<pitillo>
good
guido_rokepo has quit [Quit: guido_rokepo]
<jaeger>
And for reference my raspberrypi4.mk just contains:
<jaeger>
Might be nice to put the device-specific .mk files into a subdirectory at some point for top level organization
<jaeger>
Now that I understand a bit more, starting a full build of both stage0 and stage1 and will try the resulting packages on the rpi4
<pitillo>
that suggestion sounds pretty good
<pitillo>
jaeger: you are the ISO master.... I feel that this Makefile could be a monster for people... but for you... may be can give you ideas and/or your experience can improve it
<jaeger>
I will do my best :) I didn't create the original ISO Makefile, I inherited it... but I try :)
<pitillo>
you inherited and improved... and I'm pretty sure it can be improved (I hope this doesn't sound like a criiticism)
<jaeger>
No worries. Improvement is good
<pitillo>
you, jue, sepen and some others are cut from the same cloth... you are beasts
<jaeger>
Not sure I deserve it but appreciate the vote of confidence!
<jaeger>
Thanks :)
<pitillo>
you deserve it.... I don't know you for two days
<pitillo>
xD
<beerman>
+1
<jaeger>
Hrmm... might not be able to do stage1 in a container, bind mounting /dev/ fails
<jaeger>
Haev to go AFK for now but will look at that more later
<pitillo>
I have 4 ports ahead before launching st1....
<pitillo>
bash-5.0# umount rootfs/workspace/
<pitillo>
umount: rootfs/workspace/: must be superuser to unmount.
<pitillo>
take care or all the workspace can be deleted inside rootfs/ directory
<pitillo>
let's see if I don't break the container...
<jaeger>
:)
<pitillo>
ummm do you know how to enter the container?
<pitillo>
it seems related to how we did the docker run (without --privileged so no way to umount current mount points)
<pitillo>
at least I've run it without that option... and I understand that if I exit from the container, it will be destroyed
<pitillo>
so I was thinking in connecting to the current container using that option to check if it's possible to umount rootfs/* and then delete its contents and ran again stage1
<pitillo>
if we delete rootfs contents we'll detroy /workspace where all the job is done :(
<pitillo>
I'm thinking in moving the entire crux-arm-release dir to another machine, destroy the container and run it again with privileged mode for testing
<pitillo>
ummm there is no work done yet on /workspace... so saving packages.stage0.tar should be enought to start stage1 from it....
<jaeger>
I'm trying with --cap-add SYS_ADMIN now and it seems to work
<pitillo>
but running it again?
<pitillo>
I mean... have you destroyed your running container?
<jaeger>
Yes, but I saved its contents to a new image first
<jaeger>
so I didn't lose work
<pitillo>
how did you do that?
<pitillo>
sorry my lack of knowledge
<jaeger>
No worries. It's 1 of 2 ways, depending on whether or not you started the container with --rm
<pitillo>
I've saved the packages.stage0.tar which has all the work done on st0
<pitillo>
yes, I started with rm
<jaeger>
ok, so before you stop the container you should save it as a tar with 'docker export'
<jaeger>
then you can make a new image with that
<pitillo>
interesting...
<pitillo>
let's see
<pitillo>
I'm freaking out about docker....
<pitillo>
bash compilation error on st0
<pitillo>
updating readline on the host...
<pitillo>
right... old readline broke bash build....
<jaeger>
I had to rebuild quite a few things on the host filesystem before starting the stage0 too
<jaeger>
stage1 is currently on gcc, moving along
<pitillo>
here on the way too....
<beerman>
docker exec -it $containername bash <- does this not work?
<jaeger>
Generally works, yeah
<jaeger>
(assuming the container is running and bash is available)
<jaeger>
oops... distracted with work stuff and nuked my rootfs folder accidentally
<jaeger>
Well, at least it's much faster to build on the m1 than the rpi4 :P
<pitillo>
jaeger: do ypu hace the stage0-poets.tae file
<pitillo>
?
<pitillo>
phone keyb :( packages.stage0.tar
<pitillo>
you can avoid the st0 step
<jaeger>
oh, I do. nice.
<jaeger>
I also still have ports/*
<jaeger>
only lost rootfs
<pitillo>
beerman: with that command you enter again to the container, but it will miss the --cap-add SYS_ADMIN or privileged mode, doesn't it?
<pitillo>
so the same problem unmounting privileged devices, no?
<pitillo>
jaeger: great then, no need to restore the packages rhen
<jaeger>
I think that the SYS_ADMIN cap persists with the container, not the exec session... but I have NOT tested that
<jaeger>
OK, just tested, that is the case.
<pitillo>
but you need to export first to run it again with that option or can be used with docker exec? I thought it was a docker run option but I'm using docker just some days, I know nothing about it (reading a lot today but just some basic knowledge)
<jaeger>
`docker exec` runs a command in an already-running container
<jaeger>
`docker run` starts a new container
<jaeger>
So if you started the container with docker run and --cap-add SYS_ADMIN, any docker exec into that container has the same cap
<jaeger>
It took me a while to get used to run vs. exec and import/export vs load/save
<jaeger>
If the container was NOT started with --cap-add SYS_ADMIN, then yes, you would need to save or export it and start a new container with that cap
<pitillo>
yeah, run vs exec is understood, this is why I asked. I didn't know the export/import and it's a very good actions for non persistent containers
<pitillo>
I didn't run it with the cap-add option, so the exec couldn't work
<pitillo>
I'll read about load/save when wife goes to bed
<jaeger>
ok, running into another thing now
<jaeger>
I was noticing this error in configure output during stage1 build:
<jaeger>
sort: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory
<jaeger>
openssl isn't installed into the rootfs but sort (and presumably others) link with it
<jaeger>
I see that libnsl.so.3 is explicitly installed by itself into the rootfs, was that for a similar reason?
<jaeger>
oh, never mind, I'm reading that wrong. that's just symlinking, not adding libnsl
<jaeger>
openssl should probably be considered a required part of stage0
<pitillo>
let me check
<jaeger>
Some other stuff links it as well like sha*sum and openssl in /usr/bin
<pitillo>
at least it seem as coreutils links with host's ssl, so it will be needed on the rootfs
<jaeger>
yeah, I've added it to PORTS_STAGE0 locally for now
<pitillo>
do you mind to create a request at github?
<jaeger>
Sure. I was planning to do so with the rpi4 stuff as well, but still learning the system :)
<pitillo>
you learn really fast xD
<jaeger>
:D
<jaeger>
Just a quick check for things in rootfs/usr/bin linking openssl:
<jaeger>
bash-5.1# for F in *; do ldd ${F} 2>/dev/null | grep -q libcrypto; if [ $? -eq 0 ]; then echo ${F}; fi; done | xargs
<jaeger>
It's only missing this file but clearly points towards udev
<pitillo>
right
<jaeger>
Not bad at all, I'm learning how the workflow goes :)
<pitillo>
I need to sync core-arm with core-arm64
<pitillo>
because all those things probably were fixed by sepen on core-arm
<jaeger>
ok
<pitillo>
you are working with the ugly girl
<pitillo>
xD
<jaeger>
heh
<pitillo>
put a 32b release in your pi4! xD
<pitillo>
joking, thank you very much for all this information
<jaeger>
Well, even with footprint mismatches I should end up with enough packages to see if the rpi4 will boot them
<jaeger>
No problem!
<jaeger>
When I get to the point of creating a new 3.7 branch in crux-ports-raspberrypi4-arm64 should I create a new signing key?
<pitillo>
umm I think you don't need if you have the original one
<jaeger>
I wasn't able to find the original one, sadly :/
<pitillo>
then yes, if I remember right, beerman had one for the 32b repo
<jaeger>
If you or sepen still have it, we could figure out a good way to send it, but I looked in my backups as well and only found the .pub half
<pitillo>
I don't believe I have it, but let me check
<pitillo>
I think we never had the sec keys of any of the rpi4 repos
<jaeger>
Ah, ok
<jaeger>
I'm not sure how much work this would be, but another thing that occurs to me while testing is that it might be nice to have the ability to run stage1 in an idempotent fashion without losing work or starting over... in case a build fails and you just want to fix that one failure
<pitillo>
yeah, I was thinking about that atm
<pitillo>
because I have all packages which were built... and that work is done...
<jaeger>
yeah
<pitillo>
CRUX iso does 3 stages for building the entire core ports collection?
<pitillo>
and on each stage, the entire collection is built
<pitillo>
python3 was wrong on st0....
<jaeger>
Yes, similar to 3-stage gcc build
<jaeger>
My rpi4 boots with the packages built on the m1 :) Though there are some complaints due to missing eudev
<jaeger>
and procps
<pitillo>
niiiiice
<pitillo>
that smells good
<pitillo>
we need to fix the st0 ports to avoid eudev error and its ports cascade
<jaeger>
Good start, though
<pitillo>
with the M1 near... this is a walk...
<pitillo>
what a pain these lasts two weeks with the rpi3
<pitillo>
I didn't remember the last gcc updates to take more than 16h.... but this time 56h is embarrassing
<jaeger>
Were you using -j? It seemed like crux-arm-release doesn't set it by default
<pitillo>
I've tried with and without... with not many differences
<jaeger>
ah
<jaeger>
Maybe a memory starvation issue? I remember building gcc on the rpi3 being a lot of trouble but I no longer remember the details
<pitillo>
I think it eats a lot of memory, force swaping and the linking time gets higher
<pitillo>
it's like a big ball getting bigger and bigger