Yeah, did not think about changing it to English, but yeah looks like it
can be that, works in the text mode installer however
On Mon, May 3, 2021 at 7:55 AM Cyril Brulebois wrote:
> Luna Jernberg (2021-05-03):
> > Gets stuck before it tries to download package from the mirrors
>
> Thanks,
Luna Jernberg (2021-05-03):
> Yeah, did not think about changing it to English, but yeah looks like
> it can be that, works in the text mode installer however
That's quite normal, libpango1.0-udeb (#987587) is only used in the
graphical installer. You could confirm that it's likely the very same
Control: block 987441 by 926539
Control: block 987441 by 987788
Hi Valentin,
Thanks for your suggestions.
Valentin Vidic (2021-05-02):
> Probably not critical, but maybe these installation bugs on s390x
> could be fixed for the release?
>
> rootskel: steal-ctty no longer works on at least
Processing control commands:
> block 987441 by 926539
Bug #987441 [src:debian-installer] debian-installer: D-I must get ready for
Bullseye
987441 was blocked by: 987368 987788 961056 987449 987568 987377 987587 926539
987441 was not blocking any bugs.
Ignoring request to alter blocking bugs of
Processing control commands:
> block 987441 by 926539
Bug #987441 [src:debian-installer] debian-installer: D-I must get ready for
Bullseye
987441 was blocked by: 987587 987377 987568 987449 987368
987441 was not blocking any bugs.
Added blocking bug(s) of 987441: 926539 and 961056
> block 987441
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
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/
> ...
>
>
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
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
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
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
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
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
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
>
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
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
>
>
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,
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
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
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
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.
>>
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
22 matches
Mail list logo
