Launchpad startet wieder:
ZitatWe've turned the Launchpad i386 and amd64 builders back on. There's a bit of a queue, and capacity is reduced due to Meltdown and Spectre fixes. We expect to be able to re-enable other architectures over the next few days.
Ja, aber die Pakete, die ich heute Nachmittag hochgeladen hatte, haben über einen halben Tag Wartezeit...
Vermutlich dauert das noch ein bisschen, bis das wieder halbwegs normal läuft.
Ich bekomme:
TASK [yavdr-common : add PPAs] **********************************************************************************************
failed: [localhost] (item=ppa:yavdr/experimental-main) => {"changed": false, "item": "ppa:yavdr/experimental-main", "msg": "Failed to auto-install python-apt. Error was: 'E: The repository 'http://ppa.launchpad.net/ansible/ansible/ubuntu bionic Release' does not have a Release file.'"}
failed: [localhost] (item=ppa:yavdr/experimental-vdr) => {"changed": false, "item": "ppa:yavdr/experimental-vdr", "msg": "Failed to auto-install python-apt. Error was: 'E: The repository 'http://ppa.launchpad.net/ansible/ansible/ubuntu bionic Release' does not have a Release file.'"}
to retry, use: --limit @/home/jj/yavdr-ansible/yavdr07.retry
PLAY RECAP ******************************************************************************************************************
localhost : ok=2 changed=0 unreachable=0 failed=1Da wurde anscheinend das PPA https://launchpad.net/~ansible/+archive/ubuntu/ansible hinzugefügt, das noch keine Pakete für bionic enthält - hast du eventuell das install-yavdr.sh Skript aus dem master-Zweig (der für xenial gedacht ist, wo das PPA gut befüllt ist) unter bionic ausgeführt?
Nimm mal die Zeilen für das PPA aus der /etc/apt/sources.list.d/ansible-*.list raus und probier es noch mal.
Ach ja - der nvidia-384 Treiber in den bionic Paketquellen wurde noch nicht nach der Kernel-Härtung gegen Meltdown aktualisiert, ein funktionierendes Paket gibt es in https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
Ich habe das Paket mal nach ppa:yavdr/experimental-main kopiert, dann wird es automatisch bei der Installation genutzt.
hast du eventuell das install-yavdr.sh Skript aus dem master-Zweig (der für xenial gedacht ist, wo das PPA gut befüllt ist) unter bionic ausgeführt?
Ja, aus Versehen zuerst das, und dann, als ich meinen Irrtum bemerkt habe, das aus dem bionic Zweig, und damit kam dann die Fehlermeldung.
Nimm mal die Zeilen für das PPA aus der /etc/apt/sources.list.d/ansible-*.list raus und probier es noch mal.
OK. Werde ich probieren.
Wenn du Lust hast, kannst du es gerne probieren - ich hoffe, dass das mit der automatischen Bildschirmkonfiguration jetzt zuverlässig klappt und sich die Anschlussnamen nicht mehr zwischendrin ändern.
Bei bionic kann sich von Seiten der Ubuntu-Pakete noch einiges tun, was für ein produktiv genutztes System ein gewisses Risiko darstellt (z.B. sind diverse nvidia-Pakete in den Ubuntu-Repositories noch nicht auf die Kernel mit Meltdown-Fixes angepasst und es können prinzipiell noch neue ABI- odef API-brechende Versionen von Paketen kommen, für die man ggf. Pakete rekompilieren oder anpassen muss). Ich habe die letzten Wochen am bionic-Branch gearbeitet, weil sich das auf dem Testsystem ziemlich gut gemacht hat - das Meiste könnte man für xenial übernehmen, nur wollte ich das nicht ungetestet mergen.
Da viele Plugins von einer funktionierenden Netzwerkverbindung abhängen (z.B. epg2vdr, scraper2vdr, streamdev-client, satip, iptv, weatherforecast usw.) und der VDR mit einigen Plugins unbedienbar ist, bis die Verbindung steht, startet der VDR unter bionic übrigens erst nach erreichen des network-online.target.
Eine Sache, die ich noch nicht wirklich verstanden habe ist, warum das Booten mit aktiven IPv6 Stack so lange dauert (eventuell spielt da die recht alte Fritzbox mit hinein):
$ systemd-analyze
Startup finished in 7.867s (kernel) + 21.783s (userspace) = 29.651s
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @21.761s
└─multi-user.target @21.761s
└─vdr-net-monitor.service @21.761s
└─vdr.service @18.783s +2.976s
└─network-online.target @18.773s
└─systemd-networkd-wait-online.service @1.740s +17.032s
└─systemd-networkd.service @1.704s +34ms
└─network-pre.target @1.703s
└─ebtables.service @1.628s +74ms
└─local-fs.target @1.627s
└─run-user-666.mount @18.847s
└─local-fs-pre.target @520ms
└─keyboard-setup.service @273ms +246ms
└─systemd-journald.socket @265ms
└─system.slice @257ms
└─-.slice @254msMit einer statischen IP-Addresse für IPv4 - die Konfiguration läuft bei Ubuntu 18.04 über netplan
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
eno1:
dhcp4: yes
dhcp6: no
wakeonlan: yes
addresses:
- 192.168.1.30/24
gateway4: 192.168.1.1
nameservers:
search: [fritz.box]
addresses: [192.168.1.1,8.8.8.8,8.8.4.4]und ipv6.disable=1 als Boot-Parameter (die /etc/hosts sollte man dann natürlich auch von IPv6-Einträgen befreien) sieht es dann so aus:
$ systemd-analyze
Startup finished in 5.074s (kernel) + 9.309s (userspace) = 14.384s
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @9.283s
└─multi-user.target @9.283s
└─vdr-net-monitor.service @9.282s
└─vdr.service @6.266s +3.015s
└─network-online.target @6.254s
└─systemd-networkd-wait-online.service @1.813s +4.441s
└─systemd-networkd.service @1.763s +45ms
└─network-pre.target @1.762s
└─ebtables.service @1.681s +80ms
└─local-fs.target @1.680s
└─run-user-666.mount @6.354s
└─local-fs-pre.target @518ms
└─keyboard-setup.service @285ms +233ms
└─systemd-journald.socket @264ms
└─system.slice @261ms
└─-.slice @258msDauert DHCPv6 vielleicht so lange?
Lars.
Es ändert nichts, wenn man in der netplan-Konfiguration dhcp6: no setzt. Mit sysctl kann man auch nicht erreichen, dass er keine IPv6-Adresse bezieht (der in https://www.thomas-krenn.com/d…/IPv6_deaktivieren#Ubuntu beschriebene Weg funktioniert nicht mehr für Ubuntu 17.10 und 18.04).
Geht das (https://www.linuxbabe.com/ubuntu/disable-ipv6-on-ubuntu):
If you want to completely disable IPv6 on your Ubuntu Linux system, then you need to make some changes to Linux kernel parameter.
Edit the 99-sysctl.conf file.
sudo nano /etc/sysctl.d/99-sysctl.confCopy and paste the following 3 lines at the bottom of the file.
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1Save and close the file. Then execute the following command to load the above changes.
sudo sysctl -pnetplan kenne ich noch nicht...
Lars.
Nein, leider ignoriert er das beim Booten - in https://askubuntu.com/question…permanently/337736#337736 ist denen auch nichts anderes eingefallen als den IPv6-Stack komplett abzuschalten.
Wenn Ihr kein IPv6 wollt, bleibt euch nix anderes übrig, es aus dem Kernel zu entfernen. Sprich eigenen Kernel ohne v6 kompilieren.
Es gibt sonst immer irgendwo Software die o.g. disable umgeht und v6 startet.
Mir geht es nur um die Optimierung der Boot-Zeit (für den VDR spielt IPv6 ja bislang keine Rolle) - da reicht es dem Kernel per Boot-Parameter (ipv6.disable=1) zu sagen, dass er den IPv6-Stack nicht nutzen soll. Ich habe nur noch nicht verstanden, weshalb es nicht genügt, wenn ich DHCP für IPv6 deaktiviere (und eine statische IPv6 Adresse setze), um das network-online.target schneller zu erreichen.
Hallo,
ein nerviges Problem habe ich noch:
Ist der Fernseher beim booten nicht eingeschaltet dann beharrt pulseaudio darauf das der Anschluss unplugged ist.
Hat jemand einen Lösungsansatz?
Gruß
Murry
Man kann pulseaudio direkt das Alsa-Gerät vorgeben - dann taucht das als Gerät in der Liste auf (der Name weicht ab, also muss man einmalig in pavucontrol bzw. dem pulsecontrol-Plugin die Karte neu setzen) und sollte auch funktionieren, wenn der Bildschirm beim Starten nicht angeschlossen war - dazu in der /etc/pulse/default.pa sowas einfügen (die Bezeichung der Karte kann variieren):
load-module module-alsa-sink device=hw:1,7Codeload-module module-alsa-sink device=hw:1,7
Vielen Dank,
das funktioniert, damit habe ich ein zusätzliches Ausgabegerät (alsa_output.hw_1_7). Der alsa_output.pci-0000_01_00.1.hdmi-stereo bleibt auf unplugged.
Gruß
Murry
Ich habe nochmal etwas probiert. Wenn der TV beim booten ausgeschaltet ist, dann funktioniert nur folgender Sink:
alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1
Gruß
Murry
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!