Dear Maintainer,
it seems less a crash, instead it fails to find the
right drivers to use, therefore exits.
Looking at the Xorg.0.log from a bullseye netinst it looks
like it uses the /usr/lib/xorg/modules/drivers/modesetting_drv.so
driver inside a virtio equipped qemu VM,
which seems missing in
Hello,
this might be solved by [1].
As far as I see the dependency chain goes through
education-desktop-other to chromium, which depended to
sse3-support.
It might have started with 7df9e46cc a few month ago and ended with 98718255f,
unfortunately it does not mention a specific bug.
Kind
Hello,
this sounds related to these bugs:
https://bugs.debian.org/935916
https://bugs.debian.org/935496
Kind regards,
Bernhard
Dear Maintainer,
just tried to have a look at the part where steal-ctty is crashing.
It looks like it may get called from [1].
81 # Run the startup scripts once, using the preferred console
82 cons=$(cat /var/run/console-preferred)
83 # Some other session may have that console as
Hello Thomas,
Am 05.02.19 um 20:50 schrieb Thomas Gaugler:
...
> I thought to use the momentum around secure boot within Debian [2] for
> supporting it within win32-loader as well.
>
> The basic idea is to replicate the following commands in win32-loader:
> $ # Copy
Am 04.02.19 um 13:42 schrieb Didier 'OdyX' Raboud:
> Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
>> If such a system is detected, maybe a warning could be added?
>
> Sure. I suggest this would be done very early, but have no clue how to detect
Hello Tom Brown, dear Maintainer,
I just tried to reproduce this on a amd64 qemu EFI VM.
>From your description is not clear if you received on reboot
the menu to select between "Windows 10" or
"Debian GNU/Linux - Continue with install process"?
If that is missing you might add the output of
Hello Martin,
thanks for your answer.
It was less of an inconvenience as a surprise. In fact, after all
went fine, I was happy not to boot via tftp anymore. :-)
So, yes, this was just a note to the few users, who have concerns
writing to the flash in fear to create an unbootable device.
(I
Hello,
one little addition about this installation.
Emails like following get generated once a day:
--
From root@nas3c3b5d Wed Apr 15 22:57:26 2015
Envelope-to: root@nas3c3b5d
Delivery-date: Wed, 15 Apr 2015 22:57:26 +0200
From: mdadm monitoring root@nas3c3b5d
To: root@nas3c3b5d
Subject:
Package: installation-reports
Severity: normal
Tags: d-i
-- Package-specific info:
Boot method: network
Image version:
http://d-i.debian.org/daily-images/armel/20150415-00:19/kirkwood/network-console/qnap/ts-219/kernel
Date: 2015-04-15
Machine: QNAP Turbo Station TS-212
Partitions:
#
Hello,
just some additions.
Looks similar to bug #654380. (There mingw defaulted to produce dlls
depending also on some other mingw dlls)
There the upstream bug report [2] mentions that plugins must not depend
on a shared libgcc.
So I assume that the plugins must not depend on a shared
Hello,
probably I have found something more.
I tested in a VM with a more recent windows version, therefore I cannot
sure that this is the reason you saw (having to run win32-loader with
compatibility set to windows 7 on a windows 8.1 32bit).
I used the version from [1].
Because you already
12 matches
Mail list logo
