Re: Shipping the mini.iso files with the installer-images package?

[Wouter Verhelst]

On Wed, Dec 13, 2023 at 01:21:13PM +0200, Wouter Verhelst wrote:
> So.
> 
> On Wed, Dec 13, 2023 at 10:45:36AM +0200, Wouter Verhelst wrote:
> > That sounds like a much more reasonable way forward, although I'm not
> > keen on extending di-netboot-assistant (it's massive already, and does
> > very different things). At any rate, I'll have a look at implementing
> > this. Thanks for the suggestion!
> 
> This turned out to be fairly simple in the end. First, create a apt.conf
> file like so:
> 
> Acquire::IndexTargets::deb::SHA256SUMS {
>   MetaKey 
> "$(COMPONENT)/installer-$(ARCHITECTURE)/current/images/SHA256SUMS";
>   ShortDescription "SHA256SUMS";
>   Description "$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) d-i SHA256SUMS 
> (deb)";
> };
> 
> Next, create a config file like this:
> 
> images:
>   mini.iso:
> mirror_type: deb
> limit:
>   Suite: stable
>   Architecture: amd64
> basedir: main/installer-amd64/current/images
> relative_name: ./netboot/gtk/mini.iso
> target_filename: /var/lib/libvirt/images/bookworm-mini.iso
>   netboot.iso:
> mirror_type: cd
> basedir: current/amd64/iso-cd
> filename_regex: debian-[0-9.]+-amd64-netinst.iso
> target_filename: /var/lib/libvirt/images/bookworm-netinst.iso
> 
> And then once you have that, the following perl script should do the
> job.
> 
> (config file stored either as /etc/debian-isosync/config.yaml or
> passed as the first argument to the script)

I've pushed this to https://salsa.debian.org/installer-team/d-i/isosync.
Happy to move it elsewhere if necessary, but I think it fits within the
d-i team.

Haven't added it to the mr configuration (yet) nor uploaded to the
archive; feedback on whether people think this a good idea is welcome.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Shipping the mini.iso files with the installer-images package?

[Wouter Verhelst]

So.

On Wed, Dec 13, 2023 at 10:45:36AM +0200, Wouter Verhelst wrote:
> That sounds like a much more reasonable way forward, although I'm not
> keen on extending di-netboot-assistant (it's massive already, and does
> very different things). At any rate, I'll have a look at implementing
> this. Thanks for the suggestion!

This turned out to be fairly simple in the end. First, create a apt.conf
file like so:

Acquire::IndexTargets::deb::SHA256SUMS {
MetaKey 
"$(COMPONENT)/installer-$(ARCHITECTURE)/current/images/SHA256SUMS";
ShortDescription "SHA256SUMS";
Description "$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) d-i SHA256SUMS 
(deb)";
};

Next, create a config file like this:

images:
  mini.iso:
mirror_type: deb
limit:
  Suite: stable
  Architecture: amd64
basedir: main/installer-amd64/current/images
relative_name: ./netboot/gtk/mini.iso
target_filename: /var/lib/libvirt/images/bookworm-mini.iso
  netboot.iso:
mirror_type: cd
basedir: current/amd64/iso-cd
filename_regex: debian-[0-9.]+-amd64-netinst.iso
target_filename: /var/lib/libvirt/images/bookworm-netinst.iso

And then once you have that, the following perl script should do the
job.

(config file stored either as /etc/debian-isosync/config.yaml or
passed as the first argument to the script)

---
#!/usr/bin/perl -w

use v5.36;

use Crypt::Digest::SHA256 qw/sha256_file_hex/;
use YAML::XS qw/LoadFile Dump/;
use Dpkg::Control::HashCore;
use LWP::UserAgent;
use File::Temp qw/tempdir/;

my $ua = LWP::UserAgent->new(show_progress => 1);
$ua->env_proxy;

my $cfilename = shift;
if(!defined($cfilename)) {
$cfilename = "/etc/debian-isosync/config.yaml";
}

my $cfile = LoadFile($cfilename) or die $!;

die "need list of images in config file" unless exists($cfile->{images});
die "images setting in config file is not a hash" unless ref($cfile->{images}) 
eq "HASH";

sub get_apt_sha256sum {
my $rv = [];
my $found;
open my $indextargets, "-|", "apt-get", "indextargets";
do {
my $indexes = Dpkg::Control::HashCore->new;
$found = $indexes->parse($indextargets, "index targets");
push @$rv, $indexes if $found;
} while $found;

close $indextargets;

return $rv;
}

sub ensure_file($url, $sha256_expected, $filename) {
if(-f $filename) {
my $sha256sum_found = sha256_file_hex($filename);
if ($sha256sum_found eq $sha256_expected) {
say "$filename is up-to-date, no update required";
return;
}
} else {
say "$filename not found, downloading";
}
$ua->get($url, ":content_file" => $filename);
}

NAME:
foreach my $name(keys %{$cfile->{images}}) {
say "checking $name...";
my $image = $cfile->{images}{$name};
die "invalid entry $name in config file: missing mirror type" unless 
exists($image->{mirror_type});
die "invalid entry $name in config file: missing directory with 
SHA256SUMS file" unless exists($image->{basedir});
die "invalid entry $name in config file: missing target filename" 
unless exists($image->{target_filename});
next if $image->{disabled};

if($image->{mirror_type} eq "deb") {
die "invalid entry $name in config file: missing relative 
filename" unless exists($image->{relative_name});
my $indexes = get_apt_sha256sum;
INDEX:
foreach my $index(@$indexes) {
next INDEX unless $index->{ShortDesc} eq "SHA256SUMS";
if(exists($image->{limit})) {
foreach my $limit(keys %{$image->{limit}}) {
next INDEX unless $index->{$limit} eq 
$image->{limit}{$limit};
}
}
open my $shafile, "<", $index->{Filename};
my $sha256sum_expected;
SHASUM:
while(my $line = <$shafile>) {
chomp $line;
my $filename;
($sha256sum_expected, $filename) = split /\s+/, 
$line;
last SHASUM if $filename eq 
$image->{relative_name};
$sha256sum_expected = undef;
}
next INDEX unless defined($sha256sum_expected);
ensure_file(join('/', $index->{"Base-URI"}, 
$image->{bas

Re: Shipping the mini.iso files with the installer-images package?

[Wouter Verhelst]

On Tue, Dec 12, 2023 at 11:16:51AM +0100, Philip Hands wrote:
> Wouter Verhelst  writes:
> 
> > Hi,
> >
> > I just created
> > https://salsa.debian.org/installer-team/debian-installer-netboot-images/-/merge_requests/3,
> > which removes the "grep -v mini.iso" from the "get-images.sh" script.
> > The idea being that it can be useful to have a mini.iso available
> > locally in case you want to install a VM with libvirt. While it's
> > possible to PXE boot a VM and install that way, this involves some
> > infrastructure that needs to be set up, and pointing to a .iso file that
> > exists locally seems easier.
> >
> > I usually have a netboot mini.iso file in my home directory for that
> > purpose, but it needs to be kept up to date with every point release,
> > and that's a bit of an annoyance. I think it would be easier to just
> > have it in the debian-installer-netboot-images package.
> 
> I presume you're currently downloading a published mini.iso, rather than
> building them locally, is that right?

Correct.

> Rather than packaging up the mini.iso's, how about having a package that
> acts as an installer, and downloads the published image that matches the
> relevant kerrnel version.

... that could very much work too! I hadn't thought of that.

> The reason I think that might be worth the effort is that I suspect that
> quite a lot of the mini.iso's would have almost no users (depending on
> architecture etc), so copying them across the whole mirror network seems
> like a significant waste of resources.
> 
> Personally, I tend to use the netinst for the purpose you describe, and
> think that it might be quite useful to have a package that would
> maintain a copy of the current image on my systems, so such a package
> could be more widely useful than just for mini.iso downloads.

I had a quick look, and it turns out that both the d-i directory in the
mirror network and the CD mirror network have a SHA256SUMS file with
image names and relative paths. Both have other checksum files too, but
the two are not compatible there (d-i has MD5SUMS (yuck), cdimage has
SHA512SUMS).

I could imagine writing a tool that, when given a URI for a SHA256SUMS
file and a local path, and updates the file if the checksum does not
match (or the file is absent) 

They are both signed, but unfortunately not in the same way -- the d-i
directory is signed through (In)Release(.gpg), the cd network through a
SHA256SUMS.sign file right next to the SHA256SUMS one. But that can be
worked around.

That sounds like a much more reasonable way forward, although I'm not
keen on extending di-netboot-assistant (it's massive already, and does
very different things). At any rate, I'll have a look at implementing
this. Thanks for the suggestion!

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Shipping the mini.iso files with the installer-images package?

[Wouter Verhelst]

Hi kibi,

On Sun, Dec 10, 2023 at 03:00:56PM +0100, Cyril Brulebois wrote:
> Hi Wouter,
> 
> Wouter Verhelst  (2023-12-10):
> > I just created
> > https://salsa.debian.org/installer-team/debian-installer-netboot-images/-/merge_requests/3,
> > which removes the "grep -v mini.iso" from the "get-images.sh" script.
> > The idea being that it can be useful to have a mini.iso available
> > locally in case you want to install a VM with libvirt. While it's
> > possible to PXE boot a VM and install that way, this involves some
> > infrastructure that needs to be set up, and pointing to a .iso file that
> > exists locally seems easier.
> > 
> > I usually have a netboot mini.iso file in my home directory for that
> > purpose, but it needs to be kept up to date with every point release,
> > and that's a bit of an annoyance. I think it would be easier to just
> > have it in the debian-installer-netboot-images package.
> 
> Do you have stats before/after? Looks like it could easily double or
> triple the size of each binary package?

I don't. Creating those stats currently is somewhat difficult, because
of the version flux resulting from last weekend's two releases. But
yeah, presumably it would at least double the size of each binary
package, because the mini.iso files contain the same thing as the other
files do. I'll give it a few days and will try again afterwards.

If size is a concern, we could perhaps create
"debian-installer-*-mini-iso-*" packages instead (e.g.,
"debian-installer-12-mini-iso-amd64") which would contain the mini.iso
files, rather than the actual netboot files? This obviously in addition
to current packages.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Shipping the mini.iso files with the installer-images package?

[Wouter Verhelst]

Hi,

I just created
https://salsa.debian.org/installer-team/debian-installer-netboot-images/-/merge_requests/3,
which removes the "grep -v mini.iso" from the "get-images.sh" script.
The idea being that it can be useful to have a mini.iso available
locally in case you want to install a VM with libvirt. While it's
possible to PXE boot a VM and install that way, this involves some
infrastructure that needs to be set up, and pointing to a .iso file that
exists locally seems easier.

I usually have a netboot mini.iso file in my home directory for that
purpose, but it needs to be kept up to date with every point release,
and that's a bit of an annoyance. I think it would be easier to just
have it in the debian-installer-netboot-images package.

I haven't been involved with d-i work for several years now, so I made
it a merge request rather than just committing to master, even though I
would theoretically have been able to. Please feel free to reject the MR
in case there are reasons (that I'm not aware of) for which the mini.iso
file should not be in this package.

Thanks,

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Firmware GR result - what happens next?

[Wouter Verhelst]

On Thu, Oct 13, 2022 at 04:13:57PM +0100, Steve McIntyre wrote:
> On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
> >On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> >> Maybe and idea would to do something like isa-support does for e.g 
> >> sseX-support
> >> on CPUs that does not have that feature: It fails on installation with an 
> >> debconf message, IIRC.
> >> So that would allow something like "new package" | 
> >> "you-need-to-enable-nonfree-firmware-reminder-package"
> >> 
> >Failing on installation is a terrible user experience, let's not, pretty
> >please.
> 
> It's not great, no. Do you have a better suggestion for making sure
> people update sources.list?

We can display a debconf error (which debconf tries really really hard
to show to the user) and then succeed?

Alternatively, the package could install an apt hook that nags the user
every time they run "apt update" or equivalent, and that turns silent if
the updated firmware packages are installed (because of the difference
between "purge" and "remove").

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Next attempt to add Blends to Debian installer

[Wouter Verhelst]

On Tue, Jan 18, 2022 at 09:52:42AM +0100, Philip Hands wrote:
> I don't have anything like a design for how that should look in my head
> though -- I guess interested parties should get together and come up
> with a design _before_ we start trying to implement it :-)

This sounds like you need someone with UX design experience to look at
this first, before you can actually implement things properly.

Perhaps this is something that could be posted as a "job" on the open
source design website? I've used them in the past to great effect for
the review interface of SReview, my video review system (we did a talk
about that process at FOSDEM 2019; you can see the video at
https://archive.fosdem.org/2019/schedule/event/open_source_design_in_trenches/)

You'd need someone who's willing and able to implement the required
changes to give feedback to the designer, and you'd need to commit to a
bit of time in order to do this properly (in my experience there were a
few iterations of back-and-forth improvements that did take some time to
get fleshed out), but I think the end result is worth it...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Next attempt to add Blends to Debian installer

[Wouter Verhelst]

On Tue, Jan 11, 2022 at 12:51:45AM +, Seth Arnold wrote:
> On Mon, Jan 10, 2022 at 08:02:50PM +0100, Philip Hands wrote:
> > The only missing bit AFAIK is getting the step where tasksel gets
> > installed into the target system, and then run, to be able to grab the
> > version of tasksel to use from an alternative apt repository (which is
> > already being created as part of the salsa-CI pipeline I've got setup),
> 
> Is installing tasksel actually necessary? apt understands tasks, eg:
> apt install lamp-server^
> 
> https://shantanugoel.com/2010/10/23/apt-get-caret/
> https://askubuntu.com/questions/211912/
> 
> I believe this works even if tasksel isn't installed on the target system.

Yes, but that doesn't give a user a friendly way to select a task.

If you know the task then yes, that's plenty, but there's more at play here.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Wouter Verhelst]

On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Control: severity -1 serious
> Control: tags = confirmed
> 
> CCing the release team, and CTTE because I don't know who else is
> tracking issues related to the usrmerge effort.  I've consciously chosen
> not to pour gasoline on the flame war by CCing anyone else (nor will I
> contact anyone else about the existence of this bug).
> 
> Steps I used to try to reproduce:
> 
> 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M
> 2. Installed to EFI-enabled qemu eg:
>kvm -bios /usr/share/ovmf/bios.bin -m 2G \
>-hda debian-separate-usr-sda.raw \
>-cdrom debian-testing-amd64-netinst.iso
> 3. Guided partitioning with separate /home, then changed the mount point
>to /usr.  Partition layout is:
>   sda1: ESP  fat32
>   sda2: /ext4
>   sda3: swap swap
>   sda4: /usr ext4
> 4. Selected only "Standard System Utilities"
> 5. Rebooted
> 
> Result: SUCCESS
> 
> Then, to test the rescue functionality:
> 
> 1. I discovered qemu+OVMF boot order is broken without changing the
>command to: kvm -L /usr/share/ovmf/ -m 2G -boot menu=on \
>-hda /scratch/debian-separate-usr-sda.raw \
>-cdrom /scratch/debian-testing-amd64-netinst.iso
> 2. Selected sda2
> 3. Yes, mount /boot/efi
> 4. Execute a shell in /dev/sda2
> 5. No usable shell was found on your root file system (/dev/sda2)
> 6. Changed virtual terminal
> 7. cd /target && ls bin
>ls: bin: No such file or directory
> 
> Result: FAILED
> Conclusion: This is a usrmerged system, and the rescue system does not
> support usermerged systems.
> 
> The options are, as I see them, ranked from least to most work-hours:
> 
> 1. Debian isn't yet ready for usrmerge.  Revert to normal system installation.
> 2. Reassign to src:rescue, and fix the rescue system.
>a) before chrooting, test for the presence of /target/bin/sh
>b) if /bin/sh is not found, either emit error to the user and present a
>   dialogue for selecting /usr partition, or
>c) parse /target/etc/fstab, and attempt to mount other partitions
>d) b & c will be difficult to implement when attempting to accommodate
>   the heterogeneity of possible MD, LUKS, and LVM layouts, not to mention
>   the complications introduced by the possibility of a user-configured
>   btrfs subvolume name "@usr" on any valid device.  Fstab parsing might
>   make the btrfs case easier with:
> i)   Display a dialogue selector if a btrfs partition is detected
>  The dialogue will list all detected subvolumes
> ii)  If the user cannot find a subvolume for "@usr", then
> iii) Allow the user to escape to the partition selection screen, and
> iv)  Unmount the partition
> 3. Disallow configuring of a mount for "/usr", and *Prominently* declare that
>Debian no longer supports separating /usr from /, declare this in *many
>places*, and reply to bugs on this topic for many years.  I put this one
>last because I believe the cost to work-hours is unbounded, and
>because I believe there may be a negative social cost associated with
>this action.  Also, if Fedora/RHEL/SUSE/Ubuntu support a separate /usr
>partition, then this action could make Debian look inferior.

FWIW, Debian was the last holdout in still supporting a separate /usr
partition amongst major distributions, so that bit is irrelevant...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Tue, Sep 28, 2021 at 12:22:18PM +0200, John Paul Adrian Glaubitz wrote:
> On 9/28/21 12:13, Wouter Verhelst wrote:
> > IOW, chill out, nobody's going to kill off partman unless there's
> > something that's *actually* better than partman.
> 
> Just some comments after reading after this [1] because I honestly find it
> unfair the way I am being cornered here.

Yes, and what I'm saying is, I don't think anyone is trying to corner
you here, Nick are just saying "hey here's some cool new tech, what do
people think". The consensus in my reading is that people like it enough
that we might want to see some proof of concept, and then, assuming it
doesn't lack functionality that we don't want to lose and gives us
something new that we do like (e.g., better usability, more features,
etc etc) then we can perhaps replace partman one or more releases down
the line as the default partitioner.

You have some very good arguments against growlight in its *current*
state. That's fine. Just stay on top of things, and perhaps help Nick
out with testing a few of the more exotic features that partman
currently supports? Either through emulators or by giving him access to
real hardware if you can provide it (and given your collection, I
suspect you can ;-) ).

partman is currently being maintained by the d-i team very much in a
drive-by patches manner, but it's not actually seeing development of new
features. If Nick is offering to take over that work by replacing the
parted bits in d-i by his pet project, *and* he's offering to make sure
that we don't lose functionality we actually care about, then I think
that's a good thing? It's just a matter of making sure Nick *knows*
about the important bits, and that they get implemented in whatever we
end up replacing partman with before we actually do so...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: partman, growlight, discoverable partitions, and fun

[Wouter Verhelst]

On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
> 
> 
> > On Sep 27, 2021, at 2:25 PM, Luca Boccassi  wrote:
> > 
> > Even if that interpretation would work as an excuse to never do
> > anything, and I'm not really sure it does, this specification has been
> > published in 2014 [0] so even by Debian standard it's old stuff.
> 
> That’s not what I said so. You’re trying to dismiss my opinion as completely 
> invalid now by trying to frame it such that I am against progress. I am not.
> 
> > It's
> > older than Debian Jessie, which was EOL'd last year. If libparted can't
> > keep up with 7 years old stuff that in the meantime was implemented in
> > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019,
> > and so on, then to me it sounds like a tool in maintenance mode:
> > perfectly fine and adequate for existing tools and programs, but not
> > quite the best choice for new tools developed from scratch.
> 
> Whether a tool that was developed new from scratch is automatically better is
> not a given. The burden of proof is on the person trying to introduce the new
> software, not on the people maintaining the current set of software.

I think you're reading too much into the question here. The whole
*point* of Nick asking whether people would be opposed to that is
precisely *because* he wants to provide proof that his solution is
better than parted.

You've shown some things that are missing, and his immediate answer is
"ah, right, I'll need to add that then, but would need some assistance
to test that properly".

What's the problem with that?

Nobody is proposing to replace partman tomorrow.

Nobody is proposing to replace partman without testing the replacement.

It's also perfectly possible to imagine a transition period where both
partitioners are supported. That's the whole point of making d-i
modular: you can replace one component with another, and it adds new
features that support more use cases without killing off the older ones
because you can always ask for the other module. In fact, if memory
serves well, partman is the *second* partitioner that was written for
d-i, the first one having been replaced after just such a transition.

IOW, chill out, nobody's going to kill off partman unless there's
something that's *actually* better than partman.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#934492: debian-installer: installing drivers through preseed file causes black screen

[Wouter Wijsman]

Package: debian-installer
Severity: normal

Dear Maintainer,

Lately I've been playing with creating my own Debian ISO files with some
drivers in them. In doing so I have found an issue with the installer which is
causing me some problems.

When I use the pkgsel line in my default.preseed file to install either the
package nvidia-driver or broadcom-sta-dkms, the screen will go black directly
after the installer installed one of these packages. It will not go back to
normal, even after waiting over for 10 minutes and constantly moving the mouse
and pressing buttons on the keyboard, but the installer itself doesn't crash.
If the default.preseed file automates every step after installing one or both
of these packages, the installation will finish without other issues, even with
the black screen.

When I don't have the nvidia-driver or broadcom-sta-dkms package in my
default.preseed, I do not experience this issue. I have tested this on an
Alienware Steam Machine, a Zotac ZBOX-CI323NANO (which has intel graphics) and
in Virtualbox and I'm seeing this issue on all of them.

I think this is related to dkms being triggered, as I haven't seen this issue
being caused by other packages so far. I hope this can be resolved without
having to rebuild these packages to not do so.

Kind regards,
Wouter Wijsman



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:
> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current 
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the 
> conversion program would still be in the same exact situation as it is 
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no 
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Wed, Nov 28, 2018 at 01:49:45PM +, Ian Jackson wrote:
> Control: reassign -1 tech-ctte
> 
> Dear Technical Committee.  I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
> 
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
> 
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
> 
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
> 
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
> 
> So I believe that this change should be immediately reverted in sid
> and buster, so that we do not prejudge the situation by increasing the
> number of buster installs in the field which generate packages which
> are broken on non-merged-/usr systemss.

One thing that has not been answered yet in this discussion (and if the
TC is to make a decision about it, I think it should be) is "why are we
doing this". That is, what is the problem that usrmerge is meant to
solve, and how does it attempt to solve it? As far as I know, the reason
usrmerge exists is so that no files will be installed in /bin anymore;
but that seems like an XY problem.

Also, I would like to ask why the traditional solution in Debian -- make
a policy change that says no package can ship anything in /bin except
for a compatibility symlink, and make that rule RC at some point in the
future -- is not being considered. That seems like a solution that would
cause far less pain than what we're going through right now.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: auto url=example.com/preseed.file WITH PROXY?

[Wouter Verhelst]

On Fri, Sep 28, 2018 at 10:49:08AM +0200, Patrick Hieber wrote:
> Dear all,
> 
> I would like to automate a Debian installation with a pressed file. The
> challenge I am facing is that I am forced to use a proxy to fetch the preseed
> conf file from the mentioned URL. Any ideas how to solve this? I have checked
> the developer website (http://hands.com/d-i/) but the proxy argument is not
> mentioned.

You can preseed any question from the kernel command line, including the proxy
one. The general syntax is:

question=value

In the case of the proxy question, that would be:

mirror/http/proxy=http://proxy.example.com:3128/

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#907704: choose-mirror: default to deb.debian.org

[Wouter Verhelst]

On Wed, Sep 05, 2018 at 02:58:17PM +0200, Philipp Kern wrote:
> On 2018-09-05 12:35, Wouter Verhelst wrote:
[...]
> > I disagree with that, but I do also agree that it would be preferable if
> > local proxies or mirrors were used preferably.
> > 
> > However, this shouldn't be done by way of manual configuration; instead,
> > I think it should be done by way of autodetection performed by apt,
> > something not unlike the proxy-PAC scheme, where a browser looks for
> > pac., with the  part being what was passed to it by
> > DHCP, incrementally dropping off the leaf-most part of that until it
> > resolves.
> > 
> > I think such a scheme could work for apt too.
> 
> Arguably the correct way would be to fetch the PAC and execute it to
> determine the proxy for the host. Of course that'd require interpreting
> Javascript.

Not what I meant (but I certainly could've been clearer).

Autodetecting a proxy using the WPAD scheme is complicated, and I agree
that adding a Javascript interpreter to apt just so we can figure out
where a proxy can be found is probably way overkill. It might be nice,
but I don't think we should do it.

However, it would be nice if a network administrator could somehow
suggest a closeby *mirror*. That's why I said "something not unlike" in
the above quote. Since this'd be something we'd be creating ourselves,
we can decide that no scripting language would be necessary, but instead
just a simple configuration file that says "if you're looking for a
mirror for something of which the Release file has fields matching
, please go to ".

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#907704: choose-mirror: default to deb.debian.org

[Wouter Verhelst]

On Mon, Sep 03, 2018 at 08:13:55PM +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.
> 
> Regarding hiding the proxy question: I'm not sure that it would
> be a good decision to hide the proxy question by default.  Being
> able to connect to the mirror directly doesn't mean that one
> doesn't want to use a proxy, in particular when a package-proxy
> like apt-cacher-ng is available in the local network.
> Personally, I would prefer if the proxy question remains
> at default debconf priority.

I disagree with that, but I do also agree that it would be preferable if
local proxies or mirrors were used preferably.

However, this shouldn't be done by way of manual configuration; instead,
I think it should be done by way of autodetection performed by apt,
something not unlike the proxy-PAC scheme, where a browser looks for
pac., with the  part being what was passed to it by
DHCP, incrementally dropping off the leaf-most part of that until it
resolves.

I think such a scheme could work for apt too.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Wouter Verhelst]

On Sun, Jul 29, 2018 at 02:41:44PM -0400, Nicholas D Steeves wrote:
> On Sun, Jul 29, 2018 at 11:59:34AM +0200, Wouter Verhelst wrote:
> > On Sun, Jul 29, 2018 at 07:50:18AM +0200, Holger Wansing wrote:
> > > +Also, keep in mind: if the CDs/DVDs you are using don't contain some 
> > > packages
> > > +you need, you can always install that packages afterwards from your 
> > > running
> > > +new Debian system (after the installation has finished). If you need to 
> > > know,
> > 
> > Drop the comma (you do need it in German, but English doesn't need it)
> 
> If the subordinate clause precedes the main clause, then the comma is
> mandatory.  Likewise, even if "then" is implied, the comma is
> mandatory.  That said, a comma separating the subordinate and main
> clause is not mandatory if the subordinate clause follows the main
> clause.   /\
> no comma
> If you need to know, on which CD/DVD to find a specific package,
> visit...  /\   /\
>   no comma, because/
>   "on which...package"  mandatory comma  =/
>   is a propositionalfor the "if...package"
>   phrasesubordinate clause
> 
> Are prepositional phrases enclosed by commas in German grammar?

I don't know all the grammatical jargon :-) and my German is old and
rusty, but yes, when translated to German the phrase above would need a
comma after "know". I didn't mean to say it wouldn't need one after
"package"; it does there, which is why I didn't quote that part of the
message.

In general, German requires a lot more commas than other languages do. I
guess they're more relaxed and can take breaks more often ;-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Wouter Verhelst]

On Sun, Jul 29, 2018 at 07:50:18AM +0200, Holger Wansing wrote:
> +Also, keep in mind: if the CDs/DVDs you are using don't contain some packages
> +you need, you can always install that packages afterwards from your running
> +new Debian system (after the installation has finished). If you need to know,

Drop the comma (you do need it in German, but English doesn't need it)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Wouter Verhelst]

On Tue, Jun 26, 2018 at 06:17:31PM +0200, Raphael Hertzog wrote:
> Hello,
> 
> On Mon, 28 May 2018, Cyril Brulebois wrote:
> > debian-boot@: the requested revert looks fine to me, bonus points if it
> > comes with a (short) summary of these reasons in changelog, so that they
> > can be emphasized in the release announcement. :)
> 
> I reverted the change in git:
> https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b
> 
> I haven't uploaded the package yet. I had to reword the debconf template.
> Is the modified template fine?
> 
> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed as you
>  have to review the security advisories before installing the updates
>  using standard package management tools. Alternatively you can install
>  the unattended-upgrades package which will install security updates
>  automatically.

I think it makes sense to explain in a bit more detail why that may not
be a good idea:

"(...) security updates automatically. However, note that updates, even
to stable, are not guaranteed to be zero maintenance, and as such
automatic updates through unattended-upgrades may occasionally cause
downtime of services provided by this machine."

...or something along those lines.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#902436: Please also ship the mini.iso files

[Wouter Verhelst]

Package: src:debian-installer-netboot-images
Severity: wishlist

Hi,

The debian-installer-*-netboot-* packages currently explicitly filter
out mini.iso by way of an explicit "grep -v mini.iso", which according
to git history has always been the case.

One use case for having mini.iso files on hosts would be to have them
available on a VM host, to allow for easy installations of the VM guests
(just point to mini.iso as the file to boot from, and pronto). Having
them be installed by package by the VM host would mean they're always
up-to-date.

I'd like to see that filtering out of mini.iso removed. Downside is that
it would approximately double the size of the packages, since the
mini.iso contains everything that's in the netboot.tar.gz, but I think
the advantage outweighs that minor downside.

Thoughts?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: Include the mini.iso in the debian-installer-*-netboot-* packages?

[Wouter Verhelst]

On Tue, Jun 26, 2018 at 05:09:07PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Wouter Verhelst  (2018-06-26):
> > For some reason, the netboot installer packages do not contain the
> > mini.iso files. This is explicitly filtered out by way of a "grep -v
> > mini.iso", which "git blame" tells me has always been the case.
   ^^^
> > Anyone know (or remember) why that is so? I think that having .iso files
> > on a VM host that are auto-updated as the host is updated can be useful,
> > and so would like to instead see them be part of the installable
> > installer netboot packages.
> 
> Tried git blame? (Hint: That's the initial code.)

Yes :-)

> Anyway: no specific opinion on whether shipping (sometimes multiple)
> mini.iso is a good idea. Open a wishlist bug report against dini source
> and see what regular dini contributors think about this?

I thought that to ask it here would be equivalent, but meh, can do that
too. Bug filed (you'll see it pass by soon enough I'm sure).

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Include the mini.iso in the debian-installer-*-netboot-* packages?

[Wouter Verhelst]

Hi,

For some reason, the netboot installer packages do not contain the
mini.iso files. This is explicitly filtered out by way of a "grep -v
mini.iso", which "git blame" tells me has always been the case.

Anyone know (or remember) why that is so? I think that having .iso files
on a VM host that are auto-updated as the host is updated can be useful,
and so would like to instead see them be part of the installable
installer netboot packages.

Thanks,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Wouter Verhelst]

On Mon, Dec 11, 2017 at 10:55:20PM -0400, Raymond Burkholder wrote:
> On 12/11/2017 11:51 AM, Steve McIntyre wrote:
> > On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:
> > > On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:
> > > > > 
> > > > > I think its totally adequate to assume people want automatic security
> > > > > updates, on all kinds of systems, unless they opt out.
> > > > 
> > > > Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.
> > > 
> > > Are you advocating for having servers with known-security-buggy services
> > > running all over the Internet, then?
> > 
> > That's the point here, yes. We've had this discussion already several
> > times, and it was triggered by needs/desires of cloud providers. As a
> > *default*, it makes sense to have automated security updates to cover
> > the users who don't care, or don't know any better. Users with more
> > knowledge and hard requirements about downtime etc. should already be
> > managing this.
> 
> I think I got thrown off by the title 'unattended upgrades'.  If this is
> limited to security updates,

It is limited to updates *within the release you're running*. That is,
it won't change your sources.list, but it will upgrade packages that
you've already got installed.

The largest part of that is "security updates", yes, but there will
sometimes also be non-security updates of high-severity bugs in there
(for an example of such a non-security bug that I worked on a while
back, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787398).

> I am more for it, but still scared of it.

It's only meant to be a default that can be changed. If you don't like
it, as an informed user, you can switch it off (and we would encourage
you to do so if you have other ways of keeping your systems up-to-date
and secure).

It's only meant to help those who don't care about manually applying
updates.

> Security updates tend to come in packages which have already have had other
> regular patches applied (except, I suppose in 'stable' versions), and
> sometimes one can get caught in functional changes.
> 
> I guess that is my greatest fear,  breakages due to updates.

Please educate yourself on what Debian allows for stable updates
(answer: very very very little)

> But my experience has mostly been with regular package updates.  I haven't
> focused much on security updates.  Can security updates be applied with out
> generating dependency chains and their updates?

Yes, in general. Debian prefers to backport security fixes rather than
upgrading to "the newest version", whatever that is. However, sometimes
that isn't possible (e.g., for webbrowsers), and then we do
(reluctantly) upgrade to more recent upstream versions.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Wouter Verhelst]

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:
> > 
> > I think its totally adequate to assume people want automatic security
> > updates, on all kinds of systems, unless they opt out.
> 
> Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.

Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?

> For my infrastructure, updates, of what ever kind, need to be
> incorporated into the test/build/roll-out cycle.

If you have a test/build/roll-out cycle, then you presumably have a
local mirror (and if you don't, well, why not?) Just make sure your
servers only pull from that local mirror, and you're done.

[...]
> So, as an accommodation,  a flag in the preseed mechanism to
> enable/disable would be helpful.  But would need to be exposed in
> maybe the expert mode menus, which I think was already mentioned.

What Raphaël was proposing is exactly that, yes.

Also, there is absolutely *no* technical difference between "the preseed
mechanism", "a low-priority debconf question", and "something in the
expert mode menus". None. Zero. Zilch.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Easier installer?

[Wouter Verhelst]

On Sun, Nov 19, 2017 at 07:51:24PM +0100, Samuel Thibault wrote:
> Wouter Verhelst, on dim. 19 nov. 2017 19:27:16 +0100, wrote:
> > On Sun, Nov 19, 2017 at 04:31:21PM +0100, Samuel Thibault wrote:
> > > Wouter Verhelst, on dim. 19 nov. 2017 16:12:13 +0100, wrote:
> > > > - That would require that at least part of the functionality that's
> > > >   already implemented in the other udeb (e.g., asking for username etc)
> > > >   be duplicated into the proposed new udeb. That seems like a waste.
> > > 
> > > But the idea was precisely to reshape that question, to make it more
> > > beginner-friendly.
> > 
> > We can reshape questions reglardless of whether we implement the
> > overview screen that I'm talking about.
> 
> I believe there is a misunderstanding: I'm not saying that the existing
> questions should be modified. I'm saying that the way questions should
> be asked in the overview screen that you propose is very different from
> the existing questions (basically they'll be extremely simple). And thus
> it's not a duplication, since they'll be completely different.

Mmm. I'm not sure that's actually true, but that's orthogonal to the
point.

> I agree that implementing the overview screen is a much faster step
> to have something that doesn't frighten beginners away, rather than
> rephrasing our existing questions yet another time. I was really not
> suggesting the latter.

Right.

I'll see if I can find the time to have a stab at trying to come up with
something that would work. We can then decide what to do with the actual
questions that get asked from the overview screen later :-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Easier installer?

[Wouter Verhelst]

On Sun, Nov 19, 2017 at 04:31:21PM +0100, Samuel Thibault wrote:
> Wouter Verhelst, on dim. 19 nov. 2017 16:12:13 +0100, wrote:
> > - That would require that at least part of the functionality that's
> >   already implemented in the other udeb (e.g., asking for username etc)
> >   be duplicated into the proposed new udeb. That seems like a waste.
> 
> But the idea was precisely to reshape that question, to make it more
> beginner-friendly.

We can reshape questions reglardless of whether we implement the
overview screen that I'm talking about. Even if we don't implement the
overview screen, that would still be a step forward IMO. But in my
opinion, the killer feature in anaconda (Fedora's installer) is not the
way they present one particular bit of functionality, but the way in
which they present all their questions in a single screen. That means
having an overview screen, which to me is the higher priority.

If you disagree, I won't stop you from reworking the user creation
questions (there might be some room for improvement there), it's just
that to me we'll take a larger step forward if we implement the overview
screen.

> > - It would necessarily be somewhat limiting
> 
> That's the idea of making a beginner frontend :)

True.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Easier installer?

[Wouter Verhelst]

On Sun, Nov 19, 2017 at 03:15:08PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Wouter Verhelst, on dim. 19 nov. 2017 15:03:03 +0100, wrote:
> > - Selecting a particular option in the overview screen causes the
> >   installer to configure the selected udeb, as though it was selected
> >   from the main menu.
> 
> Mmm, do we really need to actually configure the udeb?  The way I see
> it, the overview screen would merely preseed debconf, and that's it.

That is another option, and I did consider it, but I see a few
downsides:

- That would require that at least part of the functionality that's
  already implemented in the other udeb (e.g., asking for username etc)
  be duplicated into the proposed new udeb. That seems like a waste.
- It would result in two parts that would need to be kept in sync.
- It would necessarily be somewhat limiting

As such, my train of thought was that it would be better to have the bit
that asks questions be shipped with the other udeb. Since that other
udeb will already have an implementation of "asking questions," and
since that implementation is called by configuring the other udeb, that
seems like the most straightforward way to get things rolling.

I do think it might be useful to revisit some of those other udebs in
light of the fact that they would be called from the overview screen,
and optimize them a bit for that, but that doesn't necessarily have to
be part of a first implementation.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Easier installer?

[Wouter Verhelst]

On Thu, Nov 16, 2017 at 01:17:47PM +0100, Samuel Thibault wrote:
> Wouter Verhelst, on jeu. 16 nov. 2017 12:53:16 +0100, wrote:
[...]
> > since, in essence, we'd just be providing an alternate UI to the same
> > installer, people who need some of the more advanced options can ditch
> > the hand-holding UI and switch to the advanced UI. We could add a
> > button "skip this screen" to make that easier, if needs be.
> 
> That actually triggers me another thought: the installers you are
> talking about ask basically the same set of questions, not so much
> less. The main difference is that they are asked together in a dialog
> box. I can understand that this can be less stressing for inexperienced
> users: it's easier to leave things as defaults when it's all preset in a
> dialog box and you just click "ok" than when one has to answer questions
> one after the other, which can be stressing.
> 
> I can understand that *that* can make a difference, and that could be
> implemented indeed, to preseed the rest of questions. The difficult part
> is to make sure that all such questions will be preseeded.

So, I've been thinking about how we could implement something like this
without requiring what in essense would be a rewrite of d-i, and this is
what I came up with:

- Create a new udeb for an overview screen, and make it show up early in
  main-menu so it gets run "fairly early"[1].
- In that overview screen, show the status of the "most important"[1]
  settings. Make these populated by files that are written by the
  particular udebs, similar to how partman populates its main menu.
- Allow those udebs that are shown in the overview screen to also set a
  flag file which causes their option in that screen to be marked as
  "confirmation required". You cannot confirm the overview screen until
  none of its options have the "confirmation required" flag set.
- Selecting a particular option in the overview screen causes the
  installer to configure the selected udeb, as though it was selected
  from the main menu.
- Once the user confirms the overview screen, set the debconf priority
  to critical and quit successfully. The installation is handed over to
  main-menu, which will now run normally without asking any questions
  (unless an error occurs).
- If the user selects the option "skip this screen", do not touch the
  debconf priority and quit successfully. The installation is handed
  over to main-menu, which will now run normally, asking questions as
  before.

[1] what consists "fairly early" and "most important" are
implementational details that can be fine-tuned later on and are not
important for this discussion.

With that plan, the only changes that would be required would be to:

- Implement the required logic behind the overview screen. Much of this
  could be copied from main-menu
- Make sure that the "skip this screen" option can be easily preseeded,
  so that preseeding still works.
- Modify the relevant udebs so they write their status and optionally an
  "update required" flag file in the right location for the overview
  screen

Everything else would function as before. In a first implementation,
this would already be quite some improvement I think.

In addition, I also think it would be beneficial if we were to add
another type of debconf template that could be used by that overview
screen instead of the "select" template that we use now for main-menu
and partman-base, and which would allow for a more modern and shinier
type of user interface. It could also be used by partman, then.

This can be implemented later, however.

Thoughts?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Easier installer?

[Wouter Verhelst]

On Thu, Nov 16, 2017 at 01:17:47PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Wouter Verhelst, on jeu. 16 nov. 2017 12:53:16 +0100, wrote:
> > I can't help but notice that their current installer is extremely easy
> > to use; and that, as compared to ours, it seems like a huge step
> > forwards:
> > 
> > - First screen of the installer allows to select a language
> > - Second screen has three sections: "Localisation" (which has a button
> >   for selecting the keyboard layout, one for language support allowing
> >   to select additional languages, and one for time/date settings),
> >   "Software" (with a button for the installation source and their
> >   equivalent of tasksel), and "System" (which has a button for their
> >   partitioner and one for the network configuration)
> > - The partitioner defaults to "automatic partitioning", but you have to
> >   enter it and confirm it by selecting the proper hard disk (presumably
> >   so you can't accidentally overwrite your data)
> > - Once you make the correct settings in that screen, you click on "Start
> >   installation". The next screen will cause the actual installation to
> >   start (i.e., the installer will partition & format hard disks, start
> >   downloading packages, and install them). It also has two buttons for
> >   user settings (you can enter a root password and/or create a non-root
> >   user).
> > 
> > ... and that's it.
> 
> In Debian, using netinst, we have
> 
> - language
> - country
> - keyboard
> - hostname
> - domain name, which we could arguably make expert-only, I don't
>   remember having to use it.
> - password
> - username
> - timezone, for countries which need it
> - confirmation for automatic partitioning
> - disk selection
> - partitioning layout
> - confirmation
> 
> then the base system gets installed, then
> 
> - prompt for additional CD input
> - mirror selection, perhaps we could just use deb.debian.org by default,
>   I don't know if that works nice enough nowadays.
> - http proxy (yes, one just can't skip it in quite a few places)
> - package installation poll (we do want to ask the question)
> - task selection
> - bootloader installation (we really can not avoid this step, it poses
>   too many problems).
> 
> and that's it.
> 
> That's a bit more items, but not by so much.

Indeed.

In case it wasn't clear, I'm not suggesting we copy the exact same
interface that Fedora uses. Their system has a few differences with
ours, and that's fine.

I was more talking about concepts than about implementation.

[...]
> > Such an installer wouldn't support *every* use case, but that's fine;
> 
> The problem is that some questions really have to be asked, because no
> default can really be sanely set, e.g. username.

Sure.

The same is true in the Fedora installer; they require that you either
enter a root password or create a user. Which you of those options you
choose is up to you though.

We essentially do the same (although some of our options require that
you go to expert mode, which I don't think should be necessary).

My point though, is that if we create an alternate UI for the installer
that asks a bunch of questions in a single step rather than having them
one after the other as we do now, then no doubt we'll find ourselves
unable to implement some functionality in the end. But that's fine; as
long as we make it easier for "most" (for some useful definition of that
word) novice users, and as long as we don't deprecate or remove the full
installer, this will still be a win.

> > since, in essence, we'd just be providing an alternate UI to the same
> > installer, people who need some of the more advanced options can ditch
> > the hand-holding UI and switch to the advanced UI. We could add a
> > button "skip this screen" to make that easier, if needs be.
> 
> That actually triggers me another thought: the installers you are
> talking about ask basically the same set of questions, not so much
> less. The main difference is that they are asked together in a dialog
> box. I can understand that this can be less stressing for inexperienced
> users: it's easier to leave things as defaults when it's all preset in a
> dialog box and you just click "ok" than when one has to answer questions
> one after the other, which can be stressing.
> 
> I can understand that *that* can make a difference, and that could be
> implemented indeed, to preseed the rest of questions. The difficult part
> is to make sure that all such questions will be preseeded.

Right; for the avoidance of doubt, that's exactly what I was suggesting.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Easier installer?

[Wouter Verhelst]

Hi,

At $DAYJOB I'm currently supporting a piece of software for which I
provide binary packages for a number of distributions. As part of that,
I find myself having to install a Fedora or CentOS VM occasionally.

I can't help but notice that their current installer is extremely easy
to use; and that, as compared to ours, it seems like a huge step
forwards:

- First screen of the installer allows to select a language
- Second screen has three sections: "Localisation" (which has a button
  for selecting the keyboard layout, one for language support allowing
  to select additional languages, and one for time/date settings),
  "Software" (with a button for the installation source and their
  equivalent of tasksel), and "System" (which has a button for their
  partitioner and one for the network configuration)
- The partitioner defaults to "automatic partitioning", but you have to
  enter it and confirm it by selecting the proper hard disk (presumably
  so you can't accidentally overwrite your data)
- Once you make the correct settings in that screen, you click on "Start
  installation". The next screen will cause the actual installation to
  start (i.e., the installer will partition & format hard disks, start
  downloading packages, and install them). It also has two buttons for
  user settings (you can enter a root password and/or create a non-root
  user).

... and that's it.

I think that their installer is much easier to use for inexperienced
users than is ours, and that we should take a good look at what they've
done and see if we can make improvements to ours so that it would
support a similar experience. That doesn't have to mean we need to
completely rewrite our installer; e.g., we could write a udeb which asks
the user as many questions as possible without moving on, and then uses
preseeding to preset settings for the current udebs. Such an installer
wouldn't support *every* use case, but that's fine; since, in essence,
we'd just be providing an alternate UI to the same installer, people who
need some of the more advanced options can ditch the hand-holding UI and
switch to the advanced UI. We could add a button "skip this screen" to
make that easier, if needs be.

Thoughts?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#881626: busybox: enable telnetd

[Wouter Verhelst]

On Mon, Nov 13, 2017 at 05:16:26PM +, Luca Boccassi wrote:
> Package: busybox
> Version: 1.27.2-1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainers,
> 
> Please consider enabling telnetd in the busybox package. A tiny and
> trivial patch to set the config is attached inline. A rebuild with that
> change seems to work fine.
> 
> As much as I wish it wasn't the case, telnet is still widely used,
> especially in the ISP/telco world. Telcos networking engineers expect
> to be able to telnet into boxes in their network even today.

As much as I don't mind doing weird things in support of weird use
cases, in this particular case I think that would be sending out the
wrong message. We shouldn't do that, IMO, but rather encourage people to
switch to SSH instead of telnet.

It might make sense to add some documentation that explains why telnet
isn't supported, however.

As an aside, can you tell which telco's we are talking about?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#879686: fails to install on hercules

[Wouter Verhelst]

For the benefit of the s390 porters (whom I should have Cc'd on this
from the very start):

Unless I'm doing something terribly wrong, it appears that stretch (and
later) don't install on the hercules s390 emulator anymore. Anyone have
any clue what's wrong?

On Tue, Oct 24, 2017 at 03:49:48PM +0200, Wouter Verhelst wrote:
> Package: installation-reports
> Severity: important
> Tags: d-i
> 
> 
> 
> -- Package-specific info:
> 
> Boot method: hercules virtual card reader
> Image version: daily build from 2017-10-23
> Date: 
> 
> Machine: Hercules
> Partitions: 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [E]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> Based on the inwstructions at
> http://josefsipek.net/docs/s390-linux/hercules-s390.html (which really
> should find a home on the Debian wiki, but that as an aside) I created a
> file "debian.cnf" with the following contents:
> 
> --
> CPUSERIAL 69# CPU serial number
> CPUMODEL  9672  # CPU model number
> MAINSIZE  1024  # Main storage size in megabytes
> XPNDSIZE  0 # Expanded storage size in megabytes
> CNSLPORT  3270  # TCP port number to which consoles connect
> NUMCPU4 # Number of CPUs
> LOADPARM  0120  # IPL parameter
> OSTAILOR  LINUX # OS tailoring
> PANRATE   SLOW  # Panel refresh rate (SLOW, FAST)
> ARCHMODE  ESAME # Architecture mode ESA/390 or ESAME
> # console
> 001F3270
> # terminal
> 00093215
> # reader
> 000C3505./rdr/kernel.debian ./rdr/parmfile.debian ./rdr/initrd.debian 
> autopad eof
> # printer
> 000E1403./prt/print00e.txt crlf
> # dasd
> 01203390./dasd/3390.LINUX.0120
> # tape
> 05813420
> # network   s390 realbox
> 0A00,0A01  CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1 
>
> --
> 
> Next, I created a file "dasd/3390.LINUX.0120" with the following command:
> 
>   dasdinit -lfs -linux dasd/3390.LINUX.0120 3390-3 LIN120 8000
> 
> Next, I downloaded the "initrd.debian", "kernel.debian", and
> "parmfile.debian" from the most recent successful d-i daily build.
> 
> Finally, I started hercules like so:
> 
>   sudo hercules -f debian.cnf
> 
> and entered the (hercules) command "ipl c".
> 
> When the initrd, kernel, and parmfile are from a jessie install, this
> works. When they are from stretch or later(!) however, it does not. The
> kernel boots, and it seems to be doing a bit of initialization, but then
> it stops at:
> 
> [...]
> 34.263205! Key type asymmetric registered 
>   
>
> 35.059693! ctcm: CTCM driver initialized  
>   
>
> Starting system log daemon: syslogd, klogd.   
>   
>
>  1;24r 4l(B)0 m 1;24r H J 24;1H m 
>   
>
>  1;24r 4l(B)0 m 1;24r H J 24;1H m 
>   
>
> Configure the network device  
>   
>
> 
> After this "Configure the network device", d-i *should* show the
> template for me to select the network device type. It does not, however;
> it just sits at the "Configure the network device" line.
> 
> For comparison, on jessie that looks like this:
> 
> [...]
>  5.108239! ctcm: CTCM driver initialized  
> 

Bug#879686: fails to install on hercules

[Wouter Verhelst]

Package: installation-reports
Severity: important
Tags: d-i



-- Package-specific info:

Boot method: hercules virtual card reader
Image version: daily build from 2017-10-23
Date: 

Machine: Hercules
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [E]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Based on the inwstructions at
http://josefsipek.net/docs/s390-linux/hercules-s390.html (which really
should find a home on the Debian wiki, but that as an aside) I created a
file "debian.cnf" with the following contents:

--
CPUSERIAL 69# CPU serial number
CPUMODEL  9672  # CPU model number
MAINSIZE  1024  # Main storage size in megabytes
XPNDSIZE  0 # Expanded storage size in megabytes
CNSLPORT  3270  # TCP port number to which consoles connect
NUMCPU4 # Number of CPUs
LOADPARM  0120  # IPL parameter
OSTAILOR  LINUX # OS tailoring
PANRATE   SLOW  # Panel refresh rate (SLOW, FAST)
ARCHMODE  ESAME # Architecture mode ESA/390 or ESAME
# console
001F3270
# terminal
00093215
# reader
000C3505./rdr/kernel.debian ./rdr/parmfile.debian ./rdr/initrd.debian 
autopad eof
# printer
000E1403./prt/print00e.txt crlf
# dasd
01203390./dasd/3390.LINUX.0120
# tape
05813420
# network   s390 realbox
0A00,0A01  CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1   
 
--

Next, I created a file "dasd/3390.LINUX.0120" with the following command:

  dasdinit -lfs -linux dasd/3390.LINUX.0120 3390-3 LIN120 8000

Next, I downloaded the "initrd.debian", "kernel.debian", and
"parmfile.debian" from the most recent successful d-i daily build.

Finally, I started hercules like so:

  sudo hercules -f debian.cnf

and entered the (hercules) command "ipl c".

When the initrd, kernel, and parmfile are from a jessie install, this
works. When they are from stretch or later(!) however, it does not. The
kernel boots, and it seems to be doing a bit of initialization, but then
it stops at:

[...]
34.263205! Key type asymmetric registered   
   
35.059693! ctcm: CTCM driver initialized
   
Starting system log daemon: syslogd, klogd. 
   
 1;24r 4l(B)0 m 1;24r H J 24;1H m   
   
 1;24r 4l(B)0 m 1;24r H J 24;1H m   
   
Configure the network device
   

After this "Configure the network device", d-i *should* show the
template for me to select the network device type. It does not, however;
it just sits at the "Configure the network device" line.

For comparison, on jessie that looks like this:

[...]
 5.108239! ctcm: CTCM driver initialized
   
 5.115620! lcs: Loading LCS driver  
   
Starting system log daemon: syslogd, klogd. 
   
 1;24r 4l(B)0 m 1;24r H J 24;1H m   
   

   
Configure the network device
   

   

  

Bug#795735: partman-crypto: always encrypt swap

[Wouter Verhelst]

On Thu, Oct 19, 2017 at 04:37:54PM -0400, Daniel Kahn Gillmor wrote:
> It's a shame that encrypted swap by default hasn't happened yet for
> debian.

[...]
> actual hardware performance
> ---
> 
> I suspect the cost is negligible on most hardware today, particularly
> when compared to the disk I/O.  If you're swapping, you're likely to be
> waiting for the disk, not waiting for the CPU.  That said, i agree that
> users with specialized situations ought to be able to disable this.  But
> the default should still be on.

For clarity, when I stated that, I wasn't using it as an argument
against enabling encryption of the swap partition by default; it's just
that saying "there is no performance impact when doing something extra"
is objectively wrong. The performance impact may be negligable; but when
you need to do more work, you need to actually do it and there will be
an impact. It will not matter in the common case, but there will be
exceptions where it will matter, and therefore we need to continue
supporting that.

Pet peeves, I suppose.

> suspend-to-disk
> ---
> 
> If the user suspends to disk, then the memory will be written to disk.
> this is definitely a leak.  However, we currently write the memory to
> disk *without* suspending to disk, so even if we don't handle
> suspend-to-disk "safely" it's still a win to encrypt swap, because we
> protect the people who do *not* suspend to disk.  So that's the simplest
> solution to the suspend-to-disk problem: just punt on it for now, and
> leave that case unprotected.
> 
> If suspend-to-disk (or rather, resume-from-disk) is the only problem,
> then we should look for ways to opportunistically take advantage of
> other non-disk hardware on which we could store any ephemeral keys
> needed for restoration.
> 
> For example, on systems with rewritable nvram, it's conceivable that we
> could suspend to the encrypted volume, and then stash the ephemeral
> encryption key in nvram.  Upon resume, read the key from nvram into main
> memory, clear the nvram, and restore from the encrypted volume.  This
> isn't perfectly secure (an attacker with both the disk and the nvram can
> recover your memory from the suspend file) but it is a significant win
> against an attacker who physically removes the hard disk.
> 
> 
> 
> So i think we ought to outline the steps that need to be taken to make
> this happen by default.  Which pieces need to be updated, and how?

The initramfs code that does the actual resume should be updated to read
the key from wherever it was written.

On systems that don't have writable nvram, we could still support both
encrypted swap and suspend-to-disk provided the system has an
alternative location to write that session's encryption key to (which
I'll inaccurately call "the session key" for now -- it's not really a
session key, but it's close enough).

If the kernel needs to read the session key, then it can't be on a
partition that needs to be live. The initramfs would need to mount that
partition to be able to see whether there is a session key that needs to
be used to do the resume-from-disk, which would cause a journal replay;
that would invalidate the suspended image. What we could do, however, is
if the user has a separate /boot partition, to make the "suspend" script
write the session key to a well-known file in that partition, and then,
just before actually doing the suspend, *unmounting* the /boot
partition. The resume code in the initramfs could then mount the /boot
partition and figure out if there is a session key; if there is, it
would read the key, unmount the partition again, and then proceed to
decrypt the swap partition and resume the system.

If a user installs a system with encrypted swap but no separate /boot
partition, the suspend-to-disk code could/should then produce an error
message to the effect that the user needs to either disable encrypted
swap, or create a separate /boot partition. If partman is then also
updated to default to having a separate /boot partition, we would be
able to support encrypted swap as well as suspend-to-disk virtually
anywhere.

On a side node, if the system has a TPM that is not disabled, we should
also attempt to encrypt the session key (regardless of where it is
stored) using the TPM. That way, an attacker who gains access of the
hard disk and the (encrypted) session key but not the system itself
cannot decrypt the swap partition, since a TPM is supposed to not allow
keys to be removed from it.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#872867: is ISO-3166 really the optimal list for our users?

[Wouter Verhelst]

On Thu, Aug 24, 2017 at 06:46:15PM +0200, Daniel Pocock wrote:
> 
> 
> On 24/08/17 18:02, Wouter Verhelst wrote:
> 
> > Case in point: why would Kosovo *need* to be on the d-i list of
> > countries? Is there a difference between Kosovo and Serbia[1] or other
> > countries in the former Yugoslavia that d-i would need to be aware of
> > (such as locale settings, keyboard layout, time zone, or preferred
> > mirror), or is this bug in fact just the result of people with a
> > background of Kosovan nationalist ideology complaining about it to
> > you[2]? So far I've only seen you argue that "Kosovo needs to be on the
> 
> 
> Another consideration is the uncertainty:  for many ordinary users (not
> necessarily people with strong political opinions) it is simply not
> clear what the technical consequences will be if they select RS or AL
> from the list.  Simply abolishing the list and asking people to manually
> select a timezone may be one way to eliminate this uncertainty.
> 
> About 50% of the population is under 30[1] - many of them presumably
> have no memory of being a Serbian or Yugoslavian, they have simply been
> brought up as Kosovans.  This is also the age group where people are
> likely to try free software.  I haven't observed any Kosovan taking up
> arms when they see the country list, rather, it is more sadness,
> disappointment and frustration.

This (and the explanation in your other email) are both good reasons why
adding Kosovo to the list of places is a good idea, and again, I'm not
opposed to that. I'm simply wary of setting a precedent in what is
intrinsically a very sensitive subject.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#872867: is ISO-3166 really the optimal list for our users?

[Wouter Verhelst]

On Thu, Aug 24, 2017 at 09:05:22AM +0200, Daniel Pocock wrote:
> 
> 
> On 24/08/17 08:51, Wouter Verhelst wrote:
> 
> > In the case of XYZ, "use a different distribution" isn't going to
> > silence such people. Instead, they'll just yell harder. "Debian's making
> > a political statement about XYZ, and it's wrong, and I told them that
> > it's wrong, and they're ignoring me!"
> >
> 
> Including and excluding are different things
> 
> Including extra "countries" may cause offense to people with certain
> political sensitivities, but doesn't cause any technical problem for
> people in other countries.

That may be true, but even so, those sensitivities are a hornet's nest
that we really don't want to be involved in.

> So if Debian has a policy that we favour inclusion over exclusion and
> that any country can be listed if at least one DD visits there and
> confirms it exists, is that political or would that be a policy that can
> be defended?

All disputed territories *exist*, and there will almost always be a
government that de facto rules the territory, that's not the point.
Whether a region is a country, however, is not something that Debian
Developers are expected to be able to ascertain.

I don't think that's a policy that can be defended.

> I wonder how long it would be before somebody proposed California or
> Scotland?  If they entered the list at the same time as Kosovo (and Hutt
> River) then it becomes a lot less political and the focus is not on a
> single region.

You're making the mistake of assuming that people who get upset over a
list of countries will check the whole list rather than just the bit
they care about...

Case in point: why would Kosovo *need* to be on the d-i list of
countries? Is there a difference between Kosovo and Serbia[1] or other
countries in the former Yugoslavia that d-i would need to be aware of
(such as locale settings, keyboard layout, time zone, or preferred
mirror), or is this bug in fact just the result of people with a
background of Kosovan nationalist ideology complaining about it to
you[2]? So far I've only seen you argue that "Kosovo needs to be on the
list that d-i presents," but I have not seen any technical arguments for
which that would in fact be necessary.

Put otherwise, is this request in fact a request about technical
matters, or is it instead a request about a political matter?

[1] In case that wasn't clear: Serbia is the country that Kosovo
declared independence from in 2008.
[2] For clarity, I'm not saying they're right, and I'm not saying
they're wrong. I'm not opposed to including Kosovo, even if it is
technically not necessary, provided that it can be done in a
politically neutral way.

> > Whatever solution you[1] come up with should avoid that.
> > 
> > [1] I'm assuming you're planning on submitting a patch, since you
> > suggested this change in the first place...
> > 
> 
> I would not want to waste time coding something before we have some
> consensus about what the community is comfortable with.

Sure, fair enough.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#872867: is ISO-3166 really the optimal list for our users?

[Wouter Verhelst]

On Wed, Aug 23, 2017 at 07:54:44PM +0200, Daniel Pocock wrote:
> 
> 
> On 23/08/17 19:22, Wouter Verhelst wrote:
> > On Tue, Aug 22, 2017 at 11:02:27AM +0200, Daniel Pocock wrote:
> >> While it is good that we use material from official sources, Debian is
> >> independent of any state and may not need to feel constrained by such 
> >> lists/
> >> standards in the same way that a commercial software vendor might be.
> > 
> > On the other hand, the advantage of having an official standard to point
> > to is that we can deflect complaints when they appear.
> > 
> > There are many areas in dispute in this world, and in some cases
> > deciding whether a particular area is or is not a country will result in
> > offending one or the other party. When Debian accidentally and
> 
> We should be respectful of all users, but I don't think fear of causing
> offence should be the primary concern.  Otherwise we never would have
> moved to systemd.

There is a difference.

Random people will not go complaining in the street because Debian moved
to systemd.

Random people *will* go complaining in the street about issues of
statehood:
https://www.nytimes.com/2017/06/11/us/puerto-ricans-vote-on-the-question-of-statehood.html

[...]
> > temporarily updated the representation of the countries in the installer
> > so that they would refer to the area sometimes referred to as the
> > "Republic of China", otherwise known as "Taiwan", in a particular way,
> > this offended one of our developers enough that he decided to leave the
> > project.
> > 
> 
> If a developer puts his political opinions against the needs of users in
>  a particular region, then is it possible that developer is failing to
> respect the Debian Social Contract and may not be eligible to be a
> developer?

I don't think this is a sensible argument. This is not about the social
contract; I was merely trying to point out that whether something is or
is not a country is a very sensitive subject. An equally (in)valid
argument could be that by resigning, this developer was in fact
protecting the interests of users who disagree that region XYZ should be
considered a country.

[...]
> > While it may be true that the list of countries in ISO-3166 is decided
> > upon by a small number of people, presumably these people are aware of
> > all the peculiarities and policital sensitivies in deciding what is or
> > isn't a country, and what should or should not be allowed in a list of
> > countries. As such, deciding to use ISO-3166 as our base to decide on
> > which countries to list keeps Debian politically neutral in an area for
> > which we really have no expertise and in which we really should not get
> > ourselves involved one way or the other.
> > 
> 
> I agree Debian should not get into the political side of this debate.

Good :-)

> This bug is only for the technical side...
> 
> > It may make sense to change the list of places so that it also includes
> > subdivisions, provided we do so in either a way which makes the
> > distinction between "country" and "subdivision" clear, or a way which
> > puts both in a singular list but which makes it clear that the list does
> > not refer to countries in any form or sort. Both solutions would allow
> > areas such as Kosovo to appear on the list of places, without offending
> > people who believe Kosovo should not be considered an independent nation
> > (yes, there are such people).
> > 
> 
> If that means a user in Kosovo is more likely to configure their system
> correctly, then it is a good technical solution, similar to what I
> described (leaving out the country codes for such regions and helping
> them choose alternatives).
> 
> We could also have a disclaimer, "Not all entries in this list are
> officially recognized as countries, some are disputed territories that
> have been included for the purpose of helping users in those regions get
> the optimal configuration."

That could also work, I suppose.

> More concise: "Select the entry from this list of regions and countries
> that most closely matches your geographic location"

I think that's a bit more risky.

> > We should not, however, move away from ISO-3166 as our basis for
> > deciding what is or isn't a country, unless you can point to another
> > list which has the same level of international recognition as ISO-3166.
> > I don't think such a list exists, however.
> > 
> > If we continue to use the ISO-3611 list, then if any error in the list
> > of countries in our installer exists it will either be a bug in the
> > installer code (which w

Bug#872867: is ISO-3166 really the optimal list for our users?

[Wouter Verhelst]

On Tue, Aug 22, 2017 at 11:02:27AM +0200, Daniel Pocock wrote:
> While it is good that we use material from official sources, Debian is
> independent of any state and may not need to feel constrained by such lists/
> standards in the same way that a commercial software vendor might be.

On the other hand, the advantage of having an official standard to point
to is that we can deflect complaints when they appear.

There are many areas in dispute in this world, and in some cases
deciding whether a particular area is or is not a country will result in
offending one or the other party. When Debian accidentally and
temporarily updated the representation of the countries in the installer
so that they would refer to the area sometimes referred to as the
"Republic of China", otherwise known as "Taiwan", in a particular way,
this offended one of our developers enough that he decided to leave the
project.

While it may be true that the list of countries in ISO-3166 is decided
upon by a small number of people, presumably these people are aware of
all the peculiarities and policital sensitivies in deciding what is or
isn't a country, and what should or should not be allowed in a list of
countries. As such, deciding to use ISO-3166 as our base to decide on
which countries to list keeps Debian politically neutral in an area for
which we really have no expertise and in which we really should not get
ourselves involved one way or the other.

It may make sense to change the list of places so that it also includes
subdivisions, provided we do so in either a way which makes the
distinction between "country" and "subdivision" clear, or a way which
puts both in a singular list but which makes it clear that the list does
not refer to countries in any form or sort. Both solutions would allow
areas such as Kosovo to appear on the list of places, without offending
people who believe Kosovo should not be considered an independent nation
(yes, there are such people).

We should not, however, move away from ISO-3166 as our basis for
deciding what is or isn't a country, unless you can point to another
list which has the same level of international recognition as ISO-3166.
I don't think such a list exists, however.

If we continue to use the ISO-3611 list, then if any error in the list
of countries in our installer exists it will either be a bug in the
installer code (which we could obviously fix and apologise for,
hopefully without offending anyone), or a matter of "the list is
outdated" (which we would usually fix by rebuilding the installer,
hopefully also without offending anyone), or an error in the ISO-3611
list (in which case people might be offended, but the offending elements
would not be ours and we can tell them to get ISO to update the list
rather than to complain to us).

Debian is about Free Software; it is not about International Politics.
Let's keep it that way.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: debian 9 installation problem

[Wouter Verhelst]

Hi Matthew,

For these kinds of questions, please ask on the debian-user mailinglist.
The -boot list is meant for development of the installer, not for
support with the full installation images (which contain more than just
the installer). In contrast, the -user list is meant for user support.

Regards,

On Wed, Aug 23, 2017 at 10:25:43AM +0100, Matthew Bruton wrote:
> Hi,
> I am tring to install debian 9 using the offline DVDS, which is the most
> convenient for me. The menu comes up but none of the options work. It
> just pauses for a few seconds with none of the keys working and then
> comes back to life.
> 
> When I go into the command prompt through the help menu (the only option
> which works) and try to enter the options there, it says "invalide
> argument", for each one I try.
> 
> I have a dell latitude laptop.
> 
> Please help!
> 
> Thanks,
> God bless,
> Matthew Bruton
> 
> 

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: RFC: Switching guided partitioning to LVM by default?

[Wouter Verhelst]

On Sat, Aug 05, 2017 at 04:06:49PM -0400, Cyril Brulebois wrote:
> Is anyone aware of any drawbacks of switching to LVM by default?

- It makes sharing the disk with other operating systems harder: partman
  requires that the LVM PVs are committed to disk before you can play
  around with LVs, and since "use the whole disk" creates a single
  whole-disk partition for the LVM PV, there will be no space left for
  the other operating system if that does not support Linux's LVM.

  A user who would wish to create a partition for an alternate operating
  system after going through the LVM step would have to destroy all LVM
  LVs, destroy the VG, destroy the PVs, change the size of the
  partition, and then recreate everyhing again.
- Last I checked (but this may have been changed), the LVM VG created by
  the partitioner is given a default name, which confuses the kernel if
  you place a disk containing another LVM VG with that same name in the
  same machine. This makes recovering a system by placing its disk into
  a different machine needlessly complicated.
- While LVM is indeed more flexible than plain partitions, it does add
  some overhead in terms of metadata, which is not necessarily useful if
  the user is only interested in installing to a single hard disk.

All in all, I'm not convinced that switching this default will be a net
plus for our users.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#868869: debian-installer should not recommend to change password periodically (and more)

[Wouter Verhelst]

On Tue, Jul 25, 2017 at 11:14:42PM +0100, Brian Potkin wrote:
> It is a nice debating point but I am inclined to go along with this
> assessment when it comes to the installer. Nobody takes any notice
> of the advice anyway and there are far more important things to
> attend to.

I'm not sure that's true. Bad advice in an installer is not a good idea.

I've always been unhappy about having it there, and as that previous
bugreport shows, so were you.

In addition, if we're going to change this recommendation, then now (at
the beginning of a new release cycle) is the best time for doing so.

I'd be inclined to agree it should be removed, but I'd be happy to
follow the consensus here.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#868869: debian-installer should not recommend to change password periodically (and more)

[Wouter Verhelst]

On Tue, Jul 25, 2017 at 11:22:19PM +0200, Philipp Kern wrote:
> On 07/24/2017 12:38 PM, Hideki Yamane wrote:
> >  But it also makes administrator to remember it harder as its trade-off...
> >  (and they maybe choose easy password as a result). It's a not good idea
> >  to suggests to change root password periodically, IMO. It's not a best
> >  practice.
> 
> I'd say it's one of two things: If it's easy, make sure to change it
> periodically. If it's hard enough to withstand brute-force, you don't
> need to.

The problem with regular-change policies is that it *encourages* easy
passwords, since if you want to remember something generated by "pwgen
-s 15" or some such, it will take you quite a while to do so, and by
that time it may be time to renew it again.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Bug#861263: debian-installer: zfs support

[Wouter Verhelst]

On Sat, May 06, 2017 at 03:35:52PM +0100, Sam Kuper wrote:
> On 06/05/2017, Ian Campbell  wrote:
> > It would in theory be possible to arrange build and install modules
> > during installation using the in-progress target installation (where
> > the normal toolchain packages could be installed) such that they are
> > available during the latter parts of the install procedure -- that is
> > clearly of limited use for any modules which are required for the
> > filesystems which you want to install to (certainly the root fs and
> > perhaps any separate /usr or /var partition(s)).
> 
> Given that a machine intended to run ZFS is likely to be provisioned
> with >2GB of RAM (much more than the Debian Installer would normally
> require), might a viable workaround be for the Debian Installer to
> take the following steps?
> 
> - Ensure that some minimum amount of RAM is available, and refuse to
> proceed with a root-on-ZFS installation if not;
> 
> - install the toolchain, ZFS source, and any other packages from
> "main" or "contrib" necessary to support these, to a RAM disk;
> 
> - compile and load ZFS functionality;
> 
> - format the target HDD/SSD using ZFS;
> 
> - copy the toolchain binaries and ZFS source packages, etc, to the
> relevant places on the target HDD/SSD (/usr/bin ,
> /var/cache/apt/archives/ , etc);
>
> - resume the installation as usual.

I don't see why not. We already need the ability to run debootstrap;
this would just change that to a need to do so twice.

It wouldn't be terribly efficient for a netinstall, since it requires
that you download the base system twice; but it could imagine a special
"non-free netinstall" image which would contain zfs-dkms and its
dependencies on top of the base system, so that you don't need to
download things more than once.

I don't know whether anyone on this list would be actually interested in
adding the necessary support to d-i, but hey, if you are, I'm sure
patches are welcome. As a side note, I'll add that there is already a
partman-zfs, due to Debian-kFreeBSD; this should mean that you'd only
need to extend that to also do the compilation at first.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#860368: installer: create network bridges by default?

[Wouter Verhelst]

On Sat, Apr 15, 2017 at 01:32:59PM +0200, Daniel Pocock wrote:
> On 15/04/17 13:27, Wouter Verhelst wrote:
> > On Sat, Apr 15, 2017 at 01:18:52PM +0200, Daniel Pocock wrote:
> >> As you describe, the default network is an extra layer of NAT.  It
> >> works, but not everybody wants that.
> > 
> > So those who don't want it can fix their bloody configuration.
> > 
> > Are you honestly suggesting that we should create unnecessary fluff for
> > all our users just because NAT doesn't work for a small minority of our
> > users?
> > 
> 
> There are separate questions about
>   (a) whether it can be an option (not default), or

There are many many many pieces of software in Debian which work better
or allow you to do more if you change some system-wide configuration.
For instance, Samba will work better as a server if you install and
enable nss_winbind; and there are a number of web applications which
work better if you enable particular apache modules.

If we were to add options for all of those things in the installer, then
we'd end up with an installer you couldn't use anymore.

>   (b) whether it would be a useful default

I don't think so.

> > It's always possible to create a bridge manually, there's no need to do
> > that from the installer; and NAT works out of the box (virt-manager will
> > even suggest you enable the default network if you try to use it and it
> > hasn't been enabled yet).
> 
> It isn't so hard to do manually, but every person who wants this needs
> to go and find out the necessary changes and edit /etc/network/interfaces

Yes, that's how it works, generally.

If you want to make that easier, nobody's stopping you from documenting
it, or submitting a patch to virt-manager to help with making the
necessary changes. But the installer isn't involved with
virtualisation, and therefore I think it doesn't make sense to make
those changes there.

> There is also the inconvenience factor: people have to bounce their
> interface or reboot when making a change like that.  If the bridge is
> already there we save them that inconvenience too.

This ignores the inconvenience factor for everyone who ends up with a
broken system because you added configuration which they don't need and
which conflicts with the things that they do need.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#860368: installer: create network bridges by default?

[Wouter Verhelst]

On Sat, Apr 15, 2017 at 01:18:52PM +0200, Daniel Pocock wrote:
> As you describe, the default network is an extra layer of NAT.  It
> works, but not everybody wants that.

So those who don't want it can fix their bloody configuration.

Are you honestly suggesting that we should create unnecessary fluff for
all our users just because NAT doesn't work for a small minority of our
users?

It's always possible to create a bridge manually, there's no need to do
that from the installer; and NAT works out of the box (virt-manager will
even suggest you enable the default network if you try to use it and it
hasn't been enabled yet).

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#860368: installer: create network bridges by default?

[Wouter Verhelst]

On Sat, Apr 15, 2017 at 10:50:30AM +0200, Daniel Pocock wrote:
> With libvirt, that is possible using macvtap but it is unreliable and
> doesn't allow[3] communication between the guest and the host, only
> between the guest and other hosts on the subnet.
> 
> The solution is for people to configure a bridge or Open vSwitch (OVS)
> in /etc/network/interfaces.

Actually, you can just tell virt-manager to use the "default" network,
which is configured correctly. However, it does not come enabled out of
the box; to fix, you can do one of two things; either run "virsh
net-autostart default; virsh net-start default", or use the virt-manager
UI to do the same (under Edit->Connection details->Virtual networks)

This uses NAT, and creates a virtual NIC, which therefore requires root
access; but it works nicely IME.

> (Notice OVS can be configured[4] in the interfaces file).  Maybe it would be
> useful to offer one or both of these options at install time, or even
> configure a standard (non-OVS) bridge by default in case the user decides to
> try KVM in future?
> 
> Are there other use cases apart from KVM that would benefit from this?

Very few.

> Are there things that would break badly if Debian offered this in future?

if you happen to be in an enviroment where there are conflicting network
configurations active, things will break badly.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Re: HTTPS metadata in Mirrors.masterlist?

[Wouter Verhelst]

On Fri, Apr 07, 2017 at 12:25:04AM +0200, Kurt Roeckx wrote:
> On Thu, Apr 06, 2017 at 11:20:36PM +0200, Axel Beckert wrote:
> > * https://mirror.as35701.net/debian/ (not yet accessible as
> >   https://ftp.be.debian.org/debian/ due to certificate only being
> >   valid for mirror.as35701.net)
> 
> It's easy enough to also add ftp.be.debian.org to the certificate,
> but I didn't do it because I don't feel like I have permission to
> do so.

Why would that be the case? You run a service under ftp.be.d.o, and you
can verify that it is indeed you.

Perhaps this should be clarified on a mirror-admin level?

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#749991: Wrong kernel in debian-installer package

[Wouter Verhelst]

On Thu, Apr 06, 2017 at 10:01:41AM +0700, Alexander Sosedkin wrote:
> On Thu, 6 Apr 2017 00:05:17 +0200
> Cyril Brulebois  wrote:
> 
> > That's unfortunate, yes, but there's no easy way to keep old packages
> > around in a given repository.
> 
> That's one way to think about it. Got it, keeping old modules is hard.
> But I wasn't asking about keeping old modules, I see no point in this.
> I was asking about generating and publishing a matching
> dists/testing/main/installer-/current on kernel upload.
> Why is _that_ hard?
> 
> I'm asking less of "why isn't it equal to
> https://d-i.debian.org/daily-images tree",
> and more of "why not d-i stretch rc 2 rebuilt with new kernel".
> And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749991#59
> doesn't quite cut it. Triggering is hard? Maybe, why not cron then?

We actually do cron. That's what daily-images is.

What's in the repository, however, is a whole different beast, and
"cron" is so far away from the solution that it's not funny.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#815155: Detects impossible situation as bootable option

[Wouter Verhelst]

Package: os-prober
Version: 1.71
Severity: normal

Hi,

I have a backup of the Windows installation of an old laptop on an LVM
volume on a USB disk. This backup was taken by doing something along the
lines of "dd if= of=". Obviously this can
never boot; Windows doesn't support LVM.

However, when I have the USB disk in question connected to my laptop
when I perform a kernel update, os-prober detects that Windows
installation, resulting in a boot option for that Windows installation,
which obviously cannot work.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages os-prober depends on:
ii  libc6  2.21-9

os-prober recommends no packages.

os-prober suggests no packages.

-- debconf information excluded

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "nl_BE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Re: UEFI support for mini.iso?

[Wouter Verhelst]

On Fri, Feb 12, 2016 at 09:21:31AM +0100, Thomas Schmitt wrote:
> Hi,
> 
> Wouter Verhelst wrote:
> > http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/geniso_hybrid_plus_firmware_partition
> > I add a line isohybrid -u "$iso"
> 
> This last isohybrid run replaces the partition which was crafted
> by the fdisk run.
> 
> This is also the reason why fdisk does not succeed with the result of
> isohybrid -u. Partition 2 cannot be created because ist already exists.

Right, that explains -- thank you.

> If the script would contain the ISO production run, then i would
> propose xorrisofs options like -isohybrid-gpt-basdat and
> -append_partition which would make runs isohybrid and fdisk unneeded.
> 
> 
> But since there is only the partition maker to see, i propose to just
> change partition number 2 to 3 in the fdisk run and to let it happen
> after the isohybrid -u run.
> 
> I tested this with a result of isohybrid -u named mini-test.iso:
> 
> - Because isohybrid -u expanded partition 1 to the end of the image
>   file, i had to add once again bytes for the "Firmware Partition"
>   like the script does in line 37 by
>  cat "$firmware_volume_file" >> "$iso"
>   My command was
>  dd if=/dev/zero count=12288 >>mini-test.iso
> 
>   This waste is not necessary if the isohybrid -u run happens before
>   the cat "$firmware_volume_file" >> "$iso" run.

Right. Since it seems like a bit much of a waste, I've done the latter.

> - Then i ran /sbin/fdisk with nearly the same input as in the script
>   but with partition number 3 instead of 2:
> # Make new partition #3
> echo n
> echo p
> echo 3
> echo # use default start sector
> 
> # Pedantically, set partition type to 1: FAT 16
> echo t
> echo 3
> echo 1
> 
> # Done!
> echo w
> 
> /sbin/fdisk -lu reports about the result:
> 
>   Device Boot Start   End Sectors  Size Id Type
>   mini-test.iso1 *0 63487   63488   31M  0 Empty
>   mini-test.iso2240  1071 832  416K ef EFI (FAT-12/16/32)
>   mini-test.iso3  63488 75775   122886M  1 FAT12
> 
> This boots by
> 
>   qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -hda 
> mini-test.iso

As well as the three other cases.

Thanks again!

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: UEFI support for mini.iso?

[Wouter Verhelst]

On Thu, Feb 11, 2016 at 09:42:19AM +0100, Thomas Schmitt wrote:
> Hi,
> 
> Wouter Verhelst wrote:
> > This image however does not support booting on a UEFI-only system.
> 
> It does support EFI booting from CDROM. At least with qemu and OVMF
> as EFI firmware.

Right. I haven't written a CDROM image in ages, though :-)

> > Is there anyone with the required knowledge who would be willing to
> > look into fixing that?
> 
> I downloaded
>   
> http://ftp.debian.org/debian/dists/sid/main/installer-amd64/current/images/netboot/mini.iso
> 
> which bears this boot equipment:
>   El Torito catalog  : 59  1
>   El Torito cat path : /boot.cat
>   El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz LBA
>   El Torito boot img :   1  BIOS  y   none  0x  0x00  4 268
>   El Torito boot img :   2  UEFI  y   none  0x  0x00832  60
>   El Torito img path :   1  /isolinux.bin
>   El Torito img opts :   1  boot-info-table isohybrid-suitable
>   El Torito img path :   2  /boot/grub/efi.img
> 
>   MBR partition table:   N Status  TypeStart   Blocks
>   MBR partition  :   1   0x80  0x17051200
>   MBR partition  :   2   0x00  0x015120012288
> 
> I.e. it has an EFI boot image for booting from CD, but no partition
> of MBR type 0xef which would point to that image file /boot/grub/efi.img.

Which is the problem I was trying to deal with.

> So expectably it boots by
> 
>   qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -cdrom 
> mini.iso
> 
> and does not boot by
> 
>   qemu-system-x86_64 -enable-kvm -m 512 -bios /usr/share/ovmf/OVMF.fd -hda 
> mini.iso
> 
> 
> One could use xorriso to repack the ISO and apply options which would
> cause production of partition tables.
> But in this case we have the classical situation for SYSLINUX program
> "isohybrid". (We even have the repaired version in Sid, which does
> not write random chinese GPT partition names.)
> 
>   isohybrid -u mini.iso

It turns out isohybrid is already being called, except not with the -u option:

wouter@gangtai:~/debian/debian-installer/installer/build$ grep ^isohybrid 
util/geniso_hybrid_plus_firmware_partition 
isohybrid -h "$heads" -s "$sectors" "$iso"

If I change that to add the -u option, things fail miserably later on in
the script; it tries to run fdisk on the ISO file, but that no longer
works because the -u option changes things around a fair bit.

However, if I add a line

isohybrid -u "$iso"

at the end of the script, it seems to work; I've successfully booted the
result of that on qemu in all four use cases (EFI vs not EFI, CDROM vs
hd image).

I've committed that for now, but if you have the time to look at that
script
(http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/geniso_hybrid_plus_firmware_partition),
that might be good.

Thanks for you help,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

UEFI support for mini.iso?

[Wouter Verhelst]

Hi folks,

The "netboot" target of the debian-installer build system builds the
PXE-booting files for the installer, as well as a 30-40MB "mini.iso"
image that contains just the kernel and initramfs for the installer to
boot. This makes it smaller than the netinst, which makes it my personal
favourite of booting a Debian system; but its reliance on being in
sync with the mirror archive network (if the kernel is updated,
you need to also update the iso images, otherwise it won't be able to
find matching kernel modules) makes it probably not a good choice for
the general public.

This image however does not support booting on a UEFI-only system. I
would look at fixing that myself, except that my understanding of UEFI
is extremely limited.

Is there anyone with the required knowledge who would be willing to
look into fixing that?

If not, where can I read up on how the current CD images generate UEFI
boot configuration, so I can copy the relevant bits to the mini.iso
image?

Thanks,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: cdimage?? What should we call it?

[Wouter Verhelst]

Hi,

On Fri, Aug 21, 2015 at 07:20:53AM +0200, Hideki Yamane wrote:
 On Thu, 20 Aug 2015 22:40:32 -0300
 Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote:
  And having get.debian.org as canonical maybe? But indeed I like the idea.
 
  Not only canonical but also gentoo does. 
  https://get.gentoo.org redirects https://www.gentoo.org/downloads/ 
  (and I like their newer website design...)

I think Lisandro meant the canonical location, as in, the normal name
that you'd use, with the others being merely aliases for it, not the
name that canonical (the company) uses.

But yeah, that would work too :-)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#795735: partman-crypto: always encrypt swap

[Wouter Verhelst]

On Sun, Aug 16, 2015 at 03:55:24PM +0200, Lars Wirzenius wrote:
 Could we enable encryption of swap by default, even when full disk
 encryption is not used? As far as I undrestand, there is no
 performance issue for this for most hardware made in the past
 half-decade.

This is obviously wrong. The performance cost may be low to the effect
that it is negligible on recent hardware, but it is not zero; even if
you run it on custom crypto hardware that wouldn't otherwise be used
except for crypto operation, that would make that hardware unavailable
(or at the very least, less available) for other crypto operations.

 Swap encryption also doesn't require the user to enter a
 password: it can be generated on the fly for each boot.

This also makes it impossible to use suspend-to-disk, as that uses the
swap partition to write the state of the current RAM, which needs to be
reread at boot time; if you encrypt the swap partition with a random
key, you can't read it at the next boot, so you've removed the ability
to use that feature.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#788634: debian-installer: Accepting a preseed URL from DHCP allows attacker to hijack installation

[Wouter Verhelst]

On Mon, Jun 22, 2015 at 10:03:52PM +0200, Geert Stappers wrote:
  +Template: preseed/accept_preseed_from_DHCP
  +Default: false
  +_Description: Accept a preseed URL from the DHCP server?
 
  :-(
 
 We have allready 'auto-install/enable'  ( 'auto' for short )

Which does not serve the same purpose.

auto-install/enable reorders some questions (including about networking)
so that you can put more information in the preseed URL and less
information in the command line preseed keys which you need to pass
along with auto-install/enable.

This is about enabling preseeding in the first place.

If you're going to use auto-install, you're most likely also going to
provide a preseed URL, so then having an unexpected preseed URL in DHCP
is fishy.

If you *are* going to provide the preseed URL via DHCP, then it's
perfectly possible to preseed the accept preseed from dhcp option on
the kernel command line.

However, I would personally feel more comfortable about this if it were
bypassed when the system has booted from PXE. As said before, in that
case you're already implicitly trusting your DHCP server, so it makes no
sense asking for it anymore.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150704073120.ga15...@grep.be

Re: Bug#788634: debian-installer: Accepting a preseed URL from DHCP allows attacker to hijack installation

[Wouter Verhelst]

On Sun, Jun 14, 2015 at 04:48:20PM +0200, Geert Stappers wrote:
 control: tag -1 mordac
  I don't think handwaving and tagging wontfix is the right play here.
  
 
 Now tagging with 'mordac'. For those new to Mordac, get a
 first impression at http://dilbert.com/strip/2007-11-16
 And http://dilbert.com/search_results?terms=Mordac for a complete overview
 of Mordac, the preventer of information services.
 
 
 
 In other words:
 
 How to cope with nonsense like security is more important than usability?

It's not nonsense.

Yes, if you boot off PXE, then it's fine if the network contains
preseeding data. After all, you booted off PXE, so either your network
is fine (and nothing to worry about) or it isn't (and then using a
preseeding file off the network isn't going to make matters much worse,
since you've already *booted* untrusted code).

But if you boot off CD-ROM or USB or some such? Then the situation is
much different. While I agree that having preseeding in that case can be
useful, I can also understand the POV that the system *defaulting* to
using such a preseed file is a bad idea.

Let's say you buy a new laptop, take it out of the packaging while on
the train home, pop in a USB stick with d-i on it, and boot. Somewhere
on the way home, your train waits in a train station for a few minutes,
during which time it picks up the wireless connection and does DHCP
there. Should it trust any preseeding data that it got from that
connection?

I don't think so, but currently this *does* happen.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150616093756.gb30...@grep.be

Bug#784148: base-installer: NTP daemon should be installed on any system missing an RTC

[Wouter Verhelst]

On Sun, May 03, 2015 at 06:55:51PM +0200, Geert Stappers wrote:
 embedded systems, cheap embedded systems that have no real time clock,
 those are the ones that I expect to be without network connection.
 Example given: stand-alone mediaplayers.

Isn't it possible to configure systemd so that it only starts certain
daemons if there's network? Having an NTP daemon installed on such
networks, and configured so that it does that, would alleviate that
concern.

(That would not fix the issue for non-systemd installs, but that
shouldn't be too much of a problem)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150516071646.ga22...@grep.be

Bug#783264: Bug#783247: Please don't install acpid and acpi-support-base

[Wouter Verhelst]

On Tue, Apr 28, 2015 at 11:34:36PM +0200, Marco d'Itri wrote:
 On Apr 28, Wouter Verhelst wou...@debian.org wrote:
 
  - Acpi is a useful command-line tool to easily read values of things
 So basically you are saying that it is common use case is laptops with 
 no good management GUI.

No. I am saying that it is a good *baseline* tool, which does not do
much harm in terms of disk space usage[1], and that I therefore don't
see why you want to throw it out.

 This is not enough to make it a candidate for magic installation by 
 hw-detect, but maybe you can persuade the task-laptop maintainer that it 
 is actually useful.

Or maybe you can persuade the task-laptop maintainer that the status quo
needs to be changed, and that what's currently happening is positively
harmful. I disagree with that.

Remember that task-desktop-* and task-laptop are separate. The acpi
tool will be installed even if task-desktop-whatever isn't, and there
are valid use cases for such installations; I've seen people take an old
laptop, put in a more recent disk, and use that as a home server (it
draws less power than an equally old desktop, and has a builtin UPS!).
Such an installation would not have or need a GUI, but could still use a
tool to query battery usage.

If you can show me where it does harm to keep the status quo of having
the acpi tool installed, I'll concede the point. So far, though, all
I've seen is you stating your opinion as fact. I'm not saying it's an
invalid opinion, but just stating out of the blue that acpi is totally
useless doesn't make it so.

[1]
wouter@gangtai:~$ apt-cache show acpi | grep -E '(Installed-Size|Depends)'
Installed-Size: 71
Depends: libc6 (= 2.7)

i.e., it only adds 71k to the set of Essential packages.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150429175329.ga1...@grep.be

Bug#783264: Bug#783247: Please don't install acpid and acpi-support-base

[Wouter Verhelst]

On Fri, Apr 24, 2015 at 10:07:36PM +0200, Marco d'Itri wrote:
  I'm not sure, if the acpi command line utility is that useful which
  would warrant having it installed by default. The attached patch drops
  it as well. Incidentally, this was also suggested for the laptop-task,
  which still pulls it in.
 The acpi package is *totally useless* and should be immediately dropped 
 from hw-detect and task-laptop.

Disagree.

- Acpi is a useful command-line tool to easily read values of things
  like battery life expectancy and other ACPI power-related values,
  without having to dig through files in /sys.
- It provides more detailed information than most graphical interfaces
  that I've seen (but I'd be happy to be corrected).
- Its dependencies are fairly light, so it does little harm.
- As a command-line tool, it is useful even when no GUI is available
  (for whatever reason).

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150428082216.gb2...@grep.be

Re: Package versioning and upgrades

[Wouter Verhelst]

On Fri, Mar 27, 2015 at 05:25:51PM -0400, Lennart Sorensen wrote:
 On Fri, Mar 27, 2015 at 09:46:06PM +0100, Turbo Fredriksson wrote:
  Since ZoL (ZFS On Linux) isn't yet in Debian GNU/Linux, I've been
  doing my own packages for ZoL in that package repo.
  
  This include changes to the installer (debian-installer, base-installer,
  grub-installer, partman-target and partman-zfs). But because the Debian
  GNU/Linux git repo refuses force pushes, they latest versions is now
  in the ZoL GIT repo (https://github.com/zfsonlinux/debian-installers).
  
  
  But I think I've painted myself into a corner regarding the upgrade
  path.
  
  I have four repos:
  
  wheezy  = The released ZoL version for Wheezy
  wheezy-daily= The GIT master releases of ZoL for Wheezy
  jessie  = The released ZoL version for Jessie
  jessie-daily= The GIT master releases of ZoL for Jessie
  
  So basically, the packages in 'wheezy' and 'jessie' are identical,
  except they're compiled on the different versions of Debian GNU/Linux.
  
  Same for 'wheezy-daily' vs. 'jessie-daily'.
  
  Identical, in the meaning that it uses the exact same codebase/version
  and patch set of ZoL, just compiled for different libraries
  on two different platform version.
  
  
  But certain upgrade paths isn't working (which isn't much of a
  surprise actually - didn't quite think this through I guess):
  
  UPGRADE PATHSTATUS  VERSION COMPARE
  wheezy = wheezy-daily  = YES   0.6.3-1.3-1~wheezy lt 
  0.6.3-38-7d90f5-wheezy
  wheezy = jessie= NO0.6.3-1.3-1~wheezy lt 
  0.6.3-1.3-1~jessie
  wheezy = jessie-daily  = YES   0.6.3-1.3-1~wheezy lt 
  0.6.3-35-7d90f5-jessie
  wheezy-daily = jessie  = NO0.6.3-38-7d90f5-wheezy lt 
  0.6.3-1.3-1~jessie
  wheezy-daily = jessie-daily= NO0.6.3-38-7d90f5-wheezy lt 
  0.6.3-35-7d90f5-jessie
  jessie = jessie-daily  = YES   0.6.3-1.3-1~jessie lt 
  0.6.3-35-7d90f5-jessie
  
  The versions here is the actually versions currently in the repository,
  and the result (YES/NO) is the status of dpkg --compare-versions.
 
 I suppose the big problem you have is that jessie is alphabetically lower 
 than wheezy.
 
  My question now is: How do I setup/change the versioning so that all
  of these upgrade paths work?
 
 Well you can solve the wheezy to jessue upgradesm but I don't think you
 can solve wheezy-daily = jessie, since that really is a downgrade.
 
  Doing this in intermediate steps isn't a problem, but I prefer not
  to use epochs if possible (even if that would be the simplest
  solution :)...
 
 If you were to do this:
 
 Change 0.6.3-1.3-1~wheezy to 0.6.3-1.3-2~wheezy
 Change 0.6.3-1.3-1~jessie to 0.6.3-1.3-2
 Change 0.6.3-38-7d90f5-wheezy to 0.6.3-39-7d90f5~wheezy
 Change 0.6.3-35-7d90f5-jessie to 0.6.3-39-7d90f5
 
 So always use ~wheezy suffix when building for wheezy and use no suffix
 when building for jessie, and bump the main packaging version up to make
 the new versions higher than they were before.

Alternatively, you could use release version numbers rather than code names:

0.6.3-1.3-1~Debian7 (rather than wheezy), and
0.6.3-1.3-1~Debian8 (rather than jessie)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150328061024.ga7...@grep.be

Bug#780994: flash-kernel: Missing dependency on u-boot-tools fails initramfs-tools to fail

[Wouter Verhelst]

On Thu, Jan 01, 1970 at 12:49:11AM +, Martin Stigge wrote:
 Package: flash-kernel
 Version: 3.33
 Severity: normal
 
 Hi,
 
 I just installed flash-kernel but didn't have u-boot-tools installed. I
 believe it's the initramfs trigger that failed with the following:
 
 Generating boot script u-boot image... /usr/sbin/flash-kernel: 348: 
 /usr/sbin/flash-kernel: mkimage: not found
 run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 
 127
 dpkg: error processing package initramfs-tools (--configure):
  subprocess installed post-installation script returned error exit status 1
 Errors were encountered while processing:
  initramfs-tools
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 
 That's easily resolved by installing the u-boot-tools package, but I would
 have expected that do be a dependency in that case. I see that it's a
 Suggests, but looks rather essential to me.

It may or may not be, depending on your particular hardware. The proper
way to flash a kernel differs from machine to machine, and from
bootloader to bootloader. Therefore, flash-kernel has a lot of code
paths, some of which require mkimage, some of which don't.

When d-i installs flash-kernel, it will also make sure that the required
dependencies are in place, so a suggests seems correct to me.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150324090743.ga1...@grep.be

Re: Old-timer installer, task-sysvinit?

[Wouter Verhelst]

On Sun, Nov 23, 2014 at 02:02:57PM +0100, Jonas Smedegaard wrote:
 Quoting Cyril Brulebois (2014-11-23 13:13:05)
  Well, I'm really unsure what you're calling inaccurate in the third 
  point.
 
 It is that preseeding is the mechanism used - but I may indeed be 
 wrong:
 
 I assumed the term preseeding meant debconf preseeding, but realize 
 now that indeed both https://wiki.debian.org/DebianInstaller/Preseed 
 and e.g. https://www.debian.org/releases/stable/i386/apbs01.html.en 
 uses the term without direct ties to debconf.  Both those documents do, 
 however, describe [not-only-debconf] preseeding as a way to set answers 
 to questions asked during the installation process.
 
 I consider preseeding to be feeding answers to questions before asked.  
 Executing shell scripts is something else, IMO.  You likely disagree.

Implementation details, but:

Debian-installer uses (c)debconf throughout, so debconf preseeding and
installer preseeding are really one and the same thing.

Debian-installer extends that by providing a few debconf templates that
are never shown to the user, but that *are* read by the installer and
acted upon. Some of those are the early_command and late_command
templates, which the installers assumes will contain shell snippets that
it must execute.

So yes, it's running shell scripts, but yes, it's also feeding answers
to questions (albeit questions that will *not* be asked).

Regards,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141123131527.gb22...@grep.be

Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode

[Wouter Verhelst]

On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote:
 I'm not 100% sure that partman-efi is the right package for the bug
 report, but it's as good as any. So, it's way past time to fix this
 particular bug. After a fair amount of playing with systems like this
 and discussing with folks, my proposed solution is:
 
  1. Somewhere during initial partman setup (probably partman-efi?), we
 look to see if:
 
 (a) we're in UEFI mode (trivially true if we're in partman-efi); and
 
 (b) we have an existing set of partitions that are *not* set up
 for UEFI boot (can we use os-prober to get a list at this
 stage?) Look for an existing partition setup and maybe
 bootable flags, but no detectable EFI System Partition.
 
  2. If the above is the case, warn the user:
 
 Your computer's firmware has started the installer in UEFI mode
  but there are existing Operating Systems already installed:
 
  * OS 1
  * OS 2
  ...
 
  These will not boot in UEFI mode. If you still wish to be able
  to boot one of these existing systems after installing Debian in
  UEFI mode, this will be difficult. Your best way forward is to
  reboot and restart the installer in 'BIOS compatibility
  mode'. You will need to reconfigure your computer's boot options
  to do this.
 
  If you wish to install Debian in UEFI mode and don't care about
  keeping the ability to boot one of the existing systems,
  continue.
 
  Go BackContinue
 
  If the user wants to continue, we could even suggest blanking the
  partition table(s) and starting again with GPT, but I don't think
  we currently have a blank partition table option exposed within
  d-i?
 
 What do people think of this plan? What have I missed?

Isn't it better to run this test in partman-efi's isinstallable script?
Then if things are set up in the described way, grub-efi just won't be
installed, but the normal grub will, and the system will continue to
boot in BIOS fallback as before.

It might make sense to give a warning or error message in case the
described setup exists and an ESP partition is created in the
partitioner, but other than that...

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140928064811.ga6...@grep.be

Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode

[Wouter Verhelst]

On Sun, Sep 28, 2014 at 10:26:20AM +0100, Steve McIntyre wrote:
 On Sun, Sep 28, 2014 at 08:48:11AM +0200, Wouter Verhelst wrote:
 On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote:
   If the user wants to continue, we could even suggest blanking the
   partition table(s) and starting again with GPT, but I don't think
   we currently have a blank partition table option exposed within
   d-i?
  
  What do people think of this plan? What have I missed?
 
 Isn't it better to run this test in partman-efi's isinstallable script?
 Then if things are set up in the described way, grub-efi just won't be
 installed, but the normal grub will, and the system will continue to
 boot in BIOS fallback as before.
 
 That was my initial thought, but then someone pointed out: what
 happens to a user who explicitly *wants* to replace their existing
 legacy system with a new UEFI one?

If that is a warning (as opposed to error) message saying something
along the lines of note that with this setup you won't be able to boot
your current system anymore, then that isn't an actual problem. A user
who is planning to replace a system shouldn't be worried about the
installer warning them that they can't boot the (to be replaced) old
system anymore, and can safely ignore that message.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140928165428.gb22...@grep.be

add net-retriever/localrepo?

[Wouter Verhelst]

Hi,

I've been thinking it might be nice to extend net-retriever so it checks
the net-retriever/localrepo template. This would never be shown (only
used for preseeding), and would work similar to the localudebs
directory.

This could be used for more easily testing modules that aren't usually
included in a built image, but could also be used to allow people to ask
extra local questions in a mostly-preseeded environment, should they
want that (create the udeb, create the repository, and preseed
'net-retriever/localrepo and modules to relevant values).

Thoughts?

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140327235814.ga13...@grep.be

Bug#657955: Can't reproduce this

[Wouter Verhelst]

Hi,

After reassigning this bug to partman-nbd, I appear to have forgotten about it.

I tried to reproduce it just now, but could not. Can you?

If not, I think we'll close it; it may well have been an issue that was
in initramfs-tools but which has since been fixed.

Regards,

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140321090422.ga22...@grep.be

Bug#619236: debian PS3 installation kboot.conf needed

[Wouter Verhelst]

Op maandag 3 maart 2014 10:38:12 schreef Antonio Ospite:
 kboot-utils is in Debian[1] already, all that is missing is to find a
 way to tell the installer:
 
   if this system is a PS3, then install kboot-utils
 
 Can anyone suggest where this kind of logic can be added in d-i?
 I didn't manage to allocate enough time to look deeper into that.

If the PS3 needs some special partitioning (it's been a while since I 
upgraded my PS3 to something that can't run Linux anymore, so I don't 
remember) then I would suggest a partman module.

If not, I guess finish-install is the best place to do it.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/

Re: resolv binary (partman-nbd) broken

[Wouter Verhelst]

On Mon, Feb 24, 2014 at 09:46:08PM +0300, Cyril Brulebois wrote:
 Wouter Verhelst wou...@debian.org (2014-02-21):
  It seemed to work when I originally wrote it; but today, I noticed this:
  
  wouter@carillon:~/debian/debian-installer/packages/partman-nbd$ ./resolv 
  db.debian.org
  pÐ@
  82.195.75.106
  
  The first is supposed to be an IPv6 address; instead, it is junk.
  
  I'm not sure what exactly happens, nor what the bug in the code is. Any
  help would be welcome.
 
 You want to check “man inet_ntop” and try:
 
 -   inet_ntop(rp-ai_family, addr, host, 
 rp-ai_addrlen);
 +   inet_ntop(rp-ai_family, addr, host, 
 NI_MAXHOST);
 
 or probably better, in case host's declaration changes over time:
 -   inet_ntop(rp-ai_family, addr, host, 
 rp-ai_addrlen);
 +   inet_ntop(rp-ai_family, addr, host, 
 sizeof(host));

D'oh. Thanks, fix committed (the latter of the two, which does indeed seem 
slightly more robust)

  [1] It might make sense to ship it with something more generic, but I
  couldn't think of a good udeb to put it in.
 
 Somewhere inside src:debian-installer-utils maybe? di-utils would look
 right to me at first glance.

Ah, yes. I suppose that could work. I'll move it there.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140224221220.ga6...@grep.be

Bug#739855: partman-lvm: Irreproducible metadata size

[Wouter Verhelst]

On Sun, Feb 23, 2014 at 05:13:29PM +0700, st wrote:
 The problem seems to be that partman-lvm created PVs with only
 195584 units-used-by-pvck allocated for metadata. However, there
 is no way to create PVs with less than 1047552 units-used-by-pvck
 with the standard pvcreate.

Not true, as partman-lvm uses the standard pvcreate. The exact call is in
[partman-lvm]/lib/lvm-base.sh

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140224223658.gb6...@grep.be

resolv binary (partman-nbd) broken

[Wouter Verhelst]

Hi,

When installing / to NBD, partman-nbd needs to set up some boot-time parameters
so the NBD server can be found by the initrd.

Unfortunately, since the initrd does not have a working resolver
configured, that means we need to resolve DNS names to IP addresses in
the installer. For that reason, I wrote resolv.c, a program that's
installed to /bin and ships with partman-nbd[1]. Its goal is to take a
hostname and translate it to a list of IP addresses, either IPv6 or
IPv4.

It seemed to work when I originally wrote it; but today, I noticed this:

wouter@carillon:~/debian/debian-installer/packages/partman-nbd$ ./resolv 
db.debian.org
pÐ@
82.195.75.106

The first is supposed to be an IPv6 address; instead, it is junk.

I'm not sure what exactly happens, nor what the bug in the code is. Any
help would be welcome.

Thanks,

[1] It might make sense to ship it with something more generic, but I
couldn't think of a good udeb to put it in.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221074556.gb31...@grep.be

Re: Bug#681227: Can anyone reproduce #681227: installation-reports: grub-install tries to install to a nonsense string?!

[Wouter Verhelst]

retitle 681227 does not validate free-form input
thanks

On Mon, Jan 07, 2013 at 05:54:03PM +, Steven Chamberlain wrote:
 Hi Matthew,
 
 On 07/01/13 17:15, Matthew Vernon wrote:
  Jul 10 16:48:43 in-target: grub-common is already the newest version.
  Jul 10 16:48:43 in-target: 0 upgraded, 0 newly installed, 0 to remove
  and 0 not upgraded.
  Jul 11 07:56:28 grub-installer: info: Installing grub on '/dev/sdb 
  w33sxs34rfvbg789iokm·']'
 
  On 02/01/13 22:49, Steven Chamberlain wrote:
  To the original submitter of the bug report:  do you have a cat?
  
  No. The machine is my work desktop. I do have a QWERTY keyboard
  [...] I don't know how one might
  have gotten a middot out of it!
 
 I've just learned that at least with my keyboard layout (gb), AltGr +
 period will type the interpunct/middot, in Xorg or from a Linux
 terminal.  Those keys are more or less adjacent too.
 
  That said, I cannot eliminate the
  possibility that a cleaner was overzealous or similar, but it seems
  unlikely...?
 
 I'm convinced this is the explanation.  The installer was stuck at a
 GRUB prompt for boot devices overnight;  then at 07:56 (usually
 'accurate', but might not be in the local timezone) GRUB proceeded
 trying to install to:
 
 w33 sxs 34rfvbg ... 789iokm ·']
 
 This seems to fit with down/up sweeps across a QWERTY keyboard with
 one's cleaning cloth, proceeding from the left to right (so I would even
 guess that he/she is right-handed...).
 
 [The split on an ergo keyboard would be between the ...vbg and 789...
 sequences of keystrokes, and the closing square bracket is adjacent to
 the carriage return key].
 
 So I think this can be closed.

Almost.

 What to do with the workaround added by Wouter in grub-installer/1.84?

The workaround tried to eliminate the possibility of invalid data coming
from somewhere in the installer. I hadn't noticed the long delay in
the log; I had noticed the possibility of invalid input, but didn't
think you'd be silly enough to enter such a long string and not notice.
Of course, if the installer was running overnight, that changes matters.

So what I think needs to be done to fix this properly is to move the
check from where it is located right now to where we do the db_get for
the installer device. If what's been entered by the user doesn't look
like a hard disk device, we should display an error message and allow
the user to try again.

However, given we're this late in the freeze, and given that we've
already got the workaround in place (which should allow a retry by going
through the main menu), I'm not sure it's appropriate anymore to do this
right now.

I'll leave that decision to the d-i RM.

 It did trigger a couple of regressions initially, but those are fixed
 now in Git.
 
 Silently ignoring a failure seems risky when we know that it should not
 happen.  (Someone may want to specify multiple targets, and if one of
 them is typo'd it would be silently skipped in this case).

That's indeed the only case that isn't caught by the current code.
Still, first, this is a highly unusual installation type; and second,
even were it to occur, an easy workaround is to use the installer in
rescue mode and fix the boot set-up -- or fix it from the installed
system.

Again, it's not a perfect situation, but I'm not sure this is RC
anymore.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107195616.ga21...@grep.be

Re: unblock(-udeb)s for d-i wheezy rc1, round 1

[Wouter Verhelst]

On Thu, Dec 20, 2012 at 10:34:13AM +, Steve McIntyre wrote:
 On Thu, Dec 20, 2012 at 06:26:06AM +, Adam Barratt wrote:
 britney says
 
 partman-nbd/armhf unsatisfiable Depends: nbd-client-udeb
 partman-nbd/s390x unsatisfiable Depends: nbd-client-udeb
 
 but I guess that's always been the case?
 
 Hmmm. That's surprising (to me). Ah, looking at the nbd package I can
 see that the udeb is not Architecture: any or even Architecture:
 linux-any like I'd expect. That's why. Wouter, could you fix that or
 at least add armhf and s390x please?

Sure. I keep forgetting about nbd-client-udeb; it often needs the same
changes that nbd-client needs, but it's this teeny tiny thing that's
just an appendix to nbd... oh well.

Fix uploaded. It also contains a tightening of the build-dependencies to
what's effectively already there (but not specified as such in the
changelog), but (other than the Architecture: linux-any) no functional
changes.

Please unblock, so the fix can go in.

unblock nbd/1:3.2-2

Thanks,

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


signature.asc
Description: Digital signature

Bug#696450: devices aren't detected immediately

[Wouter Verhelst]

Package: partman-nbd
Version: 0.18
Severity: minor

I just noticed that partman-nbd doesn't detect when NBD devices are
connected or disconnected right away.

While I know what the issue is[1], the issue is pretty minor (everything
works, it's just a bit confusing), but the fix might be somewhat
involved.

Given that, I'm not sure this time of the release is the right time to
fix it anymore. I'll do it once wheezy is out the door.

[1] It's a race in the script that performs the connect or disconnect
operation, which takes longer than the time the script which
populates the menu needs to do its job.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121220221041.7688.73455.reportbug@localhost

Re: unblock(-udeb)s for d-i wheezy rc1, round 1

[Wouter Verhelst]

On Thu, Dec 20, 2012 at 09:37:11PM +, Adam D. Barratt wrote:
 On Thu, 2012-12-20 at 22:25 +0100, Wouter Verhelst wrote:
  On Thu, Dec 20, 2012 at 10:34:13AM +, Steve McIntyre wrote:
   On Thu, Dec 20, 2012 at 06:26:06AM +, Adam Barratt wrote:
   partman-nbd/armhf unsatisfiable Depends: nbd-client-udeb
   partman-nbd/s390x unsatisfiable Depends: nbd-client-udeb
 [...]
   Hmmm. That's surprising (to me). Ah, looking at the nbd package I can
   see that the udeb is not Architecture: any or even Architecture:
   linux-any like I'd expect. That's why. Wouter, could you fix that or
   at least add armhf and s390x please?
 [...]
  Fix uploaded. It also contains a tightening of the build-dependencies to
  what's effectively already there (but not specified as such in the
  changelog), but (other than the Architecture: linux-any) no functional
  changes.
 
 Unblocked, but needs an explicit ack for the udeb hint.

Thanks.

 There's also this oddity, fwiw:
 
 + nbd (1:3.2-1) unstable; urgency=low
 + 
 +   * New upstream release. Includes many stability fixes, so hopefully

Ah, whoops. That's because the NMU patch didn't apply cleanly (for
obvious reasons; I'd already added the -2 changelog when I added the NMU
patch), so I just added the hunk to the changelog and removed the
leading + signs. Apparently I missed the context at the end.

I've fixed it in my local copy, but I'm not sure it's important enough
to warrant a new upload. Can you think of anything that would break?

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121221001943.ga16...@grep.be

Bug#681227: some analysis

[Wouter Verhelst]

On Sat, Dec 15, 2012 at 06:24:46PM +0100, Wouter Verhelst wrote:
 At this point, I'm tempted to add a check to the for loop that starts on
 line 650 in the current HEAD (commit 062ddbcb66150) for something along
 the lines of:
 
 if [ ! -b $bootdev ]; then
   # jump to the next loop iteration here
 fi

I've done that, but also added a check so that if this means we don't
actually install grub to any boot device, grub-installer will fail.

It's not a proper fix, so I didn't mark the change as closing this bug;
but I do plan to downgrade the severity (since it now no longer causes
the installation to fail) once it's been built everywhere.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121216163433.ga21...@grep.be

Bug#681227: some analysis

[Wouter Verhelst]

Hi,

I just spent a few hours trying to analyse this bug, but so far I
haven't found what could cause this.

The message 'Installing grub on ' is generated by this line:

info Installing grub on '$bootdev'

Obviously, this bootdev variable is what the entire rest of the script
is built to do, so figuring out where the garbage is coming from is
non-trivial.

I found two possibilities. The first is a line that looks like this:

mappedbootdev=$(mapdevfs $bootdev) || true

mapdevfs is part of debian-installer-utils, and is a fairly short file
which just calls a C function from libdebian-installer. I audited the
code which would seem to be called, but could not find any constructs
that might be suspicious or that could cause a C buffer overflow or
anything similar (which doesn't mean it doesn't exist, just that I
couldn't find one).

The second is the fact that grub-probe is called a few times, which is
also written in C. I didn't audit that code, but did find that when
called with invalid input, grub-probe would just segfault. For instance:

grub-probe '(hd0)'

segfaults with my current version of grub-probe (I filed a separate bug
on that). I didn't investigate its code, but it's not unfathomable that
some invalid input to grub-probe could generate garbage such as in this
bugreport. I don't know for sure, however, and ran out of time.

At this point, I'm tempted to add a check to the for loop that starts on
line 650 in the current HEAD (commit 062ddbcb66150) for something along
the lines of:

if [ ! -b $bootdev ]; then
# jump to the next loop iteration here
fi

which will not only protect against garbage, but also against trying to
install to devices that don't exist on this system.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121215172446.ga1...@grep.be

Bug#671824: keyboard-configuration: Selecting MacBook Pro (macbook79) offers layouts that don't exist resulting in xkb error

[Wouter Van Hemel]

Package: keyboard-configuration
Version: 1.76
Severity: normal

Hello,

When (re)configuring keyboard-configuration and selecting MacBook Pro Intl 
(macbook79), the layout selection dialogue offers options that don't exist, 
which results in setxkbmap errors during X server start-up and a default US 
keyboard being chosen as fall-back.

Layout options offered for MacBook Pro with Finnish language:

Finnish
Finnish - Finnish (classic)
Finnish - Finnish (classic, eliminate dead keys)
Finnish - Finnish (Macintosh)
Finnish - Northern Saami (Finland)
Other

 I think only Finnish and perhaps the no-dead-keys option work. At least 
the option with Macintosh fails. My guess is that Apple keyboards are merge 
together into an alias, but the MacBook keyboards don't really offer those 
variants.

As a side note, MacBooks (as most other recent EU keyboards) use EuroSign and 
not the currency sign at shift-4. It's a bit silly to require everyone to 
create a Xmodmap file, so perhaps this should be changed in the upsteam xkb 
model.


Thanks for your time,

  Wouter

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.42
ii  initscripts 2.88dsf-22.1
ii  liblocale-gettext-perl  1.05-7+b1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
ii  console-setup-linux  1.76
ii  debconf  1.5.42
ii  xkb-data 2.5.1-1

Versions of packages console-setup suggests:
ii  locales   2.13-32
ii  lsb-base  4.1+Debian2

Versions of packages console-setup-linux depends on:
ii  kbd  1.15.3-7

Versions of packages console-setup-linux suggests:
ii  console-setup  1.76

Versions of packages keyboard-configuration is related to:
ii  console-common  none
ii  console-datanone
ii  console-tools   none
ii  kbd 1.15.3-7

-- debconf information:
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
* keyboard-configuration/modelcode: macbook79
  keyboard-configuration/unsupported_config_options: true
  console-setup/fontface47: Fixed
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/toggle: No toggling
  console-setup/fontsize-text47: 8x16
* keyboard-configuration/compose: Right Logo key
* keyboard-configuration/layout:
* keyboard-configuration/xkb-keymap: fi(mac)
* keyboard-configuration/variant: Finnish
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/switch: No temporary switch
  console-setup/charmap47: UTF-8
  keyboard-configuration/unsupported_options: true
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/framebuffer_only:
* keyboard-configuration/ctrl_alt_bksp: false
  console-setup/codesetcode: Lat15
  keyboard-configuration/unsupported_layout: true
  console-setup/guess_font:
* keyboard-configuration/variantcode:
* keyboard-configuration/model: MacBook/MacBook Pro (Intl)
* keyboard-configuration/layoutcode: fi
  console-setup/store_defaults_in_debconf_db: true
  console-setup/fontsize-fb47: 8x16
* keyboard-configuration/other:
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/optionscode: compose:rwin
  console-setup/use_system_font:
  console-setup/fontsize: 8x16



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120507080334.7063.81371.reportbug@wode.solinor.local

Re: Proposal to get Wheezy Alpha1 done

[Wouter Verhelst]

On Sat, Mar 24, 2012 at 01:12:32PM +, Adam D. Barratt wrote:
 On Sun, 2012-03-18 at 15:54 +0100, Wouter Verhelst wrote:
  On Sat, Mar 17, 2012 at 03:42:03PM -0300, Otavio Salvador wrote:
   On Sat, Mar 17, 2012 at 15:37, Adam D. Barratt a...@adam-barratt.org.uk 
   wrote:
partman-nbd
   
Not done.  The files client.c, oef and opdr have all disappeared and a
chunk of code has changed in resolv.c, without any mention in the
changelog.
 [...]
  The first three should not have been there in the first place; they are
  completely and utterly unrelated to partman-nbd.
  
  The changes to resolv.c were a work in progress; I'm not sure whether
  they were actually tested.
  
  I'll do so ASAP, and upload a fixed 0.10 when that's done. Meanwhile,
  0.9 is actually in better state than 0.8 was (as in, less features but
  what's there has actually been tested), so go ahead and let it pass.
 
 Apparently this got missed last weekend; apologies for that.
 
 What's the likely timescale for the 0.9 testing / 0.10 upload (if
 needed)?

Not going to happen this week, and probably not the next, either. Please
go ahead with the migration of 0.9.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120327183902.ga19...@grep.be

Re: Proposal to get Wheezy Alpha1 done

[Wouter Verhelst]

On Sat, Mar 17, 2012 at 03:42:03PM -0300, Otavio Salvador wrote:
 On Sat, Mar 17, 2012 at 15:37, Adam D. Barratt a...@adam-barratt.org.uk 
 wrote:
  partman-nbd
 
  Not done.  The files client.c, oef and opdr have all disappeared and a
  chunk of code has changed in resolv.c, without any mention in the
  changelog.
 
 Wouter can you comment on that?

Whoops.

Apparently my 0.8 upload was done without checking git status first.
Sorry 'bout that.

The first three should not have been there in the first place; they are
completely and utterly unrelated to partman-nbd.

The changes to resolv.c were a work in progress; I'm not sure whether
they were actually tested.

I'll do so ASAP, and upload a fixed 0.10 when that's done. Meanwhile,
0.9 is actually in better state than 0.8 was (as in, less features but
what's there has actually been tested), so go ahead and let it pass.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120318145403.gb14...@grep.be

Re: Adding New Script Variants on Debian Installer

[Wouter Verhelst]

On Sun, Mar 18, 2012 at 07:13:43AM -0500, Eagle Burkut wrote:
 Before we came to that naming convention, we did a quite bit of research. 
 There
 are couple of obstacles to adopt the other idea. First of all, the FontConfig
 library does not support with language/script variant with @ such as ug_CN, 
 and
 ug_CN@latin. There is no way to develop a orthography rule file for 
 ug_CN@latin
 and have it included in FontConfig. Secondly, the online translation platform
 Launchpad does not support another language/script variant of the same 
 language
 in same country. These are originally design issues and in the near 
 foreseeable
 future, there is no clear indication that there will be a fix. And lastly,
 while doing a research on this issue, the Kurdish language in Turkey, Iraq and
 Iran draw our attention. There are just language and country code, no @
 variants. Our case is exactly same as of Kurdish, nothing more or nothing 
 less.
 The @ variant has to be used for the same language in same country, such as
 uz_UZ@latin and uz_UZ@cyrillic. For same the language in different countries,
 there is no need to add the @ variant, such as in the case of Kurdish. And in
 our case, for the same language, different writing systems are used in
 different countries, not in the same one country, thus we think the @ variant
 is not necessary.

Yes, it is. What you're describing is a bug waiting to happen.

For comparison: there is no translator who translates to the 'nl_BE'
locale; all dutch translators translate to 'nl'. Yet there is no user
who uses an 'nl' locale; all users use 'nl_NL', 'nl_BE', 'nl_AR', or
whatnot. The locales system understands that Dutch is Dutch, no matter
where it's spoken, and will take the 'nl' translation when 'nl_BE' is
asked.

In the case of Dutch, that's perfectly reasonable, because there's only
one authority on the Dutch language (the Dutch Language Union). This
isn't just limited to Dutch, however; in simple programs, it could be
that the only needed strings aren't of the variant where there's a
difference between en_US and en_GB, in which case you'll end up with
just an 'en' translation.

This assumption that 'xx_YY' is just a specialized form of 'xx' means
that it's okay to move files around if you find that there are
translations for this one specialized variant of ug but not for that
other, and your users are asking for a translation. When that happens,
with your scheme, suddenly you get a translation that jumps from one
script to the other all the time; this is even worse than having a
partially-translated program.

Also, the fact that one translation has such a bug shouldn't mean that
the other should, too.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120318212408.gp13...@grep.be

Re: do-upload fails on !i386 for partman-nbd

[Wouter Verhelst]

Hi Otavio,

On Mon, Oct 03, 2011 at 05:41:37PM -0300, Otavio Salvador wrote:
 On Sun, Oct 2, 2011 at 13:26, Wouter Verhelst wou...@debian.org wrote:
 
  I've locally patched that out, so I can at least do an upload now, but
  I'm not sure what this bit is supposed to do. Anyone?
 
 Does the attached patch works for you?

It seems to, yes. I had nothing to upload when you originally posted
that, but I just did a translation upload for partman-nbd, with your
patch applied, and everything seems to be fine now.

Thanks!

(I didn't commit it, leaving that to you)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111016105356.gm3...@grep.be

do-upload fails on !i386 for partman-nbd

[Wouter Verhelst]

Hi,

Tried to do an upload of partman-nbd, but it failed. The reason is this
bit of code:

|arch=`grep Architecture debian/control | head -n 1 | sed 's,.*: ,,g'`
|if echo $arch | grep -q `dpkg-architecture -qDEB_BUILD_ARCH`; then
|arch=`dpkg-architecture -qDEB_BUILD_ARCH`
|else
|arch=`echo $arch | cut -f 1 -d\  | sed 's,-any$,-i386,g'`

Since partman-nbd says 'Architecture: linux-any', this gets translated
into 'Architecture: linux-i386', which causes the rest of the script to
try to cross-compile -- not what I'd expect.

I've locally patched that out, so I can at least do an upload now, but
I'm not sure what this bit is supposed to do. Anyone?

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111002162624.ga26...@grep.be

converting a hostname to an IP address

[Wouter Verhelst]

Hi,

Yesterday, I committed a change to nobootloader so it also shows the
output of user-params in the kernel command line, and changed
partman-nbd so it will output a correct nbdroot= parameter. With that,
users should be shown a working kernel command line provided they
entered the server by IP address.

Unfortunately, the environment in an initramfs (as generated by
update-initramfs, not as generated by the d-i build system) does not
have the ability to do name resolving (there isn't a resolv.conf to be
found). Arguably this is a bug in initramfs-tools, but then I guess an
initramfs isn't supposed to be a full system.

As such, I'd need to a name lookup of the servername the user provided
me with, preferably in a shell command, so that when root-on-NBD is
used, I can provide the user with a working command line (i.e., an
nbdroot= parameter that specifies the server by IP address, not
hostname).

Is there anything like that in d-i? If not, I'll have to come up with
something myself, I'm afraid.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110808065011.ga9...@grep.be

Re: (forw) [SCM] UNNAMED PROJECT branch, master, updated. 34c9cfb5676eb4d97bc661139d6ff58acefb1e49

[Wouter Verhelst]

On Mon, Jul 25, 2011 at 06:10:20AM +0200, Christian PERRIER wrote:
 Wouter, isn't there something missing in the way the partman-nbd
 directory is setup in D-I's git? I suspect there is a need for
 naming the project somewhere but can't figure out where.

Looks like it.

I copied some hooks from another repository in the d-i area, and Otavio
helped me configure those hooks a few days ago here at debconf. But I
didn't see any documentation as to how this is supposed to work, and
it's perfectly possible that I missed the obvious somewhere.

Anyone else here who knows what should really be done? Also, it might be
nice if this was documented somewhere obvious.

(unless it is, in which case please slap me and tell me where to look)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110725132643.ga22...@grep.be

Re: (forw) [SCM] UNNAMED PROJECT branch, master, updated. 34c9cfb5676eb4d97bc661139d6ff58acefb1e49

[Wouter Verhelst]

On Mon, Jul 25, 2011 at 04:51:29PM +0200, Joey Hess wrote:
 Otavio Salvador wrote:
  On Mon, Jul 25, 2011 at 06:10, Christian PERRIER bubu...@debian.org wrote:
  
  Wouter, isn't there something missing in the way the partman-nbd
  directory is setup in D-I's git? I suspect there is a need for
  naming the project somewhere but can't figure out where.
  
  
  .git/description I think.
 
 Just run scripts/togit/hooksetup.sh on alioth. This will set up
 all repos the same, and was designed to be reused after the svn
 conversion.

Trying, but:

wouter@vasks:~/d-i-scripts/togit$ sh -x ./hooksetup.sh 
+ set -e
+ cd /git/d-i
+ cd /git/d-i/aboot-installer.git
+ echo aboot-installer.git
+ sed s/\.git$//
+ proj=aboot-installer
+ cat
+ chmod 755 hooks/post-receive
chmod: changing permissions of `hooks/post-receive': Operation not permitted

I just manually called the individual commands in that script so they
would run on partman-nbd only, instead. Hope that solves it.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


signature.asc
Description: Digital signature

Re: Comments regarding partman-nbd_0.1_amd64.changes

[Wouter Verhelst]

On Sat, Jul 09, 2011 at 11:59:26PM +0200, Luca Falavigna wrote:
 Il 09/07/2011 21:25, Wouter Verhelst ha scritto:
  That would require a change  rebuild of linux-kernel-di-*-2.6, which
  hasn't happened yet (I'm waiting for an ack before I commit that)
  
  Was my upload premature?
 
 If you can bear with unmet dependency for a bit, fine.
 Otherwise, we can keep it in the queue until packages are uploaded.

Well, if I saw a problem with that situation, I wouldn't have uploaded
this package in the first place :-)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110710143615.gn16...@grep.be

Re: Comments regarding partman-nbd_0.1_amd64.changes

[Wouter Verhelst]

On Sat, Jul 09, 2011 at 12:21:14PM +, Luca Falavigna wrote:
 Hi,
 
 package depends on nbd-modules, but I can't find any
 reference for it. Could you please elaborate?

That would require a change  rebuild of linux-kernel-di-*-2.6, which
hasn't happened yet (I'm waiting for an ack before I commit that)

Was my upload premature?

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110709192513.gl28...@grep.be

Re: Comments regarding partman-nbd_0.1_amd64.changes

[Wouter Verhelst]

On Sat, Jul 09, 2011 at 09:25:13PM +0200, Wouter Verhelst wrote:
 On Sat, Jul 09, 2011 at 12:21:14PM +, Luca Falavigna wrote:
  Hi,
  
  package depends on nbd-modules, but I can't find any
  reference for it. Could you please elaborate?
 
 That would require a change  rebuild of linux-kernel-di-*-2.6, which
 hasn't happened yet (I'm waiting for an ack before I commit that)

Or, better, I was giving people the possibility to NAK (I said I'd do
this 'later this week', so now qualifies, I'd guess)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110709193650.gm28...@grep.be

partman-nbd commit hook

[Wouter Verhelst]

Hi,

I tried configuring the partman-nbd git repo to send out commit mails by
copying the commit hook from another of the d-i git repositories, but
apparently that was a rather naive idea to get it to work -- it doesn't.

Could someone more familiar with the set-up either fix this for me, or
tell me how it's done?

Thanks,

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110706192227.gc3...@grep.be

Partman-nbd plans

[Wouter Verhelst]

Hi,

So, I just uploaded the first version of partman-nbd to unstable (which
happened just a few minutes ago as of this writing, so I don't know
whether it's through NEW when you read this).

It still needs some minor work; but this version is already perfectly
usable, and I am a strong believer in the 'release early' part of
'release early, release often'.

The way forward looks somewhat like this:
- Make sure all kernel udeb packages also build an nbd-modules udeb, so
  that this can actually work. Unless I hear objections within a
  reasonable timeframe, I'll commit a change to that effect to all
  architectures' kernel udeb packages.
- Make sure that users who want to, can use it, without confusing users
  who just want to install Debian on a 'normal', non-diskless, system.
- Fix the kernel command line if necessary, and handle bootloader
  installers.
- Patch it so that it also supports name-based exports (a new feature in
  NBD, which currently is only supported in sid, but the plan is that it
  will be supported in wheezy as well).

I'm hoping to work on most of that during the coming month, also during
debcamp and debconf, but no guarantees.

Regarding the 'confusing' bit, I'm not sure that enabling partman-nbd by
default is necessarily the right thing to do. When partman-nbd is loaded
into the installer, the partman menu currently shows an option
'Configure the Network Block Device', where users can connect and
disconnect NBD devices. I believe this is fairly clear, but I'm probably
biased, and I can imagine it sounding unclear to uninitiated users. I
had considered using something more generic, like 'Configure networked
storage,' instead (which could then also be used for hypothetical
support for iSCSI, AoE or similar things), but that could confuse users
even more into thinking this was something specific to NAS devices,
which it isn't (well, not really).

Alternatively, there could be another flavour for 'diskless' installs,
which could be specifically tailored to installing to machines that
don't have local storage. However, such a flavour would probably not be
useful before we actually support more than just NBD.

Worst case, it should be possible to just make partman-nbd a udeb the
user can select during the 'load additional components' phase of the
installer, but I'd prefer not to have to tell users that they need to go
to expert mode if it can be reasonably avoided.

Thoughts?

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110706195551.gd3...@grep.be

Re: Installing to NBD

[Wouter Verhelst]

Hi,

Some updates:

On Tue, Jun 28, 2011 at 09:29:38PM +0200, Wouter Verhelst wrote:
 Hi,
 
 A while back, I blogged about success in installing to an NBD device[1].
 Unfortunately, that was only partial success; that is, while it works
 perfectly well as far as partman is concerned (and therefore also the
 base-installer step), beyond that things go a bit wrong:
 
 - /usr/lib/finish-install.d has 50release-dhcp-lease and 95umount.
   Obviously, if /target is mounted over the network somehow (through
   NBD, but we might have support for installing to, say, NFS or iSCSI in
   the future too, which would run into the same problem), umount (and
   anything that wants to access anything under /target, really) is going
   to fail if there's no network anymore. This obviously means that
   whatever is between priority 50 and 95 that wants to access /target is
   going to fail too.
   I would like to fix this by moving release-dhcp-lease to priority 97,
   so it sits between umount and reboot. Any objections to that? If I
   hear none within the next few days, expect a commit to that effect
   near the end of the week (or sooner if I get a go-ahead :).

I now have a locally patched netcfg that does the above, and it seems to
work. Any objections if I commit?

 - Once the installatoin is complete, the installer will attempt to
   install grub to the local hard disk. If we've installed Debian to a
   network target, this is Wrong(TM); we've not touched the local hard
   disk for the rest of the installation, so I believe the boot loader
   shouldn't do so either. Indeed, if you're installing to an NBD device,
   you might not even *have* a local hard disk. So when the user installs
   to a network device, I believe the installer should default to
   nobootloader, rather than grub, lilo, or whatever boot loader is used
   on the architecture we're using; but if the user still wants to
   install a boot loader anyway, that should probably also be possible.
   Can this be done? If so, how do I do that? Also, note that this
   shouldn't be hardcoded; if we're installing to root-on-NBD we don't
   want to touch the local hard disk, but if we're doing, say, root on
   local hard disk but /usr on NBD, then we /do/ want to install the
   bootloader to the local hard disk.

This is still an issue, and I'm not sure how to proceed.

I've been thinking that suggesting to mount /boot on a separate
filesystem (say, NFS or so) could be an option, and that I could then
write a pxelinux.0 and a pxelinux.cfg there. That would only work for
x86*, though. Or I could just unconditionally produce an error if
/target is mounted on an NBD device, so that the user can then choose to
either use the architecture's native boot loader (if that's what they
want), or use nobootloader and figure out how to netboot the thing all
by themselves.

Input is welcome.

 - The nbd-client package has an extensive debconf configuration
   interface. Would it be considered good form to programmatically
   preseed the answers to that debconf interface from partman-nbd, or
   should I find another way?

I've done this, and it seems to work; I don't think it's a serious
problem.

 - Finally, in order for root-on-NBD to work properly, the kernel needs
   to specify an extra boot parameter that tells the nbd initramfs script
   where the server is. I couldn't find any interface to specify random
   extra kernel parameters for the installed system; did I miss
   something?

I haven't found how to do this, yet. Anyone?

 At any rate, if I ignore the hang due to the network going down
 prematuraly, manually make sure the initrd is copied to my tftp server,
 and make sure to enter the correct values in the nbd-client debconf
 interface, the system will correctly boot off NBD to a login prompt, so
 I guess I'm almost there :-)
 
 For those who want to try, I've put an installer image for
 2.6.39-2-amd64 up on http://people.debian.org/~wouter/d-i/initrd.gz[2].
 Note that this is still slightly broken in that it doesn't run
 'apt-install nbd-client' yet, but I'm working on that.

That is fixed now, too. I've updated my initrd.gz, and beyond the above
issues, it seems to work.

I've moved the source to a git repository, and added it to the .mrconfig
file, so if you run 'mr update' you should get it.

Testing would be very welcome.

(one caveat: poweroff on the installed system won't work properly, due
to an issue with the initscripts package. I have a bug filed, so please
ignore).

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110629154912.gf20...@grep.be

Re: Installing to NBD

[Wouter Verhelst]

Hi,

(I seem to be mostly talking to myself here -- anyone awake? ;-)

On Wed, Jun 29, 2011 at 05:49:12PM +0200, Wouter Verhelst wrote:
 On Tue, Jun 28, 2011 at 09:29:38PM +0200, Wouter Verhelst wrote:
  - Once the installatoin is complete, the installer will attempt to
install grub to the local hard disk. If we've installed Debian to a
network target, this is Wrong(TM); we've not touched the local hard
disk for the rest of the installation, so I believe the boot loader
shouldn't do so either. Indeed, if you're installing to an NBD device,
you might not even *have* a local hard disk. So when the user installs
to a network device, I believe the installer should default to
nobootloader, rather than grub, lilo, or whatever boot loader is used
on the architecture we're using; but if the user still wants to
install a boot loader anyway, that should probably also be possible.
Can this be done? If so, how do I do that? Also, note that this
shouldn't be hardcoded; if we're installing to root-on-NBD we don't
want to touch the local hard disk, but if we're doing, say, root on
local hard disk but /usr on NBD, then we /do/ want to install the
bootloader to the local hard disk.
 
 This is still an issue, and I'm not sure how to proceed.
 
 I've been thinking that suggesting to mount /boot on a separate
 filesystem (say, NFS or so) could be an option, and that I could then
 write a pxelinux.0 and a pxelinux.cfg there. That would only work for
 x86*, though. Or I could just unconditionally produce an error if
 /target is mounted on an NBD device, so that the user can then choose to
 either use the architecture's native boot loader (if that's what they
 want), or use nobootloader and figure out how to netboot the thing all
 by themselves.
 
 Input is welcome.

So, AIUI, there isn't really a way for me to do this, since all
bootloader installers have hardcoded logic to decide they want to run;
so if I want to make this work correctly (so that none of the
bootloaders will attempt to write to disk by default), I'll have to
patch each and every one of them myself. Hrmpf.

Also, that other issue:

[...]
  - Finally, in order for root-on-NBD to work properly, the kernel needs
to specify an extra boot parameter that tells the nbd initramfs script
where the server is. I couldn't find any interface to specify random
extra kernel parameters for the installed system; did I miss
something?
 
 I haven't found how to do this, yet. Anyone?

seems to be pretty much in the same boat, in that each of the bootloader
installers implements their own logic to come up with a reasonable
kernel command line.

So if I want to implement this properly, I'll have to patch each and
every boot loader. I was hoping that that *wouldn't* be necessary.

I believe, however, that this would be a good opportunity to modularize
bootloader installers a bit. After all, they mostly all do the same
thing: figure out which kernel to load, load it off the disk somehow,
come up with a reasonable command line to pass to the kernel, and boot
it. Whether the boot loader is lilo, uboot, grub, emile, aboot, or
whathaveyou is just a detail, really. On top of that, having each and
every boot loader come up with its own way of figuring out what the
kernel command line should be sounds very much like a bad case of code
duplication to me, so it might be a good idea regardless.

So here's a suggestion for a way in which this could theoretically be
implemented. It's not very well thought out yet, but I'm hoping it
should get us in the right direction:

Bootloaders generally exist in two flavours: those who hardcode the
location of the kernel (either by copying it to a dedicated partition in
the manner of yaboot, or by hardcoding the blocks on which the kernel is
stored in the manner of lilo), and those who try to understand the
filesystem on which the kernel is stored, and read it by reading the
filesystem metadata.

So there should be a way for a bootloader installer to specify things
like 'I can boot off any filesystem, but the kernel must reside on one
disk' (lilo), 'I can boot off any filesystem in this list' (grub), 'I
don't care where the kernel is, I copy it to somewhere else'
(yaboot/flash-kernel), etc. Similarly, there should be a standardized
way for the installer to tell the bootloader this is the command line
the kernel should receive when booting, this should be the default
kernel, etc. It's probably a good idea to do this in a way that it can
be preseeded, too.

So I'm thinking the following:
- Add a directory (say, /lib/bootloaders) that signal somehow (through
  flag files) what capabilities the different bootloaders available for
  the current (sub)architecture have available. This way, partman can
  provide warnings to the user if a particular configuration is not
  supported on the current subarchitecture, and main-menu can skip
  configuring a bootloader if it doesn't support the current

Re: Installing to NBD

[Wouter Verhelst]

On Wed, Jun 29, 2011 at 05:36:03PM -0400, Lennart Sorensen wrote:
 On Wed, Jun 29, 2011 at 11:22:51PM +0200, Wouter Verhelst wrote:
  seems to be pretty much in the same boat, in that each of the bootloader
  installers implements their own logic to come up with a reasonable
  kernel command line.
  
  So if I want to implement this properly, I'll have to patch each and
  every boot loader. I was hoping that that *wouldn't* be necessary.
  
  I believe, however, that this would be a good opportunity to modularize
  bootloader installers a bit. After all, they mostly all do the same
  thing: figure out which kernel to load, load it off the disk somehow,
  come up with a reasonable command line to pass to the kernel, and boot
  it. Whether the boot loader is lilo, uboot, grub, emile, aboot, or
  whathaveyou is just a detail, really. On top of that, having each and
  every boot loader come up with its own way of figuring out what the
  kernel command line should be sounds very much like a bad case of code
  duplication to me, so it might be a good idea regardless.
 
 Grub2 is modular, and I think it is already to a large extent doing what
 you suggest.  It supports many different system architectures (included
 being the complete firmware on some of them) and has modular plugins
 for filesystems and various OS kernel types.

That's grub2, not grub-installer. I'm talking about d-i exclusively
here.

grub-installer will install grub or grub2 if we're on PC, depending on
what makes most sense.

 uboot supports a lot of architectures, but isn't modular in the same
 way as grub2.
 
  So here's a suggestion for a way in which this could theoretically be
  implemented. It's not very well thought out yet, but I'm hoping it
  should get us in the right direction:
  
  Bootloaders generally exist in two flavours: those who hardcode the
  location of the kernel (either by copying it to a dedicated partition in
  the manner of yaboot, or by hardcoding the blocks on which the kernel is
  stored in the manner of lilo), and those who try to understand the
  filesystem on which the kernel is stored, and read it by reading the
  filesystem metadata.
 
 That's the two common flavours on x86 PCs.  I am not sure that is accurate
 for other systems.  yaboot supports filesystem reads by the way.

Yes, but only if you use a particular kind of filesystem for /boot. If
you don't, then yaboot will need a yaboot-specific filesystem that it
copies the kernel to.

 Some uboot installs have a hardcoded memory location in flash to load
 from, while other uboot installs read filesystems like grub.
 
  So there should be a way for a bootloader installer to specify things
  like 'I can boot off any filesystem, but the kernel must reside on one
  disk' (lilo), 'I can boot off any filesystem in this list' (grub), 'I
  don't care where the kernel is, I copy it to somewhere else'
  (yaboot/flash-kernel), etc. Similarly, there should be a standardized
  way for the installer to tell the bootloader this is the command line
  the kernel should receive when booting, this should be the default
  kernel, etc. It's probably a good idea to do this in a way that it can
  be preseeded, too.
  
  So I'm thinking the following:
  - Add a directory (say, /lib/bootloaders) that signal somehow (through
flag files) what capabilities the different bootloaders available for
the current (sub)architecture have available. This way, partman can
provide warnings to the user if a particular configuration is not
supported on the current subarchitecture, and main-menu can skip
configuring a bootloader if it doesn't support the current
configuration.
 
 Different boot loaders have vastly different feature sets.  Some can
 only support one kernel at a time (essentially no config) while others
 provide the user with a menu and are sometimes even dynamic at supporting
 additional kernels and OSs.  I don't know how you would make a universal
 interface to that.

It's not necessary to support the full feature set of all boot loaders
with this interface; just the bits that could be relevant to d-i.

  - Add a hidden debconf template (say,
debian-installer/bootloader/arguments) that stores the arguments which
should be specified to the kernel. Bootloades should use that template
rather than their own logic. As an added bonus, this could allow a
user to preseed the kernel command line, should the need arise.
  - Presumably the template may need to be split up to accomodate for
bootloaders who care about the difference between arguments that
specify the initrd, arguments that specify the root device (etc), and
'other arguments'.
  - Add new udeb (say, bootloader-support) that contains the generalized
code to do all of the above, and reduce the bootloader installer
packages' code to little more than read data and write boot record.
  
  Thoughts?
 
 Interesting question, but I don't know if it is even theoretically

Installing to NBD

[Wouter Verhelst]

Hi,

A while back, I blogged about success in installing to an NBD device[1].
Unfortunately, that was only partial success; that is, while it works
perfectly well as far as partman is concerned (and therefore also the
base-installer step), beyond that things go a bit wrong:

- /usr/lib/finish-install.d has 50release-dhcp-lease and 95umount.
  Obviously, if /target is mounted over the network somehow (through
  NBD, but we might have support for installing to, say, NFS or iSCSI in
  the future too, which would run into the same problem), umount (and
  anything that wants to access anything under /target, really) is going
  to fail if there's no network anymore. This obviously means that
  whatever is between priority 50 and 95 that wants to access /target is
  going to fail too.
  I would like to fix this by moving release-dhcp-lease to priority 97,
  so it sits between umount and reboot. Any objections to that? If I
  hear none within the next few days, expect a commit to that effect
  near the end of the week (or sooner if I get a go-ahead :).
- Once the installatoin is complete, the installer will attempt to
  install grub to the local hard disk. If we've installed Debian to a
  network target, this is Wrong(TM); we've not touched the local hard
  disk for the rest of the installation, so I believe the boot loader
  shouldn't do so either. Indeed, if you're installing to an NBD device,
  you might not even *have* a local hard disk. So when the user installs
  to a network device, I believe the installer should default to
  nobootloader, rather than grub, lilo, or whatever boot loader is used
  on the architecture we're using; but if the user still wants to
  install a boot loader anyway, that should probably also be possible.
  Can this be done? If so, how do I do that? Also, note that this
  shouldn't be hardcoded; if we're installing to root-on-NBD we don't
  want to touch the local hard disk, but if we're doing, say, root on
  local hard disk but /usr on NBD, then we /do/ want to install the
  bootloader to the local hard disk.
- The nbd-client package has an extensive debconf configuration
  interface. Would it be considered good form to programmatically
  preseed the answers to that debconf interface from partman-nbd, or
  should I find another way?
- Finally, in order for root-on-NBD to work properly, the kernel needs
  to specify an extra boot parameter that tells the nbd initramfs script
  where the server is. I couldn't find any interface to specify random
  extra kernel parameters for the installed system; did I miss
  something?

At any rate, if I ignore the hang due to the network going down
prematuraly, manually make sure the initrd is copied to my tftp server,
and make sure to enter the correct values in the nbd-client debconf
interface, the system will correctly boot off NBD to a login prompt, so
I guess I'm almost there :-)

For those who want to try, I've put an installer image for
2.6.39-2-amd64 up on http://people.debian.org/~wouter/d-i/initrd.gz[2].
Note that this is still slightly broken in that it doesn't run
'apt-install nbd-client' yet, but I'm working on that.

Regards,

[1] http://grep.be/blog/en/computer/debian/d-i/nbd
[2] If you want to try on a different architecture, you'll need to do
the following:
- get http://people.debian.org/~wouter/d-i/partman-nbd_0.1_all.udeb
  and put it in localudebs

- Add

Package: nbd-modules
Depends: kernel-image

  to .../packages/linux-kernel-di-arch-2.6/package-list

- Create a file
  .../packages/linux-kernel.../modules/flavour/nbd-modules with as
  contents

#include nbd-modules

- build the l-k-di package, and put nbd-modules-version in localudebs,
  too.

- add partman-nbd to .../installer/build/pkg-lists/monolithic/arch.cfg

Then, build the monolithic flavour as usual.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


signature.asc
Description: Digital signature

Bug#623939: os-prober: Errors during kernel upgrade

[Wouter Bolsterlee]

Package: os-prober
Version: 1.45
Followup-For: Bug #623939

Fwiw, this causes errors like these when e.g. upgrading kernel packages:

  /usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)

The updated patch already attached to this bug report fixes this problem, so
please upload a new version. Thanks!


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages os-prober depends on:
ii  libc6 2.11.2-13  Embedded GNU C Library: Shared lib

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110424231534.18329.26167.reportbug@him.townsville

Re: Complaint about apt installing Recommends by default.

[Wouter Verhelst]

On Sun, Mar 21, 2010 at 04:37:57PM -0400, Eric Renfro wrote:
 I'm seriously.. VERY seriously enraged by the very thought of Debian
 moving to preconfigure and install Recommends by default. This is
 the worst decision Debian could ever make. That very one thing is
 one of my biggest complaints about Ubuntu doing so and strongly
 /VERY/ strongly insist it not be done.

Actually, the fact that Debian has not done so for a long time in the
past was one of apt's most-reported bugs, and rightly so.

As a result of that, many packages listed in Recommends: are now more of
a strong suggests rather than a weak depends, as recommends are
supposed to be; and as such, the current default behaviour is indeed not
exactly perfect.

However, given time, this will fix itself.

 I have been a Debian user since way back when, and I completely
 disagree with this decision. Recommends should NOT be treated as if
 Required, ever.

They are not.

[...]
 I will firmly say this. It is completely stupid to, by default,
 install Recommends. In the past, only Ubuntu has ever done this, and
 it is by far, one of the stupidest things they have ever done.
 Absolutely /no/ other reasonable distribution does this.

That is because no other reasonable distribution has a concept even
remotely similar to Recommends, since rpm does not know suggests or
recommends, only depends.

Don't lose your sleep over it.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100321234749.gh21...@celtic.nixsys.be

Bug#447755: Minidisk support (was: Installation Question)

[Wouter Verhelst]

On Thu, Dec 24, 2009 at 01:18:08PM -0500, Stephen Powell wrote:
 On 2009-12-24 at 12:32:18 -0500, Frans Pop wrote:
  The output of the following command would be useful as well:
  # parted /dev/device print
 
 bash: parted: command not found
 
 Of course, I wasn't running D-I at the time, I was running the
 installed system.  Do I have to run D-I?  Or is there a package
 that I can install (which one) on the installed system that will
 give you the same information?

Yes, the parted package...

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: debian

[Wouter Verhelst]

Hi Douglas,

On Wed, Nov 18, 2009 at 10:50:18AM -0600, Douglas Peters wrote:
 sorry for contacting you directly, I am normally just and end user but was not
 able to find a proper way to submit this, as there is not a lot of info for
 debian on ps3 currently available.

In this particular case, the right mailinglist is probably the one where
d-i development is discussed: debian-boot@lists.debian.org

 Currently the daily build labled both 11-16-09 and 11-17-09 both hang
 at 37% on the installation of packages no matter what is selected.  I
 tried even unmarking all selectable sets, including base system and
 desktop system and got the same problem on both installers every time.

It would probably help if you could hit Alt+F4 at that point, which will
bring up the logs of what is happening at that time. It may be the case
that the installer is waiting for something, or that something broke, in
which case the logs will show that.

 The current lenny installer 5.0.3  errors when trying to connect to a
 repository. It says  no repository available for the current type.
 Sorry that isn’t an exact error phrase, it was late and I didn’t think
 to right it down.  I tried several repositories and had the exact same
 thing happen every time.

If you could please retry and indeed write down the error so we know
exactly what's going on, that would help in debugging the problem.

(if not, I'm about to swap my ps3 slim for my brother's older one, so I
can install Debian on it -- I'm sure I'll encounter similar issues then,
but of course there's no guarantee)

 All of the installers that I tried were the net install.
 
 Through a lot of searching I found the image located at  http://
 people.debian..org/~wart/ps3/mini.iso   and have had some success with
 it. the installer completes, and using kboot to directly boot the
 install with a kernel off of my USB drive has booted the system. The
 password and user account that were created during the install are no
 longer usable.  I formatted the drive before hand and it was a clean
 install so there should have been no residual install that it could
 have booted too.  Just in case I did try any password I could have
 possibly used and was not able to log in.  also I verified this all by
 re-running the installer 3 times and had the exact same problem.

Are you sure the keyboard setup went correctly? This is something that's
been in a bit of flux not that long ago, so it might be that something
broke there.

[...]
 First I want to thank you for supporting the ps3 enough to release a custom
 mini.iso for it, with out it I feel none of this would be possible at all.
 
 Second I want to ask if any of the features that are in the mini.iso,
 that make it able to complete on the ps3, are going to make it into
 the real ppc debian installer? 

I hope to work on that once I have my Debian-supporting ps3. Then again,
I have many projects, so might not find the time. We'll see.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#552067: Install process forgets the CD if left alone for long time

[Wouter Verhelst]

On Sun, Oct 25, 2009 at 05:16:01AM +0100, Frans Pop wrote:
 The most likely explanation looks to me that the system (temporarily?) 
 loses connection with the device and has some problem identifying it again 
 when you resume the installation and the connection to the device is 
 reactivated.

Indeed. I'd say the system tries to suspend the USB CDROM when it's
unused (which makes sense), but that the CDROM (or its driver) is broken
and does not properly support it; that it somehow disconnects and
reconnects itself upon suspend or resume.

The result of this would not be very visible under Windows (where you'd
at most get some spurious error messages about open files not being
available anymore, if that), so it's not unlikely that it's actually a
hardware bug.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org