Bug#926539: Bug#987441: s390x installation bugs

[John Paul Adrian Glaubitz]

Hi!

On 5/3/21 8:36 AM, Cyril Brulebois wrote:
> From skimming through the bug log, it seems it was initially a sparc64
> problem, that was fixed in the kernel (inconsistent naming) eventually.

Correct.

> The same issue exists on s390x but isn't apparently going to get fixed
> so we need to have d-i be smarter (hence the merge request)?

Seems so.

> I'd suggest at least retitling the bug report to mention s390x (release
> arch, affected) instead of sparc64 (port arch, no longer affected), to
> lower the chances people could overlook this issue, thinking it's only
> about a port arch.

We could also unmerge #926539 and #961056 again, then close the former bug
which was sparc64-specific.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#987788: debian-installer: qemu-system-s390x installation fails due to segfault in main-menu

[Cyril Brulebois]

Hi,

Valentin Vidic  (2021-04-29):
> Dear Maintainer,
> 
> Running the installation inside a QEMU instance does not work in bullseye:
> 
> $ virt-install --arch=s390x --name test --memory 1024 --disk none -l 
> http://ftp.de.debian.org/debian/dists/bullseye/main/installer-s390x/
> ...
> 
>  ┌───┤ [!!] Configure the network device ├───┐
>  │   │
>  │ Installation step failed  │
>  │ An installation step failed. You can try to run the failing item  │
>  │ again from the menu, or skip it and choose something else. The│
>  │ failing step is: Configure the network device │
>  │   │
>  │ │
>  │   │
>  └───┘
> 
> [  122.379000] User process fault: interruption code 003b ilc:3 in 
> main-menu[2aa33f0+4000]
> [  122.381112] Failing address:  TEID: 0800
> [  122.381149] Fault in primary space mode while using user ASCE.
> [  122.381239] AS:02ae01c7 R3:0024
> 
> Seems like a segfault in main-menu binary related to network detection?

Do we have any idea whether that could be something that's only
triggered within QEMU (maybe try other QEMU versions?), or something
that affects bare metal systems?


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


signature.asc
Description: PGP signature

Bug#987441: debian-installer: D-I must get ready for Bullseye

[Andrei POPESCU]

On Du, 25 apr 21, 12:04:25, Cyril Brulebois wrote:
> 
> Michael Biebl  (2021-04-25):
> 
> > I.e. do you consider #952450 a blocker for d-i?
> 
> I did see this when I was searching for /rescue/ (to get the right
> number for the bug mentioned above), but it didn't feel like a bug
> report that's been filed 1+ year ago at normal severity could be a
> blocker for the release (especially since there was apparently no
> follow-up after your suggestion).

Arguably that bug should be severity important.

> For the avoidance of doubt, I didn't dive into rescue.target at all,
> so I have no actual opinion regarding that particular issue besides
> the initial metadata-based assessment above.

Basically users end up with an unusable 'rescue' boot menu option if 
they chose not to set a root password during install.

See #977358 for a thorough explanation and workarounds (one being 
editing the kernel command line, which kind of defeats the purpose of 
having the menu entry in the first place).

Bug#977358: release-notes: document how to make the rescue mode usable if no 
root password is set (buster)

("rescue mode" should probably have been "rescue boot entry", to avoid 
confusion with D-Is rescue mode)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Processed: unmerging 961056

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unmerge 961056
Bug #961056 [src:linux,rootskel] debian-installer: qemu-system-s390x 
installation fails due to incorrect serial device
Bug #926539 [src:linux,rootskel] rootskel: steal-ctty no longer works on at 
least sparc64
Disconnected #961056 from all other report(s).
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
926539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
961056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961056
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926539: Bug#987441: s390x installation bugs

[Valentin Vidic]

On Mon, May 03, 2021 at 08:58:02AM +0200, John Paul Adrian Glaubitz wrote:
> > The same issue exists on s390x but isn't apparently going to get fixed
> > so we need to have d-i be smarter (hence the merge request)?
> 
> Seems so.

QEMU console might get fixed in the kernel, but it looks like LPAR could
have a similar problem (don't have access to test this). So it seems
better (and future proof) to fix this on the Debian side too. I have
updated the merge request to trigger the new code only on s390x as
suggested:

https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2

> > I'd suggest at least retitling the bug report to mention s390x (release
> > arch, affected) instead of sparc64 (port arch, no longer affected), to
> > lower the chances people could overlook this issue, thinking it's only
> > about a port arch.
> 
> We could also unmerge #926539 and #961056 again, then close the former bug
> which was sparc64-specific.

I have unmerged the bugs now, so the sparc one can be closed.

-- 
Valentin

Bug#961056: Bug#926539: Bug#987441: s390x installation bugs

[John Paul Adrian Glaubitz]

Hi!

On 5/3/21 12:21 PM, Valentin Vidic wrote:
>>> I'd suggest at least retitling the bug report to mention s390x (release
>>> arch, affected) instead of sparc64 (port arch, no longer affected), to
>>> lower the chances people could overlook this issue, thinking it's only
>>> about a port arch.
>>
>> We could also unmerge #926539 and #961056 again, then close the former bug
>> which was sparc64-specific.
> 
> I have unmerged the bugs now, so the sparc one can be closed.

Alright, done.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#926539: marked as done (rootskel: steal-ctty no longer works on at least sparc64)

[Debian Bug Tracking System]

Your message dated Mon, 3 May 2021 12:47:03 +0200
with message-id <82898247-7c4c-2e2c-358a-5724ce5fc...@physik.fu-berlin.de>
and subject line Re: Bug#926539: Bug#987441: s390x installation bugs
has caused the Debian Bug report #926539,
regarding rootskel: steal-ctty no longer works on at least sparc64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
926539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: rootskel
Version: 1.128
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

I built updated installation images [1] for Debian Ports today and tested
the sparc64 image on our SPARC T5 in an LDOM.

Unfortunately, it seems that the recent changes to rootskel broke the
serial console on sparc64 in d-i. The kernel boots fine but d-i never
starts, the boot stops with:

steal-ctty: No such file or directory

My suspicion is that the support multiple consoles in parallel [2] introduced
this particular regression. I haven't done any debugging yet though as I'm
not sure where to start, I haven't touched the rootskel package before and
therefore would be interested in any pointers how to debug this.

Thanks,
Adrian

> [1] https://cdimage.debian.org/cdimage/ports/2019-04-06/
> [2] 
> https://salsa.debian.org/installer-team/rootskel/commit/b6048aafed7d73ba42da04d6f7a798710f271384

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- End Message ---
--- Begin Message ---
Hi!

On 5/3/21 12:21 PM, Valentin Vidic wrote:
>>> I'd suggest at least retitling the bug report to mention s390x (release
>>> arch, affected) instead of sparc64 (port arch, no longer affected), to
>>> lower the chances people could overlook this issue, thinking it's only
>>> about a port arch.
>>
>> We could also unmerge #926539 and #961056 again, then close the former bug
>> which was sparc64-specific.
> 
> I have unmerged the bugs now, so the sparc one can be closed.

Alright, done.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913--- End Message ---

Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Thu, 29 Apr 2021 at 18:54:56 +0200, Cyril Brulebois wrote:
> Version 1.44.4 is the first one I was able to build, using the packaging
> from debian/1.44.6-1 (first 1.44.x version that was packaged and that's
> also known to be buggy).

I've been able to hack together packaging for 1.43.0 (works) and 1.44.0
(hangs when selecting Sinhala), but so much changed between 1.43.0 and
1.44.0 that bisecting between them might not be a very good route.

I've also been able to attach a debugger to debconf. My preliminary finding
is: we enter gtk_container_idle_sizer() in GTK 2 and never exit, because
every time we go into gtk_container_check_resize(), we end up in
gtk_text_layout_emit_changed() which emits a signal that eventually calls
_gtk_container_queue_resize(), so gtk_container_idle_sizer() has more work
to do and we loop indefinitely.

I assume this isn't meant to happen? But please don't mistake me for an
expert on GTK 2, or Pango, or Harfbuzz.

Steps go something like this (is there a better way?):

Host preparation:
- Build interesting libraries (pango1.0, harfbuzz, glib2.0, gtk+2.0) with
  DEB_BUILD_OPTIONS="noopt nostrip nocheck"; we'll need these later

VM preparation:
- Create a new VM booting from virtio disk /dev/vda
- Have an up-to-date bullseye installation on /dev/vda
  (I copied an existing bullseye GNOME installation and upgraded it)
- Make sure a user can log in via ssh and can sudo to root
- Power off the VM
- Attach a CD-ROM device with firmware-bullseye-DI-rc1-amd64-netinst.iso
- Make it boot from CD-ROM
- Boot it
- Start graphical installer
- Proceed with installation, in English, until we get to "Configure the
  network"
- Hit Cancel and Go Back until we get to the menu of installation steps
- Send Ctrl+Alt+F2
- modprobe ext4
- mount /dev/vda1 /mnt
- mount --rbind /dev /mnt/dev
- mount --rbind /proc /mnt/proc
- mount --rbind /sys /mnt/sys
- mkdir /mnt/d-i
- mount --bind / /mnt/d-i
- chroot /mnt bash
  - /etc/init.d/ssh start
  - exit
- ssh in to the chroot'd ssh server; this is our debugging environment
- On the graphical console, send Ctrl+Alt+F5 to go to X11

Debugging loop:
- Use rsync/ssh/cp to get the unstripped libraries into /d-i in the ssh
  session (the root directory of the d-i environment)
- Ctrl+Alt+F2, use udpkg -i to install them in the d-i environment
- In the ssh session, use pstree -p to look at the process hierarchy,
  then kill debconf and everything below it
- Hit Cancel and Go Back until we get to the menu of installation steps
- "Choose language"
- Select Sinhala
- In the ssh session:
sudo gdb -ex 'set pagination off' \
-ex 'set sysroot /d-i' \
-ex 'set logging file /log' \
-ex 'set logging overwrite off' \
-ex 'set logging on' \
/d-i/usr/bin/debconf `pgrep debconf`
- Debug interactively until you get a better idea

Some sample backtraces are attached.

My next step is going to be to try to hack Harfbuzz to disable the Indic
shaper (which is what seems to be in use here) and see whether that stops
the infinite loop. That's unlikely to be an acceptable solution, but it'll
at least tell us whether the Indic shaper is what's triggering this.

smcv

Thread 2 (Thread 0x7fb793d9b700 (LWP 4430) "event_listener"):
#0  BEInt::operator unsigned short (this=0x7fb792d24fa4) at 
../../src/hb.hh:559
#1  0x7fb7943fe084 in OT::IntType::operator unsigned 
int (this=0x7fb792d24fa4) at ../../src/hb-open-type.hh:63
#2  0x7fb7943f9c4b in OT::CoverageFormat2::get_coverage 
(this=0x7fb792d24fa0, glyph_id=49) at ../../src/hb-ot-layout-common.hh:1300
#3  0x7fb7943fa001 in OT::Coverage::get_coverage (this=0x7fb792d24fa0, 
glyph_id=49) at ../../src/hb-ot-layout-common.hh:1470
#4  0x7fb7944c736a in OT::CursivePosFormat1::apply (this=0x7fb792d249fe, 
c=0x7fb793d95eb0) at ../../src/hb-ot-layout-gpos-table.hh:1603
#5  0x7fb79450cae3 in 
OT::hb_get_subtables_context_t::apply_to 
(obj=0x7fb792d249fe, c=0x7fb793d95eb0) at ../../src/hb-ot-layout-gsubgpos.hh:692
#6  0x7fb7944bf2fc in 
OT::hb_get_subtables_context_t::hb_applicable_t::apply (this=0x7fb78c1db610, 
c=0x7fb793d95eb0) at ../../src/hb-ot-layout-gsubgpos.hh:710
#7  0x7fb7944c4074 in OT::hb_ot_layout_lookup_accelerator_t::apply 
(this=0x7fb78c1db2c0, c=0x7fb793d95eb0) at 
../../src/hb-ot-layout-gsubgpos.hh:3189
#8  0x7fb7944a5a5d in apply_forward (c=0x7fb793d95eb0, accel=...) at 
../../src/hb-ot-layout.cc:1766
#9  0x7fb7944e13df in apply_string (c=0x7fb793d95eb0, 
lookup=..., accel=...) at ../../src/hb-ot-layout.cc:1819
#10 0x7fb7944d82d8 in hb_ot_map_t::apply (this=0x7fb78c1dbbd8, 
proxy=..., plan=0x7fb78c1dbbb0, font=0x7fb78c3ae090, buffer=0x556bd8cdacd0) at 
../../src/hb-ot-layout.cc:1865
#11 0x7fb7944a5cc5 in hb_ot_map_t::position (this=0x7fb78c1dbbd8, 
plan=0x7fb78c1dbbb0, font=0x7fb78c3ae090, buffer=0x556bd8cdacd0) at 
../../src/hb-ot-layout.cc:1891
#12 0x7fb794559cd4 in hb_ot_shape_plan_t::position (this=0x7fb78c1dbbb0, 
font=0x7fb78c3ae090, buffer=0x556bd8cdacd0

Bug#987788: debian-installer: qemu-system-s390x installation fails due to segfault in main-menu

[Valentin Vidic]

On Mon, May 03, 2021 at 09:16:03AM +0200, Cyril Brulebois wrote:
> Do we have any idea whether that could be something that's only
> triggered within QEMU (maybe try other QEMU versions?), or something
> that affects bare metal systems?

I don't have access to real s390x hardware, but I tried to run the
installation with QEMU 5.2 from unstable. Similar to QEMU 3.1 from
stable the installation sometimes starts correctly but most often
fails in the first step (Configure the network device).

-- 
Valentin

Bug#987788: debian-installer: qemu-system-s390x installation fails due to segfault in main-menu

[Samuel Thibault]

Hello,

Valentin Vidic, le lun. 03 mai 2021 18:15:22 +0200, a ecrit:
> On Mon, May 03, 2021 at 09:16:03AM +0200, Cyril Brulebois wrote:
> > Do we have any idea whether that could be something that's only
> > triggered within QEMU (maybe try other QEMU versions?), or something
> > that affects bare metal systems?
> 
> I don't have access to real s390x hardware, but I tried to run the
> installation with QEMU 5.2 from unstable.

How did you start it? I couldn't manage to make it start (with qemu from
unstable or from stable), I only got the kernel start and a couple of
lines. I was taking

http://ftp.de.debian.org/debian/dists/bullseye/main/installer-s390x/current/images/generic/initrd.debian
http://ftp.de.debian.org/debian/dists/bullseye/main/installer-s390x/current/images/generic/kernel.debian

and run 

qemu-system-s390x -kernel /tmp/s390x/kernel.debian -initrd 
/tmp/s390x/initrd.debian -m 1G -serial stdio

and got

[..kernel logs..]
[4.349417] Run /init as init process
[5.499051] failover: module verification failed: signature and/or required 
key missing - tainting kernel
[6.530501] virtio_net virtio0 enc0: renamed from eth0
steal-ctty: No such file or directory
[   83.282353] random: crng init done

and nothing more.

Samuel

Bug#987441: s390x installation bugs

[Valentin Vidic]

On Mon, May 03, 2021 at 08:36:58AM +0200, Cyril Brulebois wrote:
> Also adding to the list of bugs to keep an eye on (again, possibly not
> blocking the release on its being resolved; we could have the issue
> listed in errata, and possibly fixed in a point release).

Thanks, here is another one for s390x, should be relatively simple if
you wish to link it here:

linux: Debian installation fails in qemu-system-s390x due to missing virtio_blk 
module
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988005

-- 
Valentin

Bug#987788: debian-installer: qemu-system-s390x installation fails due to segfault in main-menu

[Valentin Vidic]

On Mon, May 03, 2021 at 06:38:05PM +0200, Samuel Thibault wrote:
> How did you start it? I couldn't manage to make it start (with qemu from
> unstable or from stable), I only got the kernel start and a couple of
> lines. I was taking
> 
> http://ftp.de.debian.org/debian/dists/bullseye/main/installer-s390x/current/images/generic/initrd.debian
> http://ftp.de.debian.org/debian/dists/bullseye/main/installer-s390x/current/images/generic/kernel.debian
> 
> and run 
> 
> qemu-system-s390x -kernel /tmp/s390x/kernel.debian -initrd 
> /tmp/s390x/initrd.debian -m 1G -serial stdio
> 
> and got
> 
> [..kernel logs..]
> [4.349417] Run /init as init process
> [5.499051] failover: module verification failed: signature and/or 
> required key missing - tainting kernel
> [6.530501] virtio_net virtio0 enc0: renamed from eth0
> steal-ctty: No such file or directory
> [   83.282353] random: crng init done
> 
> and nothing more.

Hi, I start it with:

virt-install --arch=s390x --name test --memory 1024 --disk size=3 -l 
http://ftp.de.debian.org/debian/dists/bullseye/main/installer-s390x/ 
--extra-args='BOOT_DEBUG=3'

but it should be more or less the same thing as your command. The problem
is you are hitting steal-ctty bug from #961056. I use BOOT_DEBUG=3 to
get a shell before the installer starts and edit /sbin/reopen-console
with this fix:

https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2/diffs

After that installer should start and sometimes (but not always) fail in
the first step (configuring network interfaces). The problem is I don't
have a shell after that segfault to get more info from the logs or dmesg.

-- 
Valentin

Re: Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Mon, 03 May 2021 at 17:17:21 +0100, Simon McVittie wrote:
> I've also been able to attach a debugger to debconf. My preliminary finding
> is: we enter gtk_container_idle_sizer() in GTK 2 and never exit, because
> every time we go into gtk_container_check_resize(), we end up in
> gtk_text_layout_emit_changed() which emits a signal that eventually calls
> _gtk_container_queue_resize(), so gtk_container_idle_sizer() has more work
> to do and we loop indefinitely.
...
> My next step is going to be to try to hack Harfbuzz to disable the Indic
> shaper (which is what seems to be in use here) and see whether that stops
> the infinite loop. That's unlikely to be an acceptable solution, but it'll
> at least tell us whether the Indic shaper is what's triggering this.

Yes, this worked! If I disable the Indic shaper with the attached hack,
that seems to be enough to make installation proceed.

Again, this is probably not an acceptable solution: Harfbuzz has shapers
for complex scripts for a reason, and I suspect someone who can speak
the relevant language would find the text either ugly or unreadable
when using the default shaper. However, I hope this does at least point
someone who knows more about the mechanics of text rendering and/or GTK
relayout in the right direction...

I think the reason this regressed between Pango 1.43.0 and 1.44.0 might
just be that Pango 1.44.0 uses Harfbuzz to implement more of its own
functionality.

smcv
From: Simon McVittie 
Date: Mon, 3 May 2021 17:02:50 +0100
Subject: HACK: Disable Indic shaper

This appears to trigger a relayout loop in GTK 2 in the d-i environment.

Bug-Debian: https://bugs.debian.org/987587
---
 src/hb-ot-shape-complex.hh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hb-ot-shape-complex.hh b/src/hb-ot-shape-complex.hh
index a1a7a6a..6c82b87 100644
--- a/src/hb-ot-shape-complex.hh
+++ b/src/hb-ot-shape-complex.hh
@@ -263,7 +263,7 @@ hb_ot_shape_complex_categorize (const hb_ot_shape_planner_t *planner)
   else if ((planner->map.chosen_script[0] & 0x00FF) == '3')
 	return &_hb_ot_complex_shaper_use;
   else
-	return &_hb_ot_complex_shaper_indic;
+	return &_hb_ot_complex_shaper_default;
 
 case HB_SCRIPT_KHMER:
 	return &_hb_ot_complex_shaper_khmer;

Processed: Re: Bug#988013: mini.iso fails to load grub.cfg (UEFI)

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 debian-installer
Bug #988013 [debian-cd] mini.iso fails to load grub.cfg (UEFI)
Bug reassigned from package 'debian-cd' to 'debian-installer'.
Ignoring request to alter found versions of bug #988013 to the same values 
previously set
Ignoring request to alter fixed versions of bug #988013 to the same values 
previously set

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

Fwd: bits from the Release Team: bullseye status update

[Robert Thomas Hayes Link, Esq]

Greetings:

The forwarded note, below, provides a little context for how I happen to 
be writing you today. Happy to learn how I might help.


Cheers,

Robert



 Forwarded Message 
Subject:Re: bits from the Release Team: bullseye status update
Date:   Mon, 3 May 2021 21:46:11 +0200
From:   Paul Gevers 
To: Robert Thomas Hayes Link, Esq 



Hi Robert,

On 03-05-2021 21:32, Robert Thomas Hayes Link, Esq wrote:

I formerly did build acceptance for a prominent antivirus company. Just
before my contract expired I was promoted from build-acceptance to the
installer component. I've also been listed with the EFF on their
"cooperative attorneys" list. Perhaps I can be of some small service?


I have not much clue about the installer myself, maybe better to offer
your services on debian-boot@lists.debian.org, but I suggest you try to
be a bit more extensive on how you see yourself helping. All help moving
the installer forward is welcome.


I've never had pgp/gpg friends sufficient to maintain a viable key. If
you need me to spawn a new one in order to help, I'm more than happy to.


I don't think this is a requirement.

Paul

Bug#988022: installation reports Bullseye

[dhorse2]

Package: installation-reports

Boot method: 
Image version: 
Date: 

Machine: 
Processor:Intel Core 2 quad cpu Q6700 @ 2.66GHZ X 4
Memory:4 gib
Partitions: 


Output of lspci -knn (or lspci -nn):
lspci -knn
00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller 
[8086:2e20] (rev 03)
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H 
Motherboard [1458:5000]
00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI Express Root 
Port [8086:2e21] (rev 03)
Kernel driver in use: pcieport
00:1a.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #4 [8086:3a37]
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #5 [8086:3a38]
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.2 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #6 [8086:3a39]
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.7 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 
EHCI Controller #2 [8086:3a3c]
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5006]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio 
Controller [8086:3a3e]
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-UD3R Motherboard 
[1458:a002]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express 
Root Port 1 [8086:3a40]
Kernel driver in use: pcieport
00:1c.3 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express 
Root Port 4 [8086:3a46]
Kernel driver in use: pcieport
00:1c.4 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express 
Root Port 5 [8086:3a48]
Kernel driver in use: pcieport
00:1c.5 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express 
Root Port 6 [8086:3a4a]
Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #1 [8086:3a34]
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard 
[1458:5004]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #2 [8086:3a35]
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard 
[1458:5004]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.2 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #3 [8086:3a36]
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard 
[1458:5004]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 
EHCI Controller #1 [8086:3a3a]
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5 Motherboard 
[1458:5006]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
90)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801JIB (ICH10) LPC Interface 
Controller [8086:3a18]
Subsystem: Gigabyte Technology Co., Ltd 82801JIB (ICH10) LPC Interface 
Controller [1458:5001]
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 4 port 
SATA IDE Controller #1 [8086:3a20]
Subsystem: Gigabyte Technology Co., Ltd 82801JI (ICH10 Family) 4 port 
SATA IDE Controller [1458:b002]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, ata_generic
00:1f.3 SMBus [0c05]: Intel Corporation 82801JI (ICH10 Family) SMBus Controller 
[8086:3a30]
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H 
Motherboard [1458:5001]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
00:1f.5 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 2 port 
SATA IDE Controller #2 [8086:3a26]
Subsystem: Gigabyte Technology Co., Ltd 82801JI (ICH10 Family) 2 port 
SATA IDE Controller [1458:b002]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, ata_generic
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G92 [GeForce 9800 
GT] [10de:0605] (rev a2)
Subsystem: XFX Pine Group Inc. G92 [GeForce 9800 GT] [1682:2372]
Kernel driver in use: nouveau
Kernel modules: nouveau
03:00.0 USB controller [0c03]: Renesa

Bug#988013: mini.iso fails to load grub.cfg (UEFI)

[Andrei POPESCU]

On Lu, 03 mai 21, 19:52:32, Steve McIntyre wrote:
> 
> Reassigning to debian-installer, as that builds the mini.iso.
> 
> I'll take a look when I get a chance...
> 
> Oh, hmmm - do you have secure boot enabled or not on your machine?

It's not enabled (sorry, forgot to mention).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature