<GNUtoo>Hi, I joined the bug mailing list to report an issue with the wiki and it'll be taken care of, and while doing that I found that there are a lot of threads on running hurd on real hardware, especially with SATA controllers, are you looking for laptops that can run HURD? <GNUtoo>I think I managed to boot it on a laptop at some point but I don't remember in which conditions though. <damo22>ive booted it on an x200 and x220 i think, possibly x230 <GNUtoo>I think I used an x200 too, but I don't recall how I worked around the SATA controller, I probably did modifications in grub.cfg by hand <damo22>yeah, we are almost ready to roll out rump disk <damo22>that should fix most of the disk issues <damo22>since the driver is based on netbsd instead of hand coded in gnumach <GNUtoo>Nice. someone probably need to teach guix to use s* instead of h* though, I think it was the issue I was having <damo22>yeah the device names are an issue <dragestil>I was following the translator primer on the debian-hurd image <youpi>it seems there is a missing / in the doc <youpi>settrans -c mnt /hurd/iso9660fs /ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso <dragestil>this way of mounting seems to be faster than tramp in emacs <youpi>does tramp avoid downloading the whole iso file? <dragestil>not sure about that, as i have only used tramp to edit files over ssh <dragestil>does translator download the whole iso file in this scenario <dragestil>also this issue with s* and h* sounds familiar to me. what do they stand for? <youpi>apparently the translator doesn't support starting at a given position (probably because ftp itself doesn't provide it), but it stops at the last position it needs <youpi>it's merely just like sda vs hda on linux <dragestil>wait, i'm not sure if that was a typo in translator primer <dragestil>because it seemed to be building on top of the ftp translator <dragestil>> Now that we can access ftp.gnu.org transparently, let's mount a remote ISO file: <youpi>yes and the ftpfs translator is set up on /ftp: <youpi>so isofs has to look up the iso image from there <dragestil>but as /ftp: is already mounted to the pseudo dir `ftp:`, can't isofs use that <youpi> /ftp: is where the translator is running <youpi>and that just shows up the ftp world hierarchy <dragestil>> and you can access FTP sites via the pseudo-directory ftp:, for example with <youpi>that said, the content above sets up ftpfs on ftp:, i.e. in the current directory, not /ftp: <youpi>were you really in the same directory when doing the two settrans? <youpi>when I try exactly the given commands, it does work <youpi>what does "showtrans ftp:" say? <dragestil>one moment, i just rebooted the qemu image and it hang and i just killed it and now i need to fsck in the maintenance shell <youpi>and what does "showtrans รน,t" say? <youpi>and what does "showtrans mnt" say? <dragestil>it says `/hurd/iso9660fs ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso` <dragestil>but if i `ls mnt`, it says `ls: cannot access 'mnt': Translator died` <youpi>does ls ftp://ftp.gnu.org/ work, for a start? <youpi>also you can add -a to the settrans -c mnt command, to see actual errors from the translator <dragestil>i added -a to the settrans -c mnt command, there was no output <dragestil>settrans -c -a mnt /hurd/iso9660fs ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso <youpi>mnt is the argument of the -c option <dragestil>so should it have been settrans -a -c <rest>? <youpi>ah sorry -c doesn't actually take an arg <dragestil>so it worked for me with an added -a apparently <youpi>yes but I think I know why, it's just because of active vs passive translator, and the cwd <youpi>we'd rather write $PWD/ftp://etc. <youpi>to make sure the translator knows where to find ftp: <dragestil>how does that relate to active vs passive translator <youpi>because passive get triggered <youpi>without necessarily knowing from "where" it's supposed to look up files <youpi>I recommend reading whatever is referenced on the wiki :) <youpi>sure it's built along the kernel <dragestil>i can't find it in /usr/share/info/ in the hurd qemu image <youpi>odd, the gnumach-common package is supposed to contain it but apparently that got broken <youpi>you can apt-get source gnumach and get it in doc/ <damo22>youpi: what needs to be investigated for rump? <damo22>i assume i need to build all of hurd to test latest? <youpi>better use the latest version yes <youpi>personally the issue I see is the hang <youpi>so it's about stress-testing, and observing at the hang the state of rump etc. <youpi>to see where things are locked <damo22>if i do # make install from a hurd-sv build im afraid of hosing my system <damo22>hurd-sv/build$ ../configure --libexecdir=/usr/libexec --prefix=/ <youpi>why installing everything and not just the translator you want to debug? <youpi>are there patches that touch rumpdisk? <youpi>rumpdisk is linked dynamically against libdiskfs etc. isn't it? <damo22>not sure but i use the static one <youpi>debian's package apparently also sets libdir and datarootdir <damo22>how do you suggest i test rumpdisk <youpi>another non-data point: I never tried, so I don't know, actually <youpi>I suggest simply using the debian build source <damo22>just mount a disk from the dynamic rumpdisk translator <youpi>and if you think that these patches are posing problem, please comment on the copyright assignment thread <youpi>I'm tired of seeing people not seeing that they are nuisance <damo22>* 128f1e58 ext2fs: Fix block allocation on symlink->translator conversion <damo22>this patch and everything later than that, doesnt it need to be tested? <youpi>it's not a question of needing to be tested <youpi>but a question of being compatible with the rest of hurd <youpi>like the newer authentication protocol <youpi>if you don't obey it, proc will not work with you <youpi>but possibly rumpdisk doesn't need to care <youpi>again, the devil is in the details <damo22>right so i was thinking of installing all of hurd from master <youpi>and thus, just to repeat myself: I recommend just working with the debian source <youpi>I don't see the point of using master <damo22>there are some interesting fixes tohugh <youpi>I don't think anything worth backporting was not already put in the debian source <damo22>* 9be1e099 bootstrap: Fix passing proc server from FS to rumpdisk <gnu_srs>youpi: After upgrading to the latest Debian gnumach, hurd and glibc, checking disks and trying to reboot: shutdown /run/initctl: No such file or directory?? <damo22>i looked at the tag * 1dc4b701 (tag: v0.9.git20210811) and assumed that was in debian <youpi>but when I add just a couple of patches I don't bother rebuilding a whole tarball <youpi>I don't know about the initctl bug, I don't have the issue <youpi>note that there is always reboot-hurd <damo22>ext2fs: /dev/wd0s3: warning: bit already cleared for inode 5545996 <damo22>just a few warnings when accessing a partition with rumpdisk <gnu_srs>After reboot /run/initctl is there. Which package creates it, dpkg -S is empty? <youpi>it's probably sysinit that builds it <damo22>youpi: what can i run to stress test it? <gnu_srs>Does the 2021 version of Hurd have the merged-/usr layout? <youpi>if you install from scratch yes <damo22>/dev/wd0s2 1953792 22925312 20971521 10G 83 Linux <damo22>/dev/wd0s3 106811392 316526592 209715201 100G 83 Linux <damo22>cant seem to access some files on the wd0s3 <gnu_srs>Then I think it is time for a Devuan version of Hurd, where that is selectable ... <youpi>what's the point of spending the whole work of rebuilding an infrastructure just for the /usr layout? <youpi>when it's the whole Debian which will handle the issues of /usr, and not the hurd port <youpi>damo22: can't seem, that is? <gnu_srs>Because not everybody is happy with the merged-/usr, especially not the DPKG developer/maintainer. <youpi>really, the hurd port doesn't have to care <youpi>we don't have anything specific that deals with /usr <damo22>i have a git repo and when i git log it says its not a git repo: <damo22>?--------- 0 root root 0 Oct 20 2019 hooks <damo22>?--------- 0 root root 0 Jan 1 1970 info <damo22>there are some files like that in .git <youpi>gnu_srs: you keep taking pretexts for trying to pull the whole hurd port the way you want, this is sickening <youpi>damo22: and no ext2fs/rumpdisk warning? <damo22>ext2fs: /dev/wd0s3: warning: bit already cleared for inode 5767226 <damo22>ext2fs: /dev/wd0s3: warning: bit already cleared for inode 5775440 <gnu_srs>For now you can use dpkg-fsys-usrunmess(8) as a workaround. <youpi>gnu_srs: again, that's not a matter for the hurd port <gnu_srs>Does guix carry merged-/usr, I hope not? <youpi>guix uses an entirely different layout <youpi>so the question doesn't even hold <gnu_srs>Devuan GNU/Linux has a choice of merged-/usr or not when installing, Debian has not. Why not having the same choice for the Hurd port? <damo22>we need more drivers or no one will use hurd <youpi>gnu_srs: again, why bothering? <youpi>we have other problems to deal with <gnu_srs>Hurd even suggested linking /usr to / in the old days. But nobody cared! <youpi>notably right now with hurd 2021 the sbuild create-chroot script is gone, I have to re-look how to create the chroot properly <youpi>*that* is an important matter <youpi>again, nothing hurd-specific there, better not spend any time on this <damo22>ok with gnumach disk driver, the directory hooks and info are preserved, but when i mount it with rumpdisk they appear as corrupt files and there are the warnings as above <damo22>i fsck'd both partitions to be sure <youpi>you showed wd0s2 being 10G and wd0s3 being 100G, how large is wd0s1? <youpi>ok so that's smaller than 128G anyway <damo22>it seems to be fine with accessing anything on wd0s2 <youpi>I'd say put prints in ext2fs and the rumpdisk actual disk driver, to see which blocks are requested, and which blocks are actually getting accessed, and just test accessing that file to avoid getting to omuch prints <damo22>there is a patch in libstore you added for detecting overflow <damo22>i will apply that and install it <youpi>yes but the libdiskfs part is only about the 2T limit <damo22>4096 * 2^32 bytes would be the largest offset then <youpi>the problem is really not in ext2fs, I could run a 300GB partition fine with the ahci driver <youpi>I rather guess somewhere in the rumpdisk layers <damo22>what is the define macro for changing off_t to 8 bytes? <damo22>ok rumpdisk is compiled with -D_FILE_OFFSET_BITS=64 <gnu_srs>youpi: Just a hint. Hurd as a project has to abandon Debian, the sooner the better! And you should know better than sticking to commercial vendors, you know which ones I mean!!! <youpi>this is so much a complotist sentence <youpi>you can't even find something appropriate <gnu_srs>Nice to have (not) met you. I'm shutting mahler down tomorrow. Good luck! <youpi>we won't have troubles finding other boxes ***JorgeTern[m]11 is now known as JorgeTern[m]111