IRC channel logs
2022-12-24.log
back to list of logs
<nckx>ACTION really wants to switch to Linux instead. <GNUtoo>I think we have something in Guix already, but I've no idea how to use it or if it works, there is something called "heads" <GNUtoo>"Completion of initial port of Bochs BIOS code to gcc." <GNUtoo>It was probably known as legacybios before if I understood it right <nckx>Yeah, I want something like Heads, but different enough not to use Heads :) <nckx>Unfortunately, using Guile isn't feasible. <GNUtoo>Ah maybe you're looking for stuff like kexecboot or linuxboot ? <GNUtoo>Was Linuxboot used on the Talos II or was it yet another project? <nckx>A handful of Guixers have those but I'm not sure they IRC. <lechner>ConvolutedSquare / Please read up on RAID recovery under Btrfs. Some folks here use it for that purpose (wink, wink) but my own experience was terrible. I run Btrfs on top of mdadm, despite the missing features. Please try to boot with one drive removed and see if you are actually able to recover your Btrfs setup as easily as with mdadm. <GNUtoo>kexecboot also had a gui and it was pretty small <nckx>To put it bluntly, btrfs's ‘degraded’ option semantics are basically broken at a design level, so it'll never work exactly as it should. <ConvolutedSquare>lechner: thanks for the warning, will test it out later and report back. When was the lsst time you tried it? <GNUtoo>hmmm kexecboot website seems to be replaced by something else so petitboot might be better + it's used by the Talos II so it might maintained <nckx>GNUtoo: If I ever get enough round tuits to dare do this, I'd want to build it from scratch (well, from Linux, and Guix if at all possible, but that's unlikely :) <Mystified> [ Error writing /run/current-system/configuration.scm: Read-only file system ] <GNUtoo>It's probably just a matter of packaging it in Guix and adding it to the initramfs somehow <nckx>Mystified: Copy it to /etc/guix, make it writable, edit it, and run ‘guix system reconfigure /etc/guix/configuration.scm’. <nckx>GNUtoo: Also, seeing the kernel balloon every release is demotivating. <GNUtoo>kexecboot used klibc, for petitboot I don't know but it doesn't look that complicated to package <GNUtoo>Ahh if you want to put it in flash, you indeed also need a kernel configuration <ConvolutedSquare>By the way, if this does work, would it be considered a GRUB bug? Since BTRFS documentation explicity states a RAID array can be created over the devices, no partitions needed <lechner>ConvolutedSquare / maybe seven or eight years ago, but as the mdadm maintainer in another OS i saw a fundamental disagreement with what i think people expect. (see the "degradation semantics" above) the email nckx posted above from 2019 more or less described my situation, as well <nckx>The whole thing goes in flash. I really don't think Guile is feasible. At least not at my level of skill & free time. I'd rather not fork anything. <GNUtoo>Indeed, though you can use XZ compression at least <nckx>ConvolutedSquare: It could be, or something about the way we call GRUB. If this turns out to be the issue, I'm already glad we found it, and it should be trivial to write a VM reproducer to debug it more comfortably. <nckx>ACTION gets flashbacks from GRUB's abnormal mode :-/ <GNUtoo>The issue is also that Guix isn't OpenWRT / LibreCMC so it probably doesn't have support for advanced stripping and so on <GNUtoo>*more aggressive stripping (like with sstrip) <Mystified>so copy the whole file int "/etc/guix" as this file is not listed in the directory ? <GNUtoo>kexecboot uses klibc so it should be pretty small but it's probably not maintained anymore, not sure <nckx>GNUtoo: Yeah, that would be done ‘manually’. Still, one can use Guix as a build system like any other, and it's more composable (IMO) than Makefiles or shell. <GNUtoo>Well I guess that the packages would look like the heads ones with the libc and everything in 1 package <nckx>Mystified: You… don't. I'm not sure I understand you, but ‘chmod +w FILE’ makes the text file you want to edit writable. Maybe you'll need to ‘sudo chown YOUR_USERNAME FILE’ it first. <nckx>I also don't understand your previous message, sorry. Yous said /run/current-system/configuration.scm existed. If you cp that to /etc/guix, it should do the right thing. <ConvolutedSquare>also, next up is installing Guix on my ARM QNAP. That should be a joy :D <nckx>TIL (because I never looked it up) that the hf implies 7+. <GNUtoo>Ah no, QNAP is a company name, so they probably made more recent devices <nckx>Mystified edited their IRC client binary but made a typo. <nckx>ACTION yawns. I think I'm off. Good luck, ConvolutedSquare, may your misadventures at least lead us all to knowledge. o/ <ConvolutedSquare>GNUtoo: No this is an old system. I think it's the TS-420U which sports a "Marvell 1.6GHz". Not sure what arch it is <ConvolutedSquare>nckx: gnight, thanks for the assistance! And getting rid of proprietary software is always a fun adventure :) <GNUtoo>There is a ts419 supported in Linux, and that one is armv6 (kirkwood) <ConvolutedSquare>Grub is complaining with the exact same error, even with the partitioned drives :( but now ls returns "(hd0) (hd1) (hd1,gpt1) (hd2) (hd2,gpt1)" <GNUtoo>The dts doesn't seem that complicated but you'll probably have to add armv6 support to Guix <ConvolutedSquare>Trying to ls (hd1,gpt1) gives "filesystem is unknown" and "error: no signature" <ConvolutedSquare>GNUtoo: i thought it was already supported? Or is that a different arm version? <GNUtoo>I'd need to double check because here I just did a quick check, but if my memory is good the sheevaplug at least was armv6 <GNUtoo>And guix arm-linux-gnueabihf is armv7 with vfp / hard float <GNUtoo>If the SOC you have is ARMv7 that would make the thing much less time consuming <GNUtoo>Maybe linux has that info though <GNUtoo>In any case, if it's armv6, I've also an armv6 computer and there is even some old free software bootloaders for some old armv6 raspberry PI in Guix, so it might be possible to do it still if more people try to help <ConvolutedSquare>I cant even check the model number because they put it in the most inconvenient position possible: on the bottom of the device towards the back, and i cant unrack it right now <msgilligan[m]><nckx> "msgilligan: Nice! The Savannah..." <- I was just exploring, the docs were fine. I'll work on submitting a patch next week. <GNUtoo>so it might be better to look at it in more details later <ConvolutedSquare>Im not getting anywhere with GRUB honestly so ill just boot into its bios and take a look <lechner>ConvolutedSquare / please try ls (hd1,gpt1) <lechner>ConvolutedSquare / you may need to load the btrfs module for Grub <ConvolutedSquare>GNUtoo: i just noticed there is no video out on the device, so i dont think it will be practical to even attempt unfortunately <oriansj>why doesn't guix have gcc-afl packaged? <Kolev>Can I run Sway from the live image? <Kolev>So 1.4.0 is fresh and I no longer have to grab the development snapshot? <ConvolutedSquare>But that module is on a btrfs filesystem... so how would it load it without the module already loaded? Can I move it to /boot/efi? <ConvolutedSquare>Is there a way to tell Guix to include the btrfs grub module in the bootloader by default? <oat>The Guix installer 1.4.0 has a bug. <oat>The USB stick throws the errors described below. <oat>error: file '/gnu/store/3qdad0k7wvwl09wah246q7fvsb1hbr0x-linux-libre-6.0.10/bzImage' not found. <oat>error: you need to load the kernel first. <oat>Press any key to continue... <ConvolutedSquare>I tried putting all of /boot on the FAT32 partition but still no luck. Strangely enough "insmod btrfs" is the only command that doesnt error in the grub shell. <Kolev>Cannot run Sway from live image. <oriansj>anyone familiar with fan control on guix for an x200? <oriansj>(I need to set higher speed as I am getting overheating and crashing) <jackhill>jgart[m]: some cons to channels stratification I can think of off the top of my head: 1) package dicoverability 2) its hard enough as is deciding what module to put a package in, let alone channel <jackhill>pro: incentivize us to improve to tooling. <jackhill>sorry to not contribut to the email discussionl, that's all I have for now, and don't feel authoritative <lilyp>ConvolutedSquare: exactly. It only concerns raid, which is what you're missing <lilyp>if you move all of /boot, I fear grub will have trouble finding the efi partition. So either do a bios boot with a seperate boot partition or do two partitions for boot (with one being the efi partition) <lilyp>or well, actually grub finding the efi partition is not that important, uefi finding it is <lilyp>does our QA pipeline not do a clean rerun when sending revisions? <ConvolutedSquare>lilyp: I ended up moving all of /boot to one partition and it booted, but still got the exact same errors <lilyp>hmm, so you're using btrfs raid 10? <rekado>nckx: looks like the slow-down is due to all the link anchors on every line. <rekado>when I remove the anchors (and move the id to the parent div, so it’s still addressible) everything becomes much faster. <rekado>still takes too much time to *process* it before it gets sent out, but at least the browser doesn’t choke on it. <yarl>Can't `guix build --system=aarch64-linux syslinux` on x86_64 with qemu-binfmt? <yarl>Ah, not a supported system. Right. Then why `./pre-inst-env guix system image --system=aarch64-linux -e '(@ (gnu system install) rockpro64-installation-os)'` tries to build it (and fails)? <mekeor[m]><oriansj> "anyone familiar with fan control..." <- i have it set up for an x200t <mekeor[m]>oriansj: you need to load some kernel modules and then use thinkfan <nckx><lilyp: exactly. It only concerns raid, which is what you're missing> What did? <mekeor[m]>oriansj: i can send you respective snippets out of my system.scm and my thinkfan.conf when i'm at my computer <lilyp>I was confusing two different kinds of raid setups, only one of which is described in the manual. <lilyp>basically, we have a mapping setup for mdadm raid, but nothing for btrfs raid <lilyp>I'm not sure how the latter would work in Guix now :( <nckx>I think we rely entirely on btrfs (the tool) triggering a scan from user space in the initrd. <nckx>Hoped you'd stumbled on a solution for a sec :) <nckx>'insmod btrfs' succeeding means that is is built in. It being missing from the core was my only hypothesis. GRUB is supposed to support raid10. <lilyp>could we list multiple devices as "device" in filesystems? <nckx>There is no Linex standard for thah AFAIK. <nckx>That's why btrfs does the 'give me one device, I'll find the rest' hack by default. <lilyp>Perhaps it doesn't find the rest? <nckx>I really don't know what could be happening here. I'd guess either hardware not visible to GRUB, or some mkfs.btrfs option (GRUB's picky). Neither seem likely... <nckx>Of course it's also possible that the Web was just wrong about raid10 support. Also unlikely though. <nckx>Anyone here use btrfs raid without a separate /boot kernel? :) <mekeor[m]>oriansj: i will share it with you in approx. 8 hours <guix_noob>Hi Guix! I am trying to rewrite my emacs configuration with Guix. I kinda struggle to find to right section in guix documentation for that and the tutorials I found onthe Internet seems overcomplicated.. Could you point me to some directions please, reading materials and tutorials? Thank you very much :) <haugh>guix_noob, I think you want Guix Home <guix_noob>hi haugh thank you very much I will look into that! <ConvolutedSquare>nckx: thoughts on using a different bootloader? I see there is extlinux and UBoot, but i have no experience with either <jas4711[m]>hi guix! i noticed guix has insecure libksba version 1.6.0 (grafted to 1.6.2), and would like to contribute with a patch to move it to safe 1.6.3 but my knowledge about grafts is too limited. how are situations like this handled in guix? why don't we just bumb the main libksba package to 1.6.3? <singpolyma>Graft means people can get the update without reinstalling everything that depends on it <jas4711[m]>singpolyma: would you add a new graft on top of an existing graft? or modify the graft? when a new fix is needed <lightbulb>jas4711[m]: Commit eca2703 in guix.git "gnu: expat: Update replacement to 2.4.9 [fixes CVE-2022-40674]." <jas4711[m]>i sent patch #60302 to update libksba. i wonder how scalable the graft approach is. for example, openssl/fixed is continously updated to newer openssl releases. doesn't this model eventually to all work happening on foo/fixed? once 'foo' has a security problem that needs a graft, it seems future work on that package happens on foo/fixed. hm <vagrantc>for things that would trigger many rebuilds, sure ... some things can just be updated normally <vagrantc>oops. the guix packages in debian don't enable substitutes from bordeaux <rekado>jas4711[m]: if the different variants are ABI compatible you can just update the replacement. <rekado>the graft mechanism would then build 1.6.0, and all packages that depend on it would get 1.6.0 in their dependency graphs, and finally it would build grafted variants of all packages. <rekado>the grafted variants start at the first packages that use libksba directly <rekado>they are copies of the original package outputs with just *one* difference: the reference string for /gnu/store/…-libksba-1.6.0 is replaced with the reference string for the replacement package /gnu/store/…-libksba-1.6.3. <rekado>then the algorithm moves on to all those packages that are one removed from libksba, rewriting references to those direct users of libksba, etc. <rekado>this keeps going until there’s no more rewriting to be done. <ConvolutedSquare>Hm. It's booting into GRUB? Was I supposed to wipe /boot before running system init? <ConvolutedSquare>Yeah looks like the other bootloader folders are persisted... possible bug? <nckx>Yes, remove GRUB if you don't want it. But the boot loader isn't stored in /boot, neither on BIOS or UEFI. <nckx>On UEFI it's on the ESP, a FAT partition mounted at /efi (or /boot/efi by old people :-) <ConvolutedSquare>Oh. So where is it stored? My system is still booting into GRUB after I cleared out /boot <nckx>Using /boot/efi is fine. <nckx>Modern Linux is moving towards mounting it in a different place, but it's the same thing. <nckx>It's where all boot loaders are stored. Not deleting other ones is a feature, to support multpile OSes. <ConvolutedSquare>So how is my system still booting into GRUB after I rm -rf'd /boot and ran system init with EXTLINUX? I'm confused <nckx>Because /boot does not contain your boot loader, /boot/efi does. <nckx>Did you really wipe the ESP (/boot/efi)? <nckx>What you describe sounds like you must not have. <nckx>ACTION has to go eat Christmas food. <ConvolutedSquare>Actually I didn't check if it doesn't exist on my BTRFS fs, but I doubt it could boot from there... I'll take a look <ConvolutedSquare>Yep, it exists on the BTRFS raid. So does that mean my BIOS supports BTRFS? Confused. <ConvolutedSquare>A file gets created at /boot/extlinux, and a folder is created at /mnt/boot/extlinux when I run system init <nckx>it's mainly Christmas wine. <nckx>There is Lagavulin for later. :-) <nckx>I think your failures might all have been due to a misunderstanding. <ConvolutedSquare>Never tried Lagavulin, but I could use some right about now. Maybe it'll help my brain work <nckx>That FAT partition, sde1, should be mounted at /boot/efi, but the label implies you might think it's a boot partition. <nckx>I don't know how familiar you are with UEFI. <ConvolutedSquare>Wait so how does UEFI boot into BIOS if my configuration is completely wrong? <nckx>OK, so sde1 is that ESP (EFI system partition) I was talking about. It's not a traditional 'boot' partition. <nckx>Uhm, what do you mean by boot into BIOS? <nckx>I haven't read today's backlog. <jas4711[m]><rekado> "then the algorithm moves on to..." <- thanks for explaining! so this algorithm is running continuously on the substitute build servers? what should happen when this terminates? drop the graft and bump the original package definition, or? I tried reading https://guix.gnu.org/blog/2020/grafts-continued/ but I'm still not getting the entire life cycle <nckx>So you never mounted anything at /boot/efi during installation? <ConvolutedSquare>I had with GRUB before. but when I switched to extlinux, /boot/efi didn't exist. <nckx>Because you installed GRUB to sde1, then while installing extlinux sde1 wasn't mounted, so it's unchanged, so GRUB is still there, no? <nckx>With the little info I have, of course. <nckx>But where is sde1 mounted? <nckx>That's not clear from the paste. <nckx>My bad, I meant when you installed GRUB. <nckx>And what was you system configuration's boot loader target? /boot/efi, right? <nckx>I think that explains the GRUB 'bug'. <nckx>It is complicated, and I think we might have overestimated your familiarity with UEFI yesterday. <nckx>I think you should switch back to GRUB in your system configuration, and use /boot/efi as target. <nckx>But this time, make sure that: <nckx> /boot is just a subdirectory of / <nckx>You mkdir /boot/efi (which will be /mnt/boot/efi during installation), then mount sde1 there. <nckx>You can wipe /boot and sde1 of all files first. <ConvolutedSquare>Got it, will do. For reference, why would mounting sde1 as /boot be wrong? <nckx>Because I think it confused GRUB. GRUB stores all its modules in /boot, not on the ESP, but in your case they were the same thing and it probably doesn't handle that well. <nckx>ESP != /boot. Common misunderstanding, relatively. <rekado>jas4711[m]: this algorithm is how graft derivations are computed. It happens whenever a build is requested. <rekado>grafts are not built on the build farm nodes; they are generally cheap enough to be built locally. <rekado>we undo the grafts on the core-updates branch manually <rekado>we don’t want to have to graft too many things for too long, because it’s not pretty <jas4711[m]>rekado: aha! that was the missing piece I was looking for <nckx>ConvolutedSquare: one of the reasons that distros are moving its mount point from /boot/efi to /efi, because one is not 'part' of the other. Anyway, good luck, I think this was likely the cause. Sorry nobody realised that; I don't think that information made it across. <nckx>ACTION main course time. <jas4711[m]>rekado: indeed. so would it make sense to propose a patch for core-updates to clean up libksba? assuming that hasn't already been done, I didn't check <oriansj>just need to play with it to be sure <nckx>Hm, GRUB nominally supports zstd compression... <nckx>No, I meant that it shouldn't be the issue. Not that I'll stop you from testing. <nckx>Damn, I really thought we'd found it. I don't know what else could be wrong. <nckx>Unless I'm missing something more subtle, or some previous state is still wrong. <ConvolutedSquare>Also, just wanna say thanks to you nckx, and to everyone else that has helped me. I hope to one day be knowledgeable enough to be able to contribute to Guix. Definitely planning to put up a public substitute server at least. <ConvolutedSquare>I'll try it without compression, and then see if maybe I can get EXTLINUX working then <nckx>I notice the hostname. But this is x86-64... Right? <nckx>I'm afraid I'm really out of ideas. What I would personally do is try to install on a one-disc non-raid btrfs root, with everything else identical (zstd, sde1, ...). Just to find out if that's the issue. <nckx>At least then you have something to debug, that's not just 'no work'. <nckx>But that's also because I'm not familiar with {sys,ext}linux so can't help you in that direction. <nckx>I jest remembered that you said GRUB could only find 3 drives yesterday, of which one was bogus. <ConvolutedSquare>Can't even get EXTLINUX to install: path /mnt/boot/extlinux doesn't match device /dev/sda1. I'll try getting rid of the RAID. <ConvolutedSquare>Well, BIOS only allows booting from the DOM(disk on module), drive 0 and drive 3. So that kinda lines up. Not sure why that's the case though. <nckx>Another thing I'd do: enter the GRUB command line of the *installer* image (so don't boot the installer OS). That will give you a full featured GRUB, but you can still check whether 'ls' shows all hardware. <ConvolutedSquare>... i really hope there isn't some hardware RAID set up that's interfering. But that wouldnt make sense as Linux shows the 4 drives <nckx>M-hm. But firmware can lie to GRUB in ways that Linux bypasses. <nckx>(For the command line, hit C at the GRUB menu.) <nckx>That's enough of me rudely typing on a phone for now, good luck. <ConvolutedSquare>So I used /dev/sda as my root drive, and formatted it with ext4. GRUB is still dropping into a rescue shell. At this point, I assume it's just a firmware issue right? <oriansj>mekeor[m]: I can confirm that it works and thank you very much ^_^ <nckx>ConvolutedSquare: sda? You are very eager to use unpartitioned drives :). But yeah, that should have worked. Unless we're overlooking something (and I'm sorry if I have). What did the installer's GRUB's ls show? Which drives are visible, which not? <ConvolutedSquare>nckx: sorry, is that unusual? I'm just not going to use any other partitions in the future, so I don't see the point of partitioning. I'm trying one last thing(different /boot and /boot/efi partitions) and then I'll check. <ConvolutedSquare>Grub is showing an entry "GNU with Linux-libre 6.0.10", but then it says "no such device: root", "/gnu/store/*-linux-libre-6.0.10/bzImage not found" and "you need to load the kernel first" <ConvolutedSquare>All devices other than proc and hd0 report no known filesystem. Maybe there are only 2 drives that are actually available to GRUB for some reason, and /dev/sda isn't one of them <nckx>OK, so it can find /boot now, which is where its modules are. Progress indeed, but still puzzling. Especially if /boot and / are the same file system(?). <nckx>Can you insmod the ext2 module, whatever it's called exactly? <ConvolutedSquare>And installation GRUB reports the following drives: (hd0) (hd0,msdos{1,2}) (hd1) (hd1,msdos{1,2}) (hd2) (hd3) (cd0) (cd0,msdos2) <nckx>omlet[m]: And a Feliz Gnavidad to you! <nckx>I really have to go, sorry.