:: [devuan-dev] Most recent daedalus i…
Góra strony
Delete this message
Reply to this message
Autor: Dennis Clarke
Data:  
Dla: devuan-dev
Temat: [devuan-dev] Most recent daedalus installer borks the network config

All :

     I just gave a try to install the most recent 24th Oct 2022 daedalus
and everything goes swimmingly during the installer phase. I generally
use the expert mode in order to avoid DHCP and to specify the precise
network config that I want.


     However at first boot I see the machine is not at all correct in
terms of network address information. I went to the console and as root
I see that ip addr show reports both network interfaces have DHCP ip and
NEITHER of them are correct for what I really wanted during install.



root@sedna:~# uname -a
Linux sedna 6.0.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.3-1
(2022-10-21) x86_64 GNU/Linux
root@sedna:~# cat /etc/devuan_version
daedalus/ceres
root@sedna:~#
root@sedna:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
         address 172.16.35.9/26
         gateway 172.16.35.1
         # dns-* options are implemented by the resolvconf package, if 
installed
         dns-nameservers 2620:10a:80bb::10 108.160.241.186 
149.112.121.20 180.160.241.187
         dns-search genunix.com
root@sedna:~#




However in actual fact I get this DHCP madness :

root@sedna:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq 
state UP group default qlen 1000
     link/ether 6c:0b:84:0c:eb:fb brd ff:ff:ff:ff:ff:ff
     inet 172.16.35.18/26 brd 172.16.35.63 scope global eth0
        valid_lft forever preferred_lft forever
     inet6 2607:fea8:99a0:34a0:6e0b:84ff:fe0c:ebfb/64 scope global 
dynamic mngtmpaddr
        valid_lft 172799sec preferred_lft 172799sec
     inet6 fe80::6e0b:84ff:fe0c:ebfb/64 scope link
        valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc 
fq_codel state UP group default qlen 1000
     link/ether 6c:0b:84:0c:eb:fa brd ff:ff:ff:ff:ff:ff
     inet 172.16.35.19/26 brd 172.16.35.63 scope global eth1
        valid_lft forever preferred_lft forever
     inet6 2607:fea8:99a0:34a0:6e0b:84ff:fe0c:ebfa/64 scope global 
dynamic mngtmpaddr
        valid_lft 172799sec preferred_lft 172799sec
     inet6 fe80::6e0b:84ff:fe0c:ebfa/64 scope link
        valid_lft forever preferred_lft forever
root@sedna:~#



This has to be a bug.


Now then, do I need to nuke connman out of existence in order to regain
some network sanity?

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional