| drizzt | bstrap: ~/work ---# unxz control.tar.xz | 00:41 |
|---|---|---|
| drizzt | Segmentation fault | 00:41 |
| drizzt | (debian sid on arm64, fresh try to debootstrap) | 00:41 |
| drizzt | got exactly the same on devuan ceres of course | 00:45 |
| Hurgotron | drizzt: just that one file? Do other tools work? (xzcat, xz...) | 01:17 |
| drizzt | xzcat is a symlink to xz | 01:19 |
| drizzt | as is unxz | 01:19 |
| drizzt | # xz -d control.tar.xz | 01:20 |
| drizzt | Segmentation fault | 01:20 |
| drizzt | same for compression | 01:21 |
| Hurgotron | Thought so. But that means the file is bad? segfault as an error message is always bad, but it is known that xz has less error checking / recovery compared to other compression formats | 01:36 |
| drizzt | it has nothing to do with the archive being good or bad | 01:44 |
| drizzt | a segfault is a critical bug in the programm itself, or in the libraries used by that programm | 01:44 |
| gnarface | in this case could it be caused by running out of system ram? i know that xz can have very high ram requirements depending on the compression settings.... | 01:45 |
| drizzt | nope | 01:45 |
| drizzt | it does not yeld a segfault | 01:46 |
| drizzt | and I have plenty RAM available | 01:46 |
| gnarface | oh | 01:46 |
| rrq | drizzt: try LD_DEBUG=all xz -d control.tar.xz |& tee /tmp/LOG | 01:47 |
| drizzt | a segfault means that the program code tries to access some memory region which it is not alowed to, either because it tries to read address 0, or a random adress by using an uninitialized pointer | 01:47 |
| drizzt | rrq I already straced, xz starts fine | 01:48 |
| gnarface | so it's... probably just a library version mismatch? stuff gets out of sync on ceres all the time | 01:48 |
| rrq | run in gdb ? | 01:49 |
| drizzt | gnarface: it xas present on 3 of august, two months ago | 01:49 |
| gnarface | hmmm | 01:49 |
| drizzt | rrq : currently trying to run older versions, and to run with older libc and liblzma | 01:50 |
| drizzt | to know where to look for and allow the second stage of debootstrap to run | 01:51 |
| drizzt | gdb is not installed, not easy to install either, and I xz is production version, as is libc, so there's no debug symbols | 01:52 |
| rrq | I just made an arm64/ceres installer and is trying that in qemu ... should run into same problem I guess when it comes to installing base system | 01:52 |
| drizzt | rrq : yep | 01:52 |
| drizzt | running on real hardware here | 01:52 |
| rrq | for armhf there was an issue with the ext4 filesystem ... not sure if that plays in here | 01:53 |
| drizzt | of course I tested other hardware, and have a daedalus running fine on the hardware | 01:53 |
| rrq | (the dir_index attribute) | 01:53 |
| drizzt | nope, got a ceres running find on armhf, recently updated | 01:53 |
| drizzt | the problem is specific to arm64 | 01:54 |
| drizzt | s/find/fine/ | 01:54 |
| drizzt | (if it was present on amd64 it would have gotten fixed even before being packaged | 01:54 |
| drizzt | I think it's something that went untested as there must not be that many people running ceres or sid on arm64 | 01:55 |
| drizzt | a change which runs fine on other archs but crashes on arm64 | 01:56 |
| drizzt | rrq: https://www.techno-innov.fr/NotShared/LOG | 02:00 |
| drizzt | mind that dpkg crashes too, but not directly dpkg : it calls tar, which seems to call something else, which fails to extract the package content | 02:03 |
| drizzt | but it does not use xz | 02:03 |
| drizzt | debootstrap does not install xz (but has liblzma) | 02:04 |
| rrq | tried removing /etc/ld.so.cache ? | 02:04 |
| drizzt | I installed xz by hand in order to run the test | 02:04 |
| drizzt | rrq, did not, but did it right now and same segfault | 02:05 |
| drizzt | the first time this happened I was having a running system, and it crashed during the upgrade | 02:06 |
| drizzt | and then dpkg is unable to install anything | 02:06 |
| drizzt | I also tried dist-upgrade from a daedalus (running fine) to excalibur -> crashes | 02:07 |
| rrq | hmmm.. ok. (my arm64 installer is still installing ... configuring 45%.. can try repeating soon) | 02:07 |
| rrq | will be a qemu virt system with cortex-53 | 02:08 |
| drizzt | and now, it is a debootstrap for which I ran the first stage on my x86 host, then flashed an SD card, booted with init=/bin/bash, and trying to run "/debootstrap/debootstrap --second-stage" | 02:08 |
| drizzt | and when this tries to call dpkg, it crashes | 02:08 |
| rrq | was devuan's debootstrap ? | 02:09 |
| drizzt | rrq: tested two different arm64 boards, with different processors, and crashes all the same | 02:09 |
| drizzt | rrq: should be | 02:10 |
| drizzt | why ? | 02:10 |
| rrq | (it's different from debian's debootstrap) | 02:10 |
| drizzt | the problem is not from debootstrap, first occurence was when upgrading a running ceres | 02:11 |
| rrq | was that a minbase system or a "default" ? | 02:11 |
| drizzt | and happens when dist-upgrading a runing daedalus to excalibur | 02:11 |
| drizzt | it was a system I've been using for 3 or 4 years | 02:12 |
| rrq | sorry abotu question; I'm just learning about "the enevelope" | 02:12 |
| drizzt | rrq: no problem | 02:12 |
| rrq | I'm using my "bespoke-installer" which created an arm64/ceres installer (as kernel+initrd) on an amd64, and now I'm running that on qemu-systemaarch using virt and cortex-53 | 02:14 |
| rrq | still installing.. but no issues yet... (using busybox dpkg so far). | 02:15 |
| rrq | it'll go into local dpkg soonish | 02:15 |
| rrq | still installing the kernel.. it's the initramfs building that takes time | 02:26 |
| rrq | (slow... now upgrading from network .. fidning the slow debian mirrors) | 02:53 |
| rrq | it seems fastly is slowly here | 02:53 |
| drizzt | ok, running unxz from package xz-utils_5.4.1-02 : runs fine | 03:10 |
| drizzt | (with lib liblzma5_5.4.1-0.2) | 03:10 |
| drizzt | current is xz-utils_5.6.2-2 (with liblzma 5.6.2-2 too) | 03:12 |
| drizzt | but ... # /debootstrap/debootstrap --second-stage | 03:12 |
| drizzt | W: Failure trying to run: dpkg-deb -f /var/cache/apt/archives/dpkg_1.22.11_arm64.deb Version | 03:12 |
| drizzt | but as I stated, dpkg/tar is not using xz | 03:13 |
| drizzt | though I thought it was using liblzma | 03:13 |
| drizzt | well, it's not tar : tar xf data.tar.xz is now running fine | 03:15 |
| drizzt | so dpkg is doing it differently | 03:15 |
| drizzt | dpkg-deb is linked to liblzma, so it calls decompression directly | 03:17 |
| drizzt | and I chnaged the lib version under his feets ... he may not be happy with it :( | 03:17 |
| rrq | hmm I got liblzma5_5.4.1-0.2_arm64.deb for ceres | 03:21 |
| drizzt | got 5.6.2-2 on my x86_64 host | 03:22 |
| drizzt | and on the ceres debootstrap liblzma5 is 5.6.2-2 | 03:23 |
| rrq | same here for amd64/ceres | 03:24 |
| rrq | but liblzma5_5.4.1-0.2 for arm64/ceres | 03:24 |
| drizzt | that's strange | 03:25 |
| drizzt | what are the dependencies of your dpkg package (and it's version) ? | 03:25 |
| drizzt | dpkg_1.22.11_arm64 here | 03:26 |
| rrq | dpkg=1.21.22 .. pre-depends liblzma5 (>= 5.4.0) | 03:27 |
| rrq | that's from the dists/ceres/main/binary-arm64/Packages file downloaded some 4 hours ago | 03:28 |
| drizzt | liblzma5 (>= 5.4.0) here too | 03:29 |
| rrq | and it has liblzma5=5.4.1-0.2 | 03:29 |
| drizzt | erf, this is the 1.21.22 | 03:29 |
| rrq | I got Packages form deb.devuan.org; not sure which actual server | 03:30 |
| drizzt | well 1.22.11 also has liblzma5 (>= 5.4.0) | 03:30 |
| rrq | and https://pkginfo.devuan.org/ agrees too | 03:31 |
| drizzt | deb https://deb.debian.org/debian sid main | 03:32 |
| drizzt | (this is the test on the debian debootstrap) | 03:32 |
| rrq | that's debian sid's version | 03:32 |
| drizzt | yep | 03:33 |
| rrq | you will want to use devuan's installer and ceres versions (?) | 03:33 |
| drizzt | someone suggested me to test debian too | 03:33 |
| drizzt | to check if it was the same | 03:33 |
| drizzt | gonna check back devuan, but tomorrow ! | 03:34 |
| drizzt | gonna try to get some sleep | 03:34 |
| drizzt | (3:34 am here) | 03:34 |
| rrq | g'night | 03:34 |
| gnarface | Centurion_Dan: you don't happen to know where the rpi3 build scripts are, do you? | 08:46 |
| gnarface | or anyone else here, for that matter? | 08:47 |
| yeti | not I. I install Debian and transgrade it to Devuan. In the last weeks I did that on Pi1,2,4 ... no 3 yet. | 08:54 |
| jjakob | what's the build process for arm images? I want to customize images for rpi3's | 08:56 |
| jjakob | I saw mention of devuan arm-sdk and pyavitz/rpi-img-builder in https://arm-files.devuan.org/README.txt | 08:57 |
| yeti | Do devuan PI images now get kernel updates? | 08:57 |
| yeti | I switched to go the frankendevuan route because in that process deBIan's kernel upgrades still work after transgrading | 08:58 |
| yeti | and the last Pi4 image I tried contained customised blingbling and even unapackaged changes e.g. a MC theme... | 08:58 |
| yeti | that's as if they play artist instead of IT | 08:58 |
| yeti | I am not happy with the state of devuans PI images. unless there are news that I still havent seen. | 08:59 |
| jjakob | frankendevuan? transgrading? | 08:59 |
| yeti | installing debian and turning that into devuan | 08:59 |
| jjakob | I suspected it was that | 09:00 |
| yeti | https://www.devuan.org/os/documentation/install-guides/daedalus/bookworm-to-daedalus | 09:00 |
| yeti | for PCs that makes only sense to migrate existing installs. the x86/amd64 installers are ok | 09:01 |
| jjakob | i don't need kernel updates really cause I want to make rootfs read-only anyway (with a rw overlay in ram) | 09:01 |
| gnarface | well, we don't really consider it a case of "frankendevuan" unless you screw it up during the process :) | 09:01 |
| jjakob | if I want to update I'll just build a new image and write it to the sd card | 09:01 |
| yeti | id you only want chroot then just debootstrap it | 09:01 |
| yeti | if* | 09:01 |
| jjakob | cause it's gonna be a iot-like thing that I wouldn't want to upgrade the kernel remotely anyway or it might not boot | 09:02 |
| yeti | my PIs typically run headless and survived kernel updates | 09:03 |
| jjakob | years ago I used https://github.com/TheSin-/rpi-img-builder | 09:03 |
| yeti | https://salsa.debian.org/raspi-team/image-specs <<< feeding this with devuan repos might work | 09:05 |
| yeti | and modified packages lists... sure you dont want systemd on devuan | 09:05 |
| yeti | seems they are looking for someone to jump in there because the PI images maintainer has no tme now. turnig this into a builder for debian and devuan could make sense. | 09:07 |
| jjakob | if that's the case I'd rather fix the rpi-img-builder fork I made years ago to work with devuan, cause it has a better (to me) way of customizing the image with "plugins" | 09:15 |
| yeti | irc.oftc.net #debian-raspberrypi is the related channel | 09:16 |
| yeti | very low traffic. but they may have even better ideas. | 09:16 |
| jjakob | you can install the raspberry pi kernel package on devuan? from raspbian's repos or does devuan have it? | 09:16 |
| yeti | I haven't tried that. | 09:17 |
| jjakob | debootstrap devuan, install debian's rpi kernel, change cmdline and such appropriately, optionally install the extra raspi packages, and it would work? | 09:19 |
| yeti | better look into a debian images's fat partition first | 09:19 |
| jjakob | if the builder produces working debian images surely it does the right stuff already | 09:21 |
| yeti | kernel=vmlinuz-6.1.0-25-arm64 | 09:21 |
| yeti | no idea wether raspios still names everything just kernel.img | 09:22 |
| yeti | using debian's kernels will fit | 09:22 |
| drizzt | back | 14:02 |
| rrq | son bedtime here :) I'm still in progress of getting my arm64/ceres installer to run to completion | 14:09 |
| rrq | (it has problems using a squasfs rather than iso9660 media) | 14:10 |
| drizzt | rrq: got a (planned) power outage this morning, which I had forgotten about ... but my UPS is down and did not cover the few seconds requiered ... have to restart everything I had "running" :( | 14:13 |
| drizzt | and there's another one in the afternoon, so I do'nt think I'll reopen everything to close it again in two hours | 14:14 |
| rrq | ok.. when (if?) my installer completes, it'll prepare a "pure" devuan ceres installtion filesystem | 14:15 |
| rrq | I'll targeting one without desktop initially; just console and ssh access. | 14:16 |
| drizzt | back once again | 17:17 |
| drizzt | rrq: there's also vim which segfaults | 17:23 |
| drizzt | (at least on the original system) | 17:24 |
| drizzt | I'm moving back to devuan ceres (instead of debian sid) as the problem is the same on both (I didn't think it would yield different result, but it was worth the try) | 17:26 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!