dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
davidlt_ has joined #fedora-riscv
troglodito has quit [Ping timeout: 248 seconds]
troglodito has joined #fedora-riscv
davidlt_ has quit [Ping timeout: 250 seconds]
troglodito has quit [Ping timeout: 240 seconds]
troglodito has joined #fedora-riscv
_whitelogger has joined #fedora-riscv
kalev has quit [Ping timeout: 246 seconds]
kalev has joined #fedora-riscv
davidlt_ has joined #fedora-riscv
<davidlt[m]> TYPE TEXTRELS FILE
<davidlt[m]> scanelf: scanelf_file_textrels(): ELF ./usr/lib/systemd/systemd-logind has TEXTREL markings but doesnt appear to have any real TEXTREL's !?
<davidlt[m]> ET_DYN ./usr/lib/systemd/systemd-logind
<davidlt[m]> I will tag older binutils to make a new systemd build
<zbyszek[m]> davidlt: please post the build log somewhere
<davidlt[m]> zbyszek: this is a normal build (just rebuilt it this morning): http://fedora.riscv.rocks/koji/buildinfo?buildID=245184
<davidlt[m]> with TEXTREL.
<davidlt[m]> This one will be with older binutils 2.39: http://fedora.riscv.rocks/koji/taskinfo?taskID=1404933
<davidlt[m]> Should take <2 hours.
<zbyszek[m]> Looks all normal. The code is compiled with -fPIC. systemd-logind is actually executed at least twice during the build: there's a dist-check-style check for --help, and the dbus interface is exported.
<davidlt[m]> The problem is that I have seen this issue before, and I see it in my notes from years (not sure if systemd related). I have no memory what I did about it :)
<davidlt[m]> So it's time to rediscover :D
<davidlt[m]> In general the problem is simple, .text is not writable. binutils generates TEXTREL and dynamic loader cannot do anything about it.
<davidlt[m]> Thus resulting in:
<davidlt[m]> [ 2123.613276] systemd-logind[1393]: /usr/lib/systemd/systemd-logind: error while loading shared libraries: cannot make segment writable for relocation: Operation not permitted
<davidlt[m]> ```
<davidlt[m]> ```
<davidlt[m]> Fun fact, running /usr/lib/systemd/systemd-logind manually (as root) seems to work (?).
<davidlt[m]> So is it:
<davidlt[m]> 2. binutils acting up and generating wrong TEXTREL (not the 1st time, there is a ticket open for riscv64 [and other arches] about it
<davidlt[m]> 3. capabilities
<davidlt[m]> 1. Missing PROT_WRITE or something similar somewhere
<davidlt[m]> Well, it could be also 4. SELinux blocking it
<davidlt[m]> Somehow I bet on binutils bug for now.
<zbyszek[m]> How is 3.capabiliies related?
<davidlt[m]> Because running as root seems to work (well, I don't have exact environment as what's inside system daemon). systemd-logind.service lists a bunch of capabilities, so it's limited.
<zbyszek[m]> Yeah, but are caps related to linking in any way?
<davidlt[m]> It shouldn't, unless there is something that blocks writing to memory.
<davidlt[m]> Because running as root (without all other stuff in systemd service file) seemed to work fine.
<davidlt[m]> Again, not the same environment.
<davidlt[m]> But again scanelf also says TEXTREL exist (the flag), but has no actual TEXTRELs.
<davidlt[m]> Rebuilding with 2.39 binutils is relatively fast test and cheap :) So let's wait a bit, get the morning coffee/tea in.
<davidlt[m]> Let the brain boot up properly ☕️
<davidlt[m]> I also looked as known working systemd build, and there are no TEXTRELs.
<davidlt[m]> FYI:
<davidlt[m]> This was not fixed for riscv.
<davidlt[m]> I bet everyone forgot about it, especially since Jim left.
<davidlt[m]> On OpenEmbedded/Yoct side were is a QA check that looks for textrels.
<davidlt[m]> Something like:
<davidlt[m]> ERROR: QA Issue: ELF binary '/work/i586-oe-linux/glide/0.13.1-r0/packages-split/glide/usr/bin/glide' has relocations in .text [textrel]
<davidlt[m]> ```
<davidlt[m]> ```
<davidlt[m]> I keep seeing harderings and textrels in the same context a lot more.
jcajka has joined #fedora-riscv
tg has quit [Quit: tg]
rwmjones has quit [Read error: Connection reset by peer]
rwmjones has joined #fedora-riscv
<davidlt[m]> 21 minutes, 13.1.1-1, in gcc.spec :)
<davidlt[m]> Seems that binutils 2.39 is also generating TEXTREL
<davidlt[m]> TYPE TEXTRELS FILE
<davidlt[m]> scanelf: scanelf_file_textrels(): ELF ./usr/lib/systemd/systemd-logind has TEXTREL markings but doesnt appear to have any real TEXTREL's !?
<davidlt[m]> ET_DYN ./usr/lib/systemd/systemd-logind
davidlt_ has quit [Ping timeout: 260 seconds]
<rwmjones> it's about the 10th time I've restarted this dnf5 build ...
<davidlt[m]> What happened?
<rwmjones> perl flags incompatibilities
<rwmjones> ccache causing trouble
<rwmjones> I'm hoping the current build will get past the %build step
davidlt_ has joined #fedora-riscv
<davidlt[m]> Is that because you are compiling on top of F33 without mock, container, similar?
<davidlt[m]> I wonder who added rpmbuild --help in the mock...
<davidlt[m]> `DEBUG util.py:540: Executing command: ['rpmbuild', '--help'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'C.UTF-8'} and shell False`
<davidlt[m]> nirik: ^^
<davidlt[m]> I just don't see a point of it in root.log
<rwmjones> davidlt[m]: I'm building on an unholy fix of F37 & F38
<zbyszek[m]> It's probably using --help to check for support for some option.
<davidlt[m]> zbyszek: with hardening disabled TEXTREL goes away
<davidlt[m]> I wonder what would happen with LTO disabled.
zsun has joined #fedora-riscv
<skip77> Wanted to pop in and thank you guys for all the excellent fixes and things that you've already figured out for me :P
<skip77> My Rocky9 openssl build failed this morning, and I nip over to the Risc-V Koji, and there it is waiting for me
<skip77> "Add --libdir=lib64 for riscv64 (uses linux-generic64)" Easy-peasy
<davidlt[m]> Yeah, I wonder if that's still needed actually :)
<davidlt[m]> I am just too lazy to spend the compute hour to figure it out :)
<davidlt[m]> But for the older OpenSSL you definitely need it.
<davidlt[m]> Looking quickly.. and modern OpenSSL already has linux64-riscv64
<davidlt[m]> I will spin a build for that tomorrow.
<thefossguy> Quick question, on a cold boot, does uboot have any environment values already set? Can those be "hardcoded" by the vendor?
<davidlt[m]> Could you be more precise?
<davidlt[m]> In general U-Boot will set them.
<thefossguy> I have quite a few values set when I printenv
<davidlt[m]> Yes, U-Boot will generate all that environment.
<davidlt[m]> e.g. read EEPROM and set MAC address (and export that into environment).
<davidlt[m]> You can hardcode environment too. It's all in one header file.
<thefossguy> At the moment, StarFive seems to have hardcoded the 3rd partition as the FAT part to boot from and look for uEnv.txt.
<thefossguy> I tried a new image where I ignore the first two uboot and fw_* parts and am running into this issue
<davidlt[m]> Yeah, some folks assume that uEnv is universal U-Boot thing.
<thefossguy> I'm just going with the convention for now :D
<thefossguy> But the crux of the issue is that uboot is looking for the fat part as the 3rd part, not 1st part
<thefossguy> By extension, it is not loading uEnv lol
<thefossguy> But loads the kernel and dtb (because it found extlinux.conf in 1st part)
<thefossguy> But since uenv wasn't loaded somehow (don't know how lol), uboot now complains that some kernel_size_* variables are not set
<davidlt[m]> Well, all that logic is not part of upstream stuff they sent :)
<thefossguy> I know uenv isn't loaded because those variables are defined in uenv
<davidlt[m]> Oh yeah, you cannot load compressed kernel without those variables.
<thefossguy> davidlt[m]: Ah, looks like I have to compile uboot too
<thefossguy> fml but new adventure :D
<thefossguy> Yep, those! Haven't mugged up those yet haha
<davidlt[m]> All that huge logic they have in vendor U-Boot is not there.
<davidlt[m]> The initial (and minimal) support only brings the basics in.
<thefossguy> insert tony stark relief gif
<davidlt[m]> Note, `"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \` is a problem.
<davidlt[m]> As we discussion before this should not be hardcoded, but set by code after reading EEPROM.
<davidlt[m]> That's how EXLINUX will know what to load.
<thefossguy> I assume by this you mean that uboot will/shoould patch it on the fly?
<davidlt[m]> `+CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b"`
<davidlt[m]> It should just set that after reading EEPROM, see the other patch proposed.
<davidlt[m]> It only sets `env_set_hex("board_revision", pcb_rev);`
<davidlt[m]> It should also set a proper fdtfile based on board revision.
<davidlt[m]> Otherwise EXTLINUX code will not generate a proper path on 1.2A board.
<davidlt[m]> Pratham Patel: are you cooking some custom disk images?
<thefossguy> Yep, though Arch Linux for now
<davidlt[m]> Cool!
<thefossguy> I’m going out. Will check back soon!
jcajka has quit [Remote host closed the connection]
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
<davidlt[m]> zbyszek: FYI, disabling LTO also kills TEXTREL. I dropped fortify level from 3 to 2 now to test.
zsun has quit [Quit: Leaving.]
esv_ has joined #fedora-riscv
esv has quit [Ping timeout: 260 seconds]
davidlt_ has quit [Ping timeout: 240 seconds]
esv_ is now known as esv
troglodito has quit [Ping timeout: 240 seconds]
troglodito has joined #fedora-riscv