IRC channel logs

<gnu_srs1>youpi: James Clarke (jrtc27) did add his support to GR: Proposal D, probably on behalf of kFreeBSD. Why don't you on behalf of Hurd?

<gnu_srs1>see: https://www.debian.org/vote/2019/vote_002

<gnu_srs1>If you can add yourself to https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ you can make your voice heard to Debian too!

<damo22>gnu_srs1: what is GR?

<damo22>cd

***Server sets mode: +nt

<damo22>how do i set the default translators on a disk image?

<damo22>eg /dev/console is not set

<damo22>does rsync under hurd set translator bits?

<damo22>ok its easier if i shrink my / and dump the disk

<damo22>YES!

<damo22>i get the same error on qemu with trying to mount a rumpdisk partition beyond 128GB boundary

<damo22>i think its because libstore uses size_t

<damo22>so thats 2^32

<damo22>store_set_size (struct store *store, size_t newsize)

<damo22>what happens if your store is > 4G

<damo22>the problem is in libparted

<damo22>gnu_read

<damo22>size_t start;

<damo22>start = device_start * PED_SECTOR_SIZE_DEFAULT;

<damo22>that will overflow "start"

<damo22>problem is recnum_t is 32 bits

<damo22>gnumach only supports devices up to 2^32 blocks

<gnu_srs1>damo22: GR is (Debian) General Resolution, and the subject for discussion now is: Init systems and systemd

<gnu_srs1>youpi: When cross-building glibc-2.30 I get a libhurduser.a (no libhurduser_pic.a) containing io_set_some_opemodes but not in libhurdhuser.so.0.3.

<gnu_srs1>What am I missing?

<gnu_srs1>Libraries are built with -no-pie -fno-PIE, should I use -pie. Configure reports: checking whether -fPIC is default... no checking whether -fPIE is default... no

<gnu_srs1>When building Debian glibc both are set to yes.

<youpi>damo22: size_t is 64bit inside hurd (because it's built with LFS enabled, see in man feature_est_macros the LARGEFILE macros

<youpi>libparted however possibly isn't built with LFS support, that should be fixed if not

<youpi>damo22: the device_t interface is limited to 32bit integer indeed, we need to increase that

<youpi>gnu_srs1: (io_set_some_openmodes): I don't know

<youpi>gnu_srs1: building libraries with -fPIE is not needed as long as -fPIC is used

<damo22>something happened to my system and my original pci-arbiter cleanup patch is now broken on my system, should i upgrade my packages?

<youpi>the fact that -fPIE is enabled by default in debian doesn't matter

<youpi>damo22: possibly

<youpi>gnu_srs1: like I said, I don't have time to delve into it

<youpi>why should I second proposal D rather than proposal E for instance?

<damo22>youpi: what packages do i need to upgrade to get the latest changes you made for the arbiter?

<damo22>just "hurd"?

<youpi>honestly I don't remember off-hand

<youpi>probably hurd, hurd-libs0.3, libpciaccess

<damo22>ah yes

<youpi>gnu_srs1: does your libhurduser_pci.a contains e.g. __io_read ?

<youpi>damo22: normally nowadays translator bits are stored in xattr. It seems rsync's -X option can preserve them

<damo22>rsync on hurd does not support X

<damo22>at least the version i have

<youpi>you don't have version 3.1.3-7 ?

<youpi>oh it seems the support is disabled there

<youpi>probably something to fix in it

<damo22>how do i enable LFS in libparted? would it be a simple flag

<youpi>it would, but also possibly ABI concerns

<damo22>i tried setting size_t to store_offset_t in libparted

<damo22>for the gnu_read

<damo22>it didnt seem to make any difference

<damo22>i still get ext2fs panic get_hypermetadata

<youpi>did you try the dd test first?

<damo22>no

<youpi>rather than immediately getting all the complexity of ext2fs + parted

<youpi>better debug layers one by one

<damo22>yes

<damo22>so, i need to dd , and skip 512*2^23 ?

<damo22>around that boundary?

<youpi>try to see how far you can go, yes

<youpi>and making sure that it's behaving correctly

<damo22>i can fdisk /dev/wd0

<youpi>so there is getxattr etc. support in glibc on GNU/Hurd, it just seems that rsync was not taught to use it

<youpi>that'd be useful to do

<youpi>fdisk with logical partitions?

<youpi>primary partitions only touch the MBR

<damo22>yeah im only in primary partitions

<youpi>then that's not a good test :)

<damo22>but its on a real disk

<damo22>at least

<damo22>in qemu

<damo22>i sorted out my issues

<youpi>ok, but I mean fdisk is not actually accessing sectors beyond limitations

<damo22>sure now i will use dd

<damo22>hmm interesting /dev/wd0 says its 2GB size in fdisk

<damo22>but its a 320GB hdd

<damo22>Disk /dev/wd0: 2 GiB, 2147483648 bytes, 4194304 sectors

<youpi>normally stat does support 64bit size

<youpi>but possibly that's not properly reported by libstore

<damo22>root@zamhurd:~# dd if=/dev/wd0 of=/dev/null skip=4194303 count=2 bs=512

<damo22>dd: error reading '/dev/wd0': Input/output error

<damo22>1+0 records in

<damo22>1+0 records out

<damo22>i hit the end of the 2GB

<youpi>you can use bs=1048576 to make computations easier :)

<youpi>so there's the dd case to be fixed first

<youpi>no need to delve into libparted/ext2fs before that works

<damo22>true

<damo22>err = rump_sys_lseek(bd->rump_fd, (off_t)bn * bd->block_size, SEEK_SET); is returning -1

<damo22>but bd->media_size = 320GB

<damo22>hmm maybe rump_sys_lseek returns off_t

<damo22>it does !

<damo22>Disk /dev/wd0: 298.9 GiB, 320072933376 bytes, 625142448 sectors

<damo22>it mounts past 128GB

<damo22>!!!

<damo22>i read 100MB starting from 200GB

<damo22>aaand 100MB starting from 300GB

<damo22>i think its working

<damo22>bed

<gnu_srs1>youpi: I've now built glibc-2.30 with checking whether -fPIC is default... yes; checking whether -fPIE is default... yes and libhurduser_pic.a is created, e.g. containing __io_read

<youpi>damo22: yay !

<youpi>damo22: was rump built with the LFS flags?

<youpi>gnu_srs1: was it not containing __io_read before?

<youpi>really, there is no reason why fPIC/fPIE should have anything to do with __io_read getting defined or not

<gnu_srs1>It was not built before. Problem is that the cross-compiled binaries have ld.so hardcoded: file ./x ...dynamically linked, interpreter /tools/lib/ld.so,

<gnu_srs1>so they are not executable in a native hurd environment, even downloading the cross-compiled libs and settin LD_LIBRARY_PATH.

<youpi>damo22: oh, ok, both block_size and bn were 32bit, so the computation was limited to 32bit

<youpi>gnu_srs1: /lib/ld.so does exist on a Hurd system

<youpi>LD_LIBRARY_PATH is read by ld.so, so it can't be what tells where ld.so is

<gnu_srs1>cross-compiling -> hardcoded to /tools/lib/ld.so

<youpi>I'm surprised that the interpreter would get set to /tools

<youpi>but probably there is a configuration option to set that

<gnu_srs1>All cross compiled stuff goes into /tools as it is set up now.

<gnu_srs1>LD_LIBRARY_PATH=. ./whoami: Killed

<gnu_srs1>/tools/lib/ld.so -> /home/srs/test/ld.so.1

<gnu_srs1>Do I need to set up env?

<youpi>normally, gcc uses ./src/gcc/config/i386/gnu.h:#define GNU_USER_DYNAMIC_LINKER "/lib/ld.so"

<youpi>AGAIN, like I said, it's ld.so which reads the environment

<youpi>so there is no point in looking for an environment variable

<youpi>you have to fix your toolchain into setting the proper interpreter path

<youpi>normally that's define like I wrote above

<youpi>and that's used in ./src/gcc/config/i386/gnu-user.h: { "dynamic_linker", GNU_USER_DYNAMIC_LINKER }

<youpi>then passed to the linker

<youpi>now if your setup does things differently, I don't know

<gnu_srs1>And LD_LIBRARY_PATH still reads /lib/so?

<youpi>I don't understand that sentence

<youpi>it does not make technical sense

<gnu_srs1>I want to use the downloaded libraries in ./test instead of the native ones.

<youpi>look, I don't understand what you are trying to achieve, and do not have time to try to guess

<gnu_srs1>Since I cannot test the cross-compiled files in an Linux amd64 environment, I want to try them in a native Hurd i386 environment.

<youpi>ok

<youpi>does /tools/lib.ld.so exist?

<youpi>err

<youpi>does /tools/lib/ld.so exist?

<gnu_srs1>I created it yes

<gnu_srs1>ls -l /tools/lib/ld.so: /tools/lib/ld.so -> /home/srs/test/ld.so.1

<youpi>does it work when you run it by hand?

<youpi>i.e. just running /tools/lib/ld.so

<gnu_srs1>No

<youpi>then debug that first

<youpi>because that's supposed to be able to work

<gnu_srs1>/tools/lib/ld.so -bash: /tools/lib/ld.so: No such file or directory

<youpi>anything else will fail anyway if that does not work for a start

<youpi>file /tools/lib/ld.so

<youpi>file -L /tools/lib/ld.so

<youpi>does they report the same as for /lib/ld.so ?

<gnu_srs1>file /tools/lib/ld.so: /tools/lib/ld.so: symbolic link to /home/srs/test/ld.so.1<

<gnu_srs1>file -L /tools/lib/ld.so: /tools/lib/ld.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /tools/lib/ld.so.1, for GNU/Hurd 0.0.0, with debug_info, not stripped

<gnu_srs1>file /home/srs/test/ld.so.1: /home/srs/test/ld.so.1: symbolic link to libc-2.30.so

<youpi>it's very odd that ld.so has an interpreter info

<gnu_srs1>Natively: file /bin/ls: /bin/ls: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so, for GNU/Hurd 0.0.0, BuildID[sha1]=a3cf1784aa57ec0cd262f6d9df9f34d5198b40c0, stripped

<youpi>yes, /bin/ls has an interpreter, ld.so

<youpi>but ld.so *is* the interpreter, so it does not make sense that it'd have an interpreter

<gnu_srs1>When cross-compiling I don't want to override the Linux amd64 /bin/ld.so -> therefore everything goes to /tools

<youpi>sure, that's not the question

<youpi>the actual technical problem you have is that your /tools/lib/ld.so is marked as requiring an interpreter, set to itself

<youpi>that can at best just loop around

<youpi>so something is wrong in your glibc building ld.so

<gnu_srs1>file /lib/ld.so: /lib/ld.so: symbolic link to ld.so.1

<gnu_srs1>file -L /lib/ld.so: /lib/ld.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=730303a2e277416d23350292a4a3474fe9aec9e6, stripped

<gnu_srs1>Same as for /tools/lib/ld.so

<youpi>above you wrote that for /tools/lib/ld.so you had "interpreter /tools/lib/ld.so.1"

<youpi>so it's not "Same"

<gnu_srs1>OK, now I see the difference.

<gnu_srs1>Seems like double linking was not OK: now: file /tools/lib/ld.so: /tools/lib/ld.so: symbolic link to /home/srs/test/ld-2.30.so

<gnu_srs1>file -L /tools/lib/ld.so: /tools/lib/ld.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, with debug_info, not stripped

<gnu_srs1>LD_LIBRARY_PATH=. ./whoami: ./whoami: cannot find name for user ID 1000

<youpi>(14:47:09) gnu_srs1: file /home/srs/test/ld.so.1: /home/srs/test/ld.so.1: symbolic link to libc-2.30.so

<youpi>that's what was nonsense

<youpi>double-linking is not a problem, you can use many symlinks levels

<youpi>but you need to end up with ld.so, not libc.so...

<gnu_srs1>./ld.so: symbolic link to /home/srs/test/ld-2.30.so

<gnu_srs1>Yes, I made a mistake in the symlink. tks, all good :)

IRC channel logs

2019-11-23.log