Bug#907910: debian-installer: Not possible to reset root password
> > > It's been mentioned in the UI for a very long time. See > > > https://salsa.debian.org/installer-team/user-setup/blob/master/debian/po/templates.pot#L67 > > for the exact message. > Oh! you are right! So I directly ignore the messages! So, we could close this bug? What about the possibility to revert the "root disable"? -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#907910: debian-installer: Not possible to reset root password
On Tue, Sep 04, 2018 at 12:48:48AM +0200, Tuxicoman wrote: >Package: debian-installer >Severity: normal > >Dear Maintainer, > >I tested Debian testing installer the 4 september 2018 > >At one step, the installer asks for setting the root password. >I pressed Enter, without entering any password, and the installer went to the >next step (creating user accounts) > >I tried to fix this by restarting at a previous step (network configuration) >but the root password step doesn't show anymore. It jumps to user account >creation step directly after network configuration. > >Bugs are : >- maybe empty root password should not be allowed That's a deliberate choice - see later. >- the root password setting step should be replayable But this is clearly a bug, yes. The code in user-setup-ask has a state machine that doesn't cope with this. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#907910: debian-installer: Not possible to reset root password
On Mon, Sep 03, 2018 at 09:03:09PM -0300, eamanu15 wrote: > >Hello! > > >If the root password is unset/blank, root is disabled and the first >user is added to sudoers. Perhaps this should be made explicit in the >installer? > >I think that it will be a great idea, put a message that say: "if the root >password is unset, root is ... ". I am using (and installing) Debian from some >years ago, and this is new for me. =O It's been mentioned in the UI for a very long time. See https://salsa.debian.org/installer-team/user-setup/blob/master/debian/po/templates.pot#L67 for the exact message. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#907910: debian-installer: Not possible to reset root password
Hello! If the root password is unset/blank, root is disabled and the first > user is added to sudoers. Perhaps this should be made explicit in the > installer? > I think that it will be a great idea, put a message that say: "if the root password is unset, root is ... ". I am using (and installing) Debian from some years ago, and this is new for me. =O That is my opinion. Regards! Emmanuel
Bug#907910: debian-installer: Not possible to reset root password
On Tue, Sep 04, 2018 at 12:48:48AM +0200, Tuxicoman wrote: > Package: debian-installer > Severity: normal > > Dear Maintainer, > > I tested Debian testing installer the 4 september 2018 > > At one step, the installer asks for setting the root password. > I pressed Enter, without entering any password, and the installer went to the > next step (creating user accounts) > > I tried to fix this by restarting at a previous step (network configuration) > but the root password step doesn't show anymore. It jumps to user account > creation step directly after network configuration. > > Bugs are : > - maybe empty root password should not be allowed > - the root password setting step should be replayable If the root password is unset/blank, root is disabled and the first user is added to sudoers. Perhaps this should be made explicit in the installer? Cheers, Nicholas signature.asc Description: PGP signature
Bug#907910: debian-installer: Not possible to reset root password
Package: debian-installer Severity: normal Dear Maintainer, I tested Debian testing installer the 4 september 2018 At one step, the installer asks for setting the root password. I pressed Enter, without entering any password, and the installer went to the next step (creating user accounts) I tried to fix this by restarting at a previous step (network configuration) but the root password step doesn't show anymore. It jumps to user account creation step directly after network configuration. Bugs are : - maybe empty root password should not be allowed - the root password setting step should be replayable -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8), LANGUAGE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
kernel-wedge_2.99_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 03 Sep 2018 21:11:15 +0100 Source: kernel-wedge Binary: kernel-wedge Architecture: source Version: 2.99 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Ben Hutchings Description: kernel-wedge - udeb package builder for Debian-Installer Changes: kernel-wedge (2.99) unstable; urgency=medium . * gen-control: Cleanly separate template and override control fields * Refactor gen-control to put general config handling functions in a module * gen-deps: Use common module to parse and iterate over package-list file * Explicitly support merging of default-config and config directories Checksums-Sha1: 762932554e181f9bbd5ffaa12ad717fb5d451f0f 1692 kernel-wedge_2.99.dsc dff3280f820467c45c1b8fca7d081de5cb701102 35700 kernel-wedge_2.99.tar.xz dd03d24f0d3aec6c576f77fd50bf3bc5be29fbd5 6264 kernel-wedge_2.99_source.buildinfo Checksums-Sha256: 315c5dffb3e2a13cd5ac79a5bd5ab480ccfd6cd0a1beca3647879eb9543dcbdd 1692 kernel-wedge_2.99.dsc 3dd9f4fad81acee5de9661d8b83af84db34b099f00adeeba914d7a126d3b2c3e 35700 kernel-wedge_2.99.tar.xz 59200a68e4d723ce22d6fe4e456ec99dcf5751dd53c848086266acf312e819ee 6264 kernel-wedge_2.99_source.buildinfo Files: 9a0d7fd8849ef95d046d86b9ef952654 1692 utils optional kernel-wedge_2.99.dsc f9b5d68b750fc8665656332ed00076b9 35700 utils optional kernel-wedge_2.99.tar.xz 7fd0f0145046c00b92bf7ab413f5eb84 6264 utils optional kernel-wedge_2.99_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAluNlgsACgkQ57/I7JWG EQm8jQ//b+zKp5ASdqTPiXotTifajJBxhQvOUYvd7/gL5ggAn50ceLx62lNXrXpG 3wINfTBDA+BBmI6iorH+YXMood+T7iykLRcoPpCpK8DSyYtaKuOGtMndhVeGzRxk NylJ+vv6qBS3fpDrftZz5uz4bikj8xakCyYSAlYubKXrQmJaDb1dnoH59xr+gTBF facrMOqxYHsD0zA9Vlx7N0PZFDEJ+Lbxb1ZXhAeDsiCkk8lVKFIWG9z93BbiaA3t euE5E2YmCOmV4N3ZbN2bTmzRq9p0JobZGoTSUUFCdxqCrUp4TSRjw2j1u0ElqZCY xLTGYmO1sEjT2vYaFQ7sZHxNI285n7MsKKjbMJklYhQPmEU4/+JzV08diycgajrj jBN6OwaGr5n7BFuGAt9drnS8sAkSu08knRLtOGtBE52ngXjzY2Rlo0x8kVo/hISj gRZZNqDZVfg1uBtXrC3BrJgqp7rCnHxV1lNjc2SlY0zPrIYlnOmHhIwZShh7/frn KyvW7XTmNb/e6xNeaXOHBZMbo6NiWtBptYVkkT/JCO7+1UfnpgVW32FBMvEpPR8d YzflUaEtu89k/0GHN0nY+b4J1fX8aIJR6YM+iCRgKvaLJr2nh0u8Uukc9RbObJYH S7gATy0vDzJafZwJKlMuZ6uwsYjdxw/PDbxN1Lv43B+w1EwDwws= =g8Rr -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#907704: choose-mirror: default to deb.debian.org
On Mon, Sep 03, 2018 at 08:54:56PM +0100, Ben Hutchings wrote: > On Mon, 2018-09-03 at 20:13 +0200, Karsten Merker wrote: > > On Mon, Sep 03, 2018 at 04:41:10PM +0200, Julien Cristau wrote: > > > Control: tag -1 + patch > > > > > > On 08/31/2018 06:27 PM, Julien Cristau wrote: > > > > Package: choose-mirror > > > > Severity: wishlist > > > > X-Debbugs-Cc: tfh...@debian.org > > > > > > > > I think it's time for choose-mirror to stop asking by default. AFAIK > > > > deb.debian.org works well enough now that we don't need users to > > > > manually select a mirror close to them. [...] > > > > Hello, > > > > I can see the argument for not asking to select a mirror when > > there is a well-working mechanism for automatically choosing a > > "near" (in networking terms) mirror. Does deb.debian.org fulfill > > everybody's needs in this regard? ISTR that there were some > > discussions in the past that deb.debian.org didn't resolve to > > particularly useful mirrors for some parts of the world, but I > > have no idea whether that is still a problem. My personal > > experience with deb.debian.org hasn't been that great - instead > > of redirecting me to the Debian mirror that is run by my local > > ISP (and that is in d-i's mirrorlist), it redirects me to an AWS > > instance hosted rather "far" away in networking terms. > [...] > > The existing mirror network has several longstanding problems: > > 1. Many mirrors don't reliably update > 2. Some mirrors aren't reliably available at all > 3. Many mirrors don't carry all release architectures (even a few >of the "primary" ones don't) > 4. Most mirrors don't support TLS > > httpredir.debian.org attempted to solve the first 3 problems while > still doing what you want: it redirected to local mirrors known to have > up-to-date files. This would have been almost ideal as a default. But > apparently it required a lot of maintenance work, which no-one was > prepared to continue doing. > > That's why deb.debian.org is a plain CDN which doesn't rely on the > existing mirror network. It also supports TLS (which I think should > also be enabled by default in the installer). > > If deb.debian.org still doesn't provide reasonably fast service in some > countries, then maybe we should still ask—but then we should put > deb.debian.org at the top of the mirror list for most countries. /\ +1 /\ Like Karsten, my experience with deb.debian.org has been inconsistent. With a 50 Mb/s ADSL line in Montréal, most of the top candidates mirrors from netselect will consistently deliver ~6200 kB/s, but deb.debian.org often connects to an AWS instance where the download proceeds no more than 350 KB/s... Additionally, I think that it is reasonable that users look at the mirror list for the following reason: Our mirrors are a list of organisations and universities who donate storage and bandwidth. Having users look at this list provides the opportunity for the user to recognise their donation--something like "oh, these are the entities who support FLOSS in my country". Thus, I believe that hiding this from the user reduces the reciprocity with these donors, and reduces the incentive to donate storage/bandwidth. That said, I think there should be some sort of mechanism to reward those mirrors who provide TLS. It's becoming normal for a browser to display "insecure site" for those which don't support SSL... Cheers, Nicholas signature.asc Description: PGP signature
Processing of kernel-wedge_2.99_source.changes
kernel-wedge_2.99_source.changes uploaded successfully to localhost along with the files: kernel-wedge_2.99.dsc kernel-wedge_2.99.tar.xz kernel-wedge_2.99_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#907704: choose-mirror: default to deb.debian.org
On Mon, 2018-09-03 at 20:13 +0200, Karsten Merker wrote: > On Mon, Sep 03, 2018 at 04:41:10PM +0200, Julien Cristau wrote: > > Control: tag -1 + patch > > > > On 08/31/2018 06:27 PM, Julien Cristau wrote: > > > Package: choose-mirror > > > Severity: wishlist > > > X-Debbugs-Cc: tfh...@debian.org > > > > > > I think it's time for choose-mirror to stop asking by default. AFAIK > > > deb.debian.org works well enough now that we don't need users to > > > manually select a mirror close to them. > > > > > > PoC patch, completely untested: > > > > > > > Updated patch, at least somewhat tested. It downgrades the debconf > > priority for mirror/http/countries and mirror/http/mirrors so they're > > not asked by default (previous patch would still ask for a country). > > Only the "proxy" question remains; I'd kind of want to skip it by > > default unless we find out we can't get at the mirror directly, but > > that's something for another bug/patch. > > Hello, > > I can see the argument for not asking to select a mirror when > there is a well-working mechanism for automatically choosing a > "near" (in networking terms) mirror. Does deb.debian.org fulfill > everybody's needs in this regard? ISTR that there were some > discussions in the past that deb.debian.org didn't resolve to > particularly useful mirrors for some parts of the world, but I > have no idea whether that is still a problem. My personal > experience with deb.debian.org hasn't been that great - instead > of redirecting me to the Debian mirror that is run by my local > ISP (and that is in d-i's mirrorlist), it redirects me to an AWS > instance hosted rather "far" away in networking terms. [...] The existing mirror network has several longstanding problems: 1. Many mirrors don't reliably update 2. Some mirrors aren't reliably available at all 3. Many mirrors don't carry all release architectures (even a few of the "primary" ones don't) 4. Most mirrors don't support TLS httpredir.debian.org attempted to solve the first 3 problems while still doing what you want: it redirected to local mirrors known to have up-to-date files. This would have been almost ideal as a default. But apparently it required a lot of maintenance work, which no-one was prepared to continue doing. That's why deb.debian.org is a plain CDN which doesn't rely on the existing mirror network. It also supports TLS (which I think should also be enabled by default in the installer). If deb.debian.org still doesn't provide reasonably fast service in some countries, then maybe we should still ask—but then we should put deb.debian.org at the top of the mirror list for most countries. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: partman crypto changed passphrase of previously encrypted volume
On September 3, 2018 2:10 PM, Philipp Kern wrote: > I don't think the data will be recoverable unless you have a backup of > the LUKS header. The way LUKS works is that data is not encrypted with a > passphrase directly but with a key that is encrypted to a set of > passphrases. If you worked purely through the installer's UI you will > have overwritten your LUKS header and hence will be unable to decrypt > the data ever again because the key material is lost. The position of > the LUKS header on disk is always in the same place. Thank you for your quick and clear answer Philipp, this is greatly appreciated. Yes, I worked purely through the installer's UI, and I do not have a copy of the LUKS header. So, using cryptsetup to change the new passphrase back to the old one will not help me to successfully decrypt any of my data in that volume (because it will not lead to the same key material). Correct? Ouch... Are there any other options I could try? After I've recovered from this problem, I will file a feature request for partman: (a) detecting previously encrypted volumes; (b) requesting to mount previously-encrypted volumes with their passphrase and/or include a warning when proceeding to overwrite the LUKS header. Thanks again & keep up the good work caring for our beloved Debian
Processed: Re: Bug#907704: choose-mirror: default to deb.debian.org
Processing control commands: > tag -1 + patch Bug #907704 [choose-mirror] choose-mirror: default to deb.debian.org Added tag(s) patch. -- 907704: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907704 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#907704: choose-mirror: default to deb.debian.org
Control: tag -1 + patch
On 08/31/2018 06:27 PM, Julien Cristau wrote:
> Package: choose-mirror
> Severity: wishlist
> X-Debbugs-Cc: tfh...@debian.org
>
> I think it's time for choose-mirror to stop asking by default. AFAIK
> deb.debian.org works well enough now that we don't need users to
> manually select a mirror close to them.
>
> PoC patch, completely untested:
>
Updated patch, at least somewhat tested. It downgrades the debconf
priority for mirror/http/countries and mirror/http/mirrors so they're
not asked by default (previous patch would still ask for a country).
Only the "proxy" question remains; I'd kind of want to skip it by
default unless we find out we can't get at the mirror directly, but
that's something for another bug/patch.
Cheers,
Julien
>From 5773506afb888b03d03b570bda4492c293d0d2f9 Mon Sep 17 00:00:00 2001
From: Julien Cristau
Date: Mon, 3 Sep 2018 15:34:39 +0200
Subject: [PATCH] Default http mirror to deb.debian.org (closes: #907704).
---
choose-mirror.c| 6 --
debian/changelog | 6 ++
debian/choose-mirror-bin.templates.http-in | 3 ++-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/choose-mirror.c b/choose-mirror.c
index 2662c5f..f44c7ad 100644
--- a/choose-mirror.c
+++ b/choose-mirror.c
@@ -617,8 +617,10 @@ static int choose_country(void) {
debconf_set(debconf, countries, country);
debconf_fget(debconf, DEBCONF_BASE "country", "seen");
debconf_fset(debconf, countries, "seen", debconf->value);
+ debconf_input(debconf, "medium", countries);
+ } else {
+ debconf_input(debconf, "high", countries);
}
- debconf_input(debconf, "high", countries);
free (countries);
return 0;
@@ -665,7 +667,7 @@ static int choose_mirror(void) {
debconf_subst(debconf, mir, "mirrors", list);
free(list);
- debconf_input(debconf, "high", mir);
+ debconf_input(debconf, "medium", mir);
free(mir);
} else {
char *host = add_protocol("hostname");
diff --git a/debian/changelog b/debian/changelog
index 762d821..e7fbf12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+choose-mirror (2.92) UNRELEASED; urgency=medium
+
+ * Default http mirror to deb.debian.org (closes: #907704).
+
+ -- Julien Cristau Mon, 03 Sep 2018 15:33:14 +0200
+
choose-mirror (2.91) unstable; urgency=medium
* Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
diff --git a/debian/choose-mirror-bin.templates.http-in b/debian/choose-mirror-bin.templates.http-in
index 785851e..2dc1f02 100644
--- a/debian/choose-mirror-bin.templates.http-in
+++ b/debian/choose-mirror-bin.templates.http-in
@@ -29,13 +29,14 @@ _Description: Debian archive mirror country:
Template: mirror/http/mirror
Type: select
Choices: ${mirrors}
+Default: deb.debian.org
# :sl1:
_Description: Debian archive mirror:
Please select a Debian archive mirror. You should use a mirror in
your country or region if you do not know which mirror has the best
Internet connection to you.
.
- Usually, ftp..debian.org is a good choice.
+ Usually, deb.debian.org is a good choice.
Template: mirror/http/hostname
Type: string
--
2.18.0
Re: partman crypto changed passphrase of previously encrypted volume
On 2018-09-03 12:35, crotamine wrote: Now, I have the following questions to the debian-installer list: (1) during installation: with what command does the partition manager insert a password for an encrypted volume of which the data is NOT to be erased? and (2) what should be my course of action to retrieve my precious /home data from that volume (if possible at all??!)? E.g. change the password to original? Doubly decrypt?? All help is greatly appreciated. I don't think the data will be recoverable unless you have a backup of the LUKS header. The way LUKS works is that data is not encrypted with a passphrase directly but with a key that is encrypted to a set of passphrases. If you worked purely through the installer's UI you will have overwritten your LUKS header and hence will be unable to decrypt the data ever again because the key material is lost. The position of the LUKS header on disk is always in the same place. Data erase is really just about overwriting the existing data with zeros, which I understand is pretty confusing. Technically the data is already erased by the fact that the header is overwritten but some people want to be sure and write random data (or in the case of non-encrypted disks zeros) to the disk before deploying the system into production. Kind regards Philipp Kern
partman crypto changed passphrase of previously encrypted volume
Dear all, short version of the issue: in partman the passphrase of a previously encrypted volume was changed (or added) by mistake. The data on this volume was not flagged for removal. Installation was cancelled. Later after manually 'decrypting' this volume it was found that the ‘new’ password could decrypt the volume, but data could not be read. What was the command issued by partman to do this? And how to revert to the old password? More detailed description of the steps that led to this problem: I have made a silly mistake involving one of my encrypted volumes. I was reinstalling Debian and through the debian-installer partition manager and disk setup utility I wanted (1) to mount my already encrypted volume (a RAID1 volume, that was perfectly recognized and configured by mdadm in the installer) with its original key, and use it as /home; and (2) format my ssd, encrypt it with a new key, and mount it as root / So what I did: (1.1) I selected /dev/md0 and flagged it as ‘physical drive for encryption’; I set no to ‘Erase data’ and kept all the other settings at their defaults (dm-crypt, aes, 256, xts-plain64, passphrase); (1.2) I configured the other drive for encryption, all options at their defaults. (2) then I entered the ‘Configure encrypted volumes’ utility, and I selected /dev/md0 (crypto); and /dev/sda5; and finished. (3) and then, I made the mistake to misread during the next step, and I entered the wrong password (!) for my already encrypted volume /dev/md0. At the next prompt, asking me for the passphrase of the ssd /dev/sda5, I realized what just had happened, and that I entered the wrong password for my already encrypted volume, and that this password got accepted! I got spooked and I decided to cancel this particular installation, reinstall everything without touching /dev/md0, and mount that volume after the system has finished installing and is running... Done, in the running system I found mdadm was doing her job and both disks were running in RAID1. However, upon mounting the (previously) encrypted volume /dev/md0, I found that my original password was no longer working. Indeed, the new passphrase (i.e., the one I mistakenly entered during the failed/cancelled installation) could decrypt the volume! The volume could not successfully be mounted because there was no filesystem recognized. Now, I have the following questions to the debian-installer list: (1) during installation: with what command does the partition manager insert a password for an encrypted volume of which the data is NOT to be erased? and (2) what should be my course of action to retrieve my precious /home data from that volume (if possible at all??!)? E.g. change the password to original? Doubly decrypt?? All help is greatly appreciated. Thank you in advance, And of course thanks for providing an otherwise robust and lovely installer, crotamine
Bug#782287: hw-detect: install open-vm-tools in d-i
On Wed, 13 Jun 2018 00:29:33 +0200 Bernd Zeimetz wrote: > Hi again, > > things have changed - thanks VMware - and I'd be happy to support > whatever is needed to make d-i install open-vm-tools when being run in a > VMware environment. I'd think so as well, things got better since then. > Regarding the suggested extra binary I'm wondering if dmidecode wouldn't > be appropriate to handle the detection of a virtualized environment as > dmidecode is shipping an udeb anyway. I opened PR [1] for your consideration which would be a rewrite with the suggested changes. Looking much simpler now, but I can't test that so I'd ask people with VMWare to give that a sanity check. @Oliver Kurth maybe you can give that a shot if it would suit your needs? [1]: https://salsa.debian.org/installer-team/hw-detect/merge_requests/2
