| 00:01.16 | HumanG33k | but my warning may come from the debian rescue. |
| 00:04.07 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 00:04.56 | gnarface | HumanG33k: hmm. that bug report suggests something about bind mounting /run/udev/ in your chrooted system to make it work? |
| 00:06.05 | HumanG33k | for my warning yes. but i think it s not why the server not boot |
| 00:09.01 | *** join/#devuan kreyren (~kreyren@fsf/member/kreyren) |
| 00:09.13 | gnarface | HumanG33k: what version of devuan? |
| 00:09.44 | gnarface | HumanG33k: i haven't seen this problem here but it is unlikely to only be affecting you |
| 00:10.17 | HumanG33k | my sourcelist says beowulf |
| 00:11.57 | *** join/#devuan kreyren (~kreyren@fsf/member/kreyren) |
| 00:12.36 | *** join/#devuan arnoldoree (~arnoldore@113.210.201.104) |
| 00:15.55 | gnarface | HumanG33k: was it fully updated, do you recall? or was it an update that caused this? |
| 00:17.47 | HumanG33k | yes i update it when its needed but i not restart it at each time. |
| 00:18.36 | HumanG33k | i want to install wireguard and i have some error about not load module but it was list in load |
| 00:19.47 | HumanG33k | so i check list of kernel to be sure linux-image-amd64 is the only install and reboot |
| 00:20.16 | HumanG33k | it install linux-image-4.19.0-10-amd64 |
| 00:20.49 | gnarface | do you remember if the module used dkms? |
| 00:21.02 | gnarface | any error about dkms? |
| 00:21.30 | gnarface | i wonder if you also needed linux-headers-4.19.* |
| 00:21.42 | HumanG33k | there is a -dkms package yes, let me check is or not install |
| 00:21.46 | gnarface | (the one pointed to by linux-headers-amd64) |
| 00:22.09 | gnarface | that may not be related to the failure to boot |
| 00:22.22 | gnarface | but it might |
| 00:25.03 | HumanG33k | linux-headers-4.19.0-10-all-amd64 not install and that strange because i m pretty sure i apt install it |
| 00:25.29 | HumanG33k | lets loop it again |
| 00:25.46 | gnarface | well if you didn't have it installed before the dkms trigger, it would have caused the linux-image package to fail to complete installing |
| 00:25.50 | gnarface | i think |
| 00:26.02 | gnarface | at least it would have failed to build the module |
| 00:26.12 | gnarface | might have also failed to complete the apt command |
| 00:27.17 | gnarface | or maybe exited with a non-successful status, leaving the new kernel not marked installed and therefore not cataloged by grub... which would have left the system unbootable if you'd first removed all other kernels as you had said... |
| 00:27.21 | gnarface | (just a hypothesis) |
| 00:28.07 | HumanG33k | that for why i ask (hypothesis) |
| 00:29.12 | HumanG33k | sometimes i feel that server have strange behavior |
| 00:29.16 | *** join/#devuan fylgje (fylgje@gateway/vpn/protonvpn/fylgje) |
| 00:30.05 | *** join/#devuan kreyren (~kreyren@fsf/member/kreyren) |
| 00:40.57 | *** join/#devuan Jjp137 (~Jjp137@cpe-104-172-184-68.socal.res.rr.com) |
| 00:50.00 | HumanG33k | gnarface, boot again |
| 00:50.09 | HumanG33k | thx |
| 00:51.37 | HumanG33k | and the wg0 iface is gone |
| 01:01.14 | gnarface | HumanG33k: well i'm glad you got it booting again. was wg0 something you needed though? |
| 01:02.38 | HumanG33k | yes wg0 and so are wireguard network interfaces. It s the new openvpn. |
| 01:03.05 | gnarface | oh right, wireguard, for some reason i read wireshark |
| 01:03.22 | gnarface | i don't have any experience with it though |
| 01:03.34 | gnarface | is the debian kernel 4.19 even supposed to have support for it already? |
| 01:03.47 | gnarface | or that's what you were trying to add? |
| 01:04.05 | gnarface | you might want to try the beowulf-backports kernel instead |
| 01:08.23 | *** part/#devuan adhoc (adhoc@spot.ubermonkey.net) |
| 01:11.10 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 01:30.18 | *** join/#devuan mrtux (~nobody@2600:3c03:e000:266::cafe:babe) |
| 01:50.22 | *** join/#devuan Human_G33k (~HumanG33k@62.147.242.8) |
| 02:40.36 | *** join/#devuan bsd4me (~me@152-104-74-65.gci.net) |
| 02:47.59 | *** join/#devuan bsd4me (~me@152-104-74-65.gci.net) |
| 02:50.41 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 03:05.00 | *** join/#devuan nyov (~nyov@unaffiliated/nyov) |
| 03:13.53 | *** join/#devuan ac_laptop (~ac_laptop@186.2.247.129) |
| 03:56.28 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 04:09.43 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:23.28 | *** join/#devuan diogenes_ (~diogenes_@188.208.122.26) |
| 04:28.08 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 04:38.08 | *** join/#devuan wikan (~wikan@2a02:a31d:853e:3000:215:c5ff:fe42:f530) |
| 04:38.11 | wikan | hi ;) |
| 04:38.16 | wikan | I have tricky question |
| 04:38.19 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 04:38.26 | wikan | probably you can;'t help me ;) |
| 04:38.58 | wikan | I created alternative XTerm class for different colorscheme. But I can't turn 256 colors for it :| |
| 04:39.10 | wikan | anybody experienced with xterm? |
| 04:39.11 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 04:49.28 | golinux | wikan: You probably need to use 8 or 16 bit colors. |
| 04:49.59 | rwp | wikan, Set TERM=xterm-color or TERM=xterm+256color or whichever variation you like best. |
| 04:50.13 | wikan | i figured out |
| 04:50.53 | wikan | custom class's termName doesn't set XTERM variable to xterm-256color |
| 04:51.27 | wikan | I have XTermAlternate*termName: xterm-256color |
| 04:51.46 | wikan | and it doesn't work for all classes that are not just xterm ;) |
| 04:51.58 | wikan | did it via bash as you said: export XTERM ;) |
| 04:53.21 | rwp | I probably should have suggested TERM=xterm-256color as the normal 256 color TERM setting. |
| 04:53.31 | rwp | Also there is TERM=screen-256color too. |
| 05:04.44 | *** join/#devuan morruth (~quassel@77.244.124.177) |
| 05:06.41 | *** join/#devuan cocoadaemon (~foo@2a01:e0a:4e1:97e0:179d:1cc6:8854:4d5c) |
| 05:40.44 | *** join/#devuan Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 06:13.34 | *** join/#devuan morruth (~quassel@77.244.124.177) |
| 06:33.46 | *** join/#devuan Joril (~joril@host-217-194-188-145.sbs.redder.net) |
| 06:34.35 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 06:42.04 | *** join/#devuan cocoadaemon (~foo@88.123.134.95) |
| 06:56.11 | *** join/#devuan tierce (~raoulzeca@2a02:578:85c9:e12:47e7:da35:4706:d36c) |
| 07:21.58 | *** join/#devuan diogenes_ (~diogenes_@188.208.121.189) |
| 07:41.42 | *** join/#devuan KnoP (~KnoP@business-176-095-149-105.static.arcor-ip.net) |
| 07:53.55 | *** join/#devuan fidomuh (~quassel@2a01:4f8:130:6208::2) |
| 08:01.42 | *** join/#devuan GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) |
| 08:02.57 | *** join/#devuan psarria (~psarria@81.0.47.6) |
| 08:11.26 | *** join/#devuan sunshavi (~user@201.240.25.128) |
| 08:55.02 | *** join/#devuan dagelf (~quassel@169-1-140-175.ip.afrihost.co.za) |
| 09:06.47 | *** join/#devuan xinomilo (~xinomilo@gateway/tor-sasl/xinomilo) |
| 09:07.06 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 09:19.08 | *** join/#devuan brocashelm (~brocashel@172.83.43.111) |
| 09:19.11 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 09:51.49 | *** join/#devuan HalfWord (~halfword@58-220.dsl.iskon.hr) |
| 09:56.52 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 10:11.54 | *** join/#devuan Peregrinus_ (~peregrinu@178.239.173.252) |
| 10:18.52 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 10:33.31 | *** join/#devuan tierce (~raoulzeca@2a02:578:85c9:e12::1e6b) |
| 10:59.37 | *** join/#devuan kreyren_ (~kreyren@fsf/member/kreyren) |
| 11:05.03 | *** join/#devuan diogenes_ (~diogenes_@93.116.130.26) |
| 11:09.56 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 11:31.14 | *** join/#devuan cocoadaemon (~foo@36.161.2.109.rev.sfr.net) |
| 11:36.29 | *** join/#devuan rennj (~rennj@host-184-166-206-129.chy-wy.client.bresnan.net) |
| 11:38.29 | *** join/#devuan Bjornn (~Bjornn@2604:6000:1503:3ac:e867:1049:70c8:bb0d) |
| 12:09.42 | *** join/#devuan tierce (~raoulzeca@2a02:578:85c9:e12:47e7:da35:4706:d36c) |
| 12:10.55 | *** join/#devuan cocoadaemon (~foo@36.161.2.109.rev.sfr.net) |
| 12:12.26 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 12:37.39 | *** join/#devuan cd (~cd@unaffiliated/cd) |
| 12:38.38 | *** part/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 12:39.38 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 13:02.02 | *** join/#devuan tierce (~raoulzeca@77.109.105.62) |
| 13:10.54 | *** join/#devuan esse (~esse@obsd.esse.ovh) |
| 13:11.03 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 13:45.07 | esse | hi, i have some problem with apt on devuan |
| 13:45.30 | esse | all mirror gave me this error: Hashes of expected file |
| 13:47.33 | fsmithred | esse, are you using deb.devuan.org? |
| 13:49.54 | esse | yes, and i also try other mirrors |
| 13:50.02 | esse | same problem |
| 13:51.26 | fsmithred | hm, update is working ok here |
| 13:51.34 | esse | failed to fetch mirror and "Hash Sum mismatch" |
| 13:54.15 | fsmithred | tried pkgmaster.devuan.org ? |
| 13:54.31 | fsmithred | that's the one all the mirrors copy |
| 13:54.51 | fsmithred | are you running beowulf? |
| 13:57.29 | esse | <fsmithred> tried pkgmaster.devuan.org ? |
| 13:57.36 | esse | already tried |
| 13:57.57 | fsmithred | and internet works otherwise? |
| 13:58.49 | esse | no im using chimaera |
| 13:59.05 | esse | internet is working well, already tried also change dns |
| 13:59.16 | fsmithred | oh, can you post the one line in sources.list that you are using? |
| 13:59.26 | esse | already tried apt clean and rm -r /var/lib/apt/lists |
| 13:59.31 | fsmithred | ok |
| 14:00.06 | fsmithred | deb http://deb.devuan.org/merged chimaera main |
| 14:00.10 | fsmithred | is what it should be |
| 14:00.43 | esse | deb http://deb.devuan.org/merged chimaera main contrib non-free |
| 14:00.47 | *** join/#devuan xrogaan (~xrogaan@unaffiliated/xrogaan) |
| 14:00.51 | fsmithred | yup, that's good |
| 14:00.55 | esse | the first line |
| 14:01.20 | fsmithred | shouldn't be any other lines unless you want the deb-src line |
| 14:01.40 | *** join/#devuan ottavio (~m0ttv@unaffiliated/m0ttv) |
| 14:01.51 | fsmithred | I'm out of ideas |
| 14:02.41 | ottavio | Hi, if I compile packages from sources in a Devuan Ascii chroot, will they work on a Debian Stretch host? |
| 14:06.23 | fsmithred | ottavio, generally, yes |
| 14:06.51 | fsmithred | we only change a few packages. The rest are pure debian. |
| 14:07.34 | ottavio | fsmithred: thanks. I haven't used Devuan for a while. Is there a guide to making a minimal Ascii install in a chroot under Debian ? |
| 14:08.08 | ottavio | I suppose something like debootstrap but it must be really stripped down. |
| 14:08.09 | fsmithred | I don't know of one |
| 14:08.21 | fsmithred | I've only used devuan debootstrap |
| 14:08.33 | fsmithred | which is available on the devuan live isos |
| 14:08.42 | fsmithred | also on refracta live isos |
| 14:09.17 | ottavio | Can I just dump the devuan debootsrap onto my Stretch? |
| 14:09.17 | fsmithred | pretty sure others have used debian debootstrap |
| 14:09.22 | fsmithred | probably |
| 14:09.32 | ottavio | Alright thanks. |
| 14:09.36 | *** join/#devuan kizano (markizano@2600:3c00::f03c:92ff:fe86:b66e) |
| 14:10.23 | fsmithred | watch out for Recommends - devuan-keyring is listed |
| 14:11.15 | fsmithred | might not be a bad idea to get that while you're at it |
| 14:11.44 | fsmithred | https://pkgmaster.devuan.org/devuan/pool/main/d/devuan-keyring/ |
| 14:12.17 | fsmithred | get 2017 |
| 14:13.47 | ottavio | Do I need the keyring in the chroot or on the host, or both? |
| 14:16.27 | fsmithred | in the chroot only, I think |
| 14:16.34 | fsmithred | but that's a guess |
| 14:17.18 | fsmithred | oh, maybe in the host to run debootstrap |
| 14:17.57 | esse | yes fsmithred i already installed it, same error |
| 14:19.01 | fsmithred | esse, how long has this been a problem? |
| 14:19.22 | esse | at least 1 week ago |
| 14:19.33 | esse | before it i never had this problem |
| 14:19.41 | *** join/#devuan brocashelm (~brocashel@172.83.43.111) |
| 14:21.13 | fsmithred | search hits say to use https. If you do, you must select a specific mirror that supports it. |
| 14:21.23 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 14:22.06 | fsmithred | I think there were some dns changes made in the last week or two. |
| 14:22.51 | fsmithred | I don't know if that is affecting you in some way. |
| 14:23.18 | esse | i use http |
| 14:31.12 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 14:35.28 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 14:46.03 | *** join/#devuan tomtastic (~tomtastic@90.207.131.182) |
| 15:00.08 | *** join/#devuan IoFran (~Thunderbi@189.237.53.108) |
| 15:07.03 | *** join/#devuan gast0n (~g4570n@unaffiliated/g4570n) |
| 15:11.09 | *** join/#devuan diogenes_ (~diogenes_@188.208.120.39) |
| 15:47.11 | *** part/#devuan Joril (~joril@host-217-194-188-145.sbs.redder.net) |
| 15:49.06 | *** join/#devuan Soltis (~anon@c-73-3-82-11.hsd1.ut.comcast.net) |
| 15:50.32 | Soltis | Sans rose-coloured glasses: what's the current state/trajectory of this distro? I.e. I'm really interested in using it for production purposes; not so interested in being stuck in a tech dead-end if the project is resource starved i.e. stagnating. |
| 15:53.04 | *** join/#devuan bsd4me (~me@152-104-74-65.gci.net) |
| 15:59.28 | *** join/#devuan KnoP (~KnoP@176.109.163.210) |
| 16:00.58 | *** join/#devuan KnoP (~KnoP@business-176-095-149-105.static.arcor-ip.net) |
| 16:02.48 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 16:03.44 | *** join/#devuan sgage (~sgage@h69-131-19-95.cntcnh.broadband.dynamic.tds.net) |
| 16:07.50 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 16:09.05 | *** join/#devuan tierce (~raoulzeca@109.130.175.145) |
| 16:09.07 | *** part/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 16:22.53 | *** join/#devuan amesser (~amesser@p57bcf9b3.dip0.t-ipconnect.de) |
| 16:46.37 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 17:10.30 | *** join/#devuan Rick8024 (~KnoP@176.109.163.210) |
| 17:10.52 | *** join/#devuan brocashelm (~brocashel@172.83.43.111) |
| 17:12.39 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 17:14.06 | *** join/#devuan diogenes_ (~diogenes_@188.208.122.14) |
| 17:20.39 | sixwheeledbeast | i don't see how it will be stuck or you have issues for production, it's pretty much debian without systemd |
| 17:24.35 | *** join/#devuan Akuli (~akuli@mobile-access-bcee2d-21.dhcp.inet.fi) |
| 17:32.10 | mason | Soltis: I left my crystal ball at home, but I'd suggest "pretty good" based on things like how many upstream projects ship sysvinit scripts despite Debian's posture. |
| 17:55.20 | Soltis | Okay, I'll assume it's workable for now. Next question: how hard is it to get this working on modern AWS instances? The only community AMIs I see are the cloux ones and those aren't compatible with m6. |
| 18:02.37 | mason | Don't know - I don't use Amazon. |
| 18:02.51 | mason | Asking on the mailing lists is probably your best bet. |
| 18:18.26 | *** join/#devuan mcr (~mcr@obiwan.sandelman.ca) |
| 18:24.36 | *** join/#devuan markizano (markizano@2600:3c00::f03c:92ff:fe86:b66e) |
| 18:34.55 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 18:41.27 | *** join/#devuan GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) |
| 18:42.54 | *** join/#devuan cocoadaemon (~foo@88.123.134.95) |
| 18:46.22 | golinux | There used to be an image for AWS but I'm guessing it hasn't been maintained/upgraded. |
| 18:47.16 | *** join/#devuan brocashelm (~brocashel@172.83.43.111) |
| 18:47.17 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 18:49.43 | *** join/#devuan Human_G33k (~HumanG33k@62.147.242.8) |
| 19:01.03 | *** join/#devuan cocoadaemon (~foo@88.123.134.95) |
| 19:08.06 | rwp | Since Devuan supports conversion from stock Debian to stock Devuan it should always be possible to install Debian and then convert it to Devuan. |
| 19:09.25 | mason | rwp: There's always the possibility that a cloud service will inject some sort of systemd-dependant glue, but I don't know what AMI does differently, if anything. |
| 19:09.36 | rwp | My crystal ball predicts slow increase in Devuan activity over time as people become more comfortable with leaving Debian for it. |
| 19:09.55 | mason | Sounds right. |
| 19:10.05 | rwp | mason, I don't see how a cloud provider could do it. Nor why they would do it. They don't really want to be that involved in client images. |
| 19:10.22 | *** part/#devuan diogenes_ (~diogenes_@188.208.122.14) |
| 19:10.23 | rwp | They have a base level of caring that client images do not become compromised and part of a botnet. |
| 19:10.27 | mason | rwp: I'm thinking of Rackspace as one example, with Nova. |
| 19:10.35 | rwp | But beyond that I think they really don't like interacting with client images. |
| 19:11.25 | rwp | I have no experience with Rackspace cloud VMs. For me: Linode, Digital Ocean, Amazon, are the places I have spent most of my cloud provider time. |
| 19:12.10 | rwp | I should see how hard it is to create a cloud VM installation image. I haven't done that yet. |
| 19:12.52 | rwp | And lately on bare metal systems, for various reasons, I have been doing debootstrap installations. And actually liking that method very much. |
| 19:13.52 | fsmithred | Debian to Devuan migration instructions: https://devuan.org/os/install |
| 19:14.45 | mason | Mm, debootstrap is my preferred method as well, although a ZFS installer module might send me back to the installer. |
| 19:15.01 | mason | It's down a couple notches on my list since deboostrap works well enough. |
| 19:18.41 | rwp | For bare metal I pretty much only ever install RAID1 storage. |
| 19:18.44 | rwp | It's just too much hassle otherwise dealing with random disk failures and needing to recover from backup and the associated downtime. |
| 19:18.47 | rwp | So much less stress to just replace the one failed device and re-sync. |
| 19:18.50 | rwp | All usually live while the system is running. |
| 19:19.12 | rwp | And so I like to set that up first and then debootstrap on top of it and make the installation that way. |
| 19:19.57 | rwp | Can do all of that in the classic installers and have done it many times. But it just seems simpler doing it "manually". |
| 19:43.29 | *** join/#devuan danuan (1800093d@c-24-0-9-61.hsd1.nj.comcast.net) |
| 19:44.20 | danuan | attr -l /bin/ping returns Attribute "capability" has a 20 byte value for /bin/ping |
| 19:44.46 | danuan | any reason a single fine in a base install would have that set? it causes errors in rsync to nfs |
| 19:45.02 | danuan | fine - file |
| 19:47.28 | brocashelm | and that's the great thing about devuan. it's just debian without systemd (and its importance is increased when other debian-based distros include systemd in some form, including mx). anything beyond that is up in the sky |
| 19:54.53 | rwp | danuan, Interesting... Looking in the iputils-ping.postinst script it says "If we have setcap is installed, try setting cap_net_raw+ep, which allows us to install our binaries without the setuid bit." |
| 19:54.55 | mason | danuan: you mean lsattr, yes? |
| 19:55.24 | rwp | danuan, Looking at https://bugs.debian.org/731764 I see discussion in the area with arping. |
| 19:56.07 | rwp | Looking at /usr/share/doc/iputils-ping/changelog.Debian.gz there are various mentions of setting capabilities. |
| 19:56.32 | fsmithred | There's an explanation at the end of man ping. |
| 19:56.47 | rwp | In particular: * Enable the CAP_NET_RAW capability and strip the setuid bit on ping and ping6 binaries if possible. -- Noah Meyerhans <noahm@debian.org> Sun, 08 Dec 2013 17:47:52 -0800 |
| 19:59.08 | danuan | so if have root on nfs ping wont work right without xattr ? |
| 19:59.43 | rwp | wishes I had my NFS diskless test system running so I could test this... |
| 20:00.04 | mason | rwp: You can netboot vms. |
| 20:01.43 | rwp | mason, Recipe reference? I would love to know more about this! |
| 20:02.35 | mason | Recipe... I don't know. Last time I set up a Devuan netboot environment, I set up a Debian miniroot and replaced things with Devuan bits. I didn't write anything down, but Debian should have some docs. Looking. |
| 20:03.11 | mason | https://wiki.debian.org/PXEBootInstall |
| 20:03.41 | rwp | In Wheezy, Lenny, Stretch timeframe I used to have a working PXE-NFS boot system working. But it has fallen into bitrot and disrepair since then. |
| 20:03.51 | danuan | i am redoing my install now for this reason , as i did not keep good instructions last time , and guess i did cp -a and not rsync , so i never noticed this error till now |
| 20:03.51 | mason | In essence I was running an debootstrap install out of it, so it'd only be running for that. |
| 20:04.24 | danuan | https://www.linuxquestions.org/questions/blog/isaackuo-112178/how-to-simple-grub2-nfsroot-debian-8-jessie-37127/ |
| 20:04.47 | rwp | mason, Right on PXEBootInstall. That's the standard method. But my installation has fallen into disrepair. I should spend some time refreshing it. It was useful. |
| 20:05.50 | mason | Same. Last time I really heavily made use of netbooting was before PXE, using rarpd and such. (Sun era.) |
| 20:06.06 | danuan | and i am booting initrd off usb sticks to avoid the whole tftp dhcp thing , then i can just plug same usb stick to start the boot and take it out once initrd is loaded and move on to next comp |
| 20:06.47 | danuan | and works on any comp without pxe or any other issues , as long as it can boot usb |
| 20:06.47 | rwp | When the hardware supports USB boot it can really be a beautiful thing! Unfortunately some of my available victim testing hardware does not boot from USB. :-( |
| 20:07.32 | danuan | even setting usb as hard drive and not floppy or something in bios ? |
| 20:07.34 | rwp | For me it seems that PXE booting has been available in hardware longer than USB booting. At least with my random eclectic systems here. |
| 20:08.18 | rwp | Every BIOS is uniquely different. And also uniquely capable or incapable. Some feature USB booting. Some do not. |
| 20:08.33 | mason | Hear, hear. |
| 20:09.03 | rwp | And I always forget which ones support USB keyboards! There I am banging away on keys... And then I realize that one for the BIOS needs a PS/2 keyboard! D'Oh! |
| 20:09.34 | mason | Ah, attr is an XFS thing. Interesting. Never encountered it before. |
| 20:10.16 | mason | And yet, it's returning data from my ZFS root. |
| 20:10.29 | rwp | And also returns data for ext4 root too. |
| 20:17.33 | danuan | mason , how are you booting root on zfs ? |
| 20:18.54 | mason | danuan: I've done it a couple ways. For UEFI systems, I either use the Linux stub loader, or I use grub (ugh) and an ext4 /boot to hold the initramfs. Other options include elilo, which is flexible enough to make finding a kernel and initramfs inside your ESP easy. Either way, it boils down to not having the bootloader have to know anything about ZFS and pushing that off until the initramfs can just set |
| 20:19.00 | mason | everything up. |
| 20:19.22 | mason | Legacy systems, same - ext4 /boot to hold kernel and initramfs, and everything else is on ZFS. |
| 20:20.24 | mason | Caveat: The system does some things badly, and you can get a race for /var/log or /tmp, so on Debian-type systems I have those set to legacy mount and I just include them in /etc/fstab. Race won. |
| 20:22.57 | danuan | any luck having grub find other installations besides the one currently mounted for / |
| 20:25.03 | fsmithred | danuan, make sure os-prober is installed |
| 20:25.27 | fsmithred | and don't expect grub to find any other installations that are encrypted |
| 20:25.27 | danuan | yes but its non mounted zfs installs |
| 20:25.48 | fsmithred | oh, I'm not sure if it will find those |
| 20:25.54 | fsmithred | mason? ^^^ |
| 20:27.51 | mason | danuan: Hm, lately grub is pretty good about finding ZFS and setting the right root - e.g. root=ZFS=tank/foo/bar or what have you |
| 20:28.27 | danuan | yes for current system it has no problems , but for clones or other installs |
| 20:29.18 | danuan | other installs under rpool/ROOT which would not be mounted at the time and if they are they would not be mounted to current / as its occupied |
| 20:29.21 | mason | I've not yet used a boot environment manager, but folks are working on that stuff. I don't do anything at all fancy beyond snapshotting. |
| 20:30.46 | mason | danuan: example: https://ramsdenj.com/2020/03/18/zectl-zfs-boot-environment-manager-for-linux.html (haven't tried it, but it's there) |
| 20:45.41 | danuan | another question, any reason apt-cacher would clean itself without clean_cache = 1 being set , my mirror went from gig and a half to under 200 meg in last day or so |
| 20:49.47 | Soltis | not really devuan specific, but why tf does vim has _alsa_ as a dependency? |
| 20:50.54 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 20:55.20 | *** join/#devuan ac_laptop (~ac_laptop@186.2.247.129) |
| 20:55.46 | gnarface | Soltis: seems odd. my first guess would be that you got them both from a shared metapackage dependency somewhere (like desktop suite stuff) but maybe try with --no-install-recommends |
| 20:56.07 | Soltis | gnarface: it's pulled in via a dependency on libcanberra, it seems |
| 20:56.34 | Soltis | gnarface: looks like debian package maintainers crapped the bed. again. |
| 20:57.23 | gnarface | Soltis: well, still, verify it's a hard dependency or just a recommendation (recommends are on by default but that's a slightly less critical problem) |
| 20:57.46 | fsmithred | I'm not seeing it as a dep or even a recommends |
| 20:58.09 | fsmithred | aptitude why libcanberra |
| 20:58.37 | *** join/#devuan tierce (~raoulzeca@2a02:578:85c9:e12::1e6b) |
| 20:59.01 | Soltis | gnarface: looks like it's not a suggestion. this is ceres btw |
| 20:59.09 | Soltis | fsmithred: ^^^ |
| 20:59.43 | Soltis | gnarface: I could be mistaken, though. already fried enough today |
| 21:00.32 | brocashelm | i'm also on ceres and seeing that "vim Depends libcanberra0 (>= 0.2)" |
| 21:01.12 | gnarface | Soltis, brocashelm: you're both right. i'm seeing it too. |
| 21:01.25 | gnarface | vim->libcanberra0->libasound2 |
| 21:01.30 | danuan | same with openssh-server pulls in things like icon-themes and xwindow-common etc... 30 40 packages unleess âno-install-recommends |
| 21:01.33 | fsmithred | ssh nomad |
| 21:02.49 | Soltis | Jesus. |
| 21:03.12 | Soltis | When did these package maintainers all get replaced by epileptic monkeys? |
| 21:03.35 | fsmithred | slowly over the last 4-6 years |
| 21:04.47 | gnarface | seems annoying |
| 21:04.58 | brocashelm | it's fine. maybe next year gnu/linux will be the superior desktop to windows or mac :) |
| 21:05.43 | *** join/#devuan dagelf (~quassel@169-1-140-175.ip.afrihost.co.za) |
| 21:06.22 | danuan | yes , like i saw someone recently doing apt-get update on scientific linux , and it listed 2.5k packages to update not counting the ones it was not updating. and that was just a simple desktop |
| 21:10.55 | golinux | brocashelm: I hope not. Then Linux as we have known it will be lost |
| 21:11.32 | *** join/#devuan luser977 (~resuuser@188.27.70.107) |
| 21:17.19 | *** join/#devuan yae7nae4 (~yae7nae4@ezup.dev) |
| 21:19.28 | *** join/#devuan GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) |
| 21:19.42 | Soltis | golinux: I think, frankly, that has already happened. |
| 21:20.25 | *** join/#devuan yae7nae4 (~yae7nae4@2001:19f0:9002:1608:b134:e2cb:ed74:bbf0) |
| 21:20.46 | danuan | i did get my hands on lenovo ThinkCentre M92p with 16 gigs of ram and a 300 gig ssd that someone threw out, and it had LTSB version of windows 10 installed , i have never seen anything boot so fast |
| 21:21.15 | danuan | but i am not sure if i can keep using that LSTB version as it is probably tied to someones corp account |
| 21:23.16 | fsmithred | try a live usb to see if linux works on it |
| 21:24.13 | danuan | sure does , its a monster of a machine for that size , but it had that nasty second managment system in bios i had to turn off |
| 21:27.36 | danuan | ThinkCentre M92p 3238 |
| 21:32.20 | *** join/#devuan brocashelm (~brocashel@172.83.43.111) |
| 21:32.22 | *** join/#devuan brocashelm (~brocashel@unaffiliated/brocashelm) |
| 21:37.35 | brocashelm | i see linux 5.8 is already installable on ceres |
| 21:38.27 | golinux | Soltis: We won't go down without a fight. |
| 21:52.50 | *** join/#devuan gigawatt (~gigawatt@unaffiliated/gigawatt) |
| 21:59.16 | brocashelm | so is the ceres kernel 5.8.7 or 5.8.0 right now? |
| 22:00.31 | *** join/#devuan alexandros_tab (~quassel@unaffiliated/alexandros-c/x-1684531) |
| 22:00.34 | *** join/#devuan alexandros_c_ (~quassel@unaffiliated/alexandros-c/x-1684531) |
| 22:02.09 | fsmithred | linux-image-5.8.0-1-amd64 |
| 22:03.02 | brocashelm | ok, it was kinda confusing me as to which one it actually was |
| 22:07.06 | fsmithred | apt-cache search linux-image-5 |
| 22:12.34 | *** join/#devuan bilbo_b (~quassel@2a02:908:17a:dd80:20d:b9ff:fe35:b114) |
| 22:14.42 | gnarface | brocashelm: most likely you can exclude the *-dbg ones and the *-unsigned ones |
| 22:15.27 | *** join/#devuan sunshavi (~user@201.240.25.128) |
| 22:18.08 | gnarface | brocashelm: and the *-pae ones are only for 32-bit boards that can handle more than 4GB of ram, which is far more rare than the incidents of people installing this kernel |
| 22:19.03 | xrogaan | It's not so much being replaced, projects have a natural turnover. |
| 22:19.24 | xrogaan | The systemd thing accelerated people leaving IIUC |
| 22:19.28 | gnarface | brocashelm: (though if you really want to boot 32-bit linux on a amd64 board, the *-pae* ones may actually have a good use case. |
| 22:19.36 | gnarface | ) |
| 22:19.44 | *** join/#devuan kreyren_ (~kreyren@fsf/member/kreyren) |
| 22:30.48 | Soltis | Okay so ... that doesn't solve the immediate problem: vim without full throttle stupidity. |
| 22:32.28 | gnarface | Soltis: can the package be rebuilt without canberra? or maybe there's another package that doesn't have the graphical dependencies? for example there is emacs-nox |
| 22:33.03 | fsmithred | vim-tiny needs less |
| 22:33.10 | Soltis | vim-nox also depends on it |
| 22:33.25 | Soltis | ... holy god, have these guys been drinking mercury since birth? |
| 22:33.46 | Soltis | I saw someone offer the tissue paper thin argument that it was fine because alsa isn't x. |
| 22:33.55 | fsmithred | uh, vim-tiny does not need libcanberra is what I meant |
| 22:34.08 | fsmithred | lol |
| 22:34.24 | gnarface | Soltis: probably something worse and far more sinister; they're probably completely competent and consciously committing evil. i just noticed who the libcanberra maintainer is. |
| 22:35.03 | danuan | why would a commented out line after localhost in /etc/hostname actually help in setting the hostname from dhcp repply and not set it if there is no commented out line |
| 22:35.16 | gnarface | fsmithred: you're right, though the fact that vim-nox does is pretty counter intuitive |
| 22:35.37 | fsmithred | you're being polite |
| 22:35.47 | gnarface | and i just noticed emacs-nox depends on libasound2 directly :-/ |
| 22:36.12 | Soltis | gnarface: Well, yes, just between us chickens the odds this is accidental stupidity is effectively zero. |
| 22:36.12 | gnarface | at least in ceres, anyway |
| 22:36.12 | fsmithred | so your editor can make sounds. Oh goody. |
| 22:36.40 | brocashelm | lol |
| 22:38.33 | Soltis | So I do have vim-tiny installed, but it doesn't create a 'vim' command, just 'vi'. Let's see if it'll accept (and correctly handle) my .vimrc .... |
| 22:39.50 | *** join/#devuan DPA (~DPA@75-128-16-94.static.cable.fcom.ch) |
| 22:39.50 | *** join/#devuan DPA (~DPA@devuan/contributor/DPA) |
| 22:40.24 | gnarface | Soltis: there might still be some difference between vim and vi, but there might also be something about the binary just behaving differently depending on what it is named |
| 22:44.02 | *** join/#devuan gast0n (~g4570n@unaffiliated/g4570n) |
| 22:49.09 | Soltis | gnarface: Yeah, I'm used to that, but in this case it doesn't look like it works correctly. |
| 22:49.48 | *** join/#devuan Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 22:49.50 | djph | Soltis: so, install vim? |
| 22:50.28 | Soltis | djph: I'm not putting alsa on a damned server. That's slovenly administration. |
| 22:50.52 | djph | Soltis: O-o ALSA for _vim_ ? |
| 22:51.33 | Soltis | djph: Yes! Even vim-nox has it as a dep now |
| 22:51.38 | djph | o_O |
| 22:51.42 | djph | jeebus |
| 22:52.05 | djph | well, that's annoying and stupid |
| 22:52.12 | Soltis | djph: Welcome to the modern world of Linux. If you don't have a whiskey bottle at your desk, you're either an idiot or a better man than I. |
| 22:52.34 | djph | Soltis: I mean, I know at least enough to not run systemd ... |
| 22:52.42 | Soltis | djph: Hahaha |
| 22:53.21 | Soltis | You know, I used to have _fun_ administering Linux systems. |
| 23:00.14 | *** join/#devuan DPA (~DPA@75-128-16-94.static.cable.fcom.ch) |
| 23:00.15 | *** join/#devuan DPA (~DPA@devuan/contributor/DPA) |
| 23:04.24 | *** join/#devuan GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) |
| 23:05.07 | rrq | speech interface is quite useful for anyone with reduced eyesight |
| 23:17.11 | Soltis | rrq: That's true, but it's also irrelevant. While non-zero, the number of blind server administrators is quite low - much too low to justify contaminating a dep tree like that. |
| 23:18.07 | Soltis | rrq: Especially since the correct place to handle that would be in the desktop environment they're using |
| 23:18.38 | fsmithred | or make it optional |
| 23:24.56 | mason | Hrm, I'm not seeing vim-nox depending on ALSA. What's the chain? |
| 23:25.08 | mason | And which ALSA package? |
| 23:26.23 | fsmithred | libcanberra - libasound - alsa-utils |
| 23:26.53 | mason | But, that's not a dependency. |
| 23:27.22 | fsmithred | in ceres |
| 23:27.40 | mason | Ah, I don't run that anywhere. |
| 23:29.28 | mason | I guess I should spin up a test box. |
| 23:29.37 | mason | (No pun intended.) |
| 23:32.34 | rwp | OMG! Am I reading this right? vim depends upon ALSA? WAT?! |
| 23:37.53 | rwp | I think I never noticed this before because I am not a vim user. I install nvi everywhere. [ That's right, and keep way off my lawn! :-) ] |
| 23:38.46 | rwp | Also I am typing this in Emacs. For which I am complaining about the hard dbus dependency even in emacs-nox. |
| 23:38.53 | *** join/#devuan DPA (~DPA@75-128-16-94.static.cable.fcom.ch) |
| 23:38.54 | *** join/#devuan DPA (~DPA@devuan/contributor/DPA) |
| 23:41.22 | gnarface | rwp: though most stuff that depends on dbus will work fine without it if you uninstall dbus later |
| 23:41.45 | rwp | Emacs then emits a warning message. It works. But the warning message is annoying. |
| 23:42.26 | rwp | A friend of mine found a way to disable that warning message. But I have didn't fight long enough and have dbus installed now. |
| 23:45.05 | mason | upstream and stow can fix that for you :) |
| 23:46.06 | *** join/#devuan aaro (aaro@gateway/shell/xshellz/x-khkxxjchxtmoidsl) |
| 23:51.28 | rwp | mason, Yes. I can do the "Linux From Scratch" thing. Again. But I have been enjoying timely security upgrades appearing in the queue without my panic to get them created. |
| 23:51.57 | mason | That's fair. Welcome to dbus. :P |
| 23:51.58 | rwp | It's just so nice to be able to apt-get upgrade and avoid most security vulnerabilities. |
| 23:52.24 | rwp | By the time I read about some vulnerability most of the time when I look I find that I already have the mitigation patch installed. That's just so nice. |
| 23:52.37 | mason | sure |
| 23:52.39 | mason | agreed |
| 23:53.23 | rwp | When I tried to figure out why Emacs wanted dbus about the only thing I found was that someone could change a font globally and it would ripple into Emacs too. |
| 23:53.53 | rwp | That is not compelling for me. Running emacs-nox inside an XTerm. I mean... How does that work there? |