IRC channel logs


back to list of logs

<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
<damo22>under experimental conditions
<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
<GNUtoo>(for VMs h* makes sense though)
<damo22>yeah the device names are an issue
<damo22>they will change again to wd
<dragestil>I was following the translator primer on the debian-hurd image
<dragestil>The translator died when i invoked `ls mnt`
<dragestil>in the iso mount section
<dragestil>any idea what could be the problem?
<youpi>it seems there is a missing / in the doc
<youpi>settrans -c mnt /hurd/iso9660fs /
<dragestil>ah that fixed it, thanks
<dragestil>this way of mounting seems to be faster than tramp in emacs
<youpi>does tramp avoid downloading the whole iso file?
<dragestil>or is ftp just generally faster than ssh
<dragestil>not sure about that, as i have only used tramp to edit files over ssh
<dragestil>and it can be slow to "connect" to the file
<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>it doesn't
<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>s is for scsi
<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 transparently, let's mount a remote ISO file:
<dragestil>so it's a composition of translators
<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>there's no pseudo-dir
<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>that doesn't seem so
<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
<dragestil>it says /hurd/hostmux /hurd/ftpfs /
<youpi>and what does "showtrans รน,t" say?
<youpi>and what does "showtrans mnt" say?
<dragestil>it says `/hurd/iso9660fs`
<dragestil>but if i `ls mnt`, it says `ls: cannot access 'mnt': Translator died`
<youpi>does ls work, for a start?
<youpi>also you can add -a to the settrans -c mnt command, to see actual errors from the translator
<dragestil>yes i can ls
<dragestil>i added -a to the settrans -c mnt command, there was no output
<dragestil>settrans -c -a mnt /hurd/iso9660fs
<youpi>mnt is the argument of the -c option
<youpi>here you created a -a file
<dragestil>but now i can ls mnt
<dragestil>so should it have been settrans -a -c <rest>?
<youpi>ah sorry -c doesn't actually take an arg
<youpi>so -c -a is fine
<dragestil>ok no worries
<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
<dragestil>but how come it worked for you
<youpi>I don't know
<dragestil>ok would you recommend reading the hurd hacking guide
<youpi>I recommend reading whatever is referenced on the wiki :)
<dragestil>is there an info version of the gnu mach manual?
<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/
<dragestil>ok, i found it in the source tree, thanks
<youpi>really gotta sleep :)
<dragestil>thanks good night
<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=/
<damo22>will that work
<youpi>why installing everything and not just the translator you want to debug?
<damo22>because there are many patches
<damo22>i want to test latest
<damo22>some of them interact i think
<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
<youpi>(the assignments)
<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
<damo22>theres about 10 patches there
<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>which fixes?
<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
<youpi>check the debian source
<damo22>ah ok
<damo22>oh ok you backported most of it
<damo22>sorry i didnt realise
<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>it is, as the base
<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
<damo22>i havent seen that either
<youpi>note that there is always reboot-hurd
<gnu_srs>yes, reboot-hurd worked
<damo22>ext2fs: /dev/wd0s3: warning: bit already cleared for inode 5545996
<damo22>just a few warnings when accessing a partition with rumpdisk
<damo22>i booted off wd0s2
<gnu_srs>After reboot /run/initctl is there. Which package creates it, dpkg -S is empty?
<youpi> /run is dynamic
<youpi>it's probably sysinit that builds it
<damo22>youpi: what can i run to stress test it?
<youpi>build packages
<gnu_srs>Does the 2021 version of Hurd have the merged-/usr layout?
<youpi>if you install from scratch yes
<youpi>just like the 2019 version
<youpi>and even 2017 iirc
<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>gnu_srs: why so?
<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>no what?
<youpi>*so what?
<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
<youpi>did you fsck it?
<gnu_srs>For now you can use dpkg-fsys-usrunmess(8) as a workaround.
<youpi>does linux mount it fine?
<youpi>gnu_srs: again, that's not a matter for the hurd port
<damo22>ok i will fsck it now
<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?
<youpi>why bothering?
<gnu_srs>Why not bothering?
<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>gnu_srs: so what?
<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>but wd0s4 is big too
<damo22>i am just not using it
<youpi>it's after wd0s3
<youpi>wd0s3 is not your /, right?
<damo22>2 is
<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 dont think its in debian
<damo22>i will apply that and install it
<youpi>yes but the libdiskfs part is only about the 2T limit
<youpi>(2^32 sectors)
<damo22>ext2fs.h: /* A block number. */
<damo22>typedef __u32 block_t;
<damo22>what is the unit of a block?
<youpi>4096 bytes
<damo22>4096 * 2^32 bytes would be the largest offset then
<youpi>that's 8 TB yes
<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
<youpi>ah, yes
<damo22>yep its not that
<damo22>what is the define macro for changing off_t to 8 bytes?
<damo22>_USE_LARGEFILE_64 does not work
<youpi>man feature_test_macros
<damo22>ok rumpdisk is compiled with -D_FILE_OFFSET_BITS=64
<damo22>so off_t is 64 bits
<damo22>i wonder if rump libs are too
<damo22>i may be on to something
<gnu_srs>damo22: Don't you update your git repos anymore? shows no updates since months?
<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
<gnu_srs>And you are what?
<gnu_srs>a moron?
<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