Bug#1075714: (no subject)
Small omission... "This reallypromoting the adoption of IPv6!" ^isn't :) Unless of course I've got this completely wrong and there is a way to do both a static IPv4 and a static IPv6 completely through d-i before the system even reboots into Debian for the first time. But if you can, it's certainly not obvious and that's an issue in itself.
Bug#1075714: Can't statically configure both IPv4 and IPv6 using d-i
Package: debian-installer There appears to be no way (when using the Debian Installer) to specify *both* a static IPv4 address (along with netmask and gateway) and a static IPv6 address (along with netmask and gateway). It would be nice if when you pick 'Configure network manually' that it asks you for... - IPv4 IP - IPv4 netmask - IPv4 Gateway - IPv6 IP (this is missing) - IPv6 netmask (this is missing) - IPv6 Gateway (this is missing) And then it'll ask for nameservers... where you can specify both IPv4 and IPv6 nameservers together delimited by spaces. If this is confusing for some users we could have... - 'Configure IPv4 network manually' - 'Configure IPv6 network manually' - 'Configure IPv4 and IPv6 network manually' Instead of just 'Configure network manually' The way the manual reads (see section 6.3.1.5.3) ... https://www.debian.org/releases/stable/i386/ch06s03.en.html It claims "All combinations of IPv4 and IPv6 [...] are supported" but isn't specific about how you do this, or if it is limited just to autoconfiguration alone. At the moment someone has to pick either IPv4 or IPv6 and then manually edit their networking settings once Debian is installed. This really promoting the adoption of IPv6! As most people (where they have an IPv4 to use) will definitely prioritise making IPv4 connectivity work... more then IPv6. So if forced to enter just one IP address by the Debian Installer, they'll go with IPv4. Then we have to *hope* they remember to manually add IPv6 to their network configuration later on. If they don't just go straight on to installing software and other setup. -- Steven Maddox Lantizia
Bug#433568: (no subject)
It's not impossible already to do VLANs with d-i currently (for anyone reading this after a temporary work around until this is properly fixed)... Step 1) Get to the screen where d-i presents you with a list of network interfaces Step 2) Go to VT2 (using alt-F2) and activate the console Step 3) Add a VLAN interface to whichever physical interface you want it on... ip link add link eno1 name eno1.42 type vlan id 42 Step 4) Go back to VT1 (using alt+F1) and choose to go 'Back' and then forward by selecting 'Configure the network' to repopulate the list Step 5) Pick the new VLAN interface until you're at the screen where you'd normally pick 'Configure network manually...' (but don't pick this option yet) Step 6) Go BACK to VT2 (using alt-F2) Step 7) Bring the physical and VLAN interfaces up... ip link set eno1 up; ip link set eno1.42 up Step 8) Go BACK to VT1 (using alt+F1) and continue as normal EASY!.. OK... FINE... I admit that is sarcasm. It's also laughable that it's easier to get d-i to use PPPoE than it is a VLAN. Now you might think to do the commands on VT2 all at once, but I find once you've picked the network interface with d-i it'll bring the interface down! Also these instructions are useless if you're not configuring a static IP as you'll have to be super quick before the autoconfiguration fails. Lastly... (this is the main reason I'm adding to this bug report)... Does the new patch discussed here address the fact that usually I find I have to run this (AFTER the system has booted up for the first time)... sed -i 's/allow-hotplug/auto/' /etc/network/interfaces ... and then reboot again before any networking works? Because 'allow-hotplug' just doesn't cut it with VLAN interfaces... it seems it must be 'auto' Frankly I don't see why we don't use 'auto' in the default /etc/network/interfaces (whether using a VLAN or not) as it covers everything 'allow-hotplug' does but actually works in more cases. Thoughts?
Bug#1070753: (no subject)
I can confirm this patch works -- Steven Maddox Lantizia
Bug#1070753: (no subject)
It would seem the -A argument (for pppoe-discovery not ps) has been removed as a result of this bug report... #1042881 However this doesn't change that pppoe-discovery seems to indefinitely pause (preventing grep from realising there is an AC) in some circumstances. Ultimately I've logged an issue about this upstream here... https://github.com/ppp-project/ppp/issues/490 But none of this would be an issue if this was rewritten to use -Q instead. -- Steven Maddox Lantizia
Bug#1070753: (no subject)
With the help of pham of #debian-boot on OFTC... Problems found so far with /var/lib/dpkg/info/ppp-udeb.postinst - Some lines call 'ps' with a -A argument which this build of busybox doesn't understand (so it doesn't record the process number correctly to try and kill it later) - The '-A' argument passed to pppoe-discovery doesn't seem to exist and so it doesn't run properly - With *some* (but not all) PPPoE concentrators... if pppoe-discovery finds the concentrator... it'll output the details and just sit there without exiting indefinably... so grep never has a chance to process the contents of stdin and find the string 'AC'. This wouldn't be an issue if the busybox version of grep has --line-buffered but it doesn't :) - Ultimately if -Q is used (instead of grepping for 'AC') then you'll get errcode 1 if one isn't found and errcode 0 if one is found... by default this'll take 15 seconds to try (unless you set -t and/or -a). But since the script runs this twice (once without -U and once with -U) then this means a wait of up to 30 seconds, which d-i has to be patient for and allow to happen. - Ultimately if we're happy that pppoe-discovery will time itself out... then does d-i need to kill anything and thus knowing the process ID isn't needed? -- Steven Maddox Lantizia
Bug#1070753: Can't see PPPoE concentrators via d-i but pppoe-discovery can
Package: ppp-deb To recreate this issue... boot the latest Debian 12 netinst ISO and at the boot menu hit escape then at the boot: prompt type in... installgui modules=ppp-udeb Then d-i will start and after choosing language etc... it'll try to find any see PPPoE concentrators and say they're not detected. After you can go to 'Execute a shell' and you'll find that they're actually there and it shouldn't be a problem... ~ # ip link set ens192 up ~ # pppoe-discover -I ens192 Service-Name: datasuite12.13 Access-Concentrator: datasuite12.13 AC-Ethernet-Address: 00:03:97:40:00:3e -- Service-Name: datasuite12.13 Access-Concentrator: datasuite12.13 AC-Ethernet-Address: 00:03:97:3d:80:2b -- I even made a stupid animated GIF to show these steps in action... https://5r.tf/temp-bugging-me-files/debian-pppoe-broke.gif It seems someone else 14 years ago wrote about this in bug #587850 but nothing was resolved and he was told to talk to his ISP. In this case I work for the ISP, so I'm pretty confident in the fact that the PPPoE concentrator is there. I can do more tests if you've got idea where to go from here. -- Steven Maddox Lantizia
Bug#988817: (no subject)
As I've come to understand it... since fwupd is in main and it recommends a package not in main, then it violates policy 2.2.1 Since this directive is a 'must' I've changed the severity to 'serious' as per the meanings of those severity levels.
Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
I can't help but feel this needs to be rethought. If I install the current Debian 12 via netinst and choose not to install 'standard system utilities'... a choice many people take if they prefer to install their own set of utilities instead... and a choice which doesn't advertise any negative connotations for unchecking it... Then it means the debootstrap process that debian-installer did... won't install dbus (as it's only a recommends of systemd)... and dbus won't be installed from 'standard system utilities' either. From this point, there are two scenarios... If you've got recommends enabled on your system... Installing the fwupd package will automatically try to start the fwupmgr service and fail because the dbus package it just installed (because dbus is a recommends of fwupd) won't automatically start and stays inactive unless you active it or reboot. This gives you an ugly **red error message** in the apt-get output of... "dbus.service is not active, cannot reload." If you've got recommends disabled on your system... (a perfectly valid scenario, but there are haters of this!)... Installing the fwupd package will automatically try to start the fwupmgr service and fail because dbus isn't installed. This gives you an ugly **red error message** in the apt-get output of... "Failed to reload dbus.service: Unit dbus.service not found." I know that some people just install fwupd to use the fwuptool manually which works just fine without fwupdmgr... But unless this package is split into two (one for the fwupmgr service, one for fwupdtool), or unless it is reconfigured so it doesn't try to automatically start fwupmgr... then I can't see how dbus shouldn't be considered a depend for fwupd. It literally can't perform one of its main functions, a function that is automatically started, and shows an error!.. without it!
Bug#779272: mpt-status: /etc/default/mpt-statusd is not created by package install
This would still be a useful change to have in bullseye. At the moment I just run this after installing mpt-status... sed -n 's/^\(MAILTO=\|PERIOD=\|REMIND=\|RUN_DAEMON=\|ID=\)/#\1/p' /etc/init.d/mpt-statusd > /etc/default/mpt-statusd That way I have a slightly easier way of editing such options like MAILTO= (for which e-mail address to send alerts to) or ID= (for which RAID controller the service should watch) On Thu, 26 Feb 2015 10:49:58 + Chris Lewis wrote: > Package: mpt-status > Version: 1.2.0-7 > Severity: normal > > Dear Maintainer, > > It would be nice to have a /etc/default/mpt-statusd file created with #'d out > options > particularly the ID parameter for the controller. It would make setting up > the program > far more obvious. > > This would be a good template for it > > #MAILTO=root # Where to report problems > #PERIOD=600# Seconds between each check(default 10 minutes) > #REMIND=7200 # Seconds between each reminder (default 2 hours) > #RUN_DAEMON=yes > #ID=0 > > > > Cheers! > > > *** Please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these lines *** > > > -- System Information: > Debian Release: 7.8 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages mpt-status depends on: > ii daemon0.6.4-1 > ii libc6 2.13-38+deb7u8 > ii lsb-base 4.1+Debian8+deb7u1 > > mpt-status recommends no packages. > > Versions of packages mpt-status suggests: > ii bsd-mailx [mailx] 8.1.2-0.2006cvs-1+deb7u1 > > -- no debconf information > > -- Steven Maddox Lantizia
Bug#864252: phpMyAdmin package not using admin-user preseed (still)
Package: phpmyadmin Version: 4:4.2.12-2+deb8u2 I've had to log this as a fresh bug as I can't seem to re-open bug 619362... I just get back "smtp; 550 Unknown or archived bug" So the last time I logged this it was Debian 6 and people thought it was dbconfig-common for some reason (I'm not convinced). Now it's Debian 8... Give it a test like thusly on a fresh box/VM... # Setup... echo mysql-server-5.5 mysql-server/root_password password sqlpass | sed 'P;s/ /_again /2' | debconf-set-selections apt-get -y install mysql-server-5.5 mysql -psqlpass mysql -e "UPDATE mysql.user SET user='sqluser' WHERE user='root'; FLUSH PRIVILEGES" echo phpmyadmin phpmyadmin/reconfigure-webserver multiselect apache2 | debconf-set-selections echo phpmyadmin phpmyadmin/dbconfig-install boolean true | debconf-set-selections echo phpmyadmin phpmyadmin/mysql/admin-pass password sqluser | debconf-set-selections echo phpmyadmin phpmyadmin/mysql/admin-user string sqlpass | debconf-set-selections echo phpmyadmin phpmyadmin/mysql/app-pass password apppass | sed 'P;s/\/mysql//;s/ /word-confirm /2' | debconf-set-selections # Main event (get popcorn)... apt-get -y install phpmyadmin -- Steven Maddox Lantizia
Bug#619362: phpMyAdmin package not using admin-user preseed
Package: phpmyadmin Version: 3.3.7-5 When I preseed answer phpmyadmin/mysql/admin-user to something other than root debconf fails to use it when creating the user/database for phpmyadmin. This may be a larger issue with dbconfig-common. Here is what I do to test on a fresh install of Debian 6.0: # Quickly set up Apache with PHP and MySQL changing the root username... apt-get update echo mysql-server-5.1 mysql-server/root_password password mysqlpass | debconf-set-selections echo mysql-server-5.1 mysql-server/root_password_again password mysqlpass | debconf-set-selections apt-get --no-install-recommends -y install apache2-mpm-prefork mysql-server libapache2-mod-php5 mysql -u root -pmysqlpass mysql --execute="UPDATE user set user = 'mysqluser' where user = 'root';" service mysql reload # Now set up phpMyAdmin (tries to connect as 'root'@'localhost' instead of 'mysqluser'@'localhost') echo phpmyadmin phpmyadmin/reconfigure-webserver multiselect apache2 | debconf-set-selections echo phpmyadmin phpmyadmin/dbconfig-install boolean true | debconf-set-selections echo phpmyadmin phpmyadmin/app-password-confirm password pmapass | debconf-set-selections echo phpmyadmin phpmyadmin/mysql/admin-user string mysqluser | debconf-set-selections echo phpmyadmin phpmyadmin/mysql/admin-pass password mysqlpass | debconf-set-selections echo phpmyadmin phpmyadmin/mysql/app-pass password pmapass | debconf-set-selections apt-get --no-install-recommends -y install phpmyadmin service apache2 reload I am using Debian GNU/Linux 6.0, kernel 2.6.32-5-686 -- Regards Steven Maddox OCM Communications Limited, 15 High Street, Shipston on Stour, Warwickshire, CV36 4AB. This document is intended for, and should only be read by, those persons to whom it is addressed. Its contents are confidential and if you have received this message in error, please notify us immediately by telephone and delete all records of the message from your computer. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this message without our prior or written consent is strictly prohibited. Neither the author of this message nor their employers accept legal responsibility for the contents of the message. Any views or opinions presented are solely those of the author.
