IRC channel logs

<azert>Does anyone knows what happened of the libchannel idea?

<azert>« one could connect the channel directly to the application. Said application gets the packet buffers mapped directly into its address space and performs protocol processing by way of a user-space library. » sounded like a plan for the Hurd

<solid_black>hi

<Pellescours>hi

<solid_black>more executable stack breakage!

<solid_black>it's amazing how many things can go wrong when you never test it

<solid_black>like, whoever wrote this piece of code clearly wanted to support executable stacks, but they got it wrong

<solid_black>and they got it wrong in two different ways :D

<Pellescours>it’s a gnumach problem, a glibc problem, a hurd exec server problem?

<solid_black>all of the above :)

<solid_black>exec server, in this particular case

<solid_black>but all of them didn't support executable stacks properly

<solid_black>alright! /hurd/startup, userspace-execed, makes it to main :)

<solid_black>and then... panics Mach with a PAN failure??

<solid_black>why, yes, memcpying from NULL is a PAN failure

<Pellescours>:)

<solid_black>this is "software PAN" though: if we fault on a userland address while in EL1, I check if there's a recovery handler at this PC, and if not, declare it a PAN failure

<solid_black>even if hardware PAN is not engaged

<Pellescours>I don’t know to who tell it but in the latest news, the date of the news for the release of glibc 2.39 is wrong (2023 instead of 2024) : https://sourceware.org/glibc/

<almuhs>hi. I have installed Debian GNU/Hurd 2023 with noide in a HDD connected via USB, using Qemu. But, when I boot the system from qemu, I got a getty error that don't found /dev//tty1. I'm searching the file which generated this error path, but I don't found this. Do you know where can I fix it?

<almuhs>due to this error, getty doesn't work, so I can't access from ssh. I only have access to the filesystem

<solid_black>almuhs: hi! can you boot it with init=/bin/bash?

<almuhs> https://pasteboard.co/KH6glKHaRl5t.png

<almuhs>this is the error

<almuhs>hi. I can try it

<almuhs>after fsck i will try it

<almuhs>but, how can I do this in hurd

<almuhs>?

<almuhs>ok, i have bash

<almuhs>and now?

<almuhs>what have to do to find the origin of the error?

<solid_black>check if /dev/tty1 indeed doesn't exist

<almuhs>/dev/tty1 exists

<almuhs>but there are not any other tty

<almuhs>/dev/tty2, /dev/tty3... doesn't exists

<almuhs>also exists /dev//tty1. It's so strange

<solid_black>remount filesystem writable ("fsysopts / --writable") and run "/usr/lib/hurd/setup-translators -k"

<almuhs>ok

<almuhs>done

<almuhs>ln shows some errors

<almuhs> https://pasteboard.co/ZOqaJP0GBy0J.png

<solid_black>that's fine

<almuhs>and now?

<solid_black>now reboot ("reboot-hurd") and hopefully things should work

<almuhs>ok, now it works

<solid_black>yay :)

<almuhs>the next issue is to fix the harddisk problem

<almuhs>when I connect this harddisk to my T410, Hurd doesn't find the HDD unit

<almuhs>/etc/default/grub edited to add noide

<almuhs>and grub updated

<almuhs>now I go to connect it to my T410

<solid_black>I guess Debian enables all the things needed for rumpdisk out of the box now?

<solid_black>this is the same root disk you've just booted qemu from, right?

<almuhs>I doesn't know. This is 2023 image, the most recents are buggy

<almuhs>this is the error https://pasteboard.co/oXPmjfSEdfDO.jpg

<almuhs>i tried to change the unit name, but it doesn't works

<solid_black>that does look like rumpdisk starts up, and like ext2fs tries to open wd0

<solid_black>I can't help you beyond that

<almuhs>the disk unit in rumpdisk is /dev/wd0, and / is in /dev/wd0s5, if I remember well

<solid_black>ah, then change to part:5:device:wd0

<almuhs>ok, but doesn't works. I go to try in a older Thinkpad

<almuhs>in the R61i the HDD seems be detected fine

<almuhs>in R61i, the HDD boots without problems. Then the issue must be a SATA compatibility with the T410

<almuhs>**SATA compatibility problem

<almuhs>maybe SATA 2 and 3 is not fully supported

<almuhs>damo22: have you tested rumpdisk in a T410 or more modern machine?

<solid_black>Hurd server bootstrap: ext2fs[rd0] exec startup proc auth.

<solid_black>startup: rebooting Mach (flags 0)...

<solid_black>:(

<solid_black>ah, it just doesn't find anything to run

<almuhs>yes, it is

<solid_black>(I'm talking about aarch64-gnu)

<almuhs>but it's a pretty similar problem than the mine

<gnu_srs2>Hello, How do I check / when booted already. Unfortunately recovery mode does not work.

<azert>gnu_srs2: I use the Debian install cd

<azert>Just to fsck the hard disk and then reboot

<gnu_srs2>I can do the checking form Linux for now. Something happened with the usrmerged packages. I don't have that package installed.

<gnu_srs2>(And will never do).

<gnu_srs2>Which binaries/scripts are involved with booting in recovery mode? Some file is not found during boot, probably solvable by ln -s to /usr.

<gnu_srs2>Maybe booting in serial is the only way to find out.

<gnu_srs2>The following packages are reverted: cpio dbus debianutils grep init-system-helpers nano netcat sed util-linux

<gnu_srs2>youpi: maybe you can help: Which binaries/scripts are involved with booting in recovery mode? Some file is not found during boot, probably solvable by ln -s to /usr.

<youpi>probably debianutils grep ini-system-helpers util-linux

<youpi>possibly sed too

<almuhs>I continue with problems testing Hurd in real hardware. In my R61i, the Debian's gnumach boots without problem, but the upstream's gnumach shows this error when try to access to harddisk https://pasteboard.co/ve53YU8caaCz.jpg

<almuhs>noide flag applied in both

<Pellescours>almuhs: your disk is in IDE mode

<Pellescours>for some reason piixide has issues, I think even in qemu now, you’ll have issue trying booting in IDE mode

<almuhs>I configured this as AHCI

<Pellescours>it’s piixide that’s taken, so it’s not running as AHCI

<almuhs>as curiosity, I've just set as "compatibility" (IDE mode) and then the kernel detects this fine

<Pellescours>oh it’s a bug in rump that’s taking the wrong driver

<almuhs>could be

<Pellescours>Not sure but I’m wondering if piixide is broken since the DMA patch

<Pellescours>I have some ACPI logs being printed when I run qemu with IDE disk

<almuhs>yes, and the booting is slower

<almuhs>then it's necessary to fix the driver selection

<almuhs>by some reason, the Debian's gnumach detects the driver fine

<almuhs>the problem is in the upstream version

<almuhs>ok, i've just noticed that in Debian's version there are messages of pixide too, in AHCI mode

<almuhs>the difference is in Debian's gnumach the system is able to boot although use pixide over AHCI

<gnu_srs2>youpi: tks, but all packages I mentioned above were reverted from moving files to /usr?

IRC channel logs

2024-03-19.log