(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: DVD and live
Image version: DVD and live
Date: <Date and time of the install>

Machine: Thinkpad X1 Carbon Gen 13
Partitions: <df -Tl will do; the raw partition table is preferred>


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

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

Comments/Problems:

<Description of the install, in prose, and any thoughts, comments
      and ideas you had during the initial install.>

When installing Trixie via Calamares and if using btrfs as the filesystem for
the system, there's only one subvolume (@rootfs) where all the files are
installed. However, if using the live DVD, two subvolumes are created instead
(@ and @home). Not a major problem, but it's inconsistent. Some software, for
example Timeshift, expects the latter layout (two subvolumes @ and @home),
instead of just one subvolume, to function properly.

Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.

What do you mean exactly by "live DVD" and "Calamares". Calamares is the
graphical installer in the live session, so this is confusing.

Can you indicate the full ISO image name you used and how you started
the installer in both cases ?

Like in the other ticket, I used two ISOs, both from April 18th

- debian-live-testing-amd64-gnome.iso
- debian-testing-amd64-DVD-1.iso

debian-live-testing-amd64-gnome.iso with live GNOME session and clicking on the "Install Debian":
  - Creates two btrfs subvolumes (@ and @home)

debian-live-testing-amd64-gnome.iso with either Graphical installer or Text installer via the boot menu:
  - Creates one btrfs subvolume (@rootfs)

debian-testing-amd64-DVD-1.iso with either Graphical installer or Text installer:
  - Creates one btrfs subvolume (@rootfs)

Makes sense. The partitioning is the same in the installer launched from
either DVD or live boot menu, but may be different in Calamares launched
frome the live session.

For sure it would be nice if both installers were aligned. What do d-i
and live teams think ?

Additionnally, shouldn't d-i rescue mode also support Calamares layout ?

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

Calamares should not be doing its own thing.  It's also worth verifying
that Calamares is not enabling options that will trigger btrfs corner
cases--unstable features are fine for Fedora or Arch, but aren't
appropriate defaults for Debian stable (opt-in is of course always fine,
since that's liberty).  Would you please point me to the source we use
to configure/preseed Calamares for the live-cds?

Are you sure there is a Calamares layout and that this isn't just
defacto Ubuntu layout?  There weren't any discussions about this.

Have you been able to track down those discussions where we decided on
@rootfs?  One of the arguments against installing to '@' was that we're
letting Ubuntu claim that namespace, we're letting Fedora claim 'root'
(and rootfs), and we're staying out of their way.  I was surprised to
learn that people use btrfs in this way, but it's not that much of a
stretch from using one VG to hold multiple distribution's LVs.

Another topic in that (and subsequent) discussions is basically this:

  1. Ubuntu never implemented subvolume creation, because they chose
  ZFS.  At some point their installer began to statically create @ and
  @home.
  2. Fedora and SUSE implemented full support for any custom subvolume
  topology.
  3. Due to Ubuntu's popularity, some developers exclusively support
  Ubuntu's static nonconfigurable default as a kind of emergent
  bug-for-bug API.
  4. This results in DFSG-free software having an Ubuntu-specific
  implementation; DFSG-free software should also work on Debian, Fedora,
  SUSE and everywhere else.  It also result in utterly wasting the time
  and effort the Fedora and SUSE developers took to implement an actual
  solution rather than a stop-gap measure.
  5. Our users want our installer to have the same basic features as
  Fedora and SUSE.
  6. Implementing this is a waste of time if our users will only use it
  to make their Debian systems behave like Ubuntu so that
  Ubuntu-specific software will work on their Debian systems.
  7. We need to support the effort for portable software.

Regards,
Nicholas

https://salsa.debian.org/qt-kde-team/extras/calamares/-/merge_requests/7

D-I will need to start creating @home for consistency