Bug#857228: guake: f12 toggle still broken in bookworm
I just installed guake (3.9.0-2) on Bookworm and hit this issue too. FWIW I haven't had it installed for ages and last time I used it worked fine. To make it more frustrating if I had firefox open, it opens the dev tools instead! I followed the workaround noted here (in gnome settings) and that worked for me too. For good measure I also disabled for web dev tools in firefox about.config: devtools.f12_enabled false Cheers, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063897: firefox: poor performance compared to vendor package
Hi Laurent - and bug list, On 20/2/24 02:26, Laurent Bigonville wrote: AFACS, the packages provided by mozilla are only nightly/devedition/beta, but there is no stable release with the optimizations, or am I overlooking something? I can confirm that the latest stable[1] is available via the Mozilla Debian apt repo[2]. nightly/devedition/beta builds are also available via the same repo for those that are interested. [1] https://www.mozilla.org/en-US/firefox/122.0.1/releasenotes/ [2] https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions I.e.: user@laptop ~$ apt policy firefox firefox: Installed: (none) Candidate: 122.0.1~build1 Version table: 122.0.1~build1 900 900 https://packages.mozilla.org/apt mozilla/main amd64 Packages 122.0~build2 900 900 https://packages.mozilla.org/apt mozilla/main amd64 Packages FWIW obviously I haven't (yet) installed the latest upstream stable - but plan to in the near future. Regards, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package
Hi Alex,
Apologies on my slow response.
On 26/1/24 20:55, Alexandre Rossi wrote:
php-mysql depends on php8.2-mysql which provides php-mysqli and
contains mysqli.so
For adminer, adding an alternate dependency to php-mysqli would
tighten (adminer actually requires mysqli.so or pdo_mysql.so loaded in
PHP for mysql interaction). But then why keep the dependency on
php-mysql?
The patch becomes:
diff --git a/debian/control b/debian/control
index 35a3f2a..43b2d7d 100644
--- a/debian/control
+++ b/debian/control
@@ -14,11 +14,11 @@ Package: adminer
Architecture: all
Depends:
libapache2-mod-php | php-cgi | php-fpm | php,
- php-mysql | php-sqlite3 | php-pgsql,
+ php-mysqli | php-pdo-mysql | php-sqlite3 | php-pgsql,
${misc:Depends},
Recommends:
php-cli,
- php-mysql,
+ php-mysqli,
php-pgsql,
php-sqlite3,
${misc:Recommends},
Actually, you raise a good point! Although TBH, I'm not 100% sure?
As I mentioned in my offer to assist with AdminerEvo[1], my packaging
knowledge is a bit adhoc, with lots of gaps...
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055329
Or is there something I missed?
It's just as (perhaps more?) likely that I'm the one missing something! :)
However, having pondered this for some time now, I think that the reason
to continue depending on the 'php-mysql' package (and just adding an
alternative dependency on 'php-mysqli' - or 'php-pdo-mysql') is so that
the php-mysql package - assuming it's installed - gets updated during a
dist-upgrade (e.g. once trixie becomes stable).
AFAICT virtual packages don't (can't?) have a Debian version. I.e.:
# apt policy php-mysqli
php-mysqli:
Installed: (none)
Candidate: (none)
Version table:
And the way it stands now, during a dist-upgrade, the 'php-mysql'
package would pull in the newer phpX.Y-mysql package.
Let's imagine that trixie includes PHP 8.3:
If adminer depends on (virtual package) 'php-mysqli' (and not
'php-mysql'), the dependency is fulfilled by (real package)
'php8.2-mysql' in bookworm (and 'php-mysql' would not be installed).
Then when the user upgrades to trixie (with 'php8.3-mysql') the
php-mysqli dependency would still be fulfilled by php8.2-mysql wouldn't
it? Unless there's a specific Breaks/Conflicts (?) against the
'php8.2-mysql, the 'php8.3-mysql' wouldn't get pulled in would it? (IIUC
there is no upgrade path from 'php8.2-mysql' is there? Only 'php-mysql'?)
So focusing back on bookworm, in my mind, the preferred dependency
remains the 'php-mysql' package. The alternate 'php-mysqli' virtual
package dependency would just mean you could use an alternate
phpX.Y-mysql package to fulfill the dependency (without needing to pull
in the php8.2-mysql package). You could instead install Adminer with an
alternate phpX.Y-mysql package (e.g. php8.3-mysql from Ondřej's 3rd
party PHP repo).
That may well cause other issues for the 3rd party PHP user, but IMO a
user using default Debian packages should have prior consideration over
someone using third party repos.
So whilst I'm not completely sure, it seems right to me to still depend
on the real package and just have the virtual package as a fallback option.
Sorry I feel like I'm saying the same thing over and over but in
slightly different ways... Hopefully I making sense?
Actually, it just occurred to me to have a quick look at some other php
based packages that use mysql DB too. The first 2 I checked seem to be
using a similar thing to what I previously proposed (albeit depending on
the virtual 'php-mysqlnd' package instead of 'php-mysqli'):
Package: mediawiki
Depends: [...], php-mysql | php-pgsql | php-sqlite3 | php-mysqlnd, [...]
Package: wordpress
epends: [...], php-mysql | php-mysqlnd, [...]
Although I note that phpmyadmin appears to depends on php-mysql only (as
adminer does now):
Package: phpmyadmin
Depends: [...], php-mysql, [...]
TBH I'm still inclined to think that having the phpX.Y-mysql package
provide a virtual 'php-mysql' package would be an easier way to go, but
Ondřej seemed pretty clear that wasn't the way he thought it should be.
So on that basis my inclination remains to go with my prior suggestion
(i.e. add 'php-mysqli' as an optional dependency to 'php-mysql') but
you're the maintainer, so I'll defer the decision to you.
(FWIW the hack I currently use to work around this is build a local
dummy php-mysql package that depends on the relevant phpX.Y-mysql that
I'm using).
I hope I haven't made things worse for you by trying to explain myself.. :D
Regards,
Jeremy
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12
Hi Nicholas, On 26/1/24 11:40, Nicolas Haller wrote: Thanks for the suggestions. I was able to update my BIOS/UEFI but it didn't solve the issue unfortunately. :( If you haven't already, it may be worth reporting upstream (i.e. to grub devs) - they might have more ideas on troubleshooting, etc? So I change the type of my UEFI partition to BIOS boot partition, install grub-pc 2.12-1, run a grub-install and change the BIOS setting to "legacy BIOS only" as you mentioned and I'm able to boot now. Yay! I'm not sure of the consequences of switching from UEFI to BIOS, but at least, I have a GRUB I don't need to pin to 2.06. :-) AFAIK, it just means that you aren't using secureboot/UEFI so the risk of rootkits is potentially higher. TBH, I'm not sure how much risk there really is in practice though? FWIW, my laptop (a couple of years older than yours AFAIT) first had Debian 6/Squeeze installed - about ~11-12 years ago & upgraded since - has always been like that. IIRC I had to, to install Debian back then? It's always been rock solid reliable and I've never had any issues (beyond the odd Debian bug - at least to the best of my knowledge). I'm always a bit paranoid though, so super careful - daily automated aide scans, thunderbird with html disabled for email and firefox locked down for web browsing - always careful with what links I click, etc. So YMMV!? Thanks again for your help. You're most welcome. Have an awesome day! :) Cheers, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055329: Offer of support/assistance
Hi Alexandre, My name is Jeremy and I'd like to offer you my support and assistance in your efforts to package and maintain AdminerEvo if that's of any use to you? FWIW I am a core developer in a Debian derivative project named TurnKey Linux[1][2]. [1] https://wiki.debian.org/Derivatives/Census/TurnKeyLinux [2] https://www.turnkeylinux.org/ We currently use Adminer (as packaged by you) in many of our "software appliances" - e.g. our LAMP appliance[3]. [3] https://www.turnkeylinux.org/lamp I only just realised that upstream seems to have abandoned it and I finally managed to find my way here... For background and context, as part of my role in TurnKey, I maintain an apt repo[4] for our custom packages. [4] http://archive.turnkeylinux.org/ I'm certainly no packaging expert and have never been involved in formal Debian packaging before. My plan has always been to get more involved in Debian packaging and perhaps even bring some of our custom packages into Debian too. Unfortunately, I've never made the time (we're a small team with 100+ appliances)... I must admit that my packaging knowledge is quite adhoc, with lots of gaps I am sure. Also, maintaining our own repo (and never being involved with official Debian packages) means that I probably have some bad practices... Helping an experienced maintainer with a single package such as this, seems like a good way to learn the ropes and contribute something back directly to Debian. So if you are open to and/or desire some assistance, I'd be glad to help (and learn a bit...). If not, that's fine too. Take care and thanks for your contributions to Debian. Warm Regards, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package
Dear Alexandre (adminer maintainer),
As per Ondřej's note below, with regards to MySQL support, from a glance
through the source code (adminer/drivers/mysql.inc.php) it seems that
adminer should depend on php-mysql (real metapackage) OR php-mysqli
(virtual package provided by real phpX.Y-mysql package - i.e. currently
php8.2-mysql).
On 25/1/24 16:05, Ondřej Surý wrote:
The extension package provide names of the extensions actually provided by the
said package. “mysql” extension has been removed from PHP a quite a while ago
and is not provided by php8.2-mysql package. (Similar situation can be found in
php8.2-xml package.)
This needs to be fixed in the adminer, so it actually depends on an extension
it actually uses.
Ondrej
--
Ondřej Surý (He/Him)
Please find a patch attached to resolve this issue - #1061469. Hopefully
I got it right?
If you would prefer me to open a merge request on Salsa, please let me
know and I'll do that instead (I don't have a salsa account but AFAIK
it's relatively straight forward to get one).
Regards,
Jeremy
PS Actually, I've just noticed #1054574 & #1055329 - IMO it's probably
not worth applying this and just move on with AdminerEvo!?
diff --git a/debian/control b/debian/control
index d6f56f0..58d1d56 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Package: adminer
Architecture: all
Depends:
libapache2-mod-php | php-cgi | php-fpm | php,
- php-mysql | php-sqlite3 | php-pgsql,
+ php-mysql | php-mysqli | php-sqlite3 | php-pgsql,
${misc:Depends},
Recommends:
php-cli,
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package
reassign 1061469 adminer 4.8.1-1 retitle 1061469 Adminer only depends on php-mysql thanks Thank you Ondřej! :) On 25/1/24 16:05, Ondřej Surý wrote: The extension package provide names of the extensions actually provided by the said package. “mysql” extension has been removed from PHP a quite a while ago and is not provided by php8.2-mysql package. (Similar situation can be found in php8.2-xml package.) That makes sense. This needs to be fixed in the adminer, so it actually depends on an extension it actually uses. Hopefully I have reassigned correctly? I followed the instructions noted on this[2] page. (TBH, I'm not very familiar with Debian BT) [2] https://www.debian.org/Bugs/server-control Ondrej -- Ondřej Surý (He/Him) Thanks again. Regards, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061469: phpX.Y-mysql does not provide php-mysql virtual package
Package: php8.2-mysql
Version: 8.2.7-1~deb12u1
Severity: normal
Dear Maintainer/s,
Whilst I am reporting this against the php8.2-mysql package in bookworm,
it applies equally to any/all phpX.Y-mysql packages (where X.Y is the
PHP version) including packages from older stables, as well as trixie
and sid - from the 'php' source package. As it also applies to the
packages in trixie and sid (Version: 8.2.12-1+b1), perhaps I should be
explicitly reporting it against that version instead?
As an aside (perhaps irrelevant here?), this also applies to the
packages provided by Ondřej Surý via his deb.sury.org repo - whom I note
is a member of the Debian PHP Maintainers Team (hence why mentioning
it). Perhaps I should lodge a separate issue directly with him as well?
The issue
-
I note that the phpX.Y-mysql package does not provide a php-mysql
virtual package!?
I can see that it does provide php-mysqli, php-mysqlnd & php-pdo-mysql
(as well as phpX.Y-mysqli, phpX.Y-mysqlnd & phpX>Y-pdo-mysql) virtual
packages, but not php-mysql?! E.g.:
Package: php8.2-mysql
Version: 8.2.7-1~deb12u1
[...]
Provides: php-mysqli, php-mysqlnd, php-pdo-mysql, php8.2-mysqli,
php8.2-mysqlnd, php8.2-pdo-mysql
[...]
I note that the other PHP DB related packages (i.e. phpX.Y-pgsql &
phpX.Y-sqlite3) DO provide their counterpart unversioned virtual
packages (i.e. php-pgsql & php-sqlite3). For example:
Package: php8.2-sqlite3
Version: 8.2.7-1~deb12u1
[...]
Provides: php-pdo-sqlite, php-sqlite3, php8.2-pdo-sqlite
[...]
If nothing else, this seems inconsistent behaviour.
Obviously this is no problem whilst using only packages from a stable
Debian release. However, in my experience, it is quite common for
unpackaged PHP apps (installed direct from upstream source) to require a
newer PHP version than that provided in stable (e.g. newer PHP from
deb.sury.org).
It's less of an issue currently as bookworm has the relatively new
PHP8.2. It was a bigger issue in bullseye as that had 7.4 fairly late in
it's lifecycle.
If using an alternate version of PHP, Debian packages that depend on
php-mysql (e.g. adminer[1]) will always pull in the default versioned
PHP package from Debian as well (or latest PHP from sury.org - depending
on pinning). I.e. php8.2-mysql if Debian repos are preferred (or the
latest PHP version with deb.sury.org).
[1] https://packages.debian.org/bookworm/adminer
I acknowledge that supporting this scenario (installing PHP from third
party repo and still using one or more PHP apps from Debian) may not be
explicitly considered a "normal" Debian issue (so perhaps a "wishlist"
item?).
I also get that the ~500kB may not be that big a deal to some, but IMO
it'd be nice to not have to have redundant unused packages installed.
Further, I understand that the packaged PHP apps (from stable repo) may
not be (completely or at all) compatible with a newer PHP version, but
IMO that's on users such as myself to resolve, workaround or live with.
Resolution?
---
Regardless, on face value, it seems to me that if the versioned package
(php8.2-mysql) simply provided the php-mysql package virtually this
situation would be resolved. Or am I missing something fundamental?
FWIW I had intended to attach a patch for the php source
('debian/main/8.2' branch) for your consideration, but it's a much more
complex package than I have encountered before and I'm not really clear
what might be required to achieve what I am requesting/suggesting. With
some guidance I'd be more than happy to provide a patch and/or open a
merge request on salsa (and/or elsewhere).
If there is a preferred alternate path to resolve this that I can assist
with, please inform me.
Thank you for your consideration and/or guidance.
Regards,
Jeremy
-- Package-specific info:
Additional PHP 8.2 information
PHP @PHP_VERSION SAPI (php8.2query -S):
PHP 8.2 Extensions (php8.2query -M -v):
Configuration files:
/etc/php/8.2/mods-available/mysqlnd.ini
extension=mysqlnd.so
/etc/php/8.2/mods-available/mysqli.ini
extension=mysqli.so
/etc/php/8.2/mods-available/pdo_mysql.ini
extension=pdo_mysql.so
-- System Information:
Debian Release: 12.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.126-1-pve (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored:
LC_ALL set to C), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages php8.2-mysql depends on:
ii libc6 2.36-9+deb12u3
ii php-common 2:93
ii php8.2-common 8.2.7-1~deb12u1
ii ucf3.0043+nmu1
php8.2-mysql recommends no packages.
php8.2-mysql suggests no packages.
Versions of packages php8.2-common depends
Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12
Hi Nicolas, It might be worth double checking you have the latest BIOS/UEFI? If it's not the latest, then updating is worth a try IMO. FWIW I recently updated mine to resolve some (completely unrelated) issues on my Lenovo Gen 1 X1 Carbon on Bookworm. With no optical drive and no Windows, it initially seemed like a PITA, but ended up pretty easy. Process went something like this: - download relevant BIOS/UEFI update ISO specific to your model from Lenovo - extract IMG from ISO (using 'geteltorito' tool in 'genisoimage' pkg) - write IMG to USB (e.g. using 'dd') - boot from USB - update...! :) If you are already running latest, updating doesn't help, or you want to try a workaround, perhaps try disabling UEFI (i.e. disable secure boot and enable "legacy BIOS only" mode) and install the non-uefi grub (i.e. 'grub-pc')? Good luck. Cheers, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057978: Almost removed most of my system
(Random Debian user who has used unstable/Sid - sharing my 2c) Hi Dan, On 11/12/23 20:40, Tianyu Chen wrote: On Mon, 11 Dec 2023 15:22:24 +0800 Dan Jacobson wrote: Today I out of habit hit RET to the following. It removed much of my system. https://www.reddit.com/r/Crostini/comments/alytbc/comment/kcv98ks/ Next time I'll be more careful and not trust it. I didn't realize how long the list was when I hit RET. Maybe there should be a second question if the removal list is longer than 20 packages. You're using unstable, so you should be more careful with your actions, especially full-upgrade. If I guessed it right, the reason caused this is the ongoing transition of python3.12. Further to Tianyu's note re running unstable, I highly recommend NEVER blindly doing a 'full-upgrade' when running Sid! This[1] seems like a pretty solid workflow giving you the least chance of issues. [1] https://forums.debian.net/viewtopic.php?p=633248#p633248 I ran Sid for a few years myself and there were a number of times that I had to pin specific packages to stop breakages (while upgrading as much as I could). Removal of important packages/tools/dependencies that would lead to a broken state weren't uncommon in my experience. Whilst I suspect that you could create an apt hook to do what you want (i.e. fail/warn if more than x packages are being removed), that still won't avoid potential issues. It's not uncommon for packages and their dependencies to uploaded at different times - which will cause issues, e.g.[2]. [2] https://forums.debian.net/viewtopic.php?t=153857 If you want to be able to run updates blindly without worrying about breakages, just use stable. Issues are still possible, just much less likely; and when they do occur, almost always less severe (tend to be annoying bugs, rather than show stoppers). I moved back to stable during Bookworm because the cost/benefit of running Sid just didn't add up for me (I didn't really need all the newer packages, just a few - that I now update via other methods). If you want to have bleeding edge packages, use Sid - but very carefully! If you're not attached to Debian, then a "proper" rolling release - that is rolling by design (e.g. Arch) might be a better option for you? Also, this mail list is used for tracking aptitude bugs, not for user support. Apologies on the noise... Cheers, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057959: dhcpcd gets stopped during upgrade but never started again
Just a random Debian user passerby; chiming in with my 2c... On 11/12/23 18:51, Martin-Éric Racine wrote: [...] This leaves me with two possible solutions: 1) No dh_install option. This will restart after upgrade (default since dh 10). Assuming that I understand correctly (this option will start/restart dhcp post install - i.e. in postinst) then I think this would be the preferred path wouldn't it? 2) Add --no-stop-on-upgrade --no-restart-after-upgrade options. This will explicitely disable stop and restart actions. Perhaps I'm missing something, but if the dhcpd binary is updated, don't we need to restart the service to ensure that we're using the updated binary? In the case of a security update to dhcpd, wouldn't this leave the vulnerable service running until next reboot and/or manual service restart? In summary; option 1 seems like the "correct" path to me. But perhaps I'm missing something? Regardless, thanks for your work on Debian. All you awesome volunteers rock! :) Cheers, Jeremy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056395: mariadb-server: debian.cnf [mysql_upgrade] basedir option ignored
On 23/11/23 12:29, Otto Kekäläinen wrote:> If you can reproduce the issue you reported in a fresh environment in a similar way it would prove the experience you had is not just because of some custom configuration in your specific environment. Thanks! FWIW, I can't speak to sid, but it certainly appears to be in the bookworm package as reported: # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 12 (bookworm) Release:12 Codename: bookworm # apt policy mariadb-server mariadb-server: Installed: (none) Candidate: 1:10.11.4-1~deb12u1 Version table: 1:10.11.4-1~deb12u1 500 500 http://deb.debian.org/debian bookworm/main amd64 Packages # apt download mariadb-server Get:1 http://deb.debian.org/debian bookworm/main amd64 mariadb-server amd64 1:10.11.4-1~deb12u1 [3660 kB] Fetched 3660 kB in 0s (10.5 MB/s) W: Download is performed unsandboxed as root as file '/root/mariadb-server_1%3a10.11.4-1~deb12u1_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) # rm -rf tmp # dpkg-deb -R mariadb-server_1%3a10.11.4-1~deb12u1_amd64.deb tmp # grep -r '^basedir' tmp tmp/etc/mysql/mariadb.conf.d/50-server.cnf:basedir = /usr (I removed some whitespace from the last line to stop wrapping, but otherwise the output is simply copy/pasted). I hope that helps... Regards, Jeremy PS. Please use reply-to-all to ensure 1056...@bugs.debian.org is included in your replies. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#940328: O: keepassx -- Cross Platform Password Manager
keepassxc is already present in debian and maintained (https://tracker.debian.org/pkg/keepassxc) FTR I used to used to use keepassx (I still have it installed - but haven't used it for years). I switched to keepassxc some time ago. My experience was that it was a drop in replacement. There was no transition, just point it at your existing db and everything "just works". Regards, Jeremy OpenPGP_signature Description: OpenPGP digital signature
Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work
As a follow up (in case anyone hits the same issue as me): After setting 'backend = systemd' fail2ban refused to start!? It turns out that when using 'backend = systemd', python3-systemd is a hard requirement. It is a recommended package for fail2ban but I have recommends disabled by default, so had to manually install it. OpenPGP_signature Description: OpenPGP digital signature
Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work
Thank you José, I really appreciate you taking the time to confirm. Hope you have a great day! :) Regards, Jeremy On 14/7/23 08:45, José Miguel Gonçalves wrote: Hi Jeremy, On 13/07/23 23:01, Jeremy Davis wrote: Can you confirm that the current default bookworm fail2ban config/regex works with sshd with just this change (to 'backend' in /etc/fail2ban/jail.conf)? Or are further adjustments required? Yes, I can confirm that fail2ban sshd jail works fine using the default config and just changing the 'backend' to 'systemd'. Best regards, José Gonçalves OpenPGP_signature Description: OpenPGP digital signature
Bug#1012859: Info received (Syslog)
[Just a random passer-by that might have an idea?] On 14/7/23 07:14, Leslie Rhorer wrote: I filed report 1012859 to the Debian BTS over a year ago. Nothing has been done so far, and I have one cripped system and one dead system that needs to be upgraded to the most recent version, but I can't really proceed until the proper files get included into the Debian distro. Can someone please help? It looks to me like you are missing the firmware-realtek[1][2] (non-free) package?! [1] https://packages.debian.org/bullseye/firmware-realtek [2] https://packages.debian.org/bookworm/firmware-realtek If you haven't already tried, I'd suggest that you try a clean bookworm install from ISO. FWIW bookworm now includes a separate "non-free-firmware" repo that is enabled by default. So the official installer should "just work". If not, then I would suggest opening a new bug against the current installer. In the meantime, try manually installing the package (e.g. copy the deb via a USB stick). Hope that helps. Regards, Jeremy OpenPGP_signature Description: OpenPGP digital signature
Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work
FWIW it appears that this bug is essentially a duplicate of #770171: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171 On 7/7/23 19:04, José Miguel Gonçalves wrote: As Debian opted by systemd journal as the default logging mechanism for bookworm, maybe a better option would be to change the default configuration in '/etc/fail2ban/jail.conf' to select journal as the logging source, i.e., instead of setting 'backend = auto', set 'backend = systemd'. That seems like a sensible suggestion to me. Can you confirm that the current default bookworm fail2ban config/regex works with sshd with just this change (to 'backend' in /etc/fail2ban/jail.conf)? Or are further adjustments required? Regards, Jeremy OpenPGP_signature Description: OpenPGP digital signature
Bug#1040269: libapache2-mod-python version mismatch (expects python 3.11.1, got 3.11.2)
Package: libapache2-mod-python Version: 3.5.0+git20211031.e6458ec-1+b1 Severity: normal X-Debbugs-Cc: Dear Maintainer, Encountered the following apache log items today after installing libapache2-mod-python on a fresh installation of Debian 12 Bookworm. [Tue Jul 04 01:11:11.589215 2023] [:error] [pid 4760] python_init: Python version mismatch, expected '3.11.1', found '3.11.2'. [Tue Jul 04 01:11:11.589291 2023] [:error] [pid 4760] python_init: Python executable found '(null)'. [Tue Jul 04 01:11:11.589310 2023] [:error] [pid 4760] python_init: Python path being used '(null)'. [Tue Jul 04 01:11:11.589344 2023] [:notice] [pid 4760] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads. [Tue Jul 04 01:11:11.589365 2023] [:notice] [pid 4760] mod_python: using mutex_directory /tmp [Tue Jul 04 01:11:11.657668 2023] [mpm_prefork:notice] [pid 4760] AH00163: Apache/2.4.57 (Debian) mod_python/3.5.0+git20211031.e6458ec-1+b1 Python/3.11.2 OpenSSL/3.0.9 mod_perl/2.0.12 Perl/v5.36.0 configured -- resuming normal operations [Tue Jul 04 01:11:11.657780 2023] [core:notice] [pid 4760] AH00094: Command line: '/usr/sbin/apache2' (I have truncated to only include items relevant to mod_python) Specifically the first 3 lines are what confuse me, it appears to reject the version of python present and then finds no executable or path. But then later appears to be working? I don't actually need mod-python right now and I've not got time to test whether or not it actually functions at runtime however the log items alone suggest "some" bug. Seems somewhat similar to #592988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592988 -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libapache2-mod-python depends on: ii apache2-bin [apache2-api-20120211] 2.4.57-2 ii libc6 2.36-9 ii libpython3.11 3.11.2-6 ii python3 3.11.2-1+b1 libapache2-mod-python recommends no packages. Versions of packages libapache2-mod-python suggests: pn libapache2-mod-python-doc -- no debconf information OpenPGP_signature Description: OpenPGP digital signature
Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470
Thanks for the feedback. On 19/4/23 08:08, Cyril Brulebois wrote: If you can spare a reboot, it'd be interesting to confirm your installed system is actually SB-capable. It should be, as we install grub-efi-$arch and shim based on recognizing a system booted under UEFI, so it should be fine. Of course, if it isn't, turning SB off again should restore booting… I have re-enabled secure boot and can confirm that it "just works"! :) If there is anything else that is of interest that you want me to test out, please feel free to ask. TBH, I don't like some of the aspects of newer Gnome, but overall, Bookworm feels pretty solid. Great work to you and all the other incredible volunteers that make Debian possible! Cheers, Jeremy
Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470
Hi Cyril & Steve, Apologies about slow reply. I only just found this thread buried in my 'debian bugs' folder (I'm subscribed to bugs@debian and obviously don't have my filters set up as they should be...). On 9/4/23 11:39, Steve McIntyre wrote: On Sun, Apr 09, 2023 at 01:53:11AM +0200, Cyril Brulebois wrote: Hi Jeremy, and thanks for your report. Jeremy Davis (2023-04-09): Machine: Lenovo T470 (20HD) Had to disable secure boot to get USB to boot, but otherwise, everything "just worked". Why is that? We've been supporting Secure Boot for a very long while. And one of my standard test machines here is my old T470. Jeremy: what problem are you seeing please? FWIW this is my first "proper" UEFI hardware. The issue I had was that the USB stick (with debian iso copied to it) I was using wasn't showing up in the (bios/uefi) boot options (f12) as a bootable device (i.e. wasn't listed as an option). I was considering trying PXE boot, but I ran across online suggestions that some USB sticks aren't recognized by BIOS/UEFI with secure boot enabled. So I disabled secure boot and the USB appeared! :) Everything worked as expected after that. Perhaps there was something else going on and it was coincidental that it worked after disabling secure boot? I just assumed that it was a UEFI bug(/feature?) and not directly relevant to Debian. I haven't tried re-enabling secure boot. Regards, Jeremy
Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470
Package: installation-reports Severity: normal Tags: d-i X-Debbugs-Cc: jer...@turnkeylinux.org Boot method: usb Image version: https://cdimage.debian.org/cdimage/bookworm_di_rc1/amd64/iso-cd/debian-bookworm-DI-rc1-amd64-netinst.iso 2023-04-02 Date: 2023-04-08 Machine: Lenovo T470 (20HD) Partitions: root@tp-deb:~# df -Tl Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs 16273852 0 16273852 0% /dev tmpfstmpfs 32621921772 3260420 1% /run /dev/mapper/tp--deb--vg-root ext4 218500152 5219756 202108352 3% / tmpfstmpfs 16310940 0 16310940 0% /dev/shm tmpfstmpfs 5120 8 5112 1% /run/lock /dev/nvme0n1p2 ext2466026 86675354366 20% /boot /dev/nvme0n1p1 vfat5232485948517300 2% /boot/efi tmpfstmpfs 32621882584 3259604 1% /run/user/1000 root@tp-deb:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb8:16 1 0B 0 disk nvme0n1 259:00 238.5G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 488M 0 part /boot └─nvme0n1p3 259:30 237.5G 0 part └─nvme0n1p3_crypt 254:00 237.5G 0 crypt ├─tp--deb--vg-root 254:10 212.8G 0 lvm / └─tp--deb--vg-swap_1 254:20 976M 0 lvm [SWAP] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Had to disable secure boot to get USB to boot, but otherwise, everything "just worked". Used full disk with encrypted LVM and no problems at all. Everything appears to be working as expected although I haven't done extensive testing. If there is anything of particular interest that you would like more info on, please ask. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="12 (bookworm) - installer build 20230401" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux tp-deb 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1 (2023-03-19) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5904] (rev 02) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 [8086:9d10] (rev f1) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.6 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #7 [8086:9d16] (rev f1) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #11 [8086:9d1a] (rev f1) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-LP LPC Controller [8086:9d58] (rev 21) lspci -knn: Subsystem: Lenovo Device [17aa:2245] lspci -knn: 00:1f.2 Memory controller
Bug#1010715: Please close - bug caused elsewhere
This bug is caused elsewhere and is NOT related to the kernel. Please close this (I'm not sure how to close bugs?). Apologies on the noise. Regards, Jeremy OpenPGP_signature Description: OpenPGP digital signature
Bug#1010715: linux-image-5.10.0-14-amd64: Kernel panic : not syncing: VFS: Unable to mount root fs on unknown block(0,0)
Package: src:linux Version: 5.10.113-1 Severity: important X-Debbugs-Cc: jer...@turnkeylinux.org Dear Maintainer, Running Debian Bullseye (amd64) based system within VirtualBox 6.1 (Debian Bullseye host OS). Reboot after installing latest kernel (linux-image-5.10.0-14-amd64=5.10.113-1) - results in kernel panic. The kernel panic ends with the message: Kernel panic : not syncing: VFS: Unable to mount root fs on unknown block(0,0) Reboot into previous kernel (linux-image-5.10.0-13-amd64=5.10.106-1) results in normal boot. If you need more info, please ask. -- Assuming it may be storage related, here is more info about how it's set up: root@lamp ~# fdisk -l Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors Disk model: VBOX HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x4dd8d2ff Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 16775167 16773120 8G 8e Linux LVM Disk /dev/mapper/turnkey-root: 6.2 GiB, 6652166144 bytes, 12992512 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/turnkey-swap_1: 1020 MiB, 1069547520 bytes, 2088960 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes -- Boot is within the LVM: root@lamp ~# df -h /boot FilesystemSize Used Avail Use% Mounted on /dev/mapper/turnkey-root 6.1G 1.8G 4.0G 31% / -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: innotek GmbH product_name: VirtualBox product_version: 1.2 chassis_vendor: Oracle Corporation chassis_version: bios_vendor: innotek GmbH bios_version: VirtualBox board_vendor: Oracle Corporation board_name: VirtualBox board_version: 1.2 ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp hostname lamp allow-hotplug eth1 iface eth1 inet dhcp hostname lamp ** PCI devices: not available ** USB devices: not available -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-5.10.0-14-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.140 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-14-amd64 recommends: pn apparmor ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-14-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.04-20 pn linux-doc-5.10 Versions of packages linux-image-5.10.0-14-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#991839: [debian-mysql] Bug#991839: mariadb-server-10.3: MariaDB intermittantly not starting on boot on AWS EC2 t2.medium instance
Hi Otto, On 3/8/21 15:13, Otto Kekäläinen wrote: Thanks for the report! You're most welcome. Thanks for the quick response! Could you do a favour and test and identical scenario with Debian Bullseye and the MariaDB 10.5 in it? Done. I can NOT reproduce the issue in Bullseye! :) FWIW, I took a snapshot of my current server; removed the workaround and upgraded to bullseye. I rebooted 5 or six times and MariaDB restarted cleanly every time! :) Following that, on the off chance that there may be some service file change that helps, I tried pulling the newer service file into my original Buster server. I had to tweak it a little to get it to play nice with the older systemd. But after doing that, the issue is back again. :( So a 1 second pre-start sleep it is until Bullseye... Regards, Jeremy OpenPGP_signature Description: OpenPGP digital signature
Bug#991839: mariadb-server-10.3: MariaDB intermittantly not starting on boot on AWS EC2 t2.medium instance
Package: mariadb-server-10.3 Version: 1:10.3.29-0+deb10u1 Severity: important Dear Maintainer, I have hit a weird intermittant issue with MariaDB when running on an AWS EC2 t2.medium instance. Roughly 4 out of 5 reboots, MariaDB fails to start. After boot, the MariaDB service starts/restarts flawlessly. No other services appear to be effected. I can't reproduce it on a t2.micro instance (i.e. MariaDB reliably starts on lower resource machines at boot). I'm guessing that it's a boot time race condition that occurs with higher/better resources? I first noticed this with 1:10.3.27-0+deb10u1. I saw that 1:10.3.29-0+deb10u1 is now available but upgrade to that made no noticable difference. When first noticed, I was also using an older (non-cloud) kernel (linux-image-amd64: 4.19+105+deb10u9). Updating to the latest (cloud) kernel (linux-image-cloud-amd64: 4.19+105+deb10u12) changed the message but not the intermittant bad behaviour: With linux-image-amd64: 4.19+105+deb10u9 systemd[1]: Starting MariaDB 10.3.29 database server... systemd[702]: mariadb.service: Failed to set up mount namespacing: No such file or directory systemd[702]: mariadb.service: Failed at step NAMESPACE spawning /usr/sbin/mysqld: No such file or directory systemd[1]: mariadb.service: Main process exited, code=exited, status=226/NAMESPACE systemd[1]: mariadb.service: Failed with result 'exit-code'. systemd[1]: Failed to start MariaDB 10.3.29 database server. After update to linux-image-cloud-amd64: 4.19+105+deb10u12 -- systemd[1]: Starting MariaDB 10.3.29 database server... systemd[690]: mariadb.service: Failed to set up mount namespacing: Invalid argument systemd[690]: mariadb.service: Failed at step NAMESPACE spawning /usr/sbin/mysqld: Invalid argument systemd[1]: mariadb.service: Main process exited, code=exited, status=226/NAMESPACE systemd[1]: mariadb.service: Failed with result 'exit-code'. systemd[1]: Failed to start MariaDB 10.3.29 database server. After some searching, it appears that removing/overriding some of the service security hardening measures may resolve the issue? But I didn't test (because I didn't want to reduce hardening). However, adding 'ExecStartPre=/usr/bin/sleep 1' appears to reliably work around the issue. I.e.: # cat /etc/systemd/system/mariadb.service.d/override.conf [Service] ExecStartPre=/usr/bin/sleep 1 It strikes me as a bit dirty, but after adding that, it now appears to reliably start at boot. If you want any further information, please let me know and I'll collect it ASAP. Regards, Jeremy -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-cloud-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.3 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.71 ii galera-3 25.3.25-2 ii gawk 1:4.2.1+dfsg-1 ii iproute2 4.20.0-2+deb10u1 ii libc6 2.28-10 ii libdbi-perl 1.642-1+deb10u2 ii libgnutls30 3.6.7-4+deb10u6 ii libpam0g 1.3.1-5 ii libstdc++68.3.0-6 ii lsb-base 10.2019051400 ii lsof 4.91+dfsg-1 ii mariadb-client-10.3 1:10.3.29-0+deb10u1 ii mariadb-common1:10.3.29-0+deb10u1 ii mariadb-server-core-10.3 1:10.3.29-0+deb10u1 ii passwd1:4.5-1.1 ii perl 5.28.1-6+deb10u1 ii psmisc23.2-1 ii rsync 3.1.3-6 ii socat 1.7.3.2-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-server-10.3 recommends: pn libhtml-template-perl Versions of packages mariadb-server-10.3 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 pn mariadb-test pn netcat-openbsd pn tinyca -- debconf information: mariadb-server-10.3/old_data_directory_saved: mariadb-server-10.3/nis_warning: mariadb-server-10.3/postrm_remove_databases: false
Bug#970669: more info
Under some circumstance easy-rsa throws an error regarding 'set -o echo'. This has been reported upstream[1] and subsequently fixed[2]. As per Debian policy, I'm sure that the PR noted would double as a patch to fix this bug in buster. The bug has been resolved in 3.0.7[3] but (at the time of writing) the latest release is 3.0.8 so upgrading is probably the best fix for sid/bullseye?! Regards, Jeremy Davis [1] https://github.com/OpenVPN/easy-rsa/issues/308 [2] https://github.com/OpenVPN/easy-rsa/pull/315 [3] https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.7 (apologies on the mess & noise - Debian BTS is a PITA IMO...) signature.asc Description: OpenPGP digital signature
Bug#970669: EasyRSA script - 'set -o echo' causes error
Package: easy-rsa Version: 3.0.6-1 Oops the package name has a dash... :( On 21/9/20 15:36, Jeremy Davis wrote: > Package: easyrsa > Version: 3.0.6-1 > > [...] signature.asc Description: OpenPGP digital signature
Bug#970668: EasyRSA script - 'set -o echo' causes error
Package: easyrsa Version: 3.0.6-1 Under some circumstance easyrsa throws an error regarding 'set -o echo'. This has been reported upstream[1] and subsequently fixed[2]. As per Debian policy, I'm sure that the PR noted would double as a patch to fix this bug in buster. The bug has been resolved in 3.0.7[3] but (at the time of writing) the latest release is 3.0.8 so upgrading is probably the best fix for sid/bullseye?! Regards, Jeremy Davis [1] https://github.com/OpenVPN/easy-rsa/issues/308 [2] https://github.com/OpenVPN/easy-rsa/pull/315 [3] https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.7 signature.asc Description: OpenPGP digital signature
Bug#918716: python3: weakref spewing exceptions during interp finalization
I just hit up against this issue too... :( Although I discovered a somewhat weird workaround. The python3-pyfits package[1] includes a copy of weakref.py[2] and when installed, it appears that that is used instead (and the error not longer occurs). It's pretty dirty and TBH, I'm not a big fan of installing stuff that I don't directly require, but OTOH it's a really easy workaround! YMMV, but it works with python3 build of Ansible 2.7.10. Cheers, Jeremy signature.asc Description: OpenPGP digital signature
Bug#914172: Inquiry re "policy" of new dependencies (not hosted in sec repo) added when issuing security updates
Hi Salvatore, On 5/12/18 17:27, Salvatore Bonaccorso wrote: > I would acctually not recommend including only the security mirrors in > sources list. You will miss in such cases important updates as well > scheduled via a point releases. > > Does this helps? Yes that helps heaps! Thank you for the clarification! :) FWIW, this config has served us pretty well for ~10 years to only install security updates. But it seems that luck may have been a significant factor! With this info, we'll certainly need to reconsider how we do things as our current config was based on an incorrect understanding of security update "policy". Thanks again... Regards, Jeremy signature.asc Description: OpenPGP digital signature
Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1
Thanks for your input Chris, On 4/12/18 09:12, Chris Lamb wrote: > My quick glance at this bug report suggests there is something wrong > with your APT setup and/or unattended-upgrades. I apologise I was not > aware of all this context & history until now... I can't speak for unattended-upgrades, but AFAIU our apt config is essentially doing what it's designed to do. I.e. only installing updated packages within the security repo - albeit a little too violently! > You appear to be overly-preoccupied with persuing whether adding > dependencies is a "policy" or not but it remains unclear to me what you > would do with this information either way. I have my own thoughts on > whether it is a policy, but that is entirely academic. Sorry if my intention is not clear. From my perspective, the understanding of whether or not this occurrence (i.e. new deps in sec updates, not being within the sec repo) is "legitimate" is not academic. It is the vital piece of info to inform what we do next. Perhaps my message to the security team (cc this bug) helps? In case not: Our current config rests on the assumption that all security updates (and their dependencies) will be hosted within the security apt repo. (FWIW, it appears unattended-updates default config also rests on this assumption). Judging by this occurrence, this is clearly not always the case. What we do next with this info depends on whether this is "how it is" (albeit uncommon) or a mistake. If we are making an unreasonable assumption , then our apt config needs to change as a matter of urgency as it is clearly not safe! Further we'd need to investigate what alternative measures to take. Also, we probably should file a bug against unattended updates. If instead, the assumption is reasonable, but a human error has occurred in this instance, then we would be keen to see how we might support the security team to avoid this happening again. > If you could provide a minimal testcase in Debian stretch for your > issue here, that would be ideal. Alas, downloading and applying some > custom configuration to a Turnkey appliance VM might be a request too > far for someone more-knowledgeable than me who wishing you help you, > I'm afraid. Thanks, but it seems clear (to me at least) that we've worked out the "how" and the "why" we got the result we did. What remains to be understood is whether the issue is with our config making incorrect assumptions, or a mistake/bug with this update. Hope I don't sound like I'm ranting and my position makes more sense now?! :) Regards, Jeremy signature.asc Description: OpenPGP digital signature
Bug#914172: Inquiry re "policy" of new dependencies (not hosted in sec repo) added when issuing security updates
Hi, FYI TurnKey Linux is a Debian derivative which builds a library of headless server "software appliances" using mostly Debian packages, but many with upstream software pre-installed on top. I'm hoping to get some clarity on the "status" of the practice of adding new dependencies (not included in the security repo) when providing security related updated packages. For context, my question relates to a recent incident where ~70% of our library automatically uninstalled MariaDB when the recent security update[1] was released. If you want more detail, please see #914172[2]. [1] https://www.debian.org/security/2018/dsa-4341 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914172 The crux of it is that we have a daily automated update task which installs packages exclusively from the security repo. The MariaDB security update included a new dependency on 'libconfig-inifiles-perl' (hosted in main, not security). As our config does not install packages from any repo other than security, this caused MariaDB to be uninstalled (uninstallable dependency causing apt to remove the package(s)). I.e. our current config assumes that any new dependencies for security updates, would also be included in the security repo. If it is confirmed that this is expected (albeit uncommon) behaviour, we need to adjust our current auto-update config as it is not safe! If instead, this was a mistake (human error) then we'd like to see how we might be able to support the Security team to avoid this happening again in the future. I have no idea what form this might take, but am open to suggestions. Regards, Jeremy signature.asc Description: OpenPGP digital signature
Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1
Apologies on the really slow response. Also apologies that I wasn't able to fill the knowledge gaps sooner. It seems as if everyone now understand what happened. If anyone needs anything further from me, please ask. On 23/11/18 01:44, Faustin Lammler wrote: > > Let me check with Otto why this new dependence was added. From what I can see, it was added as a fix[1][2] for a bug[3]. [1] https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/b3e8b645c018d49f7889990e4ad27ca12369cc0d [2] https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/debian/changelog#L61 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875708 On 22/11/18 21:59, Olaf van der Spek wrote:> On Thu, Nov 22, 2018 at > > https://wiki.debian.org/UnattendedUpgrades Thanks for the suggestion, but as per David's note (in a later message), my testing confirms his experience. If unattended-upgrades is configured for security updates only, then the MariaDB update still fails - albeit not quite so spectacularly. On one hand, I think it could be legitimately argued that not installing the update (rather than removing MariaDB) is preferable in most scenarios. OTOH I'd personally rather know for sure that something is broken, rather than think everything is great when it isn't... I.e. thinking you are automatically getting security updates whilst still running a vulnerable piece of software is far from ideal. On 23/11/18 04:32, Robie Basak wrote: > You should use apt pinning to restrict package upgrades to security > updates only. See what the unattended-upgrades package does for an > example. Removing apt's visibility of stuff that it already has > installed on the system is a hack that will lead to the problem you've > discovered. Thanks for sharing your opinion Robie, although I would argue that explicitly installing updates __only__ from a specific repo (or set of repos - security in this instance) is a desirable and legitimate configuration. (Even if you consider the way we currently do it as a "hack"). FWIW, it's not really removing apt's visibility of what is already installed, it's more removing apt's ability to see what's available from repos other than those explicitly being queried. As noted above, unattended-upgrades still has an undesirable end result - the security update does not occur. I'd be tempted to swap out our simple solution for the the added complexity of unattended-upgrades if it could indeed do what we wanted, but it appears that it can't. Also, as hinted, some of our appliances include third party apt repos which are relatively untrusted. They are already pinned, both for security and convenience. They may also contain newer versions which users will likely not want auto-updated, but at some point may wish to update interactively. We block install of additional software from 3rd party repos via pinning already too (aiming to mitigate potential security risks) but I feel much more comfortable in completely excluding them from auto security updates. Perhaps I'm missing something, but how would pinning to only allow security updates, resolve a scenario such as this? I.e when a new dependency (not hosted in security) is a (new) required dependency of a security update? Wouldn't it at best give the same result as unattended-upgrades? > I'm interested for someone to confirm that pinning will solve this > problem correctly in this particular case. I believe that it will but am > not certain. TBH I'm not even clear where to start with configuring pinning to achieve our ends? I don't understand how pinning could allow you to install and update all packages like "normal"; whilst also allowing __only__ security packages (and any new dependencies?!) to be automatically updated on a schedule?! Although there's a good chance that I'm completely missing something! Could you please elaborate a little on how you think it might work? > I don't know about Debian's policies in adding dependencies to security > updates. Clearly it is to be avoided, but there might be some situations > when it is necessary for security purposes. As Olaf mentioned, I was under the impression that adding new dependencies to security updates is a contravention of Debian policy. FWIW, that's why we felt pretty confident of the config we've been using for the last 10 years. However, my searching has come up empty and I am unable to confirm whether or not that is indeed policy. I will follow up a little further, but if anyone has a reference, please share. > Therefore, I'm not sure that > this should be considered a bug at all from mariadb packaging's point of > view, unless there is some other reason that the dependency addition > should not have gone in. > Well if it's a contravention of policy, I'm pretty sure that counts as a bug, right?! I do agree that there are cases where adding a new dependency to a security update may be legitimate. But I would argue in those cases, adding the new dependency to the security repo as well
Bug#914172: [debian-mysql] Bug#914172: Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client
On 21/11/18 19:08, Olaf van der Spek wrote: > Are you aware of the unattended-upgrades package though? I have heard of it, but never actually tested it. FWIW we've been using this config for ~10 years now and this is only the 4th time it's bitten us (albeit one of the worst). Perhaps it's time to have a closer look at unattended-upgrades?! > Have you tried figuring out why apt wants to remove mariadb-server? Pretty sure it's because we don't have libconfig-inifiles-perl installed by default, which appears to (now?) be a 'depends' of mariadb-client-10.1. FWIW we have apt configured to only install 'depends' and I assume that it has moved from a 'recommends' to a 'depends' although that is only a guess... signature.asc Description: OpenPGP digital signature
Bug#914172: [debian-mysql] Bug#914172: Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client
Hi Olaf and Faustin, @Olaf Thanks for your quick response and suggestions. On 20/11/18 18:50, Olaf van der Spek wrote: > IMO apt shouldn't be run in such a way that packages get removed > automatically though.. If you have any specific suggestions on how to ensure that apt won't remove packages, I'd be interested to hear. Also, IIRC there have been cases where removal of old packages were required (I think that was the case with Samba security updates within Jessie?! - Although perhaps I am confused). @Faustin Thanks to you too for your prompt reply, apologies that my response has been a little slow... I'll aim to provide as much relevant info as possible, if there is anything else you need please ask. Hopefully it's not too waffley and/or includes too much irrelevant info... (I'm often told that I need to turn verbosity down...) On 21/11/18 04:57, Faustin Lammler wrote: > Are you able to provide a step-by-step procedure? > Possibly the easiest way to reproduce the issue would be to download our v15.0 (Stretch based) LAMP appliance ISO[1] (signed hash file here[2]) and install it to a VM and NOT run the initial firstboot "security updates" script (i.e. select "skip" when asked). Once logged in as root, you can then poke around inside and see exactly what is going on. [1] http://mirror.turnkeylinux.org/turnkeylinux/images/iso/turnkey-lamp-15.0-stretch-amd64.iso [2] http://mirror.turnkeylinux.org/turnkeylinux/images/iso/turnkey-lamp-15.0-stretch-amd64.iso.hash Then the issue can be reproduced by running 'turnkey-install-security-updates' That will only install updates from Debian (and TurnKey) security repos. In an effort to assist you to avoid that though, here's some more info which may help. The process that turnkey-install-security-updates uses is a little convoluted, but essentially it runs this: apt-get update apt-get autoclean -y apt-get dist-upgrade -y -o APT::Get::Show-Upgraded=true \ -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list \ -o Dir::Etc::sourceparts=nonexistent \ -o DPkg::Options::=--force-confdef \ -o DPkg::Options::=--force-confold FWIW the security.sources.list: deb http://archive.turnkeylinux.org/debian stretch-security main deb http://security.debian.org/ stretch/updates main deb http://security.debian.org/ stretch/updates contrib #deb http://security.debian.org/ stretch/updates non-free If I run the above dist-upgrade command (after apt-get update and without the -y switch), I get this: Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: galera-3 libaio1 libjemalloc1 lsof mariadb-client-core-10.1 mariadb-common mariadb-server-core-10.1 socat Use 'apt autoremove' to remove them. The following packages will be REMOVED: default-mysql-server mariadb-client-10.1 mariadb-server-10.1 mysql-server The following NEW packages will be installed: linux-image-4.9.0-8-amd64 The following packages will be upgraded: curl git git-core git-man libcurl3 libcurl3-gnutls libfuse2 libmariadbclient18 libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython3.5-minimal libpython3.5-stdlib linux-image-4.9.0-7-amd64 linux-image-amd64 mariadb-client-core-10.1 mariadb-common mariadb-server-core-10.1 openssh-client openssh-server openssh-sftp-server python2.7 python2.7-minimal python3.5 python3.5-minimal ssh 26 upgraded, 1 newly installed, 4 to remove and 0 not upgraded. Need to get 107 MB of archives. After this operation, 68.6 MB of additional disk space will be used. Do you want to continue? [Y/n] Obviously some of those packages are irrelevant to this issue, but figured it best to not omit anything. If I then allow it to install those updates (and uninstall default-mysql-server mariadb-client-10.1 mariadb-server-10.1 & mysql-server), then reinstall default-mysql-server, here's what I get: root@lamp ~# apt-get install default-mysql-server Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libconfig-inifiles-perl mariadb-client-10.1 mariadb-server-10.1 Suggested packages: mariadb-test netcat-openbsd tinyca Recommended packages: libterm-readkey-perl libhtml-template-perl The following NEW packages will be installed: default-mysql-server libconfig-inifiles-perl mariadb-client-10.1 mariadb-server-10.1 0 upgraded, 4 newly installed, 0 to remove and 25 not upgraded. Need to get 11.3 MB of archives. After this operation, 125 MB of additional disk space will be used. So it appears likely that the offending dependency (as suggested by Olaf) is libconfig-inifiles-perl ?! > If not, dpgk -l could help to understand what apt dependencies may be > problematic. And what happened when you reinstalled mariadb. Which > command did you used, what was the output? > Alternatively (or as well as?), you can see all
Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1
Package: mariadb-server-10.1 Version: unsure exactly - prior to today's security update Severity: grave Justification: renders package unusable Dear Maintainer, Please excuse me setting the severity as grave. Under the circumstance it seems appropriate, but I'm not 100% sure. FYI TurnKey Linux is a Debian derivative which builds "software appliances" using mostly Debian packages, many with upstream software pre-installed on top. It has Debian (and TurnKey) security updates automatically installed daily via cron-apt. As of the (automated) installation of today's MariaDB server security update (10.1.37-0+deb9u1) all of our user's LAMP based appliances uninstalled mariadb-server (i.e. default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1) and thus most of web based software stopped functioning. The expected outcome was that the packages were simply updated to the latest security update and continued functioning. We're still not sure exactly what caused this, but would like to note the issue. Assitance in ensuring that this sort of issue doesn't reoccur would also be welcomed. It only appears to be an issue if security only updates are installed. A full upgrade does not cause the same issue. The resolution is to simply reinstall default-mysql-server (which depends on mariadb-server-10.1 & mariadb-client-10.1 - mysql-server is an un-needed transitional package). Please note that this report was created on a freshly launched WordPress appliance (based on LAMP) with security updates installed on firstboot (and without the above menitoned fix applied). Please ask if you need any further info. Regards, Jeremy -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.1 depends on: ii adduser 3.115 ii debconf [debconf-2.0] 1.5.61 ii galera-3 25.3.19-2 ii gawk 1:4.1.4+dfsg-1 ii init-system-helpers 1.48 ii iproute2 4.9.0-1+deb9u1 ii libaio1 0.3.110-3 ii libc6 2.24-11+deb9u3 ii libdbi-perl 1.636-1+b1 ii libpam0g 1.1.8-3.6 ii libstdc++66.3.0-18+deb9u1 ii libsystemd0 232-25+deb9u4 ii lsb-base 9.20161125 ii lsof 4.89+dfsg-0.1 pn mariadb-client-10.1 ii mariadb-common10.1.37-0+deb9u1 ii mariadb-server-core-10.1 10.1.37-0+deb9u1 ii passwd1:4.4-4.1 ii perl 5.24.1-3+deb9u4 ii psmisc22.21-2.1+b2 ii rsync 3.1.2-1+deb9u1 ii socat 1.7.3.1-2+deb9u1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages mariadb-server-10.1 recommends: pn libhtml-template-perl Versions of packages mariadb-server-10.1 suggests: ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 pn mariadb-test pn netcat-openbsd pn tinyca
Bug#898896: nginx-common: systemd nginx.service is missing After=remote-fs.target
Hi, Apologies if I'm highjacking this issue, but it seemed appropriate to post here rather than opening a new bug seeing as my issue seems so closely related. Please correct me if I'm wrong. On 17/05/18 18:27, Alexandre Derumier wrote: > but systemd unit have only > After=network.target > > > we should have both in unit > After=network.target > After=remote-fs.target > According to upstream[1] it should be: After=syslog.target network.target remote-fs.target nss-lookup.target A TurnKey GNU/Linux (Debian derivative headless server library) community member (using LXC) has reported a related issue because nss-lookup.target is missing[2]. As a work around, we've added a /etc/systemd/system/nginx.service.d/override.conf file overlay[3]. Perhaps the maintainers should consider adjusting the [Unit] section to match upstream? [1] https://www.nginx.com/resources/wiki/start/topics/examples/systemd/ [2] https://github.com/turnkeylinux/tracker/issues/1110 [3] https://github.com/turnkeylinux/common/commit/17976cf63ae5facc73c2332efbc19813975b691e Regards, Jeremy Davis TurnKey GNU/Linux signature.asc Description: OpenPGP digital signature
Bug#896646: 4.9.0-6-amd64: OverlayFS: rm'd files in merged dir, reappear when merged dir remounted as lower
Package: src:linux Version: 4.9.82-1+deb9u3 Severity: normal Tags: upstream Dear Maintainer, Current behaviour: -- On Debian Stretch (running as root) this the current behaviour: # Create base directory mkdir base touch base/example # Create merge, upper and work directories for 2 layers mkdir layer1 layer1.upper layer1.work mkdir layer2 layer2.upper layer2.work # Mount layer1 as the merged directory using layer1.upper as the true # upper layer, with base as a lower layer and layer1.work as the # necessary work directory mount -t overlay overlay -o lowerdir=$(pwd)/base,upperdir=$(pwd)/layer1.upper,workdir=$(pwd)/layer1.work layer1 ls layer1 # should show example as expected ls layer1.upper # shows no file (this is expected behaviour, it should #only show files written on layer1) rm layer1/example ls layer1 # should show no files ls layer1.upper # should show a special character device called # "example", this is the "whiteout" file # unmount, and remount with layer2 being the new upper layer and using # layer1.upper directory as the top level lower layer. umount layer1 mount -t overlay overlay -o lowerdir=$(pwd)/base:$(pwd)/layer1.upper,upperdir=$(pwd)/layer2.upper,workdir=$(pwd)/layer2.work layer2 ls layer2 # now shows example again as if it was never deleted Expected behaviour: --- Deleted file doesn't exist when layer1.upper remounted as lowerdir. Workaround: --- With auFS kernel module loaded (installed via 'aufs-dkms' & 'linux-headers-amd64' packages) can be configured to exhibit expected behaviour, so using auFS instead (of OverlayFS) is a decent workaround. Additional info: FWIW, this same OverlayFS behaviour is also exhibited in 4-16-2-towo amd64 kernel (I run siduction on my desktop). Regards, Jeremy Davis -- Package-specific info: ** Version: Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 root=UUID=387db0e0-2a50-41e6-85c4-07c4b95d28b6 ro quiet systemd.show_status=true systemd.journald.forward_to_console=0 ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [309873.43] (NULL device *): firmware: direct-loading firmware brcm/BCM20702A1-0a5c-21e6.hcd [309873.422357] (NULL device *): firmware: direct-loading firmware iwlwifi-6000g2a-6.ucode [309873.422364] Freezing user space processes ... (elapsed 0.007 seconds) done. [309873.429371] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [309873.430661] PM: Suspending system (mem) [309873.430680] Suspending console(s) (use no_console_suspend to debug) [309873.557922] sd 0:0:0:0: [sda] Synchronizing SCSI cache [309873.559551] sd 0:0:0:0: [sda] Stopping disk [309873.771541] PM: suspend of devices complete after 340.759 msecs [309873.789277] PM: late suspend of devices complete after 17.734 msecs [309873.792105] ehci-pci :00:1d.0: System wakeup enabled by ACPI [309873.792106] ehci-pci :00:1a.0: System wakeup enabled by ACPI [309873.792186] xhci_hcd :00:14.0: System wakeup enabled by ACPI [309873.857261] PM: noirq suspend of devices complete after 67.985 msecs [309873.857497] ACPI: Preparing to enter system sleep state S3 [309874.217220] ACPI : EC: event blocked [309874.217222] ACPI : EC: EC stopped [309874.217223] PM: Saving platform NVS memory [309874.217249] Disabling non-boot CPUs ... [309874.218640] smpboot: CPU 1 is now offline [309874.220493] smpboot: CPU 2 is now offline [309874.222678] smpboot: CPU 3 is now offline [309874.224616] ACPI: Low-level resume complete [309874.224673] ACPI : EC: EC started [309874.224674] PM: Restoring platform NVS memory [309874.224985] Suspended for 164888.664 seconds [309874.225079] Enabling non-boot CPUs ... [309874.225155] x86: Booting SMP configuration: [309874.225157] smpboot: Booting Node 0 Processor 1 APIC 0x1 [309874.227841] cache: parent cpu1 should not be sleeping [309874.359209] CPU1 is up [309874.359279] smpboot: Booting Node 0 Processor 2 APIC 0x2 [309874.361877] cache: parent cpu2 should not be sleeping [309874.491219] CPU2 is up [309874.491284] smpboot: Booting Node 0 Processor 3 APIC 0x3 [309874.493872] cache: parent cpu3 should not be sleeping [309874.619327] CPU3 is up [309874.623205] ACPI: Waking up from system sleep state S3 [309875.322574] sdhci-pci :02:00.0: MMC controller base frequency changed to 50Mhz. [309875.347007] xhci_hcd :00:14.0: System wakeup disabled by ACPI [309875.347011] ehci-pci :00:1d.0: System wakeup disabled by ACPI [309875.347053] ehci-pci :00:1a.0: System wakeup disabled by ACPI [309875.347095] PM: noirq resume of devices complete after 68.089 msecs [309875.347513] PM: early resume of devices complete after 0.357 msecs [309875.347752] ACPI : EC: event unblocked [309875.347872] iwlwifi :03:0
Bug#801313: grub-pc: grub-install doesn't see /dev/mapper/loop0p1 as child partition of /dev/loop0; fixed in stretch
Package: grub-pc Version: 2.02~beta2-22 Severity: important Dear Maintainer, I was trying to install grub to a raw image (i.e. a flat file that will be used to house a VM). Host & guest image both Debian Jessie I have partitioned the file: part 1 : ext2 (for boot) part 2 : LVM (for root & swap) I have the raw mounted to /dev/loop0 with kpartx so these partitions map to: part 1 : /dev/mapper/loop0p1 part 2 : /dev/mapper/loop0p2 The LVM setup (vg labelled "lv") on part 2 provides: /dev/mapper/lv-root /dev/mapper/lv-swap_1 I then have it mounted like this: /dev/mapper/lv-root -> /mnt /dev/mapper/loop0p1 -> /mnt/boot I then install grub like this: chroot /mnt grub-mkdevicemap chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg grub-install --force --root-directory=/mnt /dev/loop0 Which appears to install as it should: # chroot /mnt grub-mkdevicemap # chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-3.16.0-4-amd64 Found initrd image: /boot/initrd.img-3.16.0-4-amd64 done # grub-install --force --root-directory=/mnt /dev/loop0 Installing for i386-pc platform. Installation finished. No error reported. So this appears to all complete fine... But when I boot the raw image I get an error about a device not found (a UUID that I have no idea where it comes from. It does not appear to match any of the UUIDs that I see in the grub.cfg so I assume that this is coming from the grub installation in the MBR?) I can fix grub easy enough from the vm: -boot with live iso -mount /dev/mapper/lv-root as /mnt & /dev/sda1 as /mnt/boot # grub-install --root-directory=/mnt /dev/sda Once grub is repaired than all works as it should, however I want it to just work from the start... I posted this on the gnu-grub mailing list and a kind soul reproduced it on a similar version of grub-pc (on OpenSUSE) but noted that it could not be reproduced in the current upstream version. I tried my luck on the Stretch version (2.02~beta2-28) and it's fixed there already. I was hoping that we may be able to work out where the issue lays and have the fix backported to Jessie? Any more info you need and/or anything further you would like me to do please let me know. Regards, Jeremy Davis signature.asc Description: OpenPGP digital signature
Bug#753367: Solved
Install was from USB. Setup was not removing entry for USB drive from fstab upon completion of installation. Removed line for USB from fstab. Functions normally. -- Jeremy You can ignore reality, but you cannot ignore the consequences of ignoring reality. - Ayn Rand
