Re: Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,


While this bug is now in fixed status with the recent upload of open-
iscsi version 2.1.3-4, there's still some other issue about the udeb
being reported on the tracker package.

In particular, it metions:
open-iscsi-udeb/armel has unsatisfiable dependency

I see now difference in the generated deb's dependency list. Is it
something you are aware of, in general, about d-i's status on armel ?
Or are there still bugs from the installer's point of view, where I
need to step in ?



rrs@priyasi:.../Chrome-Downloads$ dpkg -I open-iscsi-udeb_2.1.3-
4_armel.udeb 
 new Debian package, version 2.0.
 size 212060 bytes: control archive=572 bytes.
 592 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-4
 Architecture: armel
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 1185
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.
19:33 ♒ ॐ ♅ ♄ ⛢ ☺ 😄
rrs@priyasi:.../Chrome-Downloads$ dpkg -I open-iscsi-udeb_2.1.3-
4_armhf.udeb 
 new Debian package, version 2.0.
 size 218124 bytes: control archive=572 bytes.
 591 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-4
 Architecture: armhf
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 933
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.
19:33 ♒ ॐ ♅ ♄ ⛢ ☺ 😄


On Sat, 2021-05-01 at 04:32 +0200, Cyril Brulebois wrote:
> Hi,
> 
> Ritesh Raj Sarraf  (2021-04-30):
> > The upload I prepped failed on some of the architectures.
> > https://buildd.debian.org/status/logs.php?pkg=open-iscsi&ver=2.1.3-3
> 
> It's lacking a push to the Git repository (git fetch didn't get
> anything
> new from a few days ago).
> 
> > In d/control, there is:
> > 
> > ```
> > Package: open-iscsi-udeb
> > # Note: the (virtual) udeb package scsi-modules (provided by
> > different
> > #   linux kernel udebs) must exist for these architectures - so
> > #   check that before adding them to this list; the other
> > #   scsi-(core|common|...)-modules are NOT sufficient!
> > Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64
> > ppc64el s390x
> > Section: debian-installer
> > Package-Type: udeb
> > ```
> > 
> > 
> > The udeb package was introduced by Colin Watson from Ubuntu. I
> > extended
> > the architecture list, based on the supported architectures by d-i.
> > But
> > I really don't use or test this functionality of the package.
> > 
> > 
> > How would you like to see this fixed Cyril ?
> > 
> > The easiest option, if d-i supports, would be to extend architecture
> > list to: `linux-any`, keeping it in line with what the actual open-
> > iscsi package supports.
> 
> Yes, I think that would be a good idea, so that you don't have to keep
> the list in sync between debian/control and debian/rules. We don't have
> many examples of packages maintained by the d-i team that use it, but
> at least src:haveged and src:systemd have similar udebs (after all,
> that
> only matters at build-time, d-i only sees the results of the build).
> 
> Regarding your conditional, you could check whether you're building for
> linux (once you switch to linux-any) or you could check whether the
> udeb
> is being built: dh_listpackages (-a) can be use to determine that.
> 
> 
> Cheers,

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Re: Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Hi,

(cc += debian-arm@)

Ritesh Raj Sarraf  (2021-05-15):
> While this bug is now in fixed status with the recent upload of open-
> iscsi version 2.1.3-4, there's still some other issue about the udeb
> being reported on the tracker package.
> 
> In particular, it metions:
> open-iscsi-udeb/armel has unsatisfiable dependency
> 
> I see no difference in the generated deb's dependency list. Is it
> something you are aware of, in general, about d-i's status on armel ?
> Or are there still bugs from the installer's point of view, where I
> need to step in ?

It's just scsi-modules that's not available on armel apparently.

As far as I know, armel is in “maintenance mode” anyway, trying not to
lose support for old devices. I wouldn't worry if an optional component
like open-iscsi(-udeb) would not be installable on this single
architecture. I'll let folks from debian-arm@ comment further on this.

But of course, this is a problem that prevents migration now, let's
check why; the old Architecture list looked like this (before switching
it to linux-any):

Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc ppc64 ppc64el 
s390x

without armel so you had no installability issue there… Note that this
was actually explained in the comment just before that line:

# Note: the (virtual) udeb package scsi-modules (provided by different
#   linux kernel udebs) must exist for these architectures - so
#   check that before adding them to this list; the other
#   scsi-(core|common|...)-modules are NOT sufficient!

An obvious fix would be to revert to an hardcoded list of supported
architectures (and requesting a removal of the obsolete armel binary
that should start appearing in the cruft report[1] once that has
happened); that's not too nice but I don't see any obvious better fix
right now.

 1. https://ftp-master.debian.org/cruft-report-daily.txt


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


signature.asc
Description: PGP signature

Re: Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Sat, 2021-05-15 at 16:30 +0200, Cyril Brulebois wrote:
> It's just scsi-modules that's not available on armel apparently.
> 
> As far as I know, armel is in “maintenance mode” anyway, trying not
> to
> lose support for old devices. I wouldn't worry if an optional
> component
> like open-iscsi(-udeb) would not be installable on this single
> architecture. I'll let folks from debian-arm@ comment further on
> this.
> 
> But of course, this is a problem that prevents migration now, 

> let's
> check why; the old Architecture list looked like this (before
> switching
> it to linux-any):
> 
>     Architecture: amd64 arm64 armhf i386 ia64 mips mipsel powerpc
> ppc64
> ppc64el s390x
> 
> without armel so you had no installability issue there… Note that
> this
> was actually explained in the comment just before that line:
> 
>     # Note: the (virtual) udeb package scsi-modules (provided by
> different
>     #   linux kernel udebs) must exist for these architectures -
> so
>     #   check that before adding them to this list; the other
>     #   scsi-(core|common|...)-modules are NOT sufficient!
> 
> An obvious fix would be to revert to an hardcoded list of supported
> architectures (and requesting a removal of the obsolete armel binary
> that should start appearing in the cruft report[1] once that has
> happened); that's not too nice but I don't see any obvious better fix
> right now.

Yes. That scsi-modules support bites back now. I just forgot about it
completely. My intent was to not duplicate another architecture list in
d/rules, and in trying to simplify things, it has just fallen apart
with this old oddity of support on armel.

Time is pressing and I'm wondering what best to do here. I certainly do
not care much for the iSCSI support in the installer. I didn't write or
test that feature either. And I'm not even sure if that module even
works well in the installer. There's 'Root on (iSCSI + DM Multipath)'
that I use and care for but that doesn't even get set through the d-i
installer. Instead, the setup is to bootstrap the root LUN.

Maybe best to rope-in Ubuntu folks. I believe they make use of it in
the installer. I personally would like to drop the iSCSI support in the
installer, simply because I don't use it and don't have the commitment
to support/test it, nor the necessary hands-on knowledge if a bug is
reported. But derivatives may have a dependency on it.

The current easy fix, as Cyril mentioned above, it to revert it back to
the previous architecture list and adapt the same in d/rules in target
override_dh_makeshlibs.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Re: Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Ritesh Raj Sarraf  (2021-05-15):
> Yes. That scsi-modules support bites back now. I just forgot about it
> completely. My intent was to not duplicate another architecture list in
> d/rules, and in trying to simplify things, it has just fallen apart
> with this old oddity of support on armel.

I'm happy to provide (and test) a patch that would only hardcode the
list in debian/control, and make sure the extra steps aren't run from
debian/rules. If you like the idea, you might get a patch in the next
few hours.


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


signature.asc
Description: PGP signature

Re: Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

On Sat, 2021-05-15 at 17:37 +0200, Cyril Brulebois wrote:
> Ritesh Raj Sarraf  (2021-05-15):
> > Yes. That scsi-modules support bites back now. I just forgot about
> > it
> > completely. My intent was to not duplicate another architecture
> > list
> in
> > d/rules, and in trying to simplify things, it has just fallen apart
> > with this old oddity of support on armel.
> 
> I'm happy to provide (and test) a patch that would only hardcode the
> list in debian/control, and make sure the extra steps aren't run from
> debian/rules. If you like the idea, you might get a patch in the next
> few hours.

That'd be nice of you. So, yes, please.

And you'd be the next best team (debian-boot) to test that feature as
it is specific to d-i.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Re: Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Ritesh Raj Sarraf  (2021-05-15):
> That'd be nice of you. So, yes, please.
> 
> And you'd be the next best team (debian-boot) to test that feature as
> it is specific to d-i.

Here we go, udeb-support branch in:
  https://salsa.debian.org/kibi/open-iscsi

Tested successfully on amd64:
 - produces the udeb;
 - has the udeb entry in the library's shlibs file.

and on armel:
 - doesn't build the udeb;
 - doesn't have the udeb entry in the library's shlibs file.


For reference, what the second commit does is distinguish between:

kibi@tokyo:~/hack/open-iscsi.git$ dpkg --print-architecture
amd64
kibi@tokyo:~/hack/open-iscsi.git$ dh_listpackages 
open-iscsi
libopeniscsiusr
libopeniscsiusr-dev
iscsiuio
open-iscsi-udeb

and:

(sid_armel-dchroot)kibi@amdahl:~/open-iscsi-2.1.3$ dpkg 
--print-architecture   
armel
(sid_armel-dchroot)kibi@amdahl:~/open-iscsi-2.1.3$ dh_listpackages 
open-iscsi
libopeniscsiusr
libopeniscsiusr-dev
iscsiuio

Please let me know if you have any questions or objections, I'm happy to
help refine this further.


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


signature.asc
Description: PGP signature

Bug#988563: debian-installer: fresh bullseye install report (pxe boot ; lenovo thinkpad e15)

[Michel Briand]

Package: debian-installer
Version: 20190702+deb10u9
Severity: normal
Tags: l10n

Dear Maintainer,

I installed my new Lenovo Thinkpad E15 with Debian Bullseye.

I've setup my PXE + TFTP server with latest netboot.tar.gz.

I've installed Debian with the following options:
- France language, french keyboard
- assisted partman full disk with encryption
- bullseye distribution
- unchecked "debian desktop"
- checked plasma, xfce and lxqt desktops

Booting my new Debian system, initramfs can not load the (crypt) volume group.
Same problem as in #935973.

I solved this issue:
- booting on PXE
- choosing rescue
- chroot into system
- apt install cryptsetup-initramfs
  (this last operation recreates the initrd file)

My new system lacks the french localization for sddm and kde (even if I've 
choosen
France and Plasma in Debian installer).

I installed manually:
- task-french-desktop
- task-french-kde-desktop

When connecting to my bluetooth speaker, the pairing did work but the 
connection failed.
Pulseaudio was lacking the module for bluetooth.

apt install pulseaudio-module-bluetooth.

I think all those packages should be sensible defaults.

THANK YOU AND CONGRATULATIONS FOR THIS NEW DEBIAN RELEASE :))

Best regards

PS: I use only Debian on all my computers since 2005.

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#882804: cdebconf-gtk-udeb: Missing rescue mode label at start-up

[Cyril Brulebois]

Cyril Brulebois  (2017-11-26):
> The banner in the graphical installer doesn't get the “Rescue mode”
> label at start-up. It seems the information message hasn't been received
> yet when the first call to handle_exposed_banner (cdebconf gtk frontend)
> happens, so one has to select a language or switch to another vt back
> and forth to get the message displayed. That doesn't happen with the
> text rescue mode, so it's likely a cdebconf gtk frontend bug, filing
> accordingly.
> 
> This is seen in sid but also with 9.2 installation images.

With a regular mini.iso (cdebconf-gtk-udeb built against GTK+2), on the
start-up screen, the label is missing; switching to a VT and back gets
us the needed refresh and label; without the VT switch, proceeding to
the next screen is sufficient to get it as well.

With a patched mini.iso (cdebconf-gtk-udeb built against GTK+3), the
label is missing as well; the VT switch dance gets it back; but NOT
going to the next screen.


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


signature.asc
Description: PGP signature