| 00:06.00 | *** join/#devuan golinux (~golinux@cpe-66-68-116-77.austin.res.rr.com) |
| 00:06.01 | *** join/#devuan golinux (~golinux@devuan/developer/golinux) |
| 00:12.57 | *** join/#devuan hufdufhv (~Thunderbi@123.234.229.29) |
| 00:26.03 | rwp | I assume that is part of the movement to have a combined /usr/bin & /bin and /usr/sbin & /sbin? |
| 00:26.49 | fsmithred | no, it's a product of su being moved from the shadow package to util-linux |
| 00:27.24 | rwp | Oh, su... So it's only when you su to root? (I am looking to see where this PATH problem is happening...) |
| 00:27.35 | fsmithred | To revert to the old behavior, put this in /etc/default/su |
| 00:27.42 | fsmithred | ALWAYS_SET_PATH yes |
| 00:27.58 | rwp | I haven't seen the problem myself it. Looking to see if I can recreate it. |
| 00:28.20 | fsmithred | default setup in beowulf is this: if you use su, you don't get the sbins in your path. If you use 'su -' you do get root's path. |
| 00:28.45 | rwp | How about in ceres? That's where I am looking at the moment. I'll switch to looking at beowulf. |
| 00:29.15 | fsmithred | I assume ceres is the same as beowulf. |
| 00:29.37 | fsmithred | 99% sure it is |
| 00:30.07 | rwp | If this gets tedious just ignore me... I look in /etc/profile and PATH there includes PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" |
| 00:30.45 | gnarface | if you upgraded, you probably kept your old version, but people with new installs are getting it without /sbin i think |
| 00:30.46 | rwp | I do not have /etc/default/su on the system. util-linux is installed version 2.33.1-0.1+devuan1~beowulf2 |
| 00:31.11 | gnarface | malade_mental: i forgot to mention the default behavior of su changed too, see this conversation here^ |
| 00:31.41 | rwp | Right. It's an upgrade. However I probably somewhat unusually upgrade with -o DPkg::Options::=--force-confnew -o DPkg::Options::=--force-confmiss |
| 00:32.07 | rwp | That should replace all of my previously existing conffiles with the new version of the conffile from the package. |
| 00:32.40 | rwp | I also look for obsolete conffiles and remove them too. So I won't have anything left behind from the previous that doesn't exist in the new package. |
| 00:32.43 | rwp | Hopefully. |
| 00:32.55 | gnarface | maybe i'm wrong and that's not in beowulf yet |
| 00:32.58 | fsmithred | you would have to create /etc/default/su |
| 00:33.21 | rwp | FYI on the obsolete conffiles: dpkg-query -W -f='${Package} ${Conffiles}\n' | less |
| 00:35.35 | rwp | I do not have a /etc/default/su file. Not anywhere that I look on the various systems. |
| 00:36.28 | fsmithred | right. You would have to create it. |
| 00:36.56 | rwp | I do usually have my own custom /root/profile file installed overwriting the system one. |
| 00:37.28 | fsmithred | then you're all set |
| 00:37.31 | rwp | So if PATH was inappropriately set in /root/profile then I would have automatically fixed it with my overwritten copy. |
| 00:38.41 | rwp | Right. But I tend to be local admin support. So when odd and unusual questions arise in IRC it is good if I understand them because I can guarentee you that if it is a possible problem in the wild that I will eventually get asked to help someone IRL about it. |
| 00:38.42 | fsmithred | what annoys me about the new setup is that I usually want to stay in the current directory when I su, but that no longer gives me root's path. |
| 00:39.06 | fsmithred | 'su -' gives the right path but changes directory to /root |
| 00:39.24 | fsmithred | lol |
| 00:40.03 | adhoc | 'su -' is the right thing to be doing? |
| 00:40.06 | rwp | I prefer to change directory and reset HOME. Because otherwise many utils chown stuff in ~rwp to be owned by root causing me problems later. |
| 00:40.17 | adhoc | i very rarely use just 'su' |
| 00:40.25 | fsmithred | adhoc, I think there's some room for opinion |
| 00:40.33 | rwp | adhoc, "Right thing" is a loaded question. Since it all depends. And there is more than one way to do things. |
| 00:40.42 | adhoc | just su mess up permissions on local files in the users directory |
| 00:40.48 | rwp | But "su -" and "sudo -i" are both good ways. |
| 00:41.06 | adhoc | sudo is rarely "good", IMHO. |
| 00:41.25 | adhoc | however, grok "sudo -i" |
| 00:41.36 | adhoc | i tend to use "sudo su -" from habbit |
| 00:41.36 | rwp | Really? I use 'su' *a lot* but I have no grudges against 'sudo' and also use it a lot. |
| 00:41.48 | rwp | Me too. |
| 00:42.07 | adhoc | I only use sudo on systems that are outside of my admin sphere where accounts are centrally managedy |
| 00:42.28 | adhoc | some linux distros enforce sudo, which I feel is less than ideal. |
| 00:43.17 | rwp | I don't know of any distros that enforce using sudo but I do know some corporate environments that do so as a local admin policy. |
| 00:43.25 | adhoc | anyway, I gave up "su" as it would change the "user:group" of dot files in the home directory of the user. makes like hard later |
| 00:43.35 | rwp | For say Ubuntu and Mint and those one can always set a password for 'root' and then use su if one wants to. |
| 00:43.56 | adhoc | default ubuntu does not set a functionally available root password and you must sudo |
| 00:44.24 | adhoc | so when you try to support those platforms for other users, life is fun. in the dwarf fortress sense |
| 00:44.28 | rwp | Agreed on the changing of ~/ dot files. That is mostly due to $HOME not changing. aptitude is an example of a program that writes stuff in $HOME as root. But many others do too. |
| 00:44.39 | adhoc | vi |
| 00:44.40 | adhoc | vim |
| 00:45.00 | rwp | But remember if you have sudo you can always "sudo passwd root" and set a password for root. Then there is a password for root moving forward. |
| 00:45.02 | adhoc | anyhow |
| 00:45.24 | adhoc | sure I can, but other folks new to linux, not so much. |
| 00:45.40 | rwp | Learning curve for new users is always going to be a problem. |
| 00:46.10 | rwp | It is the same as the tyranny of the default. Whatever is the default then the newbie will never change from it. So the default becomes the majority. |
| 00:46.24 | adhoc | I've been using linux for a while, but my students who have hours, I try to avoid problems where they mess things up too much |
| 00:47.09 | adhoc | most my students run winodws, 10% mac, 1% linux. |
| 00:47.26 | rwp | Unfortunately that is about typical demographics these days. |
| 00:47.45 | adhoc | We provide them with VMs to do their technical tasks.If I can avoid it, I don't use Ubuntu. |
| 00:53.08 | rwp | malade_mental, In your minimal install is /bin a symlink to /usr/bin? If so then that would explain why you have /usr/bin in PATH but not /bin due to that consolidation. |
| 00:53.49 | rwp | Which is a separate issue from 'su' not changing PATH for root to include /usr/sbin (and /sbin) by default anymore. |
| 01:06.18 | *** join/#devuan Uberius (~uberius@gateway/tor-sasl/uberius) |
| 01:06.37 | *** join/#devuan unixman (~aunixman@209.165.134.7) |
| 01:06.38 | *** join/#devuan unixman (~aunixman@unaffiliated/eracc) |
| 01:10.39 | *** join/#devuan klaus (~klaus@lfbn-mar-1-506-69.w90-73.abo.wanadoo.fr) |
| 01:16.06 | adhoc | rwp: is there a move to combine all the things into one "bin" path? |
| 01:16.19 | adhoc | (or am I reading too much into between the lines) |
| 01:35.35 | *** join/#devuan sunshavi (~user@190.236.255.122) |
| 01:37.18 | *** join/#devuan epony (epony@unaffiliated/epony) |
| 01:44.40 | *** join/#devuan hufdufhv (~Thunderbi@123.234.229.29) |
| 01:50.53 | *** join/#devuan Jjp137 (~Jjp137@cpe-75-83-20-74.socal.res.rr.com) |
| 01:56.25 | golinux | adhoc: FYI What's new in this release |
| 01:56.25 | golinux | Changes in su |
| 01:56.25 | golinux | <PROTECTED> |
| 01:56.25 | golinux | <PROTECTED> |
| 01:56.25 | golinux | <PROTECTED> |
| 01:56.26 | golinux | <PROTECTED> |
| 01:56.28 | golinux | <PROTECTED> |
| 01:56.30 | golinux | <PROTECTED> |
| 01:57.13 | golinux | Much more in the Release Notes http://files.devuan.org/devuan_beowulf/Release_notes.txt |
| 01:58.49 | rwp | adhoc, https://wiki.debian.org/UsrMerge |
| 02:17.15 | *** join/#devuan Jjp137 (~Jjp137@cpe-75-83-20-74.socal.res.rr.com) |
| 02:21.32 | *** join/#devuan debdog (~debdog@194.140.113.47) |
| 02:41.28 | *** join/#devuan sunshavi (~user@190.236.255.122) |
| 02:42.21 | meep_____ | https://oc.cil.li/topic/2226-flatdb-an-sql-implementation/ |
| 02:42.25 | meep_____ | Wrong chat sorry |
| 03:04.56 | *** join/#devuan byzandula (~byzandula@beerbq.net) |
| 03:05.52 | *** join/#devuan paradigm (~paradigm@159.203.177.222) |
| 03:05.52 | *** join/#devuan FatPhil (~phil@70-251-190-90.dyn.estpak.ee) |
| 03:05.54 | *** join/#devuan sauron- (~foo@unaffiliated/sauron-) |
| 03:06.22 | *** join/#devuan Tashtari (~tashtari@unaffiliated/tashtari) |
| 03:06.23 | *** join/#devuan yae7nae4 (~yae7nae4@ezup.dev) |
| 03:06.25 | *** join/#devuan buZz (~buzz@joint.ro.lt) |
| 03:10.35 | *** join/#devuan tuxd3v (~tuxd3v@93.102.250.232.rev.optimus.pt) |
| 03:16.25 | tuxd3v | meep_____, does you like to mine? |
| 03:16.55 | meep_____ | Yes |
| 03:17.35 | tuxd3v | what do you mine usually? |
| 03:42.11 | meep_____ | Ncp+ |
| 03:54.47 | *** join/#devuan sunshavi (~user@190.236.255.122) |
| 04:02.33 | *** join/#devuan sunshavi (~user@190.236.255.122) |
| 04:10.13 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:50.18 | *** join/#devuan ar3itrary (~hacker@v22016101923038440.bestsrv.de) |
| 05:06.43 | *** join/#devuan bgustav (~bgustav@188.26.89.205) |
| 06:00.40 | *** join/#devuan cocoadaemon (~foo@2a01:e0a:4e1:97e0:179d:1cc6:8854:4d5c) |
| 06:24.38 | *** join/#devuan enyc (~enyc@muddle.enyc.org.uk) |
| 06:27.11 | *** join/#devuan Guest37465 (~buzz@unaffiliated/buzz) |
| 06:28.27 | *** join/#devuan silentjet (~jet@staticline-31-182-193-145.toya.net.pl) |
| 06:28.52 | *** join/#devuan silentjet (~jet@staticline-31-182-193-145.toya.net.pl) |
| 06:29.56 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 06:45.06 | *** join/#devuan KnoP (~KnoP@business-176-095-149-105.static.arcor-ip.net) |
| 06:49.48 | *** join/#devuan hufdufhv (~Thunderbi@123.234.229.29) |
| 06:58.34 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 07:30.57 | *** join/#devuan tierce (~raoulzeca@2a02:578:857c:c01:ca7f:fd8c:e7b9:b99e) |
| 07:36.30 | malade_mental | rwp: gnarface: many information to read after a night of sleep :] |
| 07:37.02 | malade_mental | I think I have to debootstrap more packages so the installation is complete |
| 07:37.56 | malade_mental | and I'll retry this after having a correct devuan on my physical machine (cause everything i tests was on VM) |
| 07:45.56 | *** join/#devuan dagelf (~quassel@169-0-60-17.ip.afrihost.co.za) |
| 08:11.52 | *** join/#devuan Garb0 (~Garb0@unaffiliated/garb0) |
| 08:19.30 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
| 08:25.35 | *** join/#devuan jaromil (~jaromil@vm8.ganeti.dyne.org) |
| 08:25.36 | *** join/#devuan jaromil (~jaromil@devuan/developer/jaromil) |
| 08:26.26 | *** join/#devuan golinux (~golinux@vm8.ganeti.dyne.org) |
| 08:26.27 | *** join/#devuan golinux (~golinux@devuan/developer/golinux) |
| 08:27.25 | *** join/#devuan enyc (~enyc@muddle.enyc.org.uk) |
| 08:28.12 | *** join/#devuan hufdufhv (~Thunderbi@123.234.229.29) |
| 08:28.56 | *** join/#devuan hellekin (~how@unaffiliated/hellekin) |
| 08:33.28 | *** join/#devuan enyc (~enyc@muddle.enyc.org.uk) |
| 08:52.50 | *** join/#devuan ham5urg (~ham5urg@2a04:4540:680f:cb00:35ab:ce29:9e66:9beb) |
| 09:08.09 | *** join/#devuan rocket_ca (~rocket@S0106306023d52be8.cg.shawcable.net) |
| 09:09.33 | *** part/#devuan rocket_ca (~rocket@S0106306023d52be8.cg.shawcable.net) |
| 09:10.51 | *** join/#devuan rocket_ca (~rocket@S0106306023d52be8.cg.shawcable.net) |
| 09:48.21 | *** join/#devuan cocoadaemon (~foo@2a01:e0a:4e1:97e0:179d:1cc6:8854:4d5c) |
| 10:04.33 | *** join/#devuan KnoP (~KnoP@business-176-095-149-105.static.arcor-ip.net) |
| 10:10.39 | openbsdtai123 | why TED editor is not in the repositories yet? This is X11 though :( |
| 10:11.06 | *** join/#devuan proteus-guy (~proteus-l@ppp-124-122-192-62.revip2.asianet.co.th) |
| 10:17.51 | malade_mental | ok guys, this just is REALLY sucky. |
| 10:32.23 | malade_mental | I netinstall with the last iso, install just OpenSSH server and base system, and choose openrc as init system |
| 10:33.22 | malade_mental | the /bin and /sbin are not symlinks but I have them in the path |
| 10:35.09 | malade_mental | if I login into root directly from login only, if I login from my normal user, I don't have the "sbin" directories, and if I "su", I still don't have them. |
| 10:38.04 | fsmithred | malade_mental, see the release notes for changes in su and other goodies. |
| 10:39.14 | fsmithred | you can use 'su -' or 'su --login' to get root's path. |
| 10:39.45 | fsmithred | or set it to revert to the old behavior |
| 10:42.33 | rrq | malade_mental: you don't get /bin in $PATH ? |
| 10:42.46 | openbsdtai123 | "su -" is the debian increased security. It is crucial for lot of users. Prefer sudo - which allow to increase security instead of using "su" and root account. |
| 10:44.12 | rrq | malade_mental: is it that you don't get /bin in $PATH ? |
| 10:44.34 | fsmithred | that would be very weird |
| 10:44.47 | fsmithred | not sbin makes sense |
| 10:46.01 | openbsdtai123 | fsmithred: during instlaltion it should be sysvinit or openrc, then another dialog: "debian linux" or "unix philosophy". |
| 10:46.03 | malade_mental | rrq: sorry I did not saw i have it |
| 10:46.11 | malade_mental | yeah only "sbins" are missing |
| 10:46.27 | openbsdtai123 | sbins are necessary to have. |
| 10:46.36 | malade_mental | so there is no usrmerge by default? that's a pretty good point! |
| 10:46.42 | fsmithred | not in devuan |
| 10:46.44 | malade_mental | sbins is not in the PATH |
| 10:46.52 | fsmithred | we fixed usr merge so it's optional |
| 10:46.58 | malade_mental | fsmithred: phew =] sorry I was alarmed too fast |
| 10:47.03 | malade_mental | have to it |
| 10:47.04 | fsmithred | READ THE RELEASE NOTES |
| 10:47.04 | openbsdtai123 | export can add them. |
| 10:47.11 | fsmithred | or read 'man su' |
| 10:47.19 | openbsdtai123 | Dont read, ask us... we arethere. |
| 10:47.22 | fsmithred | yor export |
| 10:47.24 | fsmithred | or |
| 10:47.49 | fsmithred | I get tired of typing the solution over and over again when it's right there in the release notes |
| 10:48.41 | *** join/#devuan paradigm (~paradigm@osuosc/paradigm) |
| 10:49.04 | openbsdtai123 | "set" will tell you what is the PATH= |
| 10:49.17 | openbsdtai123 | export PATH... can remodify it according to your own needs. |
| 10:49.53 | openbsdtai123 | fsmithred: this is why there is kde and ubuntu. |
| 10:50.50 | malade_mental | I have to eat, thanks for your answers ;) |
| 10:51.39 | openbsdtai123 | anytime |
| 10:51.42 | openbsdtai123 | bon appetit |
| 10:52.32 | openbsdtai123 | (bio naturellement ;) |
| 11:21.52 | *** join/#devuan klaus (~klaus@lfbn-mar-1-506-69.w90-73.abo.wanadoo.fr) |
| 12:13.20 | *** join/#devuan mmphs (~mmphs@83.25.154.102.ipv4.supernova.orange.pl) |
| 13:07.29 | *** join/#devuan specing (~specing@unaffiliated/specing) |
| 13:08.01 | *** join/#devuan cd (~cd@unaffiliated/cd) |
| 13:21.09 | *** join/#devuan brocashelm (~brocashel@075-142-081-050.res.spectrum.com) |
| 13:23.41 | *** join/#devuan Garb0 (~Garb0@unaffiliated/garb0) |
| 13:24.35 | *** join/#devuan brocashelm1 (~brocashel@107.181.166.214) |
| 13:26.09 | *** join/#devuan brocashelm (~brocashel@107.181.166.214) |
| 13:26.11 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 13:40.07 | *** join/#devuan user282069 (~user@32.ip-51-91-79.eu) |
| 13:45.52 | *** join/#devuan bgustav (~bgustav@188.26.89.205) |
| 13:57.56 | gordonDrogon | Hm. I see Beowulf gives us 's' in ls output now. Just read the history of that. Interesting and unexpected. |
| 13:58.12 | gordonDrogon | (as in quotes round 'tricky' filenames) |
| 13:59.23 | *** join/#devuan Centurion-Dan2 (~Thunderbi@devuan/developer/centuriondan) |
| 14:09.56 | *** join/#devuan ac_laptop (~ac_laptop@186.2.247.129) |
| 14:12.57 | *** join/#devuan cd (~cd@unaffiliated/cd) |
| 14:19.22 | *** join/#devuan cocoadaemon (~foo@2a01:e0a:4e1:97e0:179d:1cc6:8854:4d5c) |
| 14:21.17 | fsmithred | aka tricky quotes around filenames. |
| 14:23.56 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
| 14:29.35 | *** join/#devuan proteusguy (~proteusgu@cm-58-10-208-180.revip7.asianet.co.th) |
| 14:30.03 | nemo | gordonDrogon: the surprising part for me is that it happens even with "/bin/ls" |
| 14:30.17 | nemo | gordonDrogon: I'm used to having predictable output by doing an explicit path to avoid aliases |
| 14:30.24 | gordonDrogon | yea, it's an opt-out now. Add -N |
| 14:30.49 | nemo | it's kind of irritating. since now I get double quoting |
| 14:30.54 | nemo | but yeah, opt out :/ |
| 14:31.28 | gordonDrogon | like colours - I never asked nor wanted them, but more shenanigans needed there. |
| 14:31.42 | gordonDrogon | engages grumpy old man mode ... |
| 14:32.14 | gordonDrogon | https://superuser.com/questions/1376351/why-does-ls-wrap-some-filenames-in-single-quotes |
| 14:32.18 | nemo | gordonDrogon: I guess piping is another opt out |
| 14:32.50 | nemo | hm. that's odd |
| 14:32.51 | gordonDrogon | well. once upon a time... ls | sort | pr -6 |
| 14:32.58 | nemo | /bin/ls | less seems to not have quotes |
| 14:33.08 | nemo | yet that superuser says piping is one of the reasons they did it |
| 14:33.12 | gordonDrogon | it's for interactive ls only. |
| 14:33.26 | nemo | "ls wraps single quotes around filenames with spaces in them, for the purpose of allowing the filenames to be safely copied, used in a script or piped through another command." |
| 14:33.31 | nemo | sure not the implication of that lead sentence |
| 14:33.38 | nemo | but at least they aren't breaking existing pipes |
| 14:34.47 | gordonDrogon | goes back to the ol ddays of BCPL ... |
| 14:34.47 | *** join/#devuan jathan (~jathan@189.216.181.206) |
| 14:38.44 | *** join/#devuan bsd4me (~me@152-104-74-65.gci.net) |
| 14:38.47 | openbsdtai123 | how to get a directory with ftp? get -r directory? |
| 14:39.58 | gordonDrogon | mget |
| 14:40.23 | gordonDrogon | although it's been years since I did that sort of thing. any reason to not use scp or rsync ? |
| 14:41.24 | openbsdtai123 | on the linux machine, only the default machine is installed distant. not even wget... :( so man, ftp has this feature? |
| 14:44.04 | openbsdtai123 | it seems that ftp has no recursive feature. |
| 14:44.10 | gordonDrogon | no idea. I don't even have ftp installed these days. |
| 14:45.01 | openbsdtai123 | overusing the shinning graphical desktops? |
| 14:45.28 | gordonDrogon | no - mostly of the stuff I do is command-line, but I moved to scp and rsync some time ago. |
| 14:45.40 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 14:46.20 | openbsdtai123 | ftp is mostly a dead protocoll. I still use it since it works well with my android and on all machines. Even a Macintosch ;) |
| 14:46.53 | gordonDrogon | although I did ressurect rsh/rcp in the early Raspberry Pi days as encryption was very slow for scp. |
| 14:48.11 | gordonDrogon | ah, you've remonded me, I did have ftp on my old PC - just for my android phone. I've not installed it on the new PC yet. andftp I think I use, so yea, GUI from the phone. |
| 14:48.47 | openbsdtai123 | I just compiled ncftp but I guess this issue with get -R -f dir, "Could not traverse directory: could not parse extended file or directory..." |
| 14:49.08 | *** join/#devuan golinux_ (~golinux@devuan/developer/golinux) |
| 14:49.47 | openbsdtai123 | gordonDrogon: AndFTP is magic on the phone. Wish I had a N900, this would solve many file exchnage issues and more: Unix. |
| 14:50.40 | gordonDrogon | I have an n900, but it's broken now. |
| 14:50.52 | openbsdtai123 | wow |
| 14:51.19 | openbsdtai123 | I would be glad to have one, even broken, to fix. Those machines are very rare. |
| 14:51.30 | openbsdtai123 | I have a zaurus 3100 with debian on it. |
| 14:53.04 | *** join/#devuan silentjet (~jet@staticline-31-182-193-145.toya.net.pl) |
| 14:55.32 | gordonDrogon | it's no use now - not in the UK anyway - it was only 3G from what I recall. |
| 14:55.58 | gordonDrogon | I moved from that to android a long while back, but yes, it was fun to ssh into it.. |
| 14:57.17 | openbsdtai123 | really? 3G is pretty good. In UK, shall you have only 4G or 5G? lucky cancer with the coming 6G, we will all finish in hostpital with all those magnetic fields. |
| 14:57.58 | gordonDrogon | we have 2/3/4g here. but I guess I'm used to 4g all the time now. |
| 14:59.07 | gordonDrogon | and hurrah, it looks like Debuan Beowulf can read the files off my phone using shotwell and mpt, so I can remove andftp from it and no need to let google steal all myphotos now. |
| 14:59.10 | openbsdtai123 | I try to reduce the usage of phone, bluetooth,... for medias. 5G is for bad software, when we can use better software. FTP or SSH rather than a web or google, ms for streaming... and all modern crap. |
| 14:59.16 | gordonDrogon | *Dvuan, of-course.. |
| 14:59.48 | openbsdtai123 | gordonDrogon: I wish people would think like you and not use google. |
| 15:01.20 | gordonDrogon | googl has it's uses - you just need to know how to use it. |
| 15:01.25 | gordonDrogon | and not rely on it. |
| 15:01.48 | gordonDrogon | however - really - I'm sure stuff like that is best discussed elsewhere. |
| 15:02.01 | gordonDrogon | Here I'm liking Beowulf more and more... |
| 15:03.02 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 15:03.58 | openbsdtai123 | I cannot make this completely off Unix of debian and modern devuan. I wont move to beowulf just to loose the pricing of loosing unix. Even less, ... is not there. Once we will have just no "su", "cp", .... no more "cat" ... |
| 15:04.11 | nemo | say, in debian, is there a way to cleanup the cache after a release upgrade? |
| 15:04.30 | nemo | hm. say, something like "delete any archived version that is not currently installed" |
| 15:04.35 | gordonDrogon | apt clean |
| 15:04.35 | openbsdtai123 | apt-get clean |
| 15:04.38 | nemo | thanks |
| 15:04.49 | nemo | um wait |
| 15:04.53 | openbsdtai123 | su - ; apt-get clean or sudo apt-get clean for newbies |
| 15:04.53 | nemo | that deleted everything doh |
| 15:04.55 | nemo | oh well |
| 15:05.07 | nemo | moar bandwidth burned if I need to reinstall a package ⺠|
| 15:05.13 | openbsdtai123 | all is into var cache apt... directory. |
| 15:05.26 | nemo | openbsdtai123: yeah, and I've rm'd it before. I was just trying for something more nuanced |
| 15:05.31 | nemo | only deleting stuff from old versions |
| 15:07.53 | *** join/#devuan IoFran2 (~Thunderbi@189.237.224.20) |
| 15:08.11 | openbsdtai123 | Maybe there is some way someone... |
| 15:08.14 | openbsdtai123 | someohow. |
| 15:10.15 | gordonDrogon | well that's the first time I've ever been able to successfully use linux to suck stuff off my phone. it's just annoying that google use linux but don't actually support it on the desktop... |
| 15:11.32 | openbsdtai123 | gordonDrogon: google support all nasty things for the users... they corrupt linux. they do it well ;) (+) people use it freely, without obliging them. |
| 15:12.22 | openbsdtai123 | what about raspbian to phone? |
| 15:12.49 | gordonDrogon | same issue as any linux to phone - you'll not get the drivers for the modem/dsp/gps/sensors/etc. |
| 15:15.08 | gordonDrogon | if you want a linux phone there is: https://www.pine64.org/pinephone/ |
| 15:15.49 | openbsdtai123 | Back to telephony with giant rpi phone : https://www.youtube.com/watch?v=R-2-wPX3G5M |
| 15:16.08 | gordonDrogon | I'd get one, but there are a few apps I need to run on a real android phone (businessy based, banking, etc.) |
| 15:16.53 | openbsdtai123 | Get a Pandora with Linux, you can do anything with that. |
| 15:17.08 | gordonDrogon | well sure - it's possible to bolt modems, audio, etc. to a Pi (or other ARM device), but you don't get the small scale or longer battery life of something designed for it. |
| 15:21.42 | openbsdtai123 | the video is very cool. bit big cell phone ;9 |
| 15:25.26 | gordonDrogon | very big. |
| 15:26.12 | openbsdtai123 | For sure, no way to miss it. |
| 15:26.14 | gordonDrogon | although arguably that can be done with an arduino which would help battery but you might not get such a pretty UI |
| 15:26.41 | openbsdtai123 | the samsung cells can power th e rpi zero |
| 15:48.07 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 16:12.47 | *** join/#devuan rsx (~rsx@ppp-188-174-130-224.dynamic.mnet-online.de) |
| 16:14.50 | *** join/#devuan Kruppt (~Kirk_Krup@50-111-37-37.drhm.nc.frontiernet.net) |
| 16:33.44 | *** join/#devuan climbingturtle (~climbingt@c83-248-135-84.bredband.comhem.se) |
| 16:53.32 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 17:04.58 | gnarface | hehe |
| 17:05.06 | gnarface | news on slashdot to day about the planet Ceres |
| 17:05.17 | gnarface | i wonder if we'll get any spillover traffic |
| 17:05.47 | golinux | link? |
| 17:06.51 | gnarface | https://science.slashdot.org/story/20/08/11/001234/planet-ceres-is-an-ocean-world-with-sea-water-beneath-surface-mission-finds |
| 17:07.12 | gnarface | "The dwarf planet Ceres -- long believed to be a barren space rock -- is an ocean world with reservoirs of sea water beneath its surface, the results of a major exploration mission showed on Monday." |
| 17:07.27 | golinux | Whoa . . . maybe to -offtopic? |
| 17:07.36 | gnarface | well you asked for the link |
| 17:07.43 | gnarface | that's all i'll paste |
| 17:07.54 | golinux | Thanks for that. |
| 17:08.40 | gnarface | i was just speculating people might start googling ceres and end up interested in devuan |
| 17:09.52 | golinux | I know. Interesting. Something new for humans to plunder and destroy . . |
| 17:18.14 | meep_____ | I doubt it |
| 17:18.52 | meep_____ | Google & Co only link crappy bloated sites trying to sell you something |
| 17:19.19 | meep_____ | Not homepages and noncommercial sites |
| 17:22.41 | meep_____ | You'd have to use yacy |
| 17:26.40 | fsmithred | calls for a beach day on ceres. (Bring a mask!) |
| 17:27.34 | furrywolf | given the lack of atmosphere, I suspect masks, of the spacesuit helmet variety, would be fairly important. :) |
| 17:40.14 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 17:41.00 | *** join/#devuan ranix (~ranix@li1045-115.members.linode.com) |
| 17:41.41 | ranix | howdy all, I hate systemd and am considering using devuan for my mdraid fileserver. Anything I should be aware of before just jumping in |
| 17:42.04 | ranix | debian user since '98 |
| 17:42.16 | *** join/#devuan fylgje (fylgje@gateway/vpn/protonvpn/fylgje) |
| 17:44.11 | fsmithred | ranix, you will probably feel like you came home after being away for five years. |
| 17:44.35 | ranix | excellent |
| 17:44.41 | fsmithred | if you're going to migrate your system from debian to devuan, please read the appropriate migration guide. |
| 17:44.42 | gnarface | ranix: it works like debian wheezy, more or less |
| 17:44.51 | fsmithred | There are always some tricky parts. |
| 17:44.52 | ranix | this is a fresh install |
| 17:44.57 | fsmithred | cool |
| 17:45.32 | *** join/#devuan tuxd3v (~tuxd3v@93.102.250.232.rev.optimus.pt) |
| 17:46.07 | ranix | I'll get on it as soon as memtest86 gives a clean bill of health |
| 17:46.39 | fsmithred | have you used buster? |
| 17:46.39 | tuxd3v | ranix, that could take a while :) |
| 17:47.39 | tuxd3v | ranix, I believe I have a error also, related with bank 0, unfortunatly :( |
| 17:48.07 | fsmithred | biab |
| 17:51.41 | tuxd3v | does any one knows a solution to get MCE error exceptions on the OS |
| 17:51.43 | tuxd3v | ? |
| 17:51.58 | tuxd3v | I know that there are a mcelog program |
| 17:52.11 | tuxd3v | but I can't find it in beowulf |
| 17:52.37 | systemdlete | dnsmasq dhcp -- I am having a hard time making it work. dnsmasq dns works fine. I see from lsof that dnsmasq is listening on port 53, and I've configured dnsmasq.conf to listen for dhcp by enabling the range variable. Still, client cannot get a lease. |
| 17:52.46 | tuxd3v | after some time, my machine freezes on youtube, for example |
| 17:53.06 | systemdlete | I even set up wireshark to listen for dhcp traffic, and I see the requests from the client |
| 17:53.16 | systemdlete | they are on the same subnet: 192.168.56.0/24 |
| 17:53.20 | tuxd3v | on reboot I get a MCE error related with bank 0, but its very brief I can't read it all, unfortunatly |
| 17:53.45 | systemdlete | it seems like dnsmasq is not really paying attention to dhcp requests |
| 17:54.26 | systemdlete | next step will be to strace dnsmasq and see if it is getting hits |
| 17:54.32 | tuxd3v | systemdlete, I believe dhcp requests need to be inserted in the dns server.. |
| 17:54.46 | systemdlete | "inserted?" |
| 17:54.53 | tuxd3v | yep |
| 17:54.57 | systemdlete | what does that mean? |
| 17:55.12 | tuxd3v | at least with bind9 |
| 17:55.30 | systemdlete | what is the meaning of the word "inserted" here? |
| 17:55.35 | systemdlete | I'm not following that, sorry. |
| 17:56.09 | tuxd3v | inserted means inserted, by the dhcp server into the dns server |
| 17:56.21 | systemdlete | oh. I see now. |
| 17:56.37 | systemdlete | well, dnsmasq is both a dns AND a dhcp server |
| 17:56.46 | systemdlete | so there is no additional work there |
| 17:56.52 | systemdlete | (but I see your point now) |
| 17:56.53 | tuxd3v | Or you can run a cronjob, into the localhost that updates the server with the machine record.. |
| 17:57.54 | tuxd3v | usually its a good practice to update from localhost a entry in the dns server |
| 17:58.11 | systemdlete | I'm not using bind. |
| 17:58.16 | systemdlete | just dnsmasq |
| 17:58.17 | meep_____ | » <ranix> howdy all, I hate systemd and am considering using devuan for my mdraid fileserver. Anything I should be aware of before just jumping in |
| 17:58.17 | meep_____ | try using ZFS instead of dmraid |
| 17:58.27 | tuxd3v | I don't know about dnsmasq, sorry, maybe been it the 2 things .. maybe it does it automatically |
| 17:58.37 | nemo | why does /usr/lib/libreoffice have 260MiB of files according to du -hs after apt remove libreoffice ? |
| 17:58.41 | systemdlete | it does do it automatically |
| 17:59.00 | systemdlete | nemo: apt purge? |
| 17:59.33 | systemdlete | maybe apt autoremove also, idk. I'm not a devuan expert |
| 17:59.48 | *** join/#devuan user282069 (~user@32.ip-51-91-79.eu) |
| 18:01.04 | meep_____ | » [10:52:39] <tuxd3v> does any one knows a solution to get MCE error exceptions on the OS |
| 18:01.04 | meep_____ | are MCE's hardware problems? |
| 18:01.10 | meep_____ | Machine-check-error right? |
| 18:01.37 | meep_____ | » [10:54:18] <tuxd3v> on reboot I get a MCE error related with bank 0, but its very brief I can't read it all, unfortunatly |
| 18:01.37 | meep_____ | sounds like a problem with a ram stick? |
| 18:01.48 | *** join/#devuan alexandros_c (~quassel@unaffiliated/alexandros-c/x-1684531) |
| 18:02.06 | tuxd3v | meep_____, indeed it sounds |
| 18:02.06 | *** join/#devuan alexandros_tab (~quassel@unaffiliated/alexandros-c/x-1684531) |
| 18:02.27 | meep_____ | If you can't get the full error try reseating bank0 |
| 18:02.55 | systemdlete | blow some canned air also maybe? |
| 18:03.04 | meep_____ | Clean the contacts with isoprope. The faster these circuits get the more sensitive they get |
| 18:03.30 | meep_____ | Modern ram sticks running with 4GHz+ clocks |
| 18:03.57 | tuxd3v | meep_____, indeed you gave me a Idea, from cleaning it ;) |
| 18:04.09 | tuxd3v | from -> for |
| 18:04.12 | meep_____ | Speaking of, are there any supercomputing arches designed with only ~30MHz interconnects? |
| 18:04.21 | meep_____ | Not tiny home micros |
| 18:04.28 | meep_____ | But something massively parallel |
| 18:05.11 | meep_____ | I've seen arches based on 4 m68k cpus but that wasn't scalable beyond 4 cpus |
| 18:05.15 | meep_____ | Luna88k |
| 18:05.19 | meep_____ | From OMRON |
| 18:06.29 | meep_____ | I ask because if the interconnects are sub 30MHz that's simple enough to be able to manufacture boards and components at home with blank PCBs, etching solvent, and a soldering gun |
| 18:06.34 | tuxd3v | meep_____, my problem is worst than that, since they are ddr2 800Mhz... a very rare beast nowadays, for sticks bigger than 1GB.. |
| 18:07.08 | meep_____ | Oh lucky you with 800MHz ddr2. My older laptop is 666MHz ddr2 |
| 18:07.56 | *** join/#devuan Garb0 (~Garb0@unaffiliated/garb0) |
| 18:07.58 | tuxd3v | but you have tons of ddr2 at 666Mhz( were the most produced ), ddr2 800Mhz is a very rare beast |
| 18:08.41 | tuxd3v | the prices are very high, for this memories.. |
| 18:09.10 | tuxd3v | and my Desktop Xeon, likes the 800Mhz version a lot :) |
| 18:11.52 | nemo | systemdlete: I did autoremove |
| 18:11.56 | nemo | systemdlete: lemme try purge |
| 18:12.26 | nemo | systemdlete: hm. maybe something else depends on all those libs. checking |
| 18:13.39 | nemo | systemdlete: oh. weird. libreoffice-core is still installed |
| 18:14.16 | systemdlete | did you install that one separately? maybe apt thinks you meant that to stay |
| 18:14.31 | nemo | systemdlete: naw. this was just a basic devuan guided install. all templated |
| 18:14.47 | nemo | systemdlete: I'm just tidying it up a little for a newly duped qemu image with some stuff I don't need |
| 18:14.50 | systemdlete | ok, just checking. I've run into a bit like that here and there |
| 18:15.04 | nemo | after removing core /usr/lib/libreoffice still has 77MiB of stuff. heh |
| 18:15.18 | systemdlete | maybe config files? |
| 18:15.28 | systemdlete | try finding out who owns those files, if anyone |
| 18:15.29 | nemo | running autoremove now |
| 18:15.36 | nemo | probably just need cleanup again |
| 18:15.47 | nemo | heh. nope |
| 18:15.52 | nemo | although autoremove had this fun line |
| 18:16.04 | nemo | "/usr/lib/libreoffice not empty so not removed" |
| 18:16.07 | tuxd3v | nemo... if you have a file open, and you remove it, the space is not freed from the Filesystem until you reboot |
| 18:16.09 | nemo | 76MiB of packages |
| 18:16.20 | nemo | tuxd3v: whaaaaat |
| 18:16.23 | nemo | tuxd3v: no! |
| 18:16.28 | tuxd3v | nemo, yup |
| 18:16.34 | nemo | tuxd3v: I mean. the space is still there. and you have a file handle |
| 18:16.35 | systemdlete | find /usr/lib/libreoffice |
| 18:16.38 | nemo | but it won't sho up in du -hs |
| 18:16.41 | nemo | *show up |
| 18:16.44 | nemo | which is what I'm running |
| 18:17.02 | tuxd3v | has the filesystem always cound the open file descriptors to that file, and if it is bigger than zero, space is not released |
| 18:17.03 | systemdlete | what's still there actually? |
| 18:17.14 | nemo | tuxd3v: sure. I'm just saying. it won't show up in du -hs once you type rm |
| 18:17.18 | nemo | even if I have it open |
| 18:17.21 | nemo | and that's trivially testable |
| 18:17.50 | tuxd3v | nemo, yes it will :) |
| 18:18.07 | tuxd3v | you need to truncate those files or... reboot |
| 18:18.43 | tuxd3v | the space of a file is released from the fylesystem once its nr of file descriptior open reaches zero |
| 18:18.58 | nemo | $ du -hs |
| 18:18.58 | nemo | 6.4G. |
| 18:19.03 | nemo | $ rm foo |
| 18:19.06 | nemo | $ du -hs |
| 18:19.06 | nemo | 19M. |
| 18:19.10 | nemo | this is with foo open in vim |
| 18:19.16 | nemo | the space is on disc |
| 18:19.18 | nemo | I can write to it |
| 18:19.22 | nemo | but it's no longer visible in the filesystem |
| 18:19.26 | tuxd3v | till that moment, the space it ocupied and its true you can't see the files, but the filesystem has the space ocupied :) |
| 18:19.28 | nemo | it's just available through vim's open file handle |
| 18:19.37 | nemo | tuxd3v: right... that was my point above about du -hs etc |
| 18:19.51 | nemo | tuxd3v: otherwise what you're saying is true, but also totally irrelevant to what's going on here ⺠|
| 18:20.03 | tuxd3v | but 'du' shows the space ocupied |
| 18:20.06 | nemo | ... |
| 18:20.09 | nemo | clearly not |
| 18:20.15 | tuxd3v | ho yes |
| 18:20.28 | nemo | just tested. after rm, the file vanished from du |
| 18:20.34 | nemo | because it's running standard file system operations |
| 18:20.38 | nemo | tuxd3v: I think you are confusing df and du |
| 18:20.39 | tuxd3v | doing a ls -l for example the files are not there, they don't show up |
| 18:21.01 | nemo | yes. ls and du work same way. df does not |
| 18:21.03 | tuxd3v | one simple trick.. |
| 18:21.25 | nemo | thus my simple test above that I pasted with du -hs (6.4 gigs) rm foo, du -hs, 19 megs |
| 18:21.25 | tuxd3v | if you do a du on a folder, and it shows its not empty |
| 18:21.34 | nemo | all while I had vim -b foo |
| 18:21.44 | tuxd3v | and you list the content of that folder and is nothing there... |
| 18:21.55 | tuxd3v | you have unproperly removed files |
| 18:22.11 | tuxd3v | you need to reboot, or simply truncate them.. |
| 18:22.13 | nemo | ok. so again |
| 18:22.34 | nemo | what does that have to do with du -hs of /usr/lib/libreoffice still showing 76MiB of files. which are real files, and unsurprisingly show up for find etc |
| 18:22.45 | nemo | tuxd3v: what you're saying is true, but also irrelevant to this cleanup I'm doing ⺠|
| 18:23.21 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 18:23.38 | nemo | ah. uno-libs3 package |
| 18:23.41 | nemo | removes that one too |
| 18:24.33 | nemo | finally. with that removed, no more /usr/lib/libreoffice |
| 18:28.56 | systemdlete | you could have used find's output to ask apt who owned them... but it sounds like you have it solved now. |
| 18:29.15 | nemo | systemdlete: yeah, although I looked up how to do it on debian and said dpkg -S |
| 18:29.26 | nemo | systemdlete: or apt-file which I didn't have installed |
| 18:31.13 | systemdlete | well. there you go! |
| 18:31.18 | systemdlete | til |
| 18:31.26 | meep_____ | How can I configure Beowulf as to not spin up the disks when resuming from suspend power state? |
| 18:31.31 | ranix | tuxd3v: MCEs should log in /var/log/syslog |
| 18:32.04 | ranix | there's mcelog(8) |
| 18:34.17 | meep_____ | Whenever my computer resumes it spins up the CD-ROM tray |
| 18:34.50 | meep_____ | It wastes a lot of power doing this and it's annoying having the computer vibrate when it opens |
| 18:35.02 | gnarface | meep_____: the cdrom hardware might do that automatically when it powers up |
| 18:35.23 | gnarface | meep_____: see if it's in /etc/fstab though |
| 18:35.51 | meep_____ | It's in fstab, but with user,noauto |
| 18:36.42 | gnarface | just comment it out |
| 18:36.45 | gnarface | see if that helps |
| 18:37.39 | gnarface | like i said though i think that's something the physical drive's internal firmware is doing |
| 18:37.54 | tuxd3v | <ranix> there's mcelog(8), yeah but I don't know the package that contains it :( |
| 18:38.26 | ranix | apt-cache search mcelog |
| 18:38.31 | ranix | collectd-core? |
| 18:38.35 | *** join/#devuan brocashelm (~brocashel@107.181.166.214) |
| 18:38.38 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 18:38.39 | ranix | that was from a debian system though |
| 18:41.06 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 18:50.22 | tuxd3v | https://paste.debian.net/1160060/ |
| 18:50.35 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 18:50.41 | tuxd3v | I believe this has to do with the Ram bank 0, :( |
| 18:51.36 | gnarface | seems like it's time to memetest it |
| 18:51.40 | gnarface | memtest* |
| 18:51.56 | gnarface | if it comes up with no errors, enable the optional bit-fade test |
| 18:52.02 | tuxd3v | gnarface, yeah, I am afraid of it since it takes a lot of time to end :/ |
| 18:52.13 | ranix | lol memetest |
| 18:52.17 | gnarface | tuxd3v: it will probably take a good day or two, yes |
| 18:53.01 | tuxd3v | gnarface, the bit-fade is something available from the menu? |
| 18:53.09 | tuxd3v | I mean easy to discover :) |
| 18:53.21 | gnarface | tuxd3v: yea there should be an optional tests menu somewhere in there with 2 or 3 tests that aren't in the default set |
| 18:53.32 | gnarface | tuxd3v: (because they take MUCH longer) |
| 18:53.53 | gnarface | tuxd3v: (but they're useful for tracking some of the harder to diagnose memory faults) |
| 18:54.19 | tuxd3v | gnarface, yeah I am afraid I will need to be without this pc for some time( doing memtest ) :/ |
| 18:54.35 | gnarface | yea there's no way around it |
| 18:54.54 | gnarface | well, assuming the fast tests didn't show any faults, that is |
| 18:55.18 | gnarface | if you haven't tried though, it might be worth it to just test each bank individually with the fast test |
| 18:55.21 | gnarface | fast tests |
| 18:55.23 | gnarface | * |
| 18:56.37 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 18:56.45 | tuxd3v | gnarface, ranix thanks, I will be forced to do a memtest(no other option..) |
| 18:58.16 | gnarface | tuxd3v: well, probably not, but this type of error could also be caused by temporary hardware failure due to overheating. if it only happens under load, make sure you at least checked all your case fans first |
| 18:58.43 | gnarface | tuxd3v: (though, that is the exact type of temporary failure that can cause a very similar looking permanent failure) |
| 19:03.08 | *** join/#devuan IoFran2 (~Thunderbi@189.237.224.20) |
| 19:08.32 | tuxd3v | gnarface, thanks for that option, indeed it can be.. |
| 19:09.33 | tuxd3v | But I am a bit sceptical, because I compile several kernels, in this machine, and it heats up the 4 cpus.. |
| 19:10.55 | gnarface | well a actual physical fault in the memory i would expect to also be excited by heat or a kernel build |
| 19:11.02 | gnarface | because i would expect a kernel build to fill all the ram |
| 19:11.08 | gnarface | i guess unless you have like, a really large amount of it |
| 19:12.09 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 19:12.22 | tuxd3v | yeah , I also think of that option, the kernel takes some because I am compiling with -jnr_cores in parallel |
| 19:14.13 | tuxd3v | maybe the kernel is a more randomized thing, and the codecs for video, are something less random, and more frequently hit certain areas..maybe, don't know.. |
| 19:14.20 | *** join/#devuan strywgr (~db@unaffiliated/strywgr) |
| 19:15.09 | meep_____ | Maybe your cpu is going something sneaky like SMT |
| 19:15.13 | meep_____ | Presenting you fake cores |
| 19:15.22 | gnarface | i guess i don't know. i get these type of errors from the cpu cache though sometimes when the machine is overheating: https://paste.debian.net/1160062/ |
| 19:15.48 | gnarface | (usually this is a sign i need to clean the dust out of my fans) |
| 19:16.07 | meep_____ | gnarface: do you have ECC memory? |
| 19:16.12 | gnarface | no |
| 19:16.15 | gnarface | er |
| 19:16.21 | gnarface | actually the cpu cache may be ecc |
| 19:16.25 | gnarface | but the system ram is not |
| 19:16.43 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 19:19.18 | *** join/#devuan IoFran2 (~Thunderbi@189.237.224.20) |
| 19:21.02 | ranix | installing the base system |
| 19:22.06 | ranix | tuxd3v: if you still have problems memtest86+ doesn't expose try SAT |
| 19:22.14 | tuxd3v | gnarface, yeah the caches have at least capabilities to detect parity errors |
| 19:22.36 | ranix | https://github.com/stressapptest/stressapptest |
| 19:25.01 | tuxd3v | I think wen I shutdown the system, I will cleanup the bank0 ram contacts, then experiment a bit with it, if it fails( which I believe is will), then no other option left :/ I will go to memtest fast-first, then using the gnarface proposed option to go deep inspecting.. |
| 19:26.06 | tuxd3v | But I don't rule out the heating problem... because I am running a Xeon CPU, with a normal coller :/ yeah,( at the time I haven't found a exact match) |
| 19:26.14 | gnarface | tuxd3v: if you're not very unlucky, then any permanent damage will be isolated to just one ram bank and you can simply remove that one and run on half ram temporarily |
| 19:26.57 | gnarface | tuxd3v: i've never had contact corrosion issues with ram banks but it's been a problem for the first 3 nintendos so i guess it's a theoretical problem |
| 19:27.08 | tuxd3v | gnarface, thanks a lot , its yet a deepr way to locate the problem for sure :) |
| 19:27.13 | gnarface | theoretical possibility* i mean |
| 19:27.22 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 19:32.11 | *** join/#devuan ShorTie (~Idiot@pool-173-50-17-150.slsbmd.east.verizon.net) |
| 19:32.11 | *** join/#devuan ShorTie (~Idiot@unaffiliated/shortie) |
| 19:34.43 | *** join/#devuan klaus (~klaus@lfbn-mar-1-506-69.w90-73.abo.wanadoo.fr) |
| 19:35.27 | malade_mental | openbsdtai123: (bio du jardin!) |
| 19:42.04 | meep_____ | How much dedotated wam do I need for serva? |
| 19:42.48 | meep_____ | gnarface: MCEs could also just mean your CPU or chipset is worn out |
| 19:43.10 | meep_____ | A decade of being plugged directly into the wall without any line conditioner |
| 19:44.02 | meep_____ | My workstation from 2006 kept popping up those errors with more frequency in it's last two years of service |
| 19:44.04 | gnarface | MetaYan: yea, a distinct possibility, but these ones do seem to coincide with high heat |
| 19:44.08 | gnarface | meep_____: ^this was for you |
| 19:44.09 | openbsdtai123 | malade_mental: du jardin. Ca pousse en ce moment? pas d'eau |
| 19:44.17 | gnarface | MetaYan: (ignore me, sorry, tab-completion error) |
| 19:45.01 | meep_____ | Until one day the text on the screen was just replaced with random gibberish, sometimes weird distortions on analog VGA-out |
| 19:45.18 | meep_____ | Even when using known-good ram and reseating the cpu |
| 19:45.21 | gnarface | meep_____: that's usually a symptom of *video* ram failure |
| 19:45.39 | gnarface | meep_____: (i see this happen almost like clockwork to unmodified nvidia laptops) |
| 19:45.43 | meep_____ | And then 2 days later the system would just never complete a post |
| 19:45.53 | tuxd3v | thinks that his CPU is properly working, and crossing fingers..because he loves his Xeon for kernel compilations.. |
| 19:46.32 | gnarface | tuxd3v: your error specifically referenced bank 0 though, which i assume refers to motherboard ram bank 0 |
| 19:46.41 | meep_____ | However I really can't complain. Over a decade of service to a single set of parts, not upgrades except for more ram and a second hard drive and good cleanings over the years |
| 19:47.18 | meep_____ | Oh, and added USB3 pcie expansion card |
| 19:47.54 | meep_____ | gnarface: what was for me? |
| 19:48.07 | gnarface | meep_____: "yea, a distinct possibility, but these ones do seem to coincide with high heat" |
| 19:48.21 | meep_____ | Oh i'm not the one with MCEs |
| 19:48.25 | meep_____ | I'm just helping |
| 19:48.30 | tuxd3v | gnarface, yeah, I also thinks that, also I found a kernel bug, with the kernel being tainted when he tried to access a page...its for sure a memory region in bank 0 Ram sticks |
| 19:49.32 | gnarface | tuxd3v: i think that there is a kernel feature you can use to pass dead system ram blocks to the memory mapper at boot time through the kernel command-line |
| 19:50.03 | gnarface | tuxd3v: if you have dead blocks of ram but it's not many and it's not the video ram, you can probably retain use of the rest of it |
| 19:50.56 | gnarface | tuxd3v: i don't know exactly how to compile that list though, i don't know of a ram equivalent of "badblocks" unless memtest86+ can be run from userspace |
| 19:51.04 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 19:53.24 | tuxd3v | gnarface, I believe that option exists yes, I will try to find it, if memtest detects the region, and now that you spoke about video memory, indeed the system reserves some megabytes for the graphics, maybe, maybe its that region, because when I experience the problem is when on youtube, its ramdon in time , some time after 1 hour sometime after 10 minutes |
| 19:53.39 | *** join/#devuan bpmedley (~bpm@2601:246:8201:8e0:8dfc:4226:b27d:5d00) |
| 19:55.13 | tuxd3v | what should be the package for memtest{ memtest86 | memtest86+ }? |
| 19:55.20 | tuxd3v | I believe memtest86+ :) |
| 19:56.04 | tuxd3v | I will run the fast version now :) |
| 19:56.10 | gnarface | tuxd3v: yea i'm not sure. i think "86+" is the newer one |
| 19:56.21 | tuxd3v | gnarface, thanks |
| 19:57.23 | tuxd3v | I hope it should take some hours at least to complete, I only have 4 GB( 2x2GB ), but still it will have to iterate for each adress to test :) |
| 19:58.03 | nemo | 32 gigs here ⺠|
| 19:58.19 | gnarface | tuxd3v: probably in the neighborhood of 5-10 hours for the base default test sets, maybe 1-2 days for the extended tests though |
| 19:58.49 | gnarface | woops, i was too slow |
| 19:59.33 | gnarface | i remember it would finish in a few hours for the first 8 tests, then there were 2 extended tests that took 3x as long as the entire rest of the set together |
| 19:59.59 | gnarface | but those were the tests that sometimes showed the more rare errors |
| 20:00.49 | gnarface | it was more useful back in the early Athlon days when ram tolerances could be as problematic as hardware failure |
| 20:01.58 | *** join/#devuan IoFran (~Thunderbi@189.237.224.20) |
| 20:07.36 | meep_____ | » [12:50:31] <gnarface> tuxd3v: i think that there is a kernel feature you can use to pass dead system ram blocks to the memory mapper at boot time through the kernel command-line |
| 20:07.36 | meep_____ | » |
| 20:07.36 | meep_____ | not really. There's an option to disable all ram past a location |
| 20:07.47 | meep_____ | But disable specific bits |
| 20:08.14 | gnarface | oh, i could have sworn there was a way to pass a bad block list, but the problem was there's not much room in the max byte length of the kernel command-line |
| 20:11.41 | gnarface | i just remember looking into it to try to get a nvidia card with partially burned-out ram limping along again for a few more years and found out it was only for system ram |
| 20:38.36 | *** join/#devuan onefang (~onefang@infinitegrid.org) |
| 20:38.36 | *** join/#devuan onefang (~onefang@devuan/developer/onefang) |
| 20:57.27 | meep_____ | No |
| 20:57.36 | meep_____ | Not badblocks for kernel memory |
| 20:57.43 | meep_____ | Badblack is for storage |
| 20:58.25 | meep_____ | You can only disable all memory past a specified address. Which won't help you if your bad ram appears in low memory |
| 20:58.37 | ranix | it's possible to make a badblocks map for memory |
| 20:58.38 | meep_____ | Or spread out all over |
| 20:58.57 | meep_____ | ranix: howso then? |
| 20:59.01 | meep_____ | Also, is that new? |
| 20:59.02 | ranix | it's not yet done afaik |
| 20:59.15 | ranix | well not that new but the project I'm aware of was terminated |
| 20:59.20 | ranix | it was working but unreleased |
| 21:00.08 | meep_____ | I guess all the people smart enough to program the kernel can afford to buy working ram sticks if theirs goes bad |
| 21:00.20 | ranix | a certain company that will remain unnamed thought it was more expensive to reboot all their machines to apply a kernel patch than it was to replace bad ram |
| 21:01.20 | meep_____ | ranix: I don't think that's a bad decision to make |
| 21:01.38 | ranix | I think it was a bad decision to make but it wasn't necessarily completely retarded |
| 21:02.13 | meep_____ | Firstly running high-uptime servers without ECC is... Well I just think that everybody should be running ECC and it's pretty stupid of the hardware industry to make such a simple and cheap reliability factor so much needlessly more expensive |
| 21:02.25 | ranix | ecc ram still fails |
| 21:02.31 | ranix | row and column and chip failures |
| 21:02.50 | ranix | those dimms don't really need to be replaced if you blacklist the affected memory regions in a kernel badblocks page |
| 21:02.52 | meep_____ | And secondly one some blocks in your ram starts going bad, more blocks usually start going bad exponentially |
| 21:02.53 | *** join/#devuan silentjet (~jet@staticline-31-182-193-145.toya.net.pl) |
| 21:03.04 | ranix | not really |
| 21:03.18 | ranix | it's pretty common to have a row failure that doesn't affect the rest of the chip |
| 21:03.26 | ranix | or a chip failure that's isolated to one chip on the dimm |
| 21:03.44 | ranix | it's not fatal if it's not the one dedicated to checksums |
| 21:03.58 | meep_____ | It's possible yes, but usually the chips on a stick are part of the same batch |
| 21:04.06 | meep_____ | Meaning they are going to fail at similar times |
| 21:04.25 | ranix | that's not what I believe observed |
| 21:04.31 | ranix | I* |
| 21:04.36 | ranix | but I don't have proof anymore |
| 21:04.41 | ranix | I did at one time |
| 21:04.42 | meep_____ | Maybe you had a different experience |
| 21:04.51 | meep_____ | I only buy memmory |
| 21:05.04 | meep_____ | I only buy memory from Samsung and Corsair |
| 21:05.26 | meep_____ | Because those are the only vendors I trust to not skimp out of DRAM manufacture process |
| 21:05.39 | ranix | idk if my dimms were even manufactured outside the company |
| 21:05.49 | ranix | we might have just sourced components |
| 21:05.55 | meep_____ | I used to buy ram from all over |
| 21:06.21 | meep_____ | I've got an old ddr2 stick from a company that had a part in the manufacture of commodore products |
| 21:06.32 | ranix | cool |
| 21:06.35 | ranix | I still have a commodore |
| 21:06.38 | ranix | and an atari st |
| 21:09.59 | meep_____ | Ha |
| 21:10.08 | meep_____ | Memory used to come from all over |
| 21:10.25 | meep_____ | I've got here a ram stick made by ProMOS technologies in Malaysia |
| 21:10.55 | meep_____ | And DDR1 ramstick here made by AMD with a big MADE IN USA on the back |
| 21:11.08 | meep_____ | Didn't know AMD used to make DRAM chips |
| 21:11.20 | meep_____ | "Rev0" |
| 21:11.33 | meep_____ | (C) 1993 |
| 21:13.17 | meep_____ | http://datasheet.octopart.com/AM29F016B-150EC-AMD-datasheet-11784513.pdf |
| 21:13.21 | meep_____ | The thing still works |
| 21:14.42 | meep_____ | Actually wait |
| 21:14.46 | meep_____ | I don't think this is ram |
| 21:15.08 | meep_____ | It's just on a board designed to fit into a ram socket |
| 21:16.03 | *** join/#devuan xrogaan (~xrogaan@unaffiliated/xrogaan) |
| 21:16.18 | ranix | amd did make ssds for awhile |
| 21:16.54 | meep_____ | Well this looks like an SSD from 1993 designed to reuse DRAM connector sockets |
| 21:19.32 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 21:24.06 | *** join/#devuan shibboleth (~shibbolet@gateway/tor-sasl/shibboleth) |
| 21:48.13 | *** join/#devuan filipdevuan_ (~filip@cpc145856-warw18-2-0-cust934.3-2.cable.virginm.net) |
| 21:58.30 | *** join/#devuan absinthe (~absinthe@unaffiliated/absinthe) |
| 22:12.40 | *** join/#devuan tradar (~tradar@gateway/tor-sasl/tradar) |
| 22:50.49 | *** join/#devuan hplar (~ralph@147.87.5.199) |
| 22:52.07 | *** join/#devuan hplar (~ralph@147.87.5.199) |
| 23:02.31 | *** join/#devuan Anasko (cb8119f7@Maemo/community/ex-council/Wikiwide) |
| 23:23.08 | *** join/#devuan hplar (~ralph@147.87.5.199) |
| 23:35.56 | *** join/#devuan fatalerrors (~fatalerro@91.224.149.180) |