mason | onefang: Zapping the grub-efi-amd64-signed package worked on the one system that had an issue here. | 00:10 |
---|---|---|
mason | There's also elilo. | 00:10 |
fsmithred | and it happened to someone who did not have the signed package installed | 00:14 |
mason | GRUB grubbing. | 00:21 |
DPA | Looks like this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908200 | 02:12 |
fsmithred | yeah, it keeps coming back | 02:28 |
tuxd3v | the secure boot thing that in the ends plagues everything :) | 02:46 |
parabyte | okay i cant get nfs shares to automount on latest 3.1 | 16:46 |
parabyte | im getting this error and other errors | 16:46 |
parabyte | Sun Mar 7 15:19:07 2021: /etc/init.d/rpcbind: 42: /etc/init.d/rpcbind: stat: not found | 16:46 |
parabyte | this is the first error | 16:46 |
parabyte | anyone got any insight? | 16:46 |
parabyte | i can mount shares manually from my fstab for example mount /mnt/share | 16:47 |
ErRandir | stat is in coreutils | 16:47 |
parabyte | yeah i got coreutils installed | 16:49 |
parabyte | its some sort of bug im hitting i think ErRandir | 16:49 |
parabyte | im only a user, but from what i can tell the rpcbind script cant find stat | 16:50 |
ErRandir | It's in /usr/bin/ for me. Maybe that directory is not in the PATH when /etc/init.d/rpcbind is invoked. | 17:13 |
parabyte | ErRandir, yes it was a bug with stat | 19:07 |
parabyte | in the network if up script, it calls the script for nfs eventually well in the initial script in the PATH there was no path to where stat lives | 19:08 |
parabyte | do i need to make a bug report or can someone here follow this up? | 19:08 |
numzob | so I've got a program the compiles in other distros, and it fails to compile in devuan. near as I can tell, it fails to find ncurses. fought with it a while. got a little crazy. even did "apt-get install ncurses*" (note the wildard, using the shotgun aproach there). error message has moved from the compile phase (.h file) to the link phase (library). Near as I can tell I've included anything even | 19:12 |
numzob | remotely related to ncurses. can i have a hint please? Oh, here is a one line sample of the errors it gives me: /usr/bin/ld: xci.c:(.text+0x77f5): undefined reference to `wrefresh' | 19:12 |
iv4nshm4k0v | numzob: How does your linking command look like? Specifically, does it include "-lncurses"? | 19:13 |
numzob | full command (small program): cc -o xci -lncurses xci.c | 19:14 |
numzob | worked previously in lfs and slackware | 19:14 |
numzob | i know debian, and this devuan, breaks things into package and package-devel but even so it's dirving me bonkers | 19:15 |
numzob | s/this/thus/ | 19:15 |
golinux | parabyte: Have you checked Debian bugs? | 19:16 |
parabyte | i sent a bug email to devuan explaining what i have done to make nfs mounting via fstab work | 19:16 |
golinux | That's probably where you'll have to file one if it's not already there. | 19:16 |
fluffywolf | do you have lib64ncurses-dev (or 32)? | 19:16 |
mason | numzob: Have you checked your ld.so.conf and ruled out a funny LD_LIBRARY_PATH and so forth? | 19:16 |
iv4nshm4k0v | numzob: Try putting -lncurses last; like: $ cc -o xci xci.c -lncurses . | 19:16 |
golinux | If we don't fork the package, we don't fix it | 19:17 |
parabyte | golinux, was a really really really easy fix i just altered the PATH variable in /etc/network/if-up.d/mountnfs | 19:17 |
parabyte | so that the nfs script that mountnfs calls could see stat | 19:17 |
mason | parabyte: Do you have a separate /usr or somesuch? | 19:18 |
parabyte | mason, no | 19:18 |
numzob | fluffywolf: no. looks like i have to explicitely install the 64 version. that is unexpected, being that this is on a 64 bit cpu | 19:19 |
fluffywolf | does that make it compile? | 19:21 |
numzob | well, I don't have a funny $LD_LIBRARY_PATH ... but then again, I haven't got a $LD_LIBRARY_PATH. Hmm. | 19:21 |
numzob | fluffywolf: trryinh that next | 19:21 |
fluffywolf | although I think installing libncurses-dev should magically get everything... | 19:23 |
numzob | libncurse-dev i installed before even trying to compile | 19:23 |
fluffywolf | I have a multi-arch system; could be you don't need the extra 32/64 versions... | 19:24 |
iv4nshm4k0v | I see that ld does /not/ report it can't find the library; only that it can't find specific functions that are ought to come from that library. It looks like an ordering issue; ISTR that in ld (cc) invocations the objects can only use other objects or libraries specified /after/ said objects. For that reason, all the '-l's would be specified after all the '.o's (and '.c's and whatnot.) | 19:25 |
numzob | installing the 64 bit ncurses explicitly, did two things: one: it told me that i already had the 64 bit versions installed. two: it installed the 32 bit versions. | 19:25 |
numzob | reording, ok. tryng that next | 19:25 |
numzob | reordering fixedit. wow. | 19:27 |
numzob | thank you :) | 19:27 |
fluffywolf | that's an issue I've never seen. I always put all my -ls first. lol | 19:27 |
numzob | yeah, that's a thing i was not expecting | 19:28 |
iv4nshm4k0v | fluffywolf: There may be some inconsistencies in how different compilers / linkers / builds / environments handle ordering. I think I've either seen myself or heard from others about either "-l can be anywhere" or "-l should go last" only, though. | 19:30 |
mason | numzob: You normally don't *want* LD_LIBRARY_PATH. But it's the cause of similar errors sometimes. | 19:30 |
numzob | mason: ohhhh, ok. thank you, as my next was to try and set it (and probably go crazy :p ) | 19:32 |
mason | numzob: Sometimes at work we see people who have one fork special purposes applications, and it ends up hosing a vast array of unrelated software. | 19:32 |
mason | They'll set it in their environment generally rather than in a start-up script for whatever the odd software is. | 19:32 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!