IRC channel logs


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>Another hint:
<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>That I don't know.
<nckx>A handful of Guixers have those but I'm not sure they IRC.
<GNUtoo>Ah no it was Petitboot
<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.
<Mystified>Hey guy's would this be correct so this will mount with fstab
<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 :)
<nckx>A lot of work though.
<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
<ConvolutedSquare>Just ran system init on the new raid array, fingers crossed
<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.
<Mystified>btw hoew do I make nano writeable
<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.
<the_tubular>Maybe he wants to write directly on the binary /s
<nckx>That's how I read it.
<ConvolutedSquare>also, next up is installing Guix on my ARM QNAP. That should be a joy :D
<nckx>Oh boy.
<GNUtoo>ConvolutedSquare: that's armv6?
<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)
<GNUtoo>Ah it looks like a kirkwood too
<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?
<ConvolutedSquare>Back to heating up in the server room ~.~
<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
<msgilligan[m]> * (typo)
<GNUtoo>If the SOC you have is ARMv7 that would make the thing much less time consuming
<GNUtoo>Maybe linux has that info though
<ConvolutedSquare>GNUtoo: I will look into it as soon as i can figure the x86 one out :P
<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
<GNUtoo>oh ok
<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
<GNUtoo>ACTION will be back later on
<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)
<ConvolutedSquare>lechner: "filesystem is unknown" and "error: no signature"
<lechner>ConvolutedSquare / you may need to load the btrfs module for Grub
<lechner>it should be in /boot/efi/EFI or so
<lechner>sorry i have to motor
<ConvolutedSquare>How can I access /boot/efi? I can't ls any of the HDs
<lechner>you may have figured out your structural installation issue. i would inspect with something like
<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
<ConvolutedSquare>lechner: what exactly am i looking for?
<lechner>ConvolutedSquare / sorry they are in /boot/grub/$arch
<lechner>alas, i gotta go
<ConvolutedSquare>Ok, thanks for the help! I'll keep poking around
<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?
<sneek>rekado: Greetings :D
<ConvolutedSquare>lechner: I do have the btrfs module in /boot/grub/x86_64-efi
<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.
<ConvolutedSquare>Very confusing
<Gooberpatrol66>does guix write dmesg to a log somewhere by default?
<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: so how would i configure it? I dont see any mention of mdadm here
<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?
<nckx>And what was missing?
<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>Not yet.
<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>I see
<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? :)
<oriansj>mekeor[m]: yes please
<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
<ConvolutedSquare>Oh uboot is extlinux but for arm
<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
<singpolyma>That I don't know
<jas4711[m]>seems like you do modify the existing graft rather than doing a recursive graft, i found this earlier commit for example:
<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
<jas4711[m]>* model eventually lead to all
<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>extlinux installed, let's see if it works
<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
<ConvolutedSquare>Where is /efi going to be located? I only told Guix about /boot/efi
<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>Yes. /boot/efi doesn't exist.
<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>Oh, enjoy your food nckx ^^
<ConvolutedSquare>A file gets created at /boot/extlinux, and a folder is created at /mnt/boot/extlinux when I run system init
<nckx>To be entirely honest
<nckx>it's mainly Christmas wine.
<ConvolutedSquare>More of a spirits guy myself, wine never sits well with me
<ConvolutedSquare>How is my system booting into grub? Im lost
<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>Not at all haha
<ConvolutedSquare>My first time messing with bootloaders
<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 but I'm still not getting the entire life cycle
<ConvolutedSquare>I meant GRUB, not BIOS. Sorry
<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.
<ConvolutedSquare>And it still booted into GRUB
<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>That's my guess.
<nckx>With the little info I have, of course.
<ConvolutedSquare>Nope. As you can see from the paste, there is only extlinux in /boot
<nckx>But where is sde1 mounted?
<nckx>That's not clear from the paste.
<ConvolutedSquare>At /mnt/boot
<nckx>My bad, I meant when you installed GRUB.
<nckx>The same?
<nckx>And what was you system configuration's boot loader target? /boot/efi, right?
<nckx>I think that explains the GRUB 'bug'.
<ConvolutedSquare>Yep, with GRUB. I just changed it to the same with extlinux
<ConvolutedSquare>I was doing some silly stuff last night while half-awake apparently
<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>Then install Guix.
<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?
<ConvolutedSquare>(/mnt/boot in this case)
<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.
<nckx>ACTION afk.
<ConvolutedSquare>I see, thanks. I'll give that a try
<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
<mekeor[m]>oriansj: does this help?
<oriansj>mekeor[m]: looks like it will
<oriansj>just need to play with it to be sure
<ConvolutedSquare>nckx: yeah, I guess that makes sense. Any idea what I screwed up now? Still getting a GRUB rescue shell:
<nckx>Hm, GRUB nominally supports zstd compression...
<ConvolutedSquare>Fun. I'll turn that off then
<nckx>No, I meant that it shouldn't be the issue. Not that I'll stop you from testing.
<ConvolutedSquare>What's the worst that can happen :P
<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.
<nckx>That's suspicious.
<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
<ConvolutedSquare>Ok I'll try that as well.
<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>Thank you!
<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 ^_^
<oriansj>my x200 now has working fan control
<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>It worked! Kinda
<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>I think that's progress? I'll try using the UUID instead of a label
<ConvolutedSquare>Actually I'll see if i can salvage this from the rescue shell
<ConvolutedSquare>ls reports: (proc) (hd0) (hd0,msdos2) (hd0,msdos1) (hd1) and (hd2)
<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
<ConvolutedSquare>Very curious
<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(?).
<ConvolutedSquare>Nope. /boot is FAT32
<nckx>W, as they say, TF.
<ConvolutedSquare>I hope that's not directed at something I did, hah
<nckx>No no.
<omlet[m]>good Christmas to all of you
<omlet[m]>And gnutal
<omlet[m]>Gnu more christmas in portuguese
<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>Oh. More drives.
<ConvolutedSquare>Merry christmas omlet!
<nckx>I really have to go, sorry.
<ConvolutedSquare>Yeah, my installation drive has ventoy which contains a few partitions
<omlet[m]>nckx: Spanish
<nckx>Je sais.
<nckx>Bye all!
<ConvolutedSquare>No problem, I'll keep hacking at it
<omlet[m]>Whats is the joke in english?
<ConvolutedSquare>Bye! Thanks
<omlet[m]>Gnunmore christmas
<omlet[m]>* Gnu more christmas