| - chomwitt (QUIT: Ping timeout: 268 seconds) (~chomwitt@2a02:587:dc0c:c200:9b5d:e3:b4f7:170c) | 01:20 | |
| - mtm (QUIT: Ping timeout: 252 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:03 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@97-120-22-213.ptld.qwest.net) | 03:42 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:08 | |
| - mlarkin (QUIT: Quit: Lost terminal) (~mlarkin@047-048-086-214.biz.spectrum.com) | 05:07 | |
| + mlarkin (~mlarkin@047-048-086-214.biz.spectrum.com) | 05:07 | |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 07:37 | |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 08:36 | |
| josch | I just bought a new SSD for my reform. One from a brand that wasn't mentioned yet on the "Confirmed Working NVME Drives" forum thread to create another data point. If that drive also doesn't work with suspend, then this might be yet another 5.19 regression... sigh... | 09:37 |
|---|---|---|
| vkoskiv | Is there a quick way to switch back to 5.18 so I could confirm? I see it's still installed on my system | 09:38 |
| josch | vkoskiv: If the 5.18 kernel is still installed for you, then checking this is indeed very easy: just remove the 5.19 kernel package and make sure the 5.18 package is still installed. | 09:39 |
| josch | As long as you have at least one kernel installed, flash-kernel will take care of creating a working boot.scr for you. | 09:40 |
| josch | vkoskiv: removing your 5.19 kernel package will also remove the linux-image-arm64 package but that is okay as long as you still have linux-image-5.18.X-reform2-arm64 installed | 09:41 |
| josch | the linux-image-arm64 package is just a meta-package that depends on the latest real kernel package | 09:41 |
| vkoskiv | Cool, I'll give this a go after work | 09:59 |
| - jjbliss (QUIT: Remote host closed the connection) (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 10:00 | |
| + jjbliss (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 10:17 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 10:33 | |
| * wielaard -> mjw | 10:33 | |
| + mark_ (~mark@gnu.wildebeest.org) | 10:33 | |
| + MajorBiscuit (~MajorBisc@145.94.167.158) | 10:37 | |
| + chomwitt (~chomwitt@2a02:587:dc0c:c200:b8b0:dc:a578:bfaa) | 13:22 | |
| - mtm (QUIT: Ping timeout: 265 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:03 | |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 15:28 | |
| - MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@145.94.167.158) | 15:34 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:10 | |
| vkoskiv | I didn't see anything in apt when searching for 'kernel', 'linux' or 'image' | 17:16 |
| vkoskiv | Apparently apt just has a poorly implemented search. I found the package name by just grepping the output | 17:17 |
| vkoskiv | I borked my system. It failed to pick up 5.18, I chrooted on there from sd to rescue, but now I can't install 5.19 anymore either | 17:30 |
| vkoskiv | apt won't sync, and throws some file size mismatch error when trying to install 5.19 | 17:31 |
| josch | vkoskiv: what exactly did you run? Do you have logs? | 17:39 |
| vkoskiv | I uninstalled 5.19 and rebooted, it didn't come up | 17:39 |
| josch | vkoskiv: but do you have logs of your removal? | 17:39 |
| vkoskiv | Then booted off SD, chrooted to nvme, tried running that flash-kernel tool but it threw some error | 17:40 |
| vkoskiv | I do not. | 17:40 |
| josch | what error did it throw? | 17:40 |
| vkoskiv | Couldn't find dtb | 17:42 |
| josch | vkoskiv: for 5.18? What is the contents of your /boot? | 17:44 |
| josch | vkoskiv: when you install, upgrade and remove the kernel, make sure to have the correct /boot partition mounted. | 17:44 |
| vkoskiv | I have the emmc mounted under /boot, yeah. | 17:45 |
| vkoskiv | Reinstalling 5.18 yields a different error, it just says it couldn't be downloaded | 17:46 |
| vkoskiv | And apt update won't sync because gpg is missing for whatever reason | 17:46 |
| josch | Yes, you cannot re-install 5.18 after removing it because it's not available in the repos anymore. | 17:47 |
| vkoskiv | (Even though the packages are in $PATH) | 17:47 |
| josch | What is the precise gpg error message? | 17:47 |
| vkoskiv | So I need to fix flash-kernel | 17:47 |
| vkoskiv | apt says: E: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed | 17:48 |
| vkoskiv | It didn't look hard enough - gpgv is installed | 17:48 |
| josch | This sounds like your system is broken somehow. The apt package directly depends on gpgv or gpgv2 or gpgv1. | 17:49 |
| vkoskiv | Yeah, but again, it *is* installed and available in $PATH | 17:50 |
| vkoskiv | I don't know how to fix this. | 17:52 |
| + MajorBiscuit (~MajorBisc@145.94.167.158) | 17:55 | |
| - MajorBiscuit (QUIT: Client Quit) (~MajorBisc@145.94.167.158) | 17:55 | |
| josch | vkoskiv: what exactly did you run to generate the error? | 17:57 |
| vkoskiv | flash-kernel | 18:01 |
| josch | vkoskiv: are you sure? flash-kernel does nothing with apt or gpgv | 18:03 |
| vkoskiv | And it just says it can't find the dtb for imx8mq | 18:03 |
| vkoskiv | I'd like to just reinstall 5.19 again but that's a different error, it says the package is invalid on the remote end | 18:05 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 18:05 | |
| josch | vkoskiv: did you run "apt update"? | 18:05 |
| vkoskiv | I did, which yielded that gpgv error | 18:05 |
| josch | ah that's where that comes from | 18:05 |
| vkoskiv | Yeah, I might have not been clear | 18:05 |
| josch | at least I'm left very confused what you ran in which order and what generated what error | 18:06 |
| josch | it would've greatly helped to keep a log with the commands you ran and the output they generated | 18:06 |
| vkoskiv | Sorry, it takes too long to copy that stuff off the screen | 18:06 |
| josch | vkoskiv: the reform has the trackball activated by default which lets you copypaste even when not in wayland | 18:08 |
| josch | vkoskiv: I'm not expecting you to manually type anything :) | 18:08 |
| vkoskiv | I can't paste things anywhere - the system barely works as is | 18:09 |
| vkoskiv | I can't even do dns queries without messing around with it first | 18:09 |
| josch | vkoskiv: can you connect via serial? That might make it easier to copypaste | 18:09 |
| vkoskiv | No adapter. | 18:09 |
| josch | oh :( | 18:10 |
| josch | vkoskiv: are you still around in a few hours? Solving this might take a bit longer and my daughter only goes to bed in about ~2 hours. | 18:10 |
| vkoskiv | Movie night a bit later, maybe | 18:11 |
| vkoskiv | where are dtbs normally held | 18:11 |
| josch | vkoskiv: in /boot there is a dtbs subdirectory as well as symlinks into it | 18:11 |
| vkoskiv | Ah, I see the 5.18 dtbs are missing from under /boot | 18:11 |
| vkoskiv | Only 5.19 | 18:11 |
| vkoskiv | So the core issue is the 5.19 package being corrupt, the size is unexpected | 18:12 |
| josch | vkoskiv: you correct that by running "apt update" | 18:12 |
| vkoskiv | hold up, a different error now with update | 18:13 |
| vkoskiv | /usr/bin/apt-key: 95: cannot create /dev/null: permission denied | 18:13 |
| vkoskiv | but /dev/null already exists, so that makes no sense | 18:13 |
| vkoskiv | No need to create it. | 18:14 |
| vkoskiv | I'm guessing I did the chroot wrong somehow, but no idea why that is | 18:15 |
| vkoskiv | I mounted root and /boot, that should be it | 18:16 |
| josch | vkoskiv: no, you need to bind-mount /dev | 18:18 |
| josch | unless you are only doing very basic things, before entering the chroot you also might want to mount this: | 18:18 |
| josch | mount -o bind /dev "$MOUNTROOT/dev" | 18:19 |
| josch | mount -t sysfs sys "$MOUNTROOT/sys" | 18:19 |
| josch | mount -t proc proc "$MOUNTROOT/proc" | 18:19 |
| josch | These mounts are definitely necessary when you do things around installing, upgrading or removing kernels | 18:19 |
| josch | this is what reform-boot-config does, for example to be able to run update-initramfs -u | 18:20 |
| vkoskiv | Done,and now apt update works! | 18:20 |
| josch | hah | 18:20 |
| vkoskiv | Installing 5.19, should be good to go now. | 18:20 |
| vkoskiv | And I learned more about chrooting, so win-win! | 18:21 |
| vkoskiv | Thanks for the help! | 18:21 |
| josch | no problem, glad it worked now! | 18:21 |
| vkoskiv | I'll retry regression testing 5.18 now that I can fix this state. | 18:21 |
| vkoskiv | So I'll uninstall 5.19 again and then I'll try running flash-kernel right after, instead of rebooting first | 18:22 |
| josch | vkoskiv: i thought you were missing the 5.18 dtb? | 18:23 |
| josch | vkoskiv: if the 5.18 package is still installed, there is no need to run flash-kernel manually | 18:23 |
| josch | vkoskiv: what is your output when you run this "dpkg -l | grep linux-image | grep 5.18" | 18:24 |
| vkoskiv | It just lists that package | 18:24 |
| josch | if it lists the package, then that's good | 18:24 |
| josch | but then you should also have the dtb | 18:24 |
| vkoskiv | ii linux-image-5.18.0-reform2-arm64 5.18.14-1+reform1 arm64 Linux 5.18 for 64-bit ARMv8 machines | 18:25 |
| josch | that looks good | 18:25 |
| vkoskiv | vkoskiv@reform:~$ ls /boot/dtbs/ | 18:25 |
| vkoskiv | 5.19.0-reform2-arm64 boot freescale | 18:25 |
| josch | that's missing a 5.18 folder | 18:26 |
| josch | without that folder it will not boot i'm afraid :( | 18:26 |
| vkoskiv | Yeah. Not sure what happened to it. I didn't delete it. | 18:27 |
| vkoskiv | I do appreciate how apt has that extra check to make sure I want to actually remove the kernel :D | 18:31 |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 18:41 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mark@gnu.wildebeest.org))) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:58 | |
| * mark_ -> mjw | 18:58 | |
| + wielaard (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:59 | |
| + ajr (~ajr@user/ajr) | 19:03 | |
| minute | josch: would it be possible to include some modules in our kernel instead of having them as modules? otherwise we would need to do some deeper debugging on their interactions, and fix a lot of oopses that happen when unloading/reloading | 19:31 |
| minute | josch: the modules in question are (so far): mxsfb, nwl-dsi, imx_dcss | 19:33 |
| minute | if you do `rmmod nwl-dsi` and then `rmmod mxsfb` it will crash the system | 19:33 |
| minute | josch: also, `rmmod nwl-dsi; modprobe nwl-dsi; rmmod mxsfb; modprobe mxsfb` does not crash, but then the display is blank | 19:38 |
| minute | (it then complains: `mxsfb 30320000.lcd-controller: [drm] Cannot find any crtc or sizes`) | 19:40 |
| josch | minute: yes, we can run any kernel config we want. | 19:57 |
| minute | josch: my motivation is that i still get a blank display on 50% of boots with `reform-display dual` configuration | 19:58 |
| josch | minute: the downside of not building them as modules is, that then we will always be stuck with our self-built kernel as the problems will not get fixed | 19:59 |
| minute | josch: yeah, that's true | 19:59 |
| minute | `rmmod mxsfb; modprobe mxsfb` makes the display work again in such a state :| | 20:00 |
| josch | minute: if you want to build anything into the kernel just add the option to https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/config | 20:01 |
| josch | That list can be greatly reduced btw. These days, only CONFIG_DRM_CDNS_HDMI_CEC=m and CONFIG_DRM_IMX_CDNS_MHDP=m should be necessary. Once I find some time I test it out. | 20:09 |
| josch | My plan was to get this list down to zero as more stuff gets merged upstream but that effort seems to be stalled. | 20:09 |
| minute | yeah, there are some unnecessary items there | 20:10 |
| minute | i'm playing with reordering things in /etc/initramfs-tools/modules and doing `update-initramfs -v -u -k 5.19.0-reform2-arm64` but not sure if it makes a difference | 20:11 |
| minute | i.e. i don't know exactly how /etc/initramfs-tools/modules is processed | 20:11 |
| josch | vagrantc has a better understanding of that part | 20:12 |
| minute | i have a feeling that the order of the lines in the file is not respected? | 20:12 |
| josch | one sec, I'm reading the sources... | 20:12 |
| minute | in any case, i guess it boils down to a bug in mxsfb | 20:13 |
| minute | because if there's a blank screen where i can log in, it means a framebuffer console is created even if it is not correctly set up | 20:14 |
| josch | minute: the module ordering comes from the kernel and is encoded in /lib/modules/*/modules.order | 20:16 |
| minute | ahh | 20:17 |
| josch | it seems that initramfs-tools relies on what depmod and modules.dep think is the correct order | 20:23 |
| minute | do these refer to modules.order or again other files? | 20:25 |
| minute | initramfs-tools does not seem to respect modules.order at least. | 20:26 |
| minute | josch: nevermind, i think it's better to debug exactly what is going on in mxsfb | 20:41 |
| minute | / lcdif | 20:41 |
| minute | in the failing case, we get `[ 7.171135] mxsfb 30320000.lcd-controller: [drm] Cannot find any crtc or sizes`. in the working case, we get `[ 7.451390] mxsfb 30320000.lcd-controller: [drm] fb0: mxsfb-drmdrmfb frame buffer device` | 20:42 |
| q66 | minute: https://github.com/chimera-linux/cports/compare/3b274afdfbff...b4c6362d0c55 , https://github.com/chimera-linux/chimera-live/commit/fec14ef742c364ad1d73045c4fbb556f902c193d | 20:57 |
| minute | q66: exciting! | 21:00 |
| q66 | if you see anything outright wrong, lemme know, otherwise i can probably prepare an image for somebody to test | 21:00 |
| minute | q66: is this building mainline u-boot? | 21:03 |
| q66 | it's your downstream repo | 21:03 |
| q66 | i don't think mainline has support at the moment, does it | 21:04 |
| minute | ugh https://source.mnt.re/reform/reform-boundary-uboot/-/jobs/883 | 21:06 |
| q66 | yeah that's because somebody updated the blobs/code and only shoved extra vars into the dotconfig without updating kconfig accordingly | 21:07 |
| minute | ah, so that's what you're patching | 21:07 |
| q66 | yeah | 21:07 |
| minute | q66: thanks, i imported this here https://source.mnt.re/reform/reform-boundary-uboot/-/commit/c3da64bdd2b79e5b55e4e100e3652a54adc4e08e | 21:16 |
| q66 | cool | 21:17 |
| q66 | i diffed the dotconfigs pre and post refresh and they seem the same | 21:17 |
| q66 | so it should be ok | 21:17 |
| q66 | https://repo.chimera-linux.org/live/testing/ feel like giving it a quick boot? | 21:19 |
| q66 | i'd like to know if it actually works | 21:19 |
| q66 | and if not, why doesn't it | 21:19 |
| josch | minute: okay, so I've done a more thorough reading of the initramfs-tools sources and from what I understand, the order of entries in /etc/initramfs-tools/modules *is* honored, *but* for each entry, `modprobe --all --show-depends` is executed to figure out its dependencies that are then also copied over and loaded in the order of dependencies that modprobe printed. | 21:22 |
| - jackhill (QUIT: Remote host closed the connection) (~jackhill@kalessin.dragonsnail.net) | 21:33 | |
| josch | minute: I'm now quite sure that above is correct. After changing /etc/initramfs-tools/modules, your selection is stored in /conf/modules in the initramfs. The initramfs on my reform (you can unpack it using unmkinitramfs) contains exactly the contents of my /etc/initramfs-tools/modules without any reordering. The load_modules() function in /scripts/functions then does a "while read -r m; do | 21:40 |
| josch | /sbin/modprobe; done < /conf/modules" | 21:40 |
| josch | So your manual order of /etc/initramfs-tools/modules is definitely preserved and the effect you are seeing might be because the kernel decides to load other modules in surprising ways when modprobing one of those. | 21:41 |
| + jackhill (~jackhill@kalessin.dragonsnail.net) | 21:42 | |
| * jackhill -> KM4MBG | 21:42 | |
| * KM4MBG -> jackhill | 21:43 | |
| minute | josch: thanks for the thorough analysis! | 22:06 |
| minute | q66: i can definitely try tomorrow; already cycled home when you wrote this | 22:06 |
| josch | blame vagrantc not being online tonight ;) | 22:06 |
| q66 | alright | 22:09 |
| q66 | if somebody else feels like trying it in the meantime, go ahead :p | 22:09 |
| vkoskiv | q66: Just flash to sd card and boot? What is the expected outcome? | 22:11 |
| + ggoes (~gregf@fsf/staff/ggoes) | 22:11 | |
| q66 | vkoskiv: yeah just that | 22:12 |
| q66 | the expected outcome is that the system boots | 22:12 |
| vkoskiv | Alright, I'll give it a go. | 22:12 |
| q66 | it should get you a getty on both the display and the serial console | 22:12 |
| vkoskiv | I can only test display for now, my serial adapter doesn't have the right cable/connector yet | 22:13 |
| q66 | that's alright | 22:13 |
| - ggoes (QUIT: Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) (~gregf@fsf/staff/ggoes) | 22:19 | |
| vkoskiv | Writing to SD | 22:24 |
| q66 | you decompressed the image first right | 22:24 |
| q66 | just checking :P | 22:24 |
| vkoskiv | Of course. | 22:24 |
| q66 | cool | 22:24 |
| + ggoes (~gregf@fsf/staff/ggoes) | 22:26 | |
| - ggoes (QUIT: Remote host closed the connection) (~gregf@fsf/staff/ggoes) | 22:26 | |
| vkoskiv | Rebooting | 22:27 |
| vkoskiv | I think I need to flip my boot switch | 22:27 |
| vkoskiv | Flipped boot switch on SoM, nothing happens when I boot | 22:32 |
| q66 | hm, alright | 22:32 |
| q66 | without serial console it's impossible to know what happens | 22:32 |
| q66 | oh well | 22:32 |
| vkoskiv | So only a binary result, sadly - no worky :D | 22:32 |
| q66 | maybe minute can provide some insight later | 22:33 |
| q66 | maybe i screwed something up in the code that writes u-boot | 22:33 |
| q66 | or maybe my kernel is bad | 22:33 |
| + ggoes (~gregf@fsf/staff/ggoes) | 22:34 | |
| vkoskiv | There are several moving parts, as I understand it. | 22:34 |
| vkoskiv | :D | 22:34 |
| - ggoes (QUIT: Remote host closed the connection) (~gregf@fsf/staff/ggoes) | 22:34 | |
| q66 | quite | 22:43 |
| q66 | without a serial cable it's difficult to know which one is moving wrong | 22:43 |
| + ggoes (~gregf@fsf/staff/ggoes) | 23:17 | |
| - ggoes (QUIT: Remote host closed the connection) (~gregf@fsf/staff/ggoes) | 23:18 | |
| + ggoes (~gregf@fsf/staff/ggoes) | 23:22 | |
| - ggoes (QUIT: Remote host closed the connection) (~gregf@fsf/staff/ggoes) | 23:23 | |
| + ggoes (~gregf@fsf/staff/ggoes) | 23:30 | |
| - ggoes (QUIT: Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) (~gregf@fsf/staff/ggoes) | 23:39 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!