2022-03-28.log

- GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon)00:05
+ GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon)00:05
+ S0rin (~S0rin@user/s0rin)00:24
- S0rin (QUIT: Ping timeout: 256 seconds) (~S0rin@user/s0rin)00:33
- Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf6eb5.dip0.t-ipconnect.de)00:44
+ S0rin (~S0rin@user/s0rin)00:46
+ MajorBiscuit (~MajorBisc@2a02:a461:129d:1:193d:75d8:745d:e91e)01:18
- sl (QUIT: Quit: Lost terminal) (~sl@beastie.sdf.org)01:20
- mtm (QUIT: Ping timeout: 268 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)02:03
- MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@2a02:a461:129d:1:193d:75d8:745d:e91e)02:30
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)04:09
- xktr (QUIT: Ping timeout: 256 seconds) (~xktr@37.120.147.5)04:52
+ xktr (~xktr@37.120.147.5)04:53
+ sl (~sl@beastie.sdf.org)05:53
- xktr (QUIT: Ping timeout: 240 seconds) (~xktr@37.120.147.5)06:03
+ xktr (~xktr@37.120.147.6)06:05
- sbp (QUIT: *.net *.split) (~sbp@tea.infomesh.net)06:35
- joeyh (QUIT: *.net *.split) (~joeyh@kitenet.net)06:35
- flowy (QUIT: *.net *.split) (~flowy@2a01:4f8:c0c:1a8f::1)06:35
- skalk_ (QUIT: *.net *.split) (~skalk@vond.sysret.de)06:35
+ sbp (~sbp@tea.infomesh.net)06:35
+ joeyh (joeyh@kitenet.net)06:35
+ skalk (~skalk@vond.sysret.de)06:36
+ flowy (~flowy@2a01:4f8:c0c:1a8f::1)06:36
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.6)08:04
+ xktr (~xktr@37.120.147.5)08:11
- mrus (QUIT: Ping timeout: 240 seconds) (~mrus@gateway/tor-sasl/mrus)08:12
+ mrus (~mrus@gateway/tor-sasl/mrus)08:15
- mrus (QUIT: Remote host closed the connection) (~mrus@gateway/tor-sasl/mrus)08:25
+ mrus (~mrus@gateway/tor-sasl/mrus)08:26
- GNUmoon (QUIT: Ping timeout: 240 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon)08:53
- xktr (QUIT: Ping timeout: 246 seconds) (~xktr@37.120.147.5)09:03
- Lewis[m] (QUIT: Quit: Bridge terminating on SIGTERM) (~lewislewi@2001:470:69fc:105::e363)09:19
- scops (QUIT: Quit: Bridge terminating on SIGTERM) (~scopstchn@2001:470:69fc:105::8da)09:19
- indefini[m] (QUIT: Quit: Bridge terminating on SIGTERM) (~indefinim@2001:470:69fc:105::1e2a)09:19
+ xktr (~xktr@37.120.147.5)09:20
+ scops (~scopstchn@2001:470:69fc:105::8da)09:23
+ Lewis[m] (~lewislewi@2001:470:69fc:105::e363)09:26
+ indefini[m] (~indefinim@2001:470:69fc:105::1e2a)09:26
+ leonardo (~leonardo@user/leonardo)09:28
- sbp (QUIT: Changing host) (~sbp@tea.infomesh.net)09:43
+ sbp (~sbp@apache/doge/sbp)09:43
+ oomono (uid328183@id-328183.tinside.irccloud.com)10:01
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.5)10:04
+ xktr (~xktr@37.120.147.6)10:05
+ MajorBiscuit (~MajorBisc@86.88.79.148)10:45
- dj-death (QUIT: Ping timeout: 240 seconds) (~djdeath@vps-8659ed31.vps.ovh.net)10:49
- xktr (QUIT: Ping timeout: 246 seconds) (~xktr@37.120.147.6)11:23
+ mjw (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440)11:24
+ xktr (~xktr@37.120.147.5)11:40
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440)12:00
+ mjw (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440)12:28
+ Christoph_ (~Christoph@p54bf6380.dip0.t-ipconnect.de)13:02
- scops (QUIT: Quit: User was banned) (~scopstchn@2001:470:69fc:105::8da)13:05
- Lewis[m] (QUIT: Quit: User was banned) (~lewislewi@2001:470:69fc:105::e363)13:05
- indefini[m] (QUIT: Quit: User was banned) (~indefinim@2001:470:69fc:105::1e2a)13:05
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.5)13:43
- mtm (QUIT: Ping timeout: 272 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)14:04
+ adjtm (~adjtm@4.red-83-52-193.dynamicip.rima-tde.net)14:05
+ xktr (~xktr@37.120.147.6)14:15
- xktr (QUIT: Quit: leaving) (~xktr@37.120.147.6)14:39
+ scops (~scopstchn@2001:470:69fc:105::8da)14:48
+ indefini[m] (~indefinim@2001:470:69fc:105::1e2a)14:51
+ Lewis[m] (~lewislewi@2001:470:69fc:105::e363)14:51
- chomwitt (QUIT: Ping timeout: 256 seconds) (~chomwitt@2a02:587:dc18:da00:e2ec:eb52:4039:9bfe)14:55
+ chomwitt (~chomwitt@athedsl-352218.home.otenet.gr)14:56
+ xktr (~xktr@37.120.147.6)15:04
- chomwitt (QUIT: Read error: Connection reset by peer) (~chomwitt@athedsl-352218.home.otenet.gr)15:12
- MajorBiscuit (QUIT: Ping timeout: 260 seconds) (~MajorBisc@86.88.79.148)15:23
+ MajorBiscuit (~MajorBisc@86-88-79-148.fixed.kpn.net)15:24
- adjtm (QUIT: Ping timeout: 256 seconds) (~adjtm@4.red-83-52-193.dynamicip.rima-tde.net)15:32
- xktr (QUIT: Ping timeout: 256 seconds) (~xktr@37.120.147.6)15:44
+ xktr (~xktr@37.120.147.186)15:51
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net)16:09
- qbit (QUIT: Quit: WeeChat 3.3) (~qbit@h.suah.dev)16:14
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.186)16:44
+ qbit (~qbit@h.suah.dev)16:54
+ xktr (~xktr@37.120.147.186)17:11
- xktr (QUIT: Quit: leaving) (~xktr@37.120.147.186)17:23
- MajorBiscuit (QUIT: Ping timeout: 246 seconds) (~MajorBisc@86-88-79-148.fixed.kpn.net)17:24
- Ar|stote|is (QUIT: Ping timeout: 272 seconds) (~linx@149-210-29-113.mobile.nym.cosmote.net)17:52
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440)18:43
+ xktr (~xktr@37.120.147.186)19:16
+ adjtm (~adjtm@2a0c:5a80:1c01:3a00:b499:a8d6:4d3e:78e8)19:25
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20)20:23
+ buckket (~buckket@pdp8.buckket.org)21:08
joschminute: my current patch to flash-kernel calls the imx8mq based reform "MNT Reform 2" is that okay? Does that make sense with having future alternative CPU modules in mind? What will the naming scheme be?21:41
joschContext: I'm preparing a merge request with "MNT Reform 2" and "MNT Reform 2 HDMI" for the flash-kernel package and it would be nice if that naming was final and we don't have to change it later when more CPU board options for the reform become available.21:44
minutejosch: that's a very good question21:47
minutemaybe you could call it "MNT Reform (i.MX8MQ)" and "MNT Reform (i.MX8MQ) HDMI"21:48
minutethe 2 is more like an internal thing that end users don't really see21:48
vagrantcit should generally be whatever is in the upstream device tree, no?21:48
joschYes. The dtb is called freescale/imx8mq-mnt-reform2.dtb21:49
vagrantcthe "model" property in the devicetree itself21:50
joschThat would be "MNT Reform 2"21:51
vagrantcthat's what flash-kernel uses to distinguish between different boards21:51
joschI thought it uses the value of the Machine: field?21:51
vagrantcit compares the device-tree model property with the Machine: field in flash-kernel's database ... so ... yes? :)21:52
vagrantcat least, that's what it uses to detect which Machine entry to use ...21:52
vagrantcif you're forcing which machine entry, of course it doesn't matter21:53
joschHrm... I'm not quite sure I fully understand yet. Currently we are using this patch: https://source.mnt.re/reform/reform-debian-packages/-/blob/main/patches/flash-kernel21:54
joschAnd then write the desired Machine (HDMI or not) into /etc/flash-kernel/machine21:55
joschvagrantc: does that look correct?21:55
vagrantci see. yeah, that works also, though it detects the default from the running device-tree if you don't force it through /etc/flash-kernel/machine21:55
vagrantci *think* some of those values are extraneous, but it's been a while since i've paid too much attention to flash-kernel21:56
joschvagrantc: I think we want to force it because the user needs to be able to switch between normal and HDMI, no?21:56
vagrantcsure21:57
vagrantcI don't think you need Boot-Kernel-Path Boot-Initrd-Path U-Boot-Kernel-Address U-Boot-Initrd-Address22:00
vagrantcsince you're using bootscr.uboot-generic22:00
vagrantcunless your u-boot doesn't support raw initrd ...22:01
joschvagrantc: Thanks, good to know! I'll test it once the world isn't broken anymore due to the recent upload of python3-defaults :)22:07
vagrantci've mostly moved away from flash-kernel to using u-boot-menu generated "extlinux.conf" instead, as it presents a simple boot menu and is a little simpler to set up, but has a little less flexibility22:11
vagrantce.g. most of the arm64 debian-installer hooks are either EFI or extlinux.conf ... don't think we have any boot scripts there anymore22:12
joschvagrantc: extlinux works on architectures other than amd64, i386 and x32?22:13
vagrantcwish i could figure out why i can't get mainline u-boot to work anymore...22:14
vagrantcjosch: it's stupidly named extlinux.conf .... it's actually just a boot configuration file format that u-boot knows how to read22:14
joschah okay22:14
vagrantci saw some patches for u-boot to support yet another newer even better bestesteverever format for booting ... it did in fact sound better.22:16
vagrantcthough, typically on newish boards u-boot supports boot scripts, the syslinux-style configuration and using it's EFI implementation ... so a whole new format ... well ... hrm.22:17
joschThe u-boot-menu package description suggests that flash-kernel is still needed to prepare the correct dtb.22:18
vagrantconly if you have a split /boot partition22:20
joschWe do.22:20
vagrantcwell then :)22:20
vagrantcthere's also an example in u-boot-menu to copy the .dtb files into /boot22:21
vagrantcwhich is helpful if you might boot a given image on different hardware22:21
vagrantcbut if you know what hardware you're running on, then it's not needed22:22
vagrantcor rather, flash-kernel is fine22:22
joschI forgot why we need a separate /boot partition but found the reason in the chat logs. Phew... Now documented so that future-me doesn't have to grep chat logs again. :)22:29
sigridwas it "filesystems not supported by u-boot"? :)22:32
sigridfde?22:32
vagrantcnvme?22:32
joschFull disk encryption is one reason. The other is, that when the root filesystem is on another partition than the boot medium, then we need to mount the partition containing the kernel to /boot or otherwise upgrades to the kernel will take no effect. But if we don't have a separate /boot partition, then mounting the SD-Card partition to /boot will result in /boot/boot placing kernel, initramfs and dtb at 22:36
joschthe wrong location.22:36
vagrantcACTION squints22:37
joschvagrantc: do you see a problem?23:52
vagrantcwhat's placing the kernel/dtb/initrd at the /boot/boot/ location ... sounds buggy23:55
vagrantcoh, is it flash-kernel? are you creating a vmlinuz and initrd.img with u-boot headers (often called uImage or uInitrd) ?23:57
joschvagrantc: If I don't have a separate /boot partition, then the files u-boot needs will be in a subdirectory of / called boot. If I mount that partition at /boot then I will now have /boot/boot23:57
joschBut I need to be able to modify those files or otherwise kernel upgrades will be without effect.23:58
vagrantcwhy can't you just rely on your kernel packages to install kernel updates?23:59
joschthey do23:59
joschBut they have to install those updates onto the SD-Card23:59

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