Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Cyril Brulebois]

Hi Ismail,

Ismail Arif  (2023-05-19):
> Boot the installer in EFI on virtualbox 7.0.x, select every install
> options and all results in a grey screen if in text mode and an error
> can't open display:0 on graphical gtk mode. In BIOS mode, everything
> works fine

Nice! Could you please test an image for me and tell me if it helps?
  https://people.debian.org/~kibi/bug-drm-vs-uefi/mini-hackhackhack.iso

Backstory is https://bugs.debian.org/1036019 for similar issues with
different graphics adapter under QEMU, only in UEFI mode; I wanted to
include the VirtualBox DRM module at first but couldn't find anyone to
reproduce the issue first, so I dropped that part for RC 3. It's trivial
to add back to my workaround if you can confirm if helps.

(And when I say “nice” I mean I'm sorry you're experiencing troubles,
but your bug report has very interesting details, which we were lacking
from other older bug reports, which were pretty vague.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1023472: Workaround implemented for live images

[Roland Clobus]

Hello Cyril,

On 19/05/2023 00:59, Cyril Brulebois wrote:

Speaking as someone who happen{ed,s} to come across live-build things for
unrelated reasons:

Roland Clobus  (2023-05-18):

I've implemented a workaround for the live images at [1].
As a result, the xfwm4 desktop manager is now the only desktop manager.


This seems to have been merged in live-build master.

I'm not sure whether this is a workaround or a real fix; if that's the
latter, it should probably be reassigned to live-build?


I consider it a workaround, because the netinst D-I is still affected. 
If the LXQt desktop is selected in the installer, the Wayland desktop 
manager is used instead of xfwm4.

The MR for a proposed fix (in tasksel) is at [1].


Two questions, with RC 4 in mind (and as a reminder, while I'll be dealing
with D-I Bookworm RC 4 with a focus on… the installer primarily, live images
are being built and released at the same time):
  - Is there a live-build upload planned to publish this fix to unstable?


There is no (direct) need for an upload due to this workaround. The 
building process is primarily tied to git, not to the Debian archive:
The daily live images are generated reproducibly by using the timestamp 
of the last DAK run to time travel back to the corresponding git commit 
of live-build.
That same procedure is used for the weekly live builds (which have not 
been as thoroughly tested as the daily builds in openQA [3]).



  - With or without an extra upload, is there a plan to ask for an unblock?
It seems best to ship in $codename the tools being built to build
$codename. (Similar example: debian-cd.)


The script to build the live images is not present in any Debian 
package, it lives only in Salsa [2].


With kind regards,
Roland Clobus

[1] https://salsa.debian.org/installer-team/tasksel/-/merge_requests/23
[2] 
https://salsa.debian.org/live-team/live-build/-/blob/master/test/rebuild.sh

[3] https://openqa.debian.net/group_overview/14


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Cyril Brulebois]

Ismail Arif  (2023-05-19):
> Thanks for the response, I've downloaded and tried to run the installer by
> using the iso provided, however the issue still persists, I have a
> screenshot of the error that i believe is still the same error that I
> received before.

So I'm seeing different errors on that screen. The fbdev video driver
tends to trigger error messages but those shouldn't be an issue. The
core keyboard thing seems more serious.

I'll try and provide you with a full netinst image, so that you have
both Graphical Install and (text…) Install options. My patch should fix
graphics-related issues, in both text and graphical modes. At first
glance it looks like your X might have another issue preventing it from
starting.

Could you please share a screenshot of the grey screen when booting the
RC 3 in text mode?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Ismail Arif]

Here's the screenshot for both the graphical and text modes,

First file should be the graphical mode, and the second is the grey screen
in text mode

The grey screen is kind of like a background for a shell, but typing and
entering any words or commands of any kind seems to be useless (no command
output, the commands typed appears but that's just it)

The third screenshot is where I tried to type any words/commands. but the
installer does respond to ctrl+alt+del signal which rebooted the vm



On Fri, May 19, 2023 at 3:38 PM Cyril Brulebois  wrote:

> Ismail Arif  (2023-05-19):
> > Thanks for the response, I've downloaded and tried to run the installer
> by
> > using the iso provided, however the issue still persists, I have a
> > screenshot of the error that i believe is still the same error that I
> > received before.
>
> So I'm seeing different errors on that screen. The fbdev video driver
> tends to trigger error messages but those shouldn't be an issue. The
> core keyboard thing seems more serious.
>
> I'll try and provide you with a full netinst image, so that you have
> both Graphical Install and (text…) Install options. My patch should fix
> graphics-related issues, in both text and graphical modes. At first
> glance it looks like your X might have another issue preventing it from
> starting.
>
> Could you please share a screenshot of the grey screen when booting the
> RC 3 in text mode?
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Cyril Brulebois]

Cyril Brulebois  (2023-05-19):
> I'll try and provide you with a full netinst image, so that you have
> both Graphical Install and (text…) Install options. My patch should fix
> graphics-related issues, in both text and graphical modes. At first
> glance it looks like your X might have another issue preventing it from
> starting.

https://people.debian.org/~kibi/bug-drm-vs-uefi/netinst-hackhackhack+vbox.iso

(Since its size isn't negligible, it's scheduled for deletion two weeks
from now.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Ismail Arif]

Seems the problem still persists on both modes, so it might be something
else.

In bullseye there's no such issues

Trying to run the vm in windows too seems to output the same issue.

Either it's a virtualbox issue or a bookworm issue is yet to be identified,
as booting the image on my baremetal efi seems fine, also in vmware
workstation, there is no issue.



On Fri, May 19, 2023 at 3:56 PM Cyril Brulebois  wrote:

> Cyril Brulebois  (2023-05-19):
> > I'll try and provide you with a full netinst image, so that you have
> > both Graphical Install and (text…) Install options. My patch should fix
> > graphics-related issues, in both text and graphical modes. At first
> > glance it looks like your X might have another issue preventing it from
> > starting.
>
>
> https://people.debian.org/~kibi/bug-drm-vs-uefi/netinst-hackhackhack+vbox.iso
>
> (Since its size isn't negligible, it's scheduled for deletion two weeks
> from now.)
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Cyril Brulebois]

Ismail Arif  (2023-05-19):
> Seems the problem still persists on both modes, so it might be something
> else.
> 
> In bullseye there's no such issues
> 
> Trying to run the vm in windows too seems to output the same issue.
> 
> Either it's a virtualbox issue or a bookworm issue is yet to be identified,
> as booting the image on my baremetal efi seems fine, also in vmware
> workstation, there is no issue.

Yeah, from the screenshot you shared, it didn't look like the same
framebuffer issue I've been chasing lately (wrong width, height, bits
per pixel being reported, leading to corrupted graphics in both modes).

I'll keep *not* including vboxvideo.ko at this time, and we'll need
someone to understand what's going on, or at least what changed and
when…

If you feel like walking down memory lane, you could try earlier Alpha
or RC releases, and let us know which one(s) is(are) affected by this
issue. You'll find all netinst images under these directories:
  https://cdimage.debian.org/cdimage/bookworm_di_alpha1/amd64/iso-cd/
  https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/
  https://cdimage.debian.org/cdimage/bookworm_di_rc1/amd64/iso-cd/
  https://cdimage.debian.org/cdimage/bookworm_di_rc2/amd64/iso-cd/
  https://cdimage.debian.org/cdimage/bookworm_di_rc3/amd64/iso-cd/

Thanks for the report and your follow-ups so far!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1036310: bookworm installer hangs in efi mode on virtualbox 7.0.8

[Ismail Arif]

I've downloaded and tested the images. and it seems the issue has been
present since alpha 1


On Fri, May 19, 2023 at 4:11 PM Cyril Brulebois  wrote:

> Ismail Arif  (2023-05-19):
> > Seems the problem still persists on both modes, so it might be something
> > else.
> >
> > In bullseye there's no such issues
> >
> > Trying to run the vm in windows too seems to output the same issue.
> >
> > Either it's a virtualbox issue or a bookworm issue is yet to be
> identified,
> > as booting the image on my baremetal efi seems fine, also in vmware
> > workstation, there is no issue.
>
> Yeah, from the screenshot you shared, it didn't look like the same
> framebuffer issue I've been chasing lately (wrong width, height, bits
> per pixel being reported, leading to corrupted graphics in both modes).
>
> I'll keep *not* including vboxvideo.ko at this time, and we'll need
> someone to understand what's going on, or at least what changed and
> when…
>
> If you feel like walking down memory lane, you could try earlier Alpha
> or RC releases, and let us know which one(s) is(are) affected by this
> issue. You'll find all netinst images under these directories:
>   https://cdimage.debian.org/cdimage/bookworm_di_alpha1/amd64/iso-cd/
>   https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/
>   https://cdimage.debian.org/cdimage/bookworm_di_rc1/amd64/iso-cd/
>   https://cdimage.debian.org/cdimage/bookworm_di_rc2/amd64/iso-cd/
>   https://cdimage.debian.org/cdimage/bookworm_di_rc3/amd64/iso-cd/
>
> Thanks for the report and your follow-ups so far!
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1023472: Workaround implemented for live images

[Cyril Brulebois]

Hi,

Roland Clobus  (2023-05-19):
> I consider it a workaround, because the netinst D-I is still affected.
> If the LXQt desktop is selected in the installer, the Wayland desktop
> manager is used instead of xfwm4.
> The MR for a proposed fix (in tasksel) is at [1].

OK, I'll leave that one to people more used to tasksel than me.

> There is no (direct) need for an upload due to this workaround. The
> building process is primarily tied to git, not to the Debian archive:
> The daily live images are generated reproducibly by using the
> timestamp of the last DAK run to time travel back to the corresponding
> git commit of live-build.
> That same procedure is used for the weekly live builds (which have not
> been as thoroughly tested as the daily builds in openQA [3]).

[…]

> The script to build the live images is not present in any Debian
> package, it lives only in Salsa [2].

OK. I just wanted to make sure to raise that topic, I'm fine with
whatever the live team ends up (not) doing. No stone unturned, etc.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1036315: rootskel-gtk: Alpha/missing pixels on the borders of the PNG banner

[Cyril Brulebois]

Package: rootskel-gtk
Version: 12.0.1
Severity: normal

Hi,

When building the package on bullseye, I'm getting transparency on both
left and right borders. When building it on sid, I'm get that at the
bottom. It would be great if we had some better or at least reproducible
export.

Since this was ringing a bell, I've just checked the debian-installer
repository and I already tweaked the file a little there, for similar
reasons:
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/698311cb81e26512a86a7b94682367cd047f491c


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1036317: rootskel-gtk: Please consider shipping a “dark” version of the banner

[Cyril Brulebois]

Package: rootskel-gtk
Version: 12.0.1
Severity: normal

Hi,

Spotted while toying with the idea of having some code to expand the
banner automatically on the left and/or on the right, and finding the
cdebconf-gtk code handling the “dark” banner. Trying theme=dark, I'm
getting the same banner, and that's perfectly normal at this point
since it's just a symlink to the regular banner.

I have no idea whether the current situation is OK, I just thought I'd
open a bug so that shipping a specific banner could be considered.

Screenshot attached. Note that I used RGB→indexed conversion to limit
the file size, making sure the report wouldn't get lost in transit.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1036319: installation-reports: Multiple Installation report for RC3 on openQA

[Roland Clobus]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: p...@hands.com


Boot method: CD in openQA
Image version:
https://cdimage.debian.org/cdimage/bookworm_di_rc3/amd64/iso-cd/debian-
bookworm-DI-rc3-amd64-netinst.iso
Date: 

Machine: openQA x86_64 qemu video: qxl memory: 2GB. SeaBIOS and Tianocore UEFI
(non-secure)

Comments/Problems:

See
https://openqa.debian.net/tests/overview?distri=debian&version=bookworm&build=DI_rc3&groupid=10

On the page 'Logs & Assets' the file '_graphical_wait_login-journal.txt'
contains the output of journalctl.

The following issues are detected:
Cinnamon: For BIOS boot, on first boot, a dialog is shown 'You are currently
running in fallback mode'. The UEFI installation works fine.

GNOME: For BIOS boot, on first boot, a dialog is shown 'On no! Something has
gone wrong'. The UEFI installation works fine.
The journalctl file has the following suspect snippet:

May 18 17:16:17 debian org.gnome.Shell.desktop[610]: LLVM ERROR: 64-bit code
requested on a subtarget that doesn't support it!
May 18 17:16:17 debian org.gnome.Shell.desktop[610]: == Stack trace for context
0x55aacc0f37c0 ==


KDE: For BIOS boot, on first boot, the screen stays black (no plymouth splash
screen is shown). The UEFI installation works fine.
The journalctl file has the following suspect snippet:

May 18 18:14:03 debian systemd-coredump[584]: Process 536 (sddm-greeter) of
user 110 dumped core.


LXQt: For BIOS boot, on first boot, the screen stays black (no plymouth splash
screen is shown). Due to #1023472, this might be the same issue as for KDE.
The UEFI installation shows the KDE login, as reported in #1023472.

The other desktops (LXDE, Mate and XFCE) install correctly in both BIOS and
UEFI installations.

In all cases, the installation itself runs fine. (Even though a screensaver
might not be ideal -> #787279). It is 'only' the first boot that causes issues.

Note that some issues on the public openQA server (running on AMD hardware)
were not reproducible on my local openQA server (running on Intel hardware)

With kind regards,
Roland Clobus


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="7 (wheezy) - installer build 20130613+deb7u2+b1"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux silent 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Haswell DRAM 
Controller [8086:0c00] (rev 06)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5000]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell 
Integrated Graphics Controller [8086:0412] (rev 06)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:d000]
lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Haswell HD Audio 
Controller [8086:0c0c] (rev 06)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Lynx Point USB 
xHCI Host Controller [8086:8c31] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5007]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Lynx 
Point MEI Controller #1 [8086:8c3a] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a]
lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation Lynx Point KT 
Controller [8086:8c3d] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:1c3a]
lspci -knn: Kernel driver in use: serial
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet 
Connection I217-V [8086:153b] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:e000]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation Lynx Point USB 
Enhanced Host Controller #2 [8086:8c2d] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006]
lspci -knn: Kernel driver in use: ehci_hcd
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Lynx Point High 
Definition Audio Controller [8086:8c20] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:a002]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Lynx Point PCI Express 
Root Port #1 [8086:8c10] (rev d4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 
[8086:244e] (rev d4)
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation Lynx Point USB 
Enhanced Host Controller #1 [8086:8c26] (rev 04)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006]
lspci -knn: Kernel driver in use: ehci_hcd
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 

Bug#1036321: rootskel-gtk: Include metadata about the banner

[Cyril Brulebois]

Package: rootskel-gtk
Version: 12.0.1
Severity: normal

Hi,

Until now, we've always been favoring one side of the banner, and that's
been encoded in cdebconf-gtk: starting the installer in “Rescue” will
result in a (translated) label being printed on top of the banner,
either on the left or on the right. That's currently hardcoded in
cdebconf-gtk and that needs to be adjusted depending on where the Debian
name, logo, version number etc. end up for a given banner.

It would probably make sense to have a small metadata file that could be
picked up by cdebconf-gtk.

Maybe something like logo_debian.properties (or whatever name) with:

labelPosition=right
bannerExpands=right

and having cdebconf-gtk deal with default settings (e.g. right for
both). I'm not yet sure about whether it would make sense to support
bannerExpands=both (probably doesn't cost much more, but would that look
OK?).

I'm tempted to try and get that squeezed in finally (#745359 was almost
10 years ago, and the scaling trick was better than nothing, but clearly
not ideal); we can always refine the format later on.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1036347: debian-installer: missing support for RAID+LUKS+LVM via preseed

[Cyril Brulebois]

Package: partman-auto-raid
Severity: important
Tags: patch

Hi,

I'm not a preseed expert but it seems to me we're currently lacking
support for one rather common layout that's achievable via the
interactive installer, which is RAID+LUKS+LVM.

As far as I understand we support a few methods, but only *one* of
them can be chosen via partman-auto/method. The partman-auto package
intercepts “regular” and deals with it on its own, but also delegates
to partman-auto- if a different method is specified:
 - partman-auto-crypto: sets up LUKS+LVM.
 - partman-auto-lvm: sets up LVM.
 - partman-auto-raid: sets up RAID, but can also do RAID+LVM if the
   RAID specification includes the “lvm” keyword.

The fact we're supposed to be choosing one and only one method is
confirmed by looking at the implementation of each method, which
suggests they were never meant to be combined (i.e. stacked on top of
each other):
 - partman-auto-lvm ships an auto-lvm.sh library, defining functions
   like auto_lvm_prepare() and auto_lvm_perform(), which it obviously
   uses itself to implement LVM support.
 - partman-auto-crypto leverages that auto-lvm.sh library, using
   both functions directly in its autopartition-crypto script, to
   implement LUKS+LVM support.
 - partman-auto-raid also leverages that auto-lvm.sh library, but not
   as directly as partman-auto-crypto does: since auto_lvm_prepare()
   wants to create partitions, it was partially copied/adjusted in its
   initial_auto_raid_lvm script; that being said, it calls
   auto_lvm_perform() in the end; that's how it implements RAID+LVM.

Since partman-auto-raid already knows how to deal with RAID and with
RAID+LVM when the “lvm” keyword is detected, I looked into making it
support RAID+LUKS+LVM by adding support for the “crypto-lvm” keyword,
reusing the logic of the initial_auto_raid_lvm script, inserting parts
of the logic of the autopartition-crypto script in there.

Tests confirm this seems to be working fine, but I wouldn't call this
bulletproof just yet. That being said, it cannot really break existing
use cases, so I'm tempted to include this feature right away.

  
https://salsa.debian.org/installer-team/partman-auto-raid/-/commits/lvm-on-luks-on-raid

While looking at the implementation, I noticed that partman-auto-raid
doesn't declare partman-auto-lvm in its Depends despite using its
auto-lvm.sh, so I didn't add partman-crypto to Depends despite using
its crypto-base.sh. This seems to be working fine anyway, using either
a netboot-gtk build or a full-blown netinst build.

Example usage with two disks, having only /dev/sda partitioned, and
the entirety of /dev/sdb added to the RAID 0 array, alongside the 4th
partition of the first disk:

d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string raid
d-i partman-auto-raid/recipe string 0 2 0 crypto-lvm - /dev/sda4#/dev/sdb .

complemented with partman-auto/{choose,expert}_recipe regarding the
actual partitioning of /dev/sda using those methods:
 - biosgrub
 - efi (fat32, /boot/efi)
 - format (ext2, /boot)
 - raid

and of course LV definitions.

This approach means that all existing settings are still considered as
usual, like those for LUKS:

d-i partman-crypto/confirm boolean true
d-i partman-crypto/passphrase string password
d-i partman-crypto/passphrase-again string password
d-i partman-crypto/weak_passphrase boolean true
d-i partman-auto-crypto/erase_disks boolean false

(I decided to also reuse the partman-auto-crypto one despite doing the
work from partman-auto-raid, but it's trivial to adjust if desired;
that's only meant to be preseeded anyway, no strings attached. That
being said, the existing RAID+LVM support is very similar, since
partman-auto-lvm/* settings are considered even if partman-auto/method
is set to “raid” and partman-auto-raid is doing the heavy lifting, see
below.)

That also applies for LVM:

d-i partman-auto-lvm/guided_size string max
d-i partman-auto-lvm/new_vg_name string main
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-lvm/device_remove_lvm boolean true

I plan on polishing and sharing some complete preseed example later
on, and possibly adding a pointer from the example preseed that's
published in the installation guide (and therefore on the website).


That partman request was submitted to me a while back but I've chosen
to prioritize other topics until now, since those were beneficial to
virtually everyone and needed to be worked on in a timely fashion:
non-free-firmware, Alpha and RC releases, also trying to get a greater
autonomy with debian-cd and debian-ftp so that we could accommodate
whatever might be needed or preferred by the kernel team and the
release team as far as timings go (which seems pretty important the
closer we get to the tentative release date).

Since we've spent quite some time fixing and improving LUKS support, I
would hate it if we didn't consider bui

Bug#1036321: rootskel-gtk: Include metadata about the banner

[Cyril Brulebois]

Control: tag -1 patch pending

Hi,

Cyril Brulebois  (2023-05-19):
> Maybe something like logo_debian.properties (or whatever name) with:
> 
> labelPosition=right
> bannerExpands=right

I settled for a logo_installer.ini (logo_debian.ini for us, plus a
symlink via the Makefile, as it is done for the logo files themselves):

[banner]
# supported values: left, right
label-position = right
# supported values: left, right, both
expand-direction = both

See: https://salsa.debian.org/installer-team/rootskel-gtk/-/commit/306e00e96b

I'm not entirely the current expand-direction is the best for Bookworm:
 - Setting it to “right” would accentuate the strange rendering on the
   right (since repeating the last 1-px column hadn't been anticipated).
 - Setting it to “both” pushes “debian 12” towards the center without
   really centering it, so it could be considered less appealing than
   keeping in on the left.

> and having cdebconf-gtk deal with default settings (e.g. right for
> both). I'm not yet sure about whether it would make sense to support
> bannerExpands=both (probably doesn't cost much more, but would that
> look OK?).

cdebconf-gtk now defaults to right and both (respectively). This is
totally arbitrary, and as noted in the changelog: the theme should
provide an up-to-date metadata file so that we never have to touch
cdebconf's code (or default banner settings) again.

> I'm tempted to try and get that squeezed in finally (#745359 was
> almost 10 years ago, and the scaling trick was better than nothing,
> but clearly not ideal); we can always refine the format later on.

I'd call that mergeable at it is. I've pushed the cdebconf side directly
to master. Since rootskel-gtk's master branch contains old changes that
have never been uploaded to the archive, and since I don't feel like
taking responsibility for them at this stage, I've forked a bookworm
branch from the last tag, and plan on uploading to unstable from it.

Aurélien, please work within that branch if you have a chance to look
into #1036315 and #1036317. Feel free to tweak logo_installer.ini, I'm
happy to let you pick whatever you feel is best!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: Re: Bug#1036321: rootskel-gtk: Include metadata about the banner

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch pending
Bug #1036321 [rootskel-gtk] rootskel-gtk: Include metadata about the banner
Added tag(s) patch and pending.

-- 
1036321: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036321
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Cyril Brulebois]

Hi,

Andrew M.A. Cater  (2023-05-19):
> I'd honestly suggest *just* publishing DVD1 for i386.
> 
> Netinst requires internet access: DVD1 can be used to install a basic
> system without this. Scrap *everything else* for i386 installation media.

I'm not sure how dropping one netinst ISO is going to change anything in
debian-cd: that's a very fast build, that's a small, single ISO, and not
having to download several GBs seems quite appealing to me. Having DVD1
only would really not seem acceptable to me.

I'm also very much *not* in favour of dropping images just *days* before
the release, without any kind of heads-up.

If the point is to limit the amount of testing done before publishing,
it would seem acceptable to me to limit i386 testing, and to only be
“reacting” to user reports about things that might not be working for
them (instead of proactively checking various combinations).

Cc-ing debian-boot@ and debian-cd@ for information, seeing such an idea
mentioned only on debian-devel@ feels weird.

> Update media for i386 - no, really, don't bother. One DVD per point
> release and have done with it. The utility for i386 was questioned by
> me (amongst others) late in Bookworm planning and it was suggested
> that it should be decided for Trixie immediately bookworm is released.

No opinion on that.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1023472: Workaround implemented for live images

[Holger Wansing]

Hi kibi,

Cyril Brulebois  wrote (Fri, 19 May 2023 10:50:57 +0200):
> Hi,
> 
> Roland Clobus  (2023-05-19):
> > I consider it a workaround, because the netinst D-I is still affected.
> > If the LXQt desktop is selected in the installer, the Wayland desktop
> > manager is used instead of xfwm4.
> > The MR for a proposed fix (in tasksel) is at [1].
> 
> OK, I'll leave that one to people more used to tasksel than me.

Do you think, that just changing the order in the Recommends packages list
like in


  Depends: ${misc:Depends},
   task-desktop,
+ # Mention the preferred theme before sddm, otherwise another theme will be 
used
+  sddm-theme-debian-elarun | sddm-theme,
   sddm,
-  sddm-theme-debian-elarun | sddm-theme-debian-elarun,
   lxqt,
  Recommends: xsane,


changes the result?
My guess would be that the order is of no relevance.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1036371: debian-installer: Blu-ray double-level iso is too large to burn to DLBD disk

[Bud Heal]

Package: debian-installer
Version: 20210731+deb11u8
Severity: important
Tags: d-i
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Since the DLBD .iso install neither sets up sources.list with a mirror to
download from nor requests more disks to complete the set, a test of the
DLBD install when using actual Blu-ray disks were in order.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
RC3, packaged at 61-62GB per volume, can not be burned into DLBD media.
   * What was the outcome of this action?
The test could not even be started.
   * What outcome did you expect instead?
The DLBD volumes should be configured at 48-48.5GB. At 61GB, apt still
asks for new packages in /media/cdrom, which cannot possible be
satisfied. See bug#1035476 - editing sources.list as a workaround is, as
apt reminds each time, insecure.
All the packages d-i needs fit in the 25GB set, if not the 16GB one.
Then, the following volumes allow someone with a slow connection (like
mine) to complete an installation from media - if the volumes fit on the 
media.  Otherwise, the rest of the volumes are not easy to use as a
complete download of the distribution.

-- System Information:
Debian Release: (inserted) 12 RC3 --