| - sevan (QUIT: Ping timeout: 272 seconds) (~sevan@user/venture37) | 00:36 | |
| - franpoli (QUIT: Remote host closed the connection) (~fpo@46.252.5.28) | 01:09 | |
| - mjw (QUIT: Ping timeout: 248 seconds) (~mjw@gnu.wildebeest.org) | 01:11 | |
| - nsc (QUIT: Ping timeout: 265 seconds) (~nicolas@i5C74DC3A.versanet.de) | 03:21 | |
| + arminweigl_ (~arminweig@sourcehut/user/arminweigl) | 03:24 | |
| - arminweigl (QUIT: Ping timeout: 248 seconds) (~arminweig@sourcehut/user/arminweigl) | 03:26 | |
| * arminweigl_ -> arminweigl | 03:26 | |
| - aloo_shu (QUIT: Ping timeout: 252 seconds) (~aloo_shu@90.166.193.229) | 03:41 | |
| - paperManu (QUIT: Ping timeout: 244 seconds) (~paperManu@172.93.30.55) | 04:00 | |
| + aloo_shu (~aloo_shu@90.166.193.229) | 04:05 | |
| + nsc (~nicolas@i5C74DC3A.versanet.de) | 05:06 | |
| - gsora (QUIT: Ping timeout: 252 seconds) (~gsora@user/gsora) | 05:35 | |
| - Ar|stote|is (QUIT: Ping timeout: 244 seconds) (~linx@149.210.0.172) | 06:38 | |
| + Ar|stote|is (~linx@149.210.5.137) | 06:43 | |
| + chomwitt (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 06:51 | |
| - RandyK (QUIT: Remote host closed the connection) (~RandyK@user/randyk) | 07:36 | |
| + RandyK (~RandyK@user/randyk) | 07:36 | |
| + AtleoS (~AtleoS@user/AtleoS) | 07:40 | |
| + gsora (~gsora@user/gsora) | 07:40 | |
| - gsora (QUIT: Ping timeout: 245 seconds) (~gsora@user/gsora) | 07:49 | |
| - chomwitt (QUIT: Ping timeout: 265 seconds) (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 08:00 | |
| - AtleoS (QUIT: Quit: AtleoS) (~AtleoS@user/AtleoS) | 08:39 | |
| + gsora (~gsora@user/gsora) | 08:42 | |
| + mjw (~mjw@gnu.wildebeest.org) | 10:30 | |
| + andreas-e (~Andreas@2001:861:c4:f2f0::457) | 11:09 | |
| + chomwitt (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 11:22 | |
| + paperManu (~paperManu@172.93.30.55) | 12:09 | |
| + gustav28 (~gustav@c-78-82-53-72.bbcust.telenor.se) | 13:02 | |
| - mjw (QUIT: Ping timeout: 276 seconds) (~mjw@gnu.wildebeest.org) | 13:40 | |
| + mjw (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 13:57 | |
| potatoespotatoes | I'm trying to build a zfs kernel module for guix and, because of how guix works, it seems like I build the kernel /then/ the module, which the internet believes is unusual (is that unusual)? So I now have a folder for the kernel outputs (including a folder of modules), and a folder of zfs-specific kernel modules (there are two of them). Everyone in guix-land seems to build the kernel twice to merge the artifacts but that seems very | 15:02 |
|---|---|---|
| potatoespotatoes | redundant. Does anyone know if I can just add these module paths to the modules.builtin or modules.order files? Or... maybe there is a better irc channel to ask this? you all are the most expert kernel hackers I know, so I'm asking here first. | 15:02 |
| potatoespotatoes | "so I'm asking here first." really: "I am not sure were else to ask" | 15:03 |
| - bkeys (QUIT: Ping timeout: 244 seconds) (~Thunderbi@173.186.16.211) | 15:11 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:15 | |
| + bkeys1 (~Thunderbi@38-146-94-247.echocast.zone) | 15:33 | |
| - bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@66.110.201.50) | 15:35 | |
| * bkeys1 -> bkeys | 15:35 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 15:38 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 15:41 | |
| * bkeys1 -> bkeys | 15:41 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 15:55 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 15:55 | |
| * bkeys1 -> bkeys | 15:58 | |
| hramrach | potatoespotatoes: building a kernel module requires the kernel, that's normal: https://www.kernel.org/doc/html/latest/kbuild/modules.html When kmod is looking for modules it searches a specific directory which is named after the kernel version. Traditionally the kernel modules are in a 'kernel' subdirectory, and modules for additional extensions are put into separate directories in an 'update' | 16:12 |
| hramrach | subdirectory, eg. /lib/modules/6.6.6/kernel /lib/modules/6.6.6/updates/zfs | 16:12 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:25 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:25 | |
| * bkeys1 -> bkeys | 16:27 | |
| potatoespotatoes | oooh, okay. very good to know | 16:37 |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:41 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 16:41 | |
| * bkeys1 -> bkeys | 16:41 | |
| potatoespotatoes | super -- yeah, I did a full rebuild of what the guix folks usually do and it is exactly as you stated, they just seem to merge all of the folders. | 16:41 |
| potatoespotatoes | thank you hramrach! | 16:42 |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 16:50 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:50 | |
| josch | anzu: the /boot contents you sent me look just fine! Here is the serial output: https://mister-muffin.de/p/Wo7m.txt | 16:53 |
| josch | it loads the kernel, it loads the initramfs, it loads the dtb... | 16:53 |
| josch | and then it tries to find an encrypted rootfs on nvme which of course doesn't exist in my case | 16:54 |
| josch | but which it should find in your case | 16:54 |
| josch | so i think you need some serial output to get any further because as far as I can see, your /boot looks good | 16:56 |
| anzu | josch: Thank you a lot! That helps! Strange, but good that my /boot is fine :) | 16:59 |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 16:59 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 17:00 | |
| minute | josch: about the lpc battery comms work by mojyack, i'm not sure if i agree with the approach yet. i think something like CRC would be more useful (a common method), and it could be optional, so backwards compatible. also, i would like to understand better why this problem is happening at all instead of just plastering over it | 17:02 |
| * bkeys1 -> bkeys | 17:02 | |
| zeha | ack | 17:02 |
| zeha | i also dont understand what the sysctl fw changes do in the first place | 17:03 |
| zeha | "why does this help" | 17:03 |
| minute | i.e., why would SPI not be reliable? it's supposed to be more reliable than this | 17:03 |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 17:03 | |
| minute | so i guess there's just a bug somewhere | 17:04 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:10 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:10 | |
| josch | minute: understood. I don't want to make any call in this matter and will leave this completely up to you to decide how to proceed with all of this. | 17:11 |
| minute | josch: cool! | 17:12 |
| josch | i only felt that i had to comment that it's a problem to update the dkms module in a way which *requires* users to also flash a new lpc firmware... i found that not quite ideal to put it mildly | 17:13 |
| minute | yeah also the module works for a range of machines | 17:13 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:21 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 17:21 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 17:23 | |
| * bkeys1 -> bkeys | 17:23 | |
| + chomwitt (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 17:38 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:05 | |
| + bkeys (~Thunderbi@66.110.201.50) | 18:06 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 18:12 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:16 | |
| + bkeys (~Thunderbi@66.110.201.50) | 18:16 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 18:18 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 18:18 | |
| * bkeys1 -> bkeys | 18:21 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:27 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 18:27 | |
| * bkeys1 -> bkeys | 18:29 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:37 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 18:37 | |
| * bkeys1 -> bkeys | 18:40 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:48 | |
| + bkeys (~Thunderbi@66.110.201.50) | 18:48 | |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2001:861:c4:f2f0::457) | 18:48 | |
| - chomwitt (QUIT: Ping timeout: 272 seconds) (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 18:54 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:58 | |
| + bkeys (~Thunderbi@66.110.201.50) | 18:58 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 19:09 | |
| + bkeys (~Thunderbi@66.110.201.50) | 19:09 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 19:12 | |
| - mjw (QUIT: Killed (lead.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 19:14 | |
| * mark_ -> mjw | 19:14 | |
| + Guest9700 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 19:14 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 19:20 | |
| + chomwitt (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 19:27 | |
| - amk (QUIT: Remote host closed the connection) (~amk@user/amk) | 20:04 | |
| + amk (~amk@user/amk) | 20:04 | |
| - amk (QUIT: Remote host closed the connection) (~amk@user/amk) | 20:05 | |
| + amk (~amk@user/amk) | 20:18 | |
| - amk (QUIT: Remote host closed the connection) (~amk@user/amk) | 20:20 | |
| + amk (~amk@user/amk) | 20:21 | |
| - amk (QUIT: Remote host closed the connection) (~amk@user/amk) | 20:23 | |
| + amk (~amk@user/amk) | 20:29 | |
| - hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 20:58 | |
| + hairu (m-uotkmd@user/hairu) | 21:03 | |
| hramrach | there is the thing that TPM drivers also implement cheksums and retransmits so it's not unheard of that data gets corrupted. It's probably a hardware bug if that happens often enough to notice but it can happen | 21:21 |
| hramrach | but also adding the cheksumming may alter some timing or something, I recall talking to some NFC reader and it would just not respond at all but the Arduino library would work just fine, even when compiled for Linux | 21:24 |
| elb | Is there a way to get an update on order status from shop.mntre.com ? | 21:50 |
| gordon2 | elb: you can drop a message on support@mntre.com including your order number and ask for estimate, it is an official way mentioned in FAQ | 21:57 |
| elb | ok, that felt pestersome, but maybe I'm itchy enough to do that ;-) | 22:00 |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-53-72.bbcust.telenor.se) | 22:15 | |
| - chomwitt (QUIT: Ping timeout: 244 seconds) (~chomwitt@2a02:85f:9a8c:5400:1ac0:4dff:fedb:a3f1) | 22:58 | |
| - op_4 (QUIT: Ping timeout: 265 seconds) (~tslil@user/op-4/x-9116473) | 22:59 | |
| + op_4 (~tslil@user/op-4/x-9116473) | 23:13 | |
| + xha (~xha@user/xha) | 23:23 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!