2026-01-27.log

joschminute: if we really need another dtb for rk3588 desktop reform, then another u-boot build also needs to be added to reform-rk3588-uboot00:16
minutejosch: we don't need to build an image for it, -any is ok00:23
minutejosch: uboot sure00:23
joschminute: do other boards need a desktop reform dtb as well?00:24
minutejosch: not yet, needs to be tested00:26
joschminute: you used u-boot 2026-01-11 -- can you confirm that it works or are you on an older u-boot release? people had nvme/pci problems with 2026-01-1100:26
minutehmm i didn't have an nvme in that machine, so not a good data point yet. more tomorrow! today i had to deal a lot with imx8mplus flashing process ;/00:50
minuteusing uuu and stuff...00:50
joschminute: also, we then have for rk3588: reform2-rcore, reform2-rcore-dsi, reform-next, pocket-reform and desktop-reform. Maybe the dtbs could get unified a bit to prevent copypasting/cargoculting/bitrot? The upstream rk3588-mnt-reform2.dts has an #include "rk3588-firefly-icore-3588q.dtsi" which allows removing a few lines. Here is an attempt at making use of that: 00:52
joschhttps://source.mnt.re/reform/reform-debian-packages/-/merge_requests/15900:52
joschusing uuu?00:52
joschah uuu00:52
joschif your head has swapped in imx8m+ data right now, maybe you have some ideas on this forum thread of a imx8m+ pocket reform user who does not see anything on serial: https://community.mnt.re/t/unable-to-power-on-new-pocket-reform/4123/100:54
josch(also broken thermistor because the battery holder broke, similar to what happened to grimmware)00:55
joschminute: what do you think about enabling tags in the community forum? I often loose track whether a post was for a311d/imx8mq/imx8m+/rk3588/ls1028a and maybe it would also help other users to quickly find out whether they might be affected by a specific problem https://meta.discourse.org/t/admin-guide-to-tags-in-discourse/12104101:01
minutejosch: everything looks good in the thread, thanks for helping that user so much. i think we need to get this back for warranty inspection01:06
- voltaire28_ (QUIT: Remote host closed the connection) (~jlafon@28.162.2.93.rev.sfr.net)01:07
minutejosch: another option is the sysctl usb-c rewiring trick and UUU, but it's a bit of a hassle to set that up. we have a special bodge plug for that now @ mnt01:08
minutejosch: but it's weird that there's no serial output at all01:08
minutejosch: tags sound very good, i didn't know that was an option. would you ping me tomorrow about it?01:09
joschminute: should i merge https://source.mnt.re/reform/reform-tools/-/merge_requests/159 with the older u-boot (the one that all the other rk3588 platform have)?01:10
joschminute: sure, will do thank you!01:10
minutejosch: oh yes that would be really nice @ uboot, many thanks!01:10
minutei need to sleep very soon :D01:10
joschgood night and see you tomorrow _o/01:11
josch(same here)01:11
joschI just read the irc logs about the nvme issues of u-boot 2026-01-11 and it seems I was able to reproduce it two weeks ago with RCORE-DSI. More testing tomorrow. https://mntre.com/reform-irc-logs/2026-01-17.log.html#t10:52:5401:23
- chomwitt (QUIT: Ping timeout: 245 seconds) (~chomwitt@2a02:85f:9a3c:a200:1ac0:4dff:fedb:a3f1)01:24
* plomlompom0 -> plomlompom01:35
- AnimaInvicta (PART: !!unknown attribute: msg!!) (~AnimaInvi@88-120-179-216.subs.proxad.net)01:56
- pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0)01:57
+ pomel0 (~pomel0@user/pomel0)01:57
- mjw (QUIT: Ping timeout: 264 seconds) (~mjw@gnu.wildebeest.org)02:31
- paperManu_ (QUIT: Ping timeout: 252 seconds) (~paperManu@146.71.9.156)02:38
- xktr (QUIT: Ping timeout: 246 seconds) (~xktr@user/xktr)02:40
+ xktr (~xktr@user/xktr)02:41
- pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0)02:45
+ pomel0 (~pomel0@user/pomel0)02:48
- manis (QUIT: Ping timeout: 244 seconds) (01a66df340@185.72.67.185)03:04
- kop316 (QUIT: Remote host closed the connection) (m-6f6zq6@static.138.159.90.157.clients.your-server.de)03:06
+ kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de)03:08
- kop316 (QUIT: Remote host closed the connection) (m-6f6zq6@static.138.159.90.157.clients.your-server.de)03:08
+ kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de)03:08
- pomel0 (QUIT: Ping timeout: 244 seconds) (~pomel0@user/pomel0)03:41
+ pomel0 (~pomel0@user/pomel0)03:43
- paperManu (QUIT: Ping timeout: 255 seconds) (~paperManu@146.71.9.156)04:04
- mjv (QUIT: Remote host closed the connection) (~matt@user/reform11910)05:34
+ manis (01a66df340@185.72.67.185)07:21
+ chomwitt (~chomwitt@2a02:85f:9a3c:a200:1ac0:4dff:fedb:a3f1)07:32
joschrwa_: about the nvme issues -- do you have some time to help replicate the problem with u-boot? You'd need to "reform-flash-uboot --zero emmc" and then "reform-flash-uboot sd" to make your rk3588 load u-boot from sd-card instead of emmc and then you can experiment08:44
- chomwitt (QUIT: Ping timeout: 244 seconds) (~chomwitt@2a02:85f:9a3c:a200:1ac0:4dff:fedb:a3f1)08:58
+ chomwitt (~chomwitt@2a02:85f:9a3c:a200:1ac0:4dff:fedb:a3f1)09:20
- lanodan (QUIT: Quit: WeeChat 4.7.2) (~lanodan@nightmaremoon.hacktivis.me)10:37
+ lanodan (~lanodan@2a01:e0a:d6:9930::35)11:48
+ mjw (~mjw@gnu.wildebeest.org)11:53
joschminute: here is a MR adding desktop reform support if you'd like to try: https://source.mnt.re/reform/reform-rk3588-uboot/-/merge_requests/1812:04
- chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:85f:9a3c:a200:1ac0:4dff:fedb:a3f1)12:05
+ paperManu (~paperManu@146.71.9.156)12:35
- pomel0 (QUIT: Ping timeout: 260 seconds) (~pomel0@user/pomel0)12:40
- buckket (QUIT: Quit: buckket) (~buckket@vps.buckket.org)12:48
+ buckket (~buckket@vps.buckket.org)12:50
joschminute: i just performed one hour each of continuous cold-boots with two SSDs and am unable to see the problem where nvme isn't found by the initramfs even though one of the SSDs was the same SSD with which I was able to reproduce the problem 10 days ago.13:05
josch(i used the most recent reform-system-any image plus u-boot from the desktop reform MR)13:05
+ sevarat (~sevarat@2601:647:6511:cfac:2cba:eef:fe33:34b3)13:06
- paperManu (QUIT: Ping timeout: 246 seconds) (~paperManu@146.71.9.156)13:48
minutejosch: probably not a software issue then13:48
+ mjv (~matt@user/reform11910)13:55
joschminute: it would be great to have a professional (i.e. you) confirm this so that we can maybe merge desktop reform u-boot and create another tag?14:11
minutejosch: ok, this is about the uboot build, or the kernel, or both?14:12
joschminute: if i could reproduce the issue i could narrow it down :/14:13
joschminute: if you cannot reproduce it either on latest kernel (6.18.5) and u-boot from the desktop reform MR, then i guess this was a fluke or connected to something completely different?14:13
+ paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca)14:15
minutejosch: no i'm just asking what i should test :D14:16
minutejosch: i can install 6.18.5 and desktop reform MR uboot now on reform next, for example14:17
joschminute: if you wanted to do this anyways, please go ahead :)14:17
minutejosch: i can also install the kernel 6.18.5 on my pocket reform, but want to keep barebox at the moment14:17
joschminute: you could also try the actual desktop reform u-boot blob for your desktop reform and see if it does the right thing (i just copypasted the reform2 dts and made some slight changes)14:18
minutejosch: i can also try several nvmes in the desktop reform, which should cover classic. the mb is a 3.0 proto14:18
minutejosch: oh right14:18
joschtrying it on desktop reform should probably reveal any issues that happen on classic reform as well14:18
joschwhat i did here was to zero out u-boot on my emmc, flashed the latest reform-system-any to an sd-card, flashed u-boot to the same sd-card, popped that into classic reform with rcore-dsi and ran echo m | sudo reform-setup-encrypted-disk --force14:20
joschthen i moved /boot/extlinux away (so that a reboot would not load the system from sd-card) and did 10+ cold boots of the system on nvme14:20
joschvery mindless task but i'm still sick so i can press buttons :)14:20
minutejosch: btw we should look into removing some kernel options in uboots14:29
minutejosch: there's no desktop reform blob in that MR's pipeline https://source.mnt.re/josch/reform-rk3588-uboot/-/jobs/17968/artifacts/browse14:30
minutejosch: btw, little bug for `man reform-flash-uboot`: -i doesn't in fact imply offline and doesn't disable checksum verification14:34
minutejosch: this worked > sudo reform-flash-uboot --offline -i ./rk3588-mnt-reform2-flash.bin emmc14:34
minutedesktop reform boots normally from emmc with that uboot and kernel 6.18.5. will now put in some SSDs14:36
minutejosch: i put in 2 ssds together, samsung 970evoplus and taifast 4tb.  system does not come up. lets check serial14:39
minuteah shit, that board has some issue with serial14:40
minutejosch: didn't you change boot order? maybe nvme is preferred now and can contain unbootable stuff?14:40
minutesystem boots normally with taifast ssd removed14:41
minutehehe, there's some linux 5.15 on that samsung 970pro14:43
minuteah that was my disk i used in lx2160a14:46
minuteok, moving that disk to the main m.2 slot. system boots normally from emmc as well14:46
minuteok, disk is _not_ detected by that controller14:47
minutemhm, maybe because of BAR issues14:49
joschminute: yes, the boot order change is the only change which to me could have an effect on bootability but if nvme indeed contained unbootable stuff then that doesn't explain why it's flaky and it doesn't explain the errors on dmesg that me and rwa_ saw14:49
minute> [    4.862380] pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc14:49
minutejosch: which dmesg errors did you see, do you have a copy?14:49
minute[    4.853105] pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space14:49
minute[    4.853764] pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign14:49
minutesomething like that?14:50
joschminute: here is the log from rwa_ https://paste.sr.ht/~rwa/777f5b950927f52e690d02dfb0957f2a6a66337714:50
minuteok, i hot plugged the nvme and it comes up14:50
joschoh look, BAR issues14:50
minutejosch: ah ok. in that log there's a different issue > nvme nvme0: I/O tag 12 (000c) QID 0 timeout, disable controller14:51
minutejosch: did you encounter that exact issue as well?14:51
joschno, i only saw it once 10 days ago and didn't have serial attached back then14:51
joschi never encountered it again afterwards14:51
minutejosch: but it was that error message?14:51
minutebecause that error is from after nvme has probed on pcie14:52
minutenot a pcie probing issue14:52
joschsorry, i didn't write down the error messages in the irc log from january 17 and it's too long ago to remember14:52
minutejosch: ok, then we don't have other evidence of that particular error14:53
minutebad link here > Speed 2.5GT/s, Width x114:53
minutei mean, could be better :D14:54
minuteit works though14:54
minutebut only after hotplugging it14:54
minute(don't try that at home)14:54
joschminute: thank you for the reform-flash-uboot bug reports -- they are fixed in the develop branch, so queued for the next release14:55
minutetaifast 4tb works in mpcie (with adapter), now testing again in m.2 (pcie3.0)14:58
joschminute: about removing kernel options, clk_ignore_unused is queued for removal in that MR -- which other have to go?14:59
minutejosch: the ones about console rotation i think14:59
minutejosch: because this should be automatic since a kernel that we released a longer time ago15:00
joschah that affects multiple u-boots15:00
* mjw -> Guest6115:00
- Guest61 (QUIT: Killed (tungsten.libera.chat (Nickname regained by services))) (~mjw@gnu.wildebeest.org)15:00
* Guest3234 -> mjw15:00
minutejosch: and the issue with that is that it also rotates hdmi15:00
minutejosch: that kernel option i mean15:00
minuteok taifast 4tb doesn't work on m.2 (pcie3.0) because of BAR issues. also only when hot plugged15:01
minutethis wouldn't affect pocket reform though15:01
minutejosch: which systems did users have where the ssd didn't come up reliably, all classic reforms or any pocket reforms as well?15:01
joschthank you for reporting that the desktop reform artifact was missing, it's getting built now: https://source.mnt.re/josch/reform-rk3588-uboot/-/jobs/17971/artifacts/browse15:02
joschminute: pocket reform only had issues with a311d15:02
minutetrying pci=realloc now15:02
joschminute: rk3588 is all classic reform as far as i remember15:02
minutejosch: ok, that's a different topic then15:02
joschyes15:02
minutejosch: aha, the plot thickens then15:02
joschbut i hear that you do see issues?15:02
minutejosch: because rk3588 classic is unique because you have the big pcie3.0 controller with up to 4 lanes15:02
joschokay, have to run now sorry15:03
minutejosch: yes i have issues here with 2 ssds that don't work initially because of BAR issues. i am kind of familiar with those issues because of my GPU experiments. they recently messed with that in the kernel and caused some new issues i think15:03
minutejosch: i have a patch for that though15:03
minuteand i'll try pci=realloc now15:03
minutepci=realloc didn't help. also, kernel 6.15.3 doesn't help :D the taifast 4tb also doesn't work with older kernels.15:08
minuteprobably needs the pcie bar patch15:08
minuteworks on 6.15.3 on m.2/pcie3.0: > Sandisk Corp WD Black SN770M NVMe SSD (DRAM-less) (rev 01)15:11
minuteworks on 6.18.5 on m.2/pcie3.0: > Sandisk Corp WD Black SN770M NVMe SSD (DRAM-less) (rev 01)15:13
minuteworks as well on 6.18.5/m.2/pcie3.0: > MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) (rev 01)15:16
minute(kingspec nx 512gb)15:16
minuteworks on 6.18.5/m.2/pcie3.0: > Micron/Crucial Technology P1 NVMe PCIe SSD[Frampton] (rev 03)15:19
minute(crucial 500gb)15:20
minuteworks as well on 6.18.5/m.2/pcie3.0: > Silicon Motion, Inc. SM2263EN/SM2263XT (DRAM-less) NVMe SSD Controllers (rev 03)15:22
minute(taifast 1tb)15:22
minuteok the only issues i could find here are older BAR issues with samsung 970evo plus and taifast 4tb. i think both can be solved with a patch. but that issues is an older one15:23
minutejosch: the error log from rwa_ is with kernel 6.17.13. that isn't even 6.18.515:24
minutejosch: anyway i think we can say kernel 6.18.5 is fine for rk3588 / classic reform. the uboot question: the only thing i can imagine is that there could have been some glitch where uboot talks to the nvme because of the changed boot order, and the nvme is then in a different state than before15:26
minutejosch: before, uboot wouldn't have touched the nvme i think15:26
minutejosch: so i think you should revert the boot order and let the affected people test the newer uboot again15:26
minutejosch: but with the old boot order.15:26
minutejosch: we can try this patch to possibly make samsung evo 970pro and taifast 4tb work on the pcie3.0 controller https://source.mnt.re/reform/reform-debian-packages/-/commit/d6a458b98e0815059aa4dce28b0f914ceb600525#8b63154c1231cde7c3caa7605410d69aadbedfd415:30
+ xandy (~xandyv@user/xandyv)15:35
joschminute: okay, wonderful that you saw problems!15:51
joschabout u-boot: if we revert boot order (taking out nvme) then how do we find people affected by this?15:51
josch(i'm now making sure that taking out the fb rotation from kernel cmdline indeed works fine on pocket reform)15:52
joschanother practical issue that needs a decision is that src:mesa build is currently borked. Should we just not build mesa with the panfrost PIPE_TEXTURE_TRANSFER_BLIT patch for the time being to work around this until mesa in unstable is fixed?15:56
+ siviq (~siviq@user/siviq)16:01
minutejosch: well the problems i saw are not recent uboot or kernel related though.16:04
+ _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154)16:04
minutejosch: yes, it's ok to not build mesa for a while16:04
joschat least you saw some! :D16:05
joschokay, i'll disable it for now16:05
minutejosch: well, as long as the potentially problematic uboot is not rolled out to everyone, it's ok to release it, maybe with a warning16:05
joschminute: the funny thing was that i even added a warning to reform-flash-uboot because of the boot order and that didn't prent people from flashing that u-boot despite them having a boot.scr on their nvme ;)16:07
joschu-boot updates will always be manual16:07
joschi shall add another even more scary warning on rk3588 u-boot upgrades explaining the situation, okay?16:07
minutejosch: ahhh ok @ warning. then i don't worry anymore16:11
minutejosch: i think it's not necessary to make it scarier16:11
minutejosch: anyway we'll soon open the barebox can o'worms16:11
minutejosch: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/164/commits i've stopped my pipelines here until i can merge in your change to disable mesa build16:12
joschminute: awesome, i set this to auto-merge: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/16516:18
joschit disables mesa and backports the panel fix to the Debian stable kernel or otherwise removing the rotate arg from u-boot will break Trixie16:18
joschafter that is in main, you can rebase MR 164 and merge it16:18
joschgreat, i can confirm that as expected, fbcon=rotate:3 is no longer necessary16:26
joschminute: i'll prepare some MRs and will need your help in tagging the a new u-boot release with that change, okay?16:26
joschminute: were you able to verify that the desktop reform u-boot blob does what it's supposed to?16:27
joschkernel 6.19-rc6 is already in experimental :)16:28
minuteoh this is cool https://alexxcons.github.io/blogpost_15.html16:29
minutejosch: yep, no problem @ tagging16:30
minutejosch: no i wasn't able to very uboot beyond that it still boots what i put in extlinux.conf16:30
joschminute: first to merge and tag: https://source.mnt.re/reform/reform-imx8mp-uboot/-/merge_requests/916:37
joschnice to hear that xfce is still alive and well :)16:37
joschminute: here is the one for a311d but it seems at some point you gave me sufficent permission to do the merging and tagging myself: https://source.mnt.re/reform/reform-a311d-uboot/-/merge_requests/816:38
joschsame for rk3588 u-boot16:38
joschminute: so if you agree and would like me to, i can handle a311d and rk3588 myself16:39
gsoranice to see xfce writing new bits in rust!17:00
- sevarat (QUIT: Quit: zzz) (~sevarat@2601:647:6511:cfac:2cba:eef:fe33:34b3)17:32
+ paperManu_ (~paperManu@146.71.9.156)18:06
minutejosch: yes, please tag away!18:29
minutejosch: i gave you maintainer access now also to imx8mp uboot18:30
rwa_josch: didn't read through the whole log, but yes i can spare some time for u-boot testing if still needed18:41
+ pomel0 (~pomel0@user/pomel0)18:44
+ mark_ (~mjw@gnu.wildebeest.org)19:00
joschrwa_: yes, that would be very much appreciated!19:01
joschrwa_: it would be easiest to run "reform-flash-uboot --zero emmc" and then flash u-boot to sd-card. Then you can easily experiment without risking anything because if something fails you can just flash another u-boot to sd-card.19:02
joschrwa_: best would be if you could try the artifact from this job: https://source.mnt.re/josch/reform-rk3588-uboot/-/jobs/1797219:03
joschthat's from this MR: https://source.mnt.re/reform/reform-rk3588-uboot/-/merge_requests/1819:03
joschyou can most easily flash it by doing: reform-flash-uboot --image /path/to/image sd19:03
rwa_ok, prepared an sd card, it says there is a hash mismatch for the newly flashed uboot, but iirc this is a known issue19:14
rwa_it doesn't boot without sd card, so emmc should be correctly zeroed out19:17
joschrwa_: yes, the hashmismatch problem will be solved with the next reform-tools version.19:18
rwa_the uboot from the job linked above has the same nvme issue19:19
joschrwa_: what SSD do you have?19:19
rwa_which means it drops the initramfs rescue shell, no nvme shows up and dmesg log has something like "I/O tag 4 QUID 0 timeout"19:20
rwa_WD SN350 1TB19:20
joschrwa_: okay, i can create a u-boot build for you with the nvme commit reverted and then we can see whether that's the culprit19:20
rwa_alright19:21
joschokay, building...19:21
rwa_hm...i should have prepared another sd card with a working uboot version before :D19:21
joschrwa_: the dd command to flash the blob manually would be: dd if=/path/to/blob of=/dev/mmcblkX bs=512 seek=64 skip=0 conv=fdatasync19:24
rwa_ah, thats easy then19:26
rwa_job https://source.mnt.re/josch/reform-rk3588-uboot/-/jobs/18011 i guess?19:26
- paperManu_ (QUIT: Ping timeout: 264 seconds) (~paperManu@146.71.9.156)19:27
joschrwa_: yes that one19:28
joschtop commit is Revert "patch: reorder BOOT_TARGETS to sd, nvme, emmc, usb"19:28
joschrwa_: also, what do you have on your nvme? is it just one big luks drive or does it have unencrypted partitions on it?19:29
rwa_no luks at all, only one big unencrytped ext4 partition19:31
joschoh interesting, maybe that is connected and u-boot does something19:31
joschrwa_: the /boot folder in that partition is empty i assume?19:31
rwa_yep19:31
joschokay, but then i shall test that next19:32
rwa_and its up again19:33
rwa_with u-boot from https://source.mnt.re/josch/reform-rk3588-uboot/-/jobs/18011/artifacts/file/rk3588-mnt-reform2-dsi-flash.bin19:33
rwa_whatever the changed boot order does to u-boot...19:33
joschnice thanks a lot for trying this out!19:35
joschminute: since rwa_ seems to have a reliable reproducer i think it's better to revert the offending commit for now until somebody cares enough to investigate this more?19:36
- mjw (QUIT: Killed (platinum.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:a09a:fc1c:5a8:e74d)19:36
* mark_ -> mjw19:36
+ Guest6884 (~mjw@2001:1c06:2486:a800:a09a:fc1c:5a8:e74d)19:36
rwa_did the double check: going back to the uboot from 17972 and nvme won't come up19:37
rwa_reflashing uboot from 18011 and its up and running19:37
rwa_josch: you're welcome19:38
minutejosch: was the problem the boot order as suspected?19:39
rwa_yes19:40
minuteok great, thanks for confirming19:42
joschminute: so lets revert?19:47
joschunfortunately there is a person in the forum who is rather fond of the nvme boot order change to run guix :(19:47
rwa_iirc there was another user here on irc that reported this issue - do we know what kind of partition setup this user had?19:49
rwa_searched through the logs, seems like we don't have that information19:53
- siviq (QUIT: Ping timeout: 272 seconds) (~siviq@user/siviq)19:58
+ siviq (~siviq@user/siviq)20:03
- siviq (QUIT: Client Quit) (~siviq@user/siviq)20:03
+ anuejn (~quassel@2a03:b0c0:3:f0:0:1:9e0a:7000)20:12
minutejosch: could it be that we're not shipping git in the system image?20:34
joschminute: yes, git is not in the system image by default -- do you want it in?20:40
minutejosch: yesss... and also ncurses-bin :D20:42
joschminute: while i add that, could you enable tags in the discourse?20:43
josch(i'm absolutely for git being in the system image, one of the first things i do after booting a fresh system image is to clone git repos from source.mnt.re)20:44
minutejosch: oh right @ tags20:47
minutejosch: yeah that was just an oversight @ git20:47
minutejosch: and forces us to do apt install things in our factory image :D20:47
minutejosch: ok, tags enabled i think20:51
minutehttps://community.mnt.re/tag/a311d20:51
joschrwa_: can you send me the output of "sfdisk --dump /dev/nvme0n1" on your system?20:54
joschminute: thank you!20:55
- cli (QUIT: Remote host closed the connection) (~m-vsauiy@user/cli)20:57
+ cli (~m-vsauiy@user/cli)21:05
- cli (QUIT: Remote host closed the connection) (~m-vsauiy@user/cli)21:23
+ cli (~m-vsauiy@user/cli)21:25
rwa_josch: send you some info in a private msg21:29
joschthank you <321:29
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50)21:42
+ siviq (~siviq@user/siviq)21:53
- nsc (PART: !!unknown attribute: msg!!) (~nicolas@i5C74DEEA.versanet.de)22:06
- _justin_kelly71 (QUIT: Read error: Connection reset by peer) (~justinkel@user/justin-kelly/x-6011154)22:24
+ _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154)22:27
- siviq (QUIT: Quit: Client closed) (~siviq@user/siviq)22:32
- _justin_kelly71 (QUIT: Read error: Connection reset by peer) (~justinkel@user/justin-kelly/x-6011154)22:35
+ _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154)22:37
- _justin_kelly71 (QUIT: Read error: Connection reset by peer) (~justinkel@user/justin-kelly/x-6011154)22:46
- marty (QUIT: Ping timeout: 240 seconds) (~marty@172.59.96.54)22:46
+ marty (~marty@146.70.165.231)22:48
+ _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154)22:49
joschminute: we have experiment results. The issue rwa_ sees with u-boot 2026-01-11 and NVMe *only* exists with linux 6.17. With the most recent reform-system image from MNT and debian unstable and kernel 6.18 there is no problem even with the u-boot version 2026-01-1123:00
minutejosch: hah, weird!23:04
rwa_to say the least23:06
vagrantcbetter than the other way around...23:07
rwa_true23:08
joschhi vagrantc _o/ did you read in the forum that your guix work is getting used? :)23:08
- pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0)23:09
vagrantcjosch: probably not the forum, but a bit on the fediverse :)23:12
joschnice :)23:13
vagrantcso is u-boot 2026-01-11 ... based on upstream v2026.01 ?23:14
vagrantcACTION rummages around for the repositories to check23:14
joschvagrantc: no, we didn't change the u-boot version23:14
joschthe major change in 2026-01-11 is the boot order23:15
joschit's now sd, nvme, emmc, usb23:15
vagrantcah23:15
- paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca)23:17
+ chomwitt (~chomwitt@2a02:85f:9a3c:a200:1ac0:4dff:fedb:a3f1)23:36
+ paperManu (~paperManu@146.71.9.156)23:39
+ paperManu_ (~paperManu@146.71.9.156)23:39
- _justin_kelly71 (QUIT: Read error: Connection reset by peer) (~justinkel@user/justin-kelly/x-6011154)23:44
- xandy (QUIT: Quit: Leaving) (~xandyv@user/xandyv)23:44
+ _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154)23:48
- RandyK (QUIT: Ping timeout: 252 seconds) (~RandyK@user/randyk)23:52
+ RandyK (~RandyK@user/randyk)23:53

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!