Dear Maintainer,

If preseeding the debian-9.2-amd64-netinst installer, it's not possible to
correct a failed automatic partitioning.
Installation only claims that there's no root file system chosen and I should
correct it but I can't get past that screen, even when rescanning harddisks.

Preseed.cfg regarding partitioning:
d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string crypto
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman-auto-crypto/erase_disks boolean false
d-i partman-auto-lvm/guided_size string max
d-i partman-auto-lvm/new_vg_name string crypt

Hi,

Additional information:
Preseeding was configured for /dev/sda but the system did only contain a
NVMe drive so /dev/sda pointed to the installation usb stick.

Best wishes
Michael

control: reassign -1 debian-installer

Dear maintainers,

I think this bug is specific to partman.
Partman should allow rescanning devices and recognize NVMe devices when
preconfigured with /dev/sda.
Alternatively, there should be an installation target "largest disk" or
something similar.

Best wishes
Michael

control: reassign -1 partman-auto


Dear maintainers,

I think this bug is specific to partman-auto.
Partman should allow rescanning devices and recognize NVMe devices when
preconfigured with /dev/sda.
Alternatively, there should be an installation target "largest disk" or
something similar.

Best wishes
Michael

Hi Michael,

Michael Kesper <mkesper@schokokeks.org> (2017-11-06):
have is NVMe… Don't feed wrong info through preseed in the first place?

Also, “largest disk” doesn't seem too good an idea, as evidenced here:
https://lists.debian.org/debian-boot/2017/11/msg00028.html


KiBi.

Dear Cyril,

Yes sure but why can't I correct it after the fact?
Even "rescanning disks" does not let you chose any other disks.

Is there a way of chosing "first internal disk" then?
Imagine I want to create one installation medium for laptops which only
differ whether they are set up with a NVM or a sata SSD.
I did not find any documentation helping me with this.

Best wishes
Michael

I can't think of any reliable way to determine what is an internal or
external disk, and the concept of 'first' doesn't even have meaning.

This is true, but I don't think it's a good reason not to implement a
mostly-reliable heuristic.

If there are multiple disks, there are usually going to be just 2 of
them, one of which contains the installer.  In any installer build
other than netboot, it will look for its own disk in order to load
udebs.  Once it has done that, it can determine that the other disk is
the one to install on.  That's a pretty good heuristic.

Aside from that, we can also make a guess based on the bus type:

- ATA: probably internal
- NVMe: probably internal
- USB: probably external
- MMC/SD: ambiguous (eMMC must be internal, and Linux has a notion of
'non-removable' slots, but I don't think userland has this info)

If we could get more information about MMC/SD slots then we should be
able to implement an heuristic that would work for >99% of cases.

Ben.

I think more than one disk in the machine isn't that unusual.

eSATA is not that unusual.

You can certainly try to make a good guess, but it certainly still needs
to be confirmed.

Is there any reason why the following method wouldn't be an
improvement?:

1) get a list of disks
2) identify the disk used by the installer
3) exclude the disk found at #2
4) present modified list as target disks for installation
5) unless in expert mode, where a user could use one partition of a
disk as the installation source and another partition as the
installation target.  I'm not sure how important #5 is, but maybe some
users want to be able to do this?

Cheers,
Nicholas

The context of this bug is that Michael wants to partition a single
disk - not set up a RAID.  I think it *is* unusual that Debian would be
installed on a single disk of a system that contains multiple internal
disks.  If someone really wants to pre-seed partman in that case then
they would have to specify the device name just as they do now
(presumably using /dev/disk/by-path/...).

That seems to defeat the point of pre-seeding.

Ben.

I won't participate in this

Nicholas D Steeves <nsteeves@gmail.com> (2017-11-10):

How do you do 2?

Last I touched this, nothing obvious appeared in d-i to know what the
installer was booted from. ISTR having suggested at the time that
bootloaders could set something to help d-i figure out where it booted
from, but I don't think anything happened in this area since then.


KiBi.

OK, This Is a crazy Idea, but . . . When generating Installer images, they
get various readmes and so on, and I believe one of them includes version
information, so we can parse that file for the version number, compare it
with the one in the initrd (to be added). This handles the common cases of
cd (overkill as cds are read only) and USB (presumably most important), but
fails on net-install (where it is not needed). We can have installer loader
scripts copy the version info file to mark the drives they are using which
should catch most of the rest of the cases.

A variation of this is to have a pseudo random token in the version file
which is passed on the command-line to the installer instead of modifying
the initrd. This has the advantage that we could have special case values
for net-boot to skip the scan. (ie if the token was a hexadecimal value but
the special case was the word netboot.

both cases make identifying and protecting partitions used to store
archives and iso images easy by manually placing the version file.

Hi Kibi,

I see Ben Hildred send a reply before I finished this draft :-)  I'll
reply to it separately.
that /proc/cmdline could be used.  The next idea was to tie it to the
installer build somehow.  eg:

/dev/disk/by-uuid/2017-10-10-10-09-57-00 for Debian 9.2.1.  Is that only for amd64?
 * is a link that points to a device name...remove that disk from the list
 * not necessary for optical media IIRC
 * how hard would it be to make the installer aware of this?
 * Is PTUUID better? (eg: 5c91ec76) Or does this depend on blkid?

Alternatively, and expensive fall-back like this:
use existing code to get list of disks and partition
for i in partitions_or_unpartitioned_disks; do
  mount $i \
    && check for something that indicates it's Debian installation media \
    && check for specific version of something (would need a hook when building media to embed this)
    or maybe check for existence of initrd.gz in $i, unpack it \
    and compare checksum of something on initrd_used_to_boot_installer and initrd_found_on_$i \
    && rm disk_for_$i from list
    or alternatively, maybe just check for a file that indicates "This is Debian installation media"
done

Alternatively all disks that match something that indicates "This is
Debian installation media", unless in expert mode.  This breaks
installation from one drive that has been prepared as installation
media to another drive that has been prepared as installation media
(possibly with a different version),

Most these methods break down for custom media that uses
grub-imageboot...that's the case I don't know how to solve, but maybe
the following would work: use /proc/cmdline and then loop-back mount
the image, check for match between file on running system and mounted
image, and remove the parent disk/partition from the list?

Cheers,
Nicholas

net-boot media be excluded as an installation target--except for the
expert case.

Another feature that could be piggybacked on the "mount block device
and identify if it's Debian installation media" is OS identification.
It's been so many years since I dual-booted with another OS that I
don't know if this functionality already exists.  If it does exist,
I'm guessing that is where this new "Identify installation media"
could be added.

Re: the identification step:

I don't think it's crazy :-)  Do you know if such a magic file already
exists (especially if the installer build was recorded)?

Can busybox-provided cat, grep, cksum and cmp provide strong enough
magic file match, or do you think we also need a
/sys/.../something/uuid check as well?

Cheers,
Nicholas

On Mon, Nov 13, 2017 at 1:17 PM, Nicholas D Steeves <nsteeves@gmail.com> wrote:

I was not talking about the net-boot cd, (that is cd or in some cases usb)
but a tfttp boot or similar where  there is no install media at all, and
the value would be a speed hack only.

If we do this we might not want to special case netboot

the netboot.tar.gz file has version.info which I was thinking of which is
not currently included in mini.iso, but f1.txt has version and build date
(lines 3 and 4 in the one I checked).

standard tools should do it.