| unclouded | hi. 70-persistent-net.rules isn't renaming my interfaces. dmesg says "Error changing net interface name eth0 to amt: Device or resource busy", which suggests something is bringing up the interfaces before udev renames them? | 00:36 |
|---|---|---|
| unclouded | network/interfaces has "auto br0" but I tried reproducing the problem on a guest with a bridge and it works there. the only difference seems to be "IPv6: ADDRCONF(NETDEV_UP" happens before the rename in the problem system | 00:38 |
| unclouded | where should I look next? | 00:38 |
| unclouded | sorry, i forgot to say it's using sysvinit | 00:41 |
| rwp | Hi unclouded. Does your "cat /proc/cmdline" show any net options? What does that line say? | 00:53 |
| rwp | unclouded, I'll also note that I have seen some weirdness with things there too but don't perfectly understand it myself. But the cmdline info will help others to help. | 00:54 |
| rwp | Since you mention "auto br0" I assume you are using "ifupdown" to configure the network (I do too) and that you have a bridge configured (possibly for KVM guests). | 00:55 |
| rwp | In which case it would also be useful to know what your /etc/network/interfaces (possibly .d/whatever) says to configure both br0 and the interfaces bridged to it. | 00:56 |
| unclouded | hi rwp. /proc/cmdline was vanilla initially. it now has net.ifnames=1. yes, definitely using ifupdown. network/interfaces is fairly unusual apart from the bridge. can I post multi-line here? | 01:06 |
| buZz | feel free to use paste.debian.net for multiline :) | 01:09 |
| unclouded | thanks buZz. here is the network/interfaces: http://paste.debian.net/1202417/ | 01:11 |
| unclouded | interfaces.d/ is empty | 01:12 |
| unclouded | the system does use AoE but the aoe module seems to load after the "Error changing net interface name" messages | 01:14 |
| unclouded | it also uses mvsas, and takes a good 20 seconds to detect all disks, could that be an issue? the system I tried to reproduce the issue on finishes its disks in 1 second | 01:16 |
| rwp | unclouded, I have "iface eth0 inet manual" in mine. Suggest adding that for your three eth0, eth1, eth2 interfaces to ensure that other things like NM do not grab them. | 01:24 |
| rwp | Not sure that is "the" problem though. Perhaps just defensive programming. But seems like a good addition. | 01:25 |
| rwp | I have the same bridge_stp, bridge_fd, bridge_maxwait configuration as you. So that seems good from my viewpoint. | 01:25 |
| rwp | unclouded, I am uncertain of the correct combination of net.ifnames coupled with /etc/udev/ net persist rules. That's where I have had weirdness before myself. | 01:26 |
| unclouded | ok, I'll try that thank you. I'm also going to try disabling IPv6, wondering if its auto-configuration would raise the interfaces before udev tries to rename | 01:26 |
| rwp | For my own systems I have net.ifnames=0 along with the legacy net persist udev rules. | 01:27 |
| unclouded | I think the default might be net.ifnames=1 but I was just being explicit after reading a script somewhere | 01:27 |
| rwp | And unfortunately I must run afk for a while. Good luck! | 01:28 |
| unclouded | does that system rename interfaces ok with net.ifnames=0? | 01:28 |
| unclouded | thanks! | 01:28 |
| ShorTie | is no net.ifnames=0 | 01:36 |
| unclouded | hi ShorTie, does udev rename interfaces ok that way? | 01:38 |
| unclouded | what part of the boot process would bring up interfaces before udev? I've got ipv6.disable=1 now and tried net.ifnames=0 but still the same: "Error changing net interface name" "Device or resource busy" | 01:50 |
| unclouded | if I take an interface down with "ifconfig eth0 down" and then "udevadm test --action=add /sys/class/net/eth0" then it renames the interface, so I guess it's not a problem with the rules | 01:51 |
| rrq | unclouded: but your br0 setup seems to want the name eth0 ? | 02:13 |
| * rrq should maybe read more backlog | 02:14 | |
| unclouded | yes, that's so I can get back in. if br0 breaks then I hope it's because the interfaces have now been renamed | 02:14 |
| unclouded | and then I'll have to visit the machine in person | 02:15 |
| unclouded | there is another odd thing: "udevadm info --export --query=property /sys/class/net/eth0" seems to show "ID_NET_NAME_ONBOARD='eno1'" for *both* of the interfaces on the mainboard | 02:18 |
| unclouded | but hopefully that's not important since 70-persistent-net.rules only uses the MAC address to match (and renaming works if i take down an interface by hand) | 02:19 |
| unclouded | what would cause the interfaces to be up before udev tries to rename them? IPv6 (and thus autoconf) is disabled now, to no avail | 02:20 |
| rrq | do you run any network management tool eg wicd or network-manager? | 02:23 |
| unclouded | no, just /etc/network/interfaces with static IPs | 02:27 |
| rwp | Could you also pastebin your "ip addr show" information too? | 02:27 |
| rwp | Because it seems that you want ethX style names and are getting ethX style names, right? | 02:28 |
| rwp | So the only problem is error messages at startup? Is that the only issue? Otherwise things are resulting in an okay result? | 02:28 |
| unclouded | I wanted predictable names (eth0, eth1 and eth2 don't refer to the same devices on every boot) but to get them I've created names such as 'gbe' in the persistent rules | 02:30 |
| unclouded | here is the output of "ip addr show": http://paste.debian.net/1202437/ | 02:30 |
| unclouded | and here is /etc/udev/rules.d/70-persistent-net.rules: http://paste.debian.net/1202438/ | 02:31 |
| rwp | So the problem gets down to /etc/udev/rules.d/70-persistent-net.rules having configured renamed devices but not having the effect of renaming to those names? | 02:32 |
| unclouded | the :bc MAC is commented out so that br0 comes up even if the others are renamed properly | 02:32 |
| unclouded | during boot, udev is trying to rename interfaces according to 70-persistent-net.rules but emitting "Error changing net interface name" "Device or resource busy" | 02:33 |
| rwp | It confused me that your /etc/network/interfaces file used the ethX names instead of gbeX names as you wanted. | 02:34 |
| unclouded | yes, sorry. I've changed thing around a bit trying to debug. br0 refers to those just so I can get in via SSH even if renaming begins working | 02:36 |
| rwp | Most of my bare metal systems have a br0 bridge set up so that they can host KVM guests. So the bridge setup feels very normal to me. | 02:38 |
| rwp | I am not well versed on the details of how the device renaming works. Sorry. Hoping someone else will be able to help. But can try to be a sounding board for ideas. | 02:38 |
| rrq | have you verified that the uevent for the mainboard interfaces don't provide the same "address" | 02:39 |
| unclouded | me too, br0 is for KVM guests | 02:40 |
| unclouded | I didn't think it's a problem with the MAC addresses since if I manually take an interface down once is has booted and then invite udev to rename the interfaces then it works | 02:41 |
| unclouded | I think the issue is that the interfaces are in the UP state when udev tries to rename during boot, so renaming fails | 02:41 |
| rwp | Do you have the "eudev" package installed? Or "udev"? I expect to see "eudev" there. | 02:42 |
| unclouded | yes, it's eudev | 02:42 |
| unclouded | here is the part of dmesg that shows the rename fault during boot: http://paste.debian.net/1202439/ | 02:43 |
| rwp | That error resulted when using net.ifnames=1 ? Just trying to sort out the details. | 02:45 |
| unclouded | with both net.ifnames=0 and net.ifnames=1 | 02:45 |
| unclouded | net.ifnames=1 for that particular paste | 02:46 |
| rwp | With both? Hmm... I would expect that with net.ifnames=1 it would try to rename to the enp9s25 types of names ignoring /etc/udev/...net-persist rules. But I do not know this very well. | 02:47 |
| rwp | I'm re-reading https://wiki.debian.org/NetworkInterfaceNames again now... | 02:48 |
| unclouded | I'm a bit lost, but from what I read, net.ifnames=0 causes systemd to leave kernel names alone and net.ifnames=1 lets it rename them | 02:48 |
| unclouded | not that I have systemd on this system of course! :) | 02:49 |
| rwp | Well... We are here in #devuan so we don't need to worry about systemd itself here. Just the eudev fork from it. | 02:49 |
| rrq | it looks like renaming has worked during pre-pivot but left /sys/class/net/eth0 (etc) in the tree and then that causes a post-pivot complaint...? | 02:50 |
| unclouded | interestingly, boting with ifnames=0 causes one less error message in dmesg: http://paste.debian.net/1202440/ | 02:51 |
| unclouded | though the interface is still not renamed (they're still eth0, eth1 and eth2 once I ssh in) | 02:51 |
| rwp | Do you have console access to this system? Or is it remote? And if remote is it bare metal or a VM? | 02:52 |
| rwp | Just read that net.ifnames=0 does not override 70-persistent-net.rules rules. | 02:53 |
| unclouded | console access is in another room, so I'm using ssh from a bigger monitor. it's bare metal | 02:53 |
| rwp | But you can get to it if needed. Oh good. Whew! I hate needing to drive to the data center an hour away! | 02:54 |
| unclouded | yes, I read similar. to postpone the problems when users who have upgraded have to switch from their custom interface names, rewrite firewall rules, etc. | 02:55 |
| unclouded | :O thankfully I can get to it! it's just cold in that room and the keyboard is horrible | 02:55 |
| rwp | I understand. At one client site where it is really frosty in front I always move the console cart to the rear where the heat from the servers makes it bearable. :-) | 02:56 |
| unclouded | rrq: how would I check for that? /sys/class/net/ shows "br0 eth0 eth1 eth2 lo" post-pivot | 02:57 |
| rwp | I am re-reading /usr/share/doc/eudev/NEWS.Debian.gz where it says 70-persistent-net.rules is deprecated "by Debian 10". Doesn't "by" mean "before"? Feels ambiguous. | 02:58 |
| unclouded | is the intent that 70-persistent-net.rules is deprecated in Devuan too? I just assumed not because there is no systemd to rename interfaes without it | 03:02 |
| rwp | I don't know Devuan's plans. But it seems to me that the networking issues are mostly separate from the systemd issues. | 03:03 |
| rwp | And things are entangled because udev is forked into eudev out of the systemd source code base. Therefore there may be some coupling regardless of intentions. | 03:04 |
| mason | unclouded: It's not just systemd that renames interfaces. Anything with udev/eudev. | 03:05 |
| rwp | I read that updates to 70-persistent-net.rules require updating the initramfs. I did not realize that was pushed into the initrd. | 03:05 |
| mason | unclouded: For instance, Void also renames interfaces, and they use eudev but no systemd. | 03:05 |
| rrq | unclouded: right. I had wrong idea. | 03:05 |
| rwp | Void uses runit as an init. Just to note. | 03:06 |
| rwp | My previous weirdness may have been due to not knowing that I needed to rebuild the initramfs after modifying 70-persistent-net.rules before. That could explain much. | 03:07 |
| unclouded | I've been "update-initramfs -u" before every reboot just to be sure | 03:09 |
| mason | rwp: For kicks, lsinitramfs sometime, and you can see the great range of things that make it into initramfs. | 03:09 |
| unclouded | mason: thanks, I didn't know that command. very cool | 03:10 |
| mason | Just learned recently that some (newer?) versions of lsinitramfs will also unpack them for you, which is nice since the newer ones have that awful set of microcode cpio's glommed onto the front. | 03:10 |
| mason | unclouded: There's a lot of fun stuff out there. | 03:10 |
| unclouded | kind of do want catinitramfs to see what the contents of files put in there are | 03:11 |
| mason | unclouded: You can unpack them without lsinitramfs. https://access.redhat.com/solutions/24029 has some examples. | 03:12 |
| unclouded | for sure, and I guess I should hack a script if I want to see the same file over and over again to check it | 03:13 |
| mason | unclouded: Ah, kk, we seem to ship unmkinitramfs | 03:14 |
| unclouded | I tried udev_log="debug" in udev.conf but it produced so much output that it chopped off the part where udev tries to rename interfaces | 03:15 |
| mason | unclouded: Can you restate your issue? Something with bridges? | 03:15 |
| rwp | mason, I did not know about that command either. Very cool. Trying it raises more questions for me though. | 03:16 |
| rwp | For example I have /etc/udev/rules.d/70-persistent-net.rules file. But "lsinitramfs /boot/initrd.img-4.19.0-16-amd64 | grep persistent" reveals usr/lib/udev/rules.d/60-persistent-storage.rules but no 70-persistent-net.rules file. | 03:17 |
| unclouded | sure, I was having eth0, eth1 and eth2 come up in a different order on each boot, so I made a /etc/udev/rules.d/70-persistent-net.rules to rename the interfaces, and this works with "udevadm test --action=add /sys/class/net/eth0"as long as the interface is down | 03:17 |
| rwp | The NetworkInterfaceNames wiki suggests using "echo /sys/class/net/*" in order "To find out what names udev would be choosing between if you switched over to the new system" | 03:18 |
| rwp | But on every machine I try I just see the old names. | 03:18 |
| unclouded | ..but dmesg shows "Error changing net interface name" almost as if the interface were UP by the time udev tried to rename the interfaces | 03:18 |
| unclouded | (during boot) | 03:19 |
| rwp | All of my easily available systems are all legacy with a configuration trail of past versions. Or is a VM. | 03:19 |
| mason | Frankly, if you have multiple interfaces and re-ordering issues, just use the new NIC names. I don't like them, but you can just use aliases in your interfaces file so you're only ever using human-readable names. | 03:19 |
| rwp | I think I need to grab a scratch victim system, do an install, and see what happens there. | 03:19 |
| mason | Most of my boxes have at most two NICs and they don't re-order, so I'm safe. | 03:20 |
| rwp | Most of *my* systems have only one NIC. But client servers often have 2x or 4x NICs. | 03:21 |
| rwp | Eventually they will catch up to the new versions of things and I will need to know how to work with them. | 03:21 |
| unclouded | that's the thing: this is just a plain beowulf installation as of a month ago but with KVM and AoE stuff added. I'd use the new interface names like eno1 or enp6s0 if I could | 03:21 |
| mason | rwp: The funny thing is that "predictable naming" changes version to version. | 03:22 |
| rwp | My systems with multiple NICs are all upgrades from legacy and that seems to be using 70-persistent-net.rules file. | 03:22 |
| mason | The notion is that the software learns new ways to disambiguate the interfaces, and so it uses the most specific naming it can. The humour of calling this "predictable" is lost on the authors. | 03:22 |
| rwp | mason, Right! The repeatable names are always changing! | 03:22 |
| mason | Frankly, MAC-based naming is the only thing that makes sense. | 03:23 |
| rwp | I'm mostly okay with new names as long as they stop changing. | 03:23 |
| mason | They won't. | 03:24 |
| unclouded | I read that MACs can change but I don't think I've had it happen to me. Even VM interfaces and wlan interfaces in laptops always seem to have the same MAC | 03:24 |
| unclouded | (a predictable MAC I mean) | 03:24 |
| mason | You can change MACs if you need to, but they tend not to do it on their own. | 03:25 |
| unclouded | the only time I had to choose a MAC was with the Arduino and even that I kept in EEPROM once generated | 03:25 |
| mason | For instance, if you have a gateway device that knows a specific MAC, you can avoid pain by just cloning that MAC if you ever need to swap firewalls, for example. I've had to do that. | 03:25 |
| rwp | MACs won't change unless "macchanger" is installed to randomize them for mobile use. Or you intentionally change them otherwise. | 03:26 |
| mason | Right. For instance, the "hwaddress" directive for /etc/network/interfaces | 03:26 |
| rwp | Or the VM configuration of a virtual machine. We can definitely change the hardware ethernet address intentionally. But it won't otherwise change. | 03:27 |
| rwp | But I think none of us like the enp9s25 types of names! WAT?! | 03:27 |
| unclouded | I did not know about "hwaddress" thanks | 03:27 |
| mason | Stick around. Who can tell what random trivia I'll spout when prodded? | 03:28 |
| rwp | But whatever... If it is my own desktop I would remove the 70-persistent-net.rules and default to net.ifnames=1 and just see what new name appeared and use it. | 03:28 |
| * unclouded prods mason | 03:28 | |
| * mason sputters out, "You can use the same keyboard config in X and on the console with XKBOPTIONS in /etc/default/keyboard." | 03:29 | |
| mason | Hey, stop that. | 03:29 |
| unclouded | OMG, but it so awesome | 03:29 |
| unclouded | are the rules in /lib/udev/rules.d applied in order like they seem to be named? | 03:30 |
| mason | Sadly, I wouldn't hazard a guess about udev behaviour. rwp might know. | 03:30 |
| unclouded | because lots of network things like aoe.rules seem to come before the network interface renaming | 03:30 |
| rwp | Sadly I do not know. But I presume so as well. | 03:31 |
| rwp | For me I need to break for dinner. Then I think I will try installing a fresh bare metal system in order to see how it is different from the other legacy systems I look at. TTYL! Good Luck! | 03:33 |
| unclouded | thanks rwp | 03:33 |
| unclouded | ok, /proc/cmdline now has "net.ifnames=1" and /etc/udev/rules.d/ is empty and udev is all like "could not rename interface '2' from 'eth0' to 'eno1': Device or resource busy" | 03:40 |
| unclouded | so it is generating the predicatable names but still can't rename the interfaces | 03:41 |
| unclouded | I wonder if the bridge is being brought up (and enabling the interfaces, prohibiting rename afterwards) before interfaces are renamed | 03:44 |
| mason | I think the bridge comes up later than that, but I don't rename here, so I could be wrong. | 03:46 |
| rrq | unclouded: is there maybe a backup file in /lib/udev/rules.d (after editing) ? | 04:02 |
| rrq | apparently eudev also uses /run/udev/ with stuff in | 04:09 |
| rrq | hmm "udevd" aso mentions /usr/lib/udev/rules.d/ but not /lib/udev/rules.d/ ?? | 04:12 |
| unclouded | that's a clever thought (backup file) but no | 04:42 |
| zgu|skaro | does the installer support lvm at all? it only seems to list regular partitions | 04:42 |
| unclouded | '/usr/lib/udev/rules.d': No such file or directory | 04:44 |
| unclouded | I commented out all lines in /etc/network/interfaces and even added a new 79-net-name-slot.rules that explicitly takes the interfaces down prior to rename | 04:45 |
| unclouded | no dice. bed time here. thanks for all the suggestions | 04:45 |
| zgu|skaro | or is there some kind of manual install mode to do things the wizard isn't designed for? | 04:46 |
| sadsnork | zgu|skaro, as near as I can tell the partitioning options in the Devuan installer are the same as the options in the Debian installer. I don't use LVM but I typically choose "manual" partitioning and am able to add encrypted partitions (which I am guessing is the purpose you were hoping for with LVM). | 04:50 |
| gnarface | i would try it again in expert mode | 04:51 |
| gnarface | should be the same afaik as debian's was last i tried it anyway... | 04:51 |
| zgu|skaro | how do i get to expert mode? i'm on the xfce livecd and can only seem to find the refracta gui | 04:52 |
| gnarface | oh | 04:53 |
| gnarface | zgu|skaro: that's the problem. the live installer is entirely different and based on refracta | 04:54 |
| zgu|skaro | didn't look like the minimal image supported efi which is why i used the livecd | 04:54 |
| gnarface | i thought one of them does though | 04:55 |
| gnarface | did you look in the "load additional installer components" section? | 04:55 |
| gnarface | by minimal you mean netinstall | 04:55 |
| zgu|skaro | probably | 04:56 |
| zgu|skaro | then there was the 4 CD set or whatever it is... debian always had sort of weird installer options | 04:56 |
| gnarface | https://files.devuan.org/devuan_beowulf/installer-iso/ | 04:57 |
| zgu|skaro | would server.iso have the other installer? | 04:58 |
| gnarface | all these have the "other" installer. the minimal one is something completely different again | 04:58 |
| gnarface | you can pick desktop, server or the 4-cd set | 04:58 |
| gnarface | or the netinstall | 04:58 |
| zgu|skaro | i figured desktop live would have the text mode installer (that i see screenshots of with "guided - use LVM") | 04:59 |
| zgu|skaro | didn't realize it was completely different | 04:59 |
| gnarface | yea the live one is new, fsmithred might know how to make it do what you want | 05:00 |
| gnarface | and i dunno if you'll have to disable secure boot or not, i don't have a lot of EFI hardware around here | 05:00 |
| zgu|skaro | this is a box that's had existing linux efi installs before so the board is all set up. and in fact booting the desktop live iso in efi mode now | 05:02 |
| zgu|skaro | server.iso doesn't seem to have the efi/boot/bootx64.efi file i was expecting... | 05:03 |
| gnarface | there was also some bug | 05:03 |
| gnarface | i think, not sure if it's relevant to you, but it was about a directory renaming | 05:03 |
| gnarface | something to do with the debian/devuan dichotomy | 05:03 |
| gnarface | in the efi path | 05:03 |
| zgu|skaro | or if there's a way to tell the initramfs to look for the squashfs image on an arbitrary fs that's not necessarily iso9660 (i have other r/w boot media handy with a working grub). i don't remember if debian's implementation has an easy way to do that or not | 05:05 |
| zgu|skaro | wish i knew this was a non-starter so far before i blew away that old root fs | 05:06 |
| gnarface | don't panic | 05:06 |
| gnarface | there's a way to do this you're not the first person | 05:07 |
| gnarface | i'm just the wrong person to help | 05:07 |
| zgu|skaro | at least i don't have anything to do early tomorrow morning :) | 05:07 |
| gnarface | because i can't test the efi problem here | 05:07 |
| zgu|skaro | well let me see of one of these other images boots at all | 05:07 |
| gnarface | well can you boot the server one? that's the one you just downloaded, i assume? | 05:07 |
| gnarface | i always use the netinstall | 05:08 |
| zgu|skaro | OH ok i think it's that weird thing with an extra EFI partition after the iso fs... so that doesn't show up if you just open the iso in something like file roller/engrampa | 05:10 |
| zgu|skaro | a desktop live image that let you use the regular installer too sure would be nice though | 05:13 |
| gnarface | well in theory you could run it in qemu from the existing live installer and just point it at your harddrive | 05:30 |
| gnarface | it's a lot of extra steps though just to use a live installer | 05:30 |
| gnarface | i'd just debootstrap at that point | 05:31 |
| gnarface | but the LVM thing does add extra complications | 05:31 |
| gnarface | hmmm | 05:32 |
| gnarface | wait | 05:32 |
| gnarface | there might actually be a way to just run it | 05:32 |
| gnarface | i think it's in a package | 05:32 |
| gnarface | uh yea | 05:32 |
| gnarface | there's a debian-installer package | 05:32 |
| gnarface | you might not even need qemu | 05:32 |
| gnarface | maybe that's just the image | 05:32 |
| zgu|skaro | well i'm in the server installer now, up to the select init system step | 05:33 |
| gnarface | but i also see a package called "debian-installer-launcher" that's called a "desktop launcher" | 05:33 |
| zgu|skaro | hmm | 05:34 |
| zgu|skaro | openrc on something that's not either gentoo or that weird embedded board i ported it to years ago! so weird | 05:36 |
| zgu|skaro | is there a quick way to add sudo access for a non root user? | 05:38 |
| zgu|skaro | i don't see any wheel group rules or anything | 05:38 |
| gnarface | visudo | 05:38 |
| gnarface | it's called sudoers or sudo i think | 05:38 |
| gnarface | the group should already exist when you install sudo, you just have to uncomment a line in the config | 05:39 |
| gnarface | also not different from debian last i used debian | 05:39 |
| zgu|skaro | oh it's group sudo. derp | 05:39 |
| gnarface | wheel is bsd | 05:39 |
| gnarface | that's what they call it on openbsd | 05:40 |
| golinux | zgu|skaro: According to the install guide you can do lvm with the live iso https://www.devuan.org/os/documentation/install-guides/beowulf/live-gui | 05:40 |
| golinux | Always good to look for documentation and there is a lot on our website. | 05:40 |
| golinux | Look for section 3.2 | 05:41 |
| zgu|skaro | well i had found https://www.devuan.org/os/documentation/install-guides/beowulf/install-devuan | 05:41 |
| zgu|skaro | and then wondered why i couldn't find that on the live iso | 05:41 |
| golinux | That is for the debian installer | 05:41 |
| golinux | But the option IS on the live iso. | 05:42 |
| zgu|skaro | yeah i saw the encryption option... does that let you do arbitrary lvm stuff? | 05:42 |
| golinux | I have never done encryption | 05:42 |
| zgu|skaro | ah well... next adventure is porting over my old syslog and radius server config, openvswitch, eventually asterisk in an lxc container hopefully | 05:45 |
| golinux | Way above my paygrade . . . hope it goes smoothly. | 05:46 |
| zgu|skaro | mostly all stuff i've done on other platforms/distros before | 05:47 |
| * zgu|skaro removes the cdrom line from sources.list | 05:57 | |
| tuxd3v | zgu|skaro, nice move! | 05:57 |
| zgu|skaro | hrm... how to set a slave interface (actually used by an openvswitch port) in /etc/network/interfaces so it brings the link up but doesn't have any ip configuration (because it's part of a bridge) | 06:31 |
| rrq | "iface eth0 inet manual" .. see "man interfaces" | 07:06 |
| zgu|skaro | yeah, found that... now trying to get openvswitch-switch to start before networking which i think is the issue | 07:19 |
| zgu|skaro | also totally confused by these supposed openrc service scripts that don't look anything like real openrc scripts and the lack of a /etc/conf.d directory | 07:20 |
| zgu|skaro | openvswitch-switch in sysinit and networking in default seems to make it start up in the right order | 07:21 |
| gnarface | the debian openrc we inherit is sorta a hybrid | 07:24 |
| gnarface | it's not like the gentoo one but people have swapped it out for that one | 07:25 |
| zgu|skaro | and why is syslog-ng not starting by on boot even though it's in default runlevel | 07:25 |
| zgu|skaro | yeah this makes no sense | 07:29 |
| zgu|skaro | i start it manually, the process runs, but it doesn't show up in rc-status | 07:29 |
| zgu|skaro | start it again, it doesn't give the 'already running; message | 07:29 |
| gnarface | the rc-status thing rings a bell, but i forget the fix | 07:30 |
| gnarface | might have been specific to another daemon | 07:30 |
| gnarface | call it as root maybe? | 07:30 |
| gnarface | or as the right user anyway | 07:30 |
| gnarface | not sure | 07:30 |
| gnarface | maybe path thing | 07:30 |
| gnarface | root's default path changed | 07:30 |
| gnarface | they took /usr/sbin and /sbin out | 07:30 |
| gnarface | annoyingly | 07:30 |
| zgu|skaro | yeah i noticed that | 07:31 |
| zgu|skaro | where is the openrc i know and love :/ | 07:31 |
| zgu|skaro | what have they done to you | 07:32 |
| zgu|skaro | i guess this is mostly still based on the legacy sysvinit and rc.d stuff | 07:32 |
| gnarface | it's just the way debian has done it to preserve sysvinit compatibility yea | 07:41 |
| gnarface | someone has packages for the gentoo one built somewhere | 07:42 |
| gnarface | the rc-status thing might really be a simple fix though | 07:43 |
| zgu|skaro | gotta be something wrong with the init.d/syslog-ng script | 07:46 |
| zgu|skaro | none of these init scripts seem to actually control their daemons at all | 08:19 |
| zgu|skaro | or at least stop/restart does nothing | 08:21 |
| zgu|skaro | oh, chrony can actually stop and start itself properly | 08:24 |
| zgu|skaro | rc-status still always shows it as started though | 08:24 |
| zgu|skaro | so i guess there's some bug there | 08:25 |
| gnarface | it probably needs some love | 08:37 |
| gnarface | this is a slow channel, but someone who uses openrc will eventually show up and might be able to give you better advice | 08:37 |
| gnarface | there may be some common path fixes | 08:38 |
| gnarface | that sysvinit does the starting and stopping and openrc does status monitoring and whatever else is by design with the setup | 08:39 |
| gnarface | that status isn't working is a bug | 08:39 |
| onefang | 300 messages while I slept, and some one was complaining it's too quiet in here. lol | 12:45 |
| brocashelm | anyone remember this video? one of the earliest promotions for devuan (while going into details of the flaws of systemd): https://www.youtube.com/watch?v=RkFNMEk0xn8 | 15:54 |
| debdog | Sign in to confirm your age | 15:55 |
| debdog | This video may be inappropriate for some users. | 15:55 |
| debdog | WAT | 15:55 |
| brocashelm | it's really not nsfw | 15:55 |
| brocashelm | just some edgy stuff | 15:56 |
| onefang | Maybe someone said "systemd is shit"? | 15:56 |
| brocashelm | heh | 15:56 |
| sadsnork | This one did not nag me about logging in. https://yewtu.be/watch?v=RkFNMEk0xn8 | 16:04 |
| newbie | Fellow Devuan'ers, if most everybody has migrated from FreeNode, I have a question: | 16:11 |
| newbie | Does someone readily know a Devuan-friendly alternative to Anbox? I want to run some Android apps without having to run the full OS. | 16:11 |
| zgu | probably dumb apt question: is there a flag for apt install that makes it always ask or confirmation? | 16:13 |
| newbie | https://unix.stackexchange.com/a/164494 | 16:19 |
| newbie | 16:19 | |
| newbie | Trigger warning | 16:19 |
| newbie | 16:19 | |
| newbie | > There's just no way to do this with the current implementation of apt-get, you would need to open a feature request and appeal to the maintainer. The current behavior of apt-get is that when the list of packages you implicitly declared to be installed is equal to the amount of packages that will get installed, and no other packages are affected with upgrades or breaks, apt-get presumes the user already is sure of what is going to be done | 16:19 |
| newbie | , if you are not sure or want to analyze what will be done without actually installing the package, you can use Costas recommendation of -s, --simulate, --just-print, --dry-run, --recon, --no-act. | 16:19 |
| newbie | 16:19 | |
| newbie | > There are other tools like apt-listbugs that would analyze the versions of packages to be installed before you actually install them (in this case for bugs) and warn you. | 16:19 |
| zgu | oh so it's if there are any extra dependency packages that's what triggers the prompt? | 16:27 |
| fsmithred | -s|--simulate | 16:30 |
| fsmithred | oh, someone already said that. Sorry. | 16:30 |
| newbie | Don't give me too much credit. I was simply quoting :) | 16:32 |
| fsmithred | I like using 'aptitude -s' to see what will happen. (Better formatted output) | 16:35 |
| zgu | oh that's why none of these VLANs are working... the server's not currently in its normal rack connected to its normal switch | 18:03 |
| Walex_ | one good idea is to use 'aptitude' because it gives an easy full screen way of looking at dependencies and reviewin in detail the packages that are about to be installed. | 18:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!