Humble suggestion for AMD GPUs problem

[Cmdte Alpha Tigre Z]

Hi.  I have been reading these threads about AMD GPUs failing and giving black
or distorted screens at boot.  I am writing here to drop an idea.  I
hope this helps,
if not, just forget it. :)

Could you make the system detect the unsuccessful boot failing to load
the graphical desktop interface, for example memory consumption is not rising
or some process initiated at a late stage has not loaded
after some seconds/minutes?  Then, if you can check for this, you could make
the system reload the graphical interface with the GPU disabled, only using
the CPU and then show the user a warning stating that his GPU is not working
and that he needs to download firmware X to get it working.

Well, I don't know if this is possible/feasible.  It just came to my
mind because
my PCs depend mostly on the CPU (no GPU) to do all the work.  I thought that
if the old ones could do it, then the new ones could surely do it too.

Again, I hope this helps.

Have a good day.

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

Hi.

I'm writing here to share my experience with eatmydata in the debian-installer.

I was installing Debian 10 on a USB stick.  The PC has a USB 2.0 port
and the stick's writing speed is about 4.6 MiB/s.  I did not measure
the installation time precisely, but I'm sure it took at least 6 hours
to complete
with an LXQt desktop and an Apache server.

I installed manually eatmydata, libeatmydata1 and eatmydata-udeb
on the installer's filesystem, by extracting the contents of the archives
to their right locations.  I do not remember using anna-install to install
the udeb, I don't know if it would make a difference.
Also, I used the normal DVD-1 ISO image, without eatmydata in it.

I wanted debootstrap to be called with eatmydata from the installer's menu,
so I renamed debootstrap as "debootstrap1" and put along it a script called
"debootstrap" which does 'eatmydata debootstrap "$@"'.  I made the patch
described at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633#50
but debootstrap complained that it cannot find eatmydata in the ISO, so I
installed it by hand, no apt, I don't know if this changed the
expected behavior.
Also, I don't know if using eatmydata explicitly with the script and later using
the scripts included with eatmydata-udeb cause some conflict and make it
not work.

I saw at the fourth virtual console that libeatmydata1.so was not being found
by the installer in the target directory tree, it was because I forgot
to make the
symbolic links pointing to the real library.  I made it while the
installation was
already running and I stopped seeing the messages come out in the syslog;
I suppose it was detected later, but I don't know if it worked as it
should since
I did this at the middle of the installation process, not before.

Anyway, perhaps I did something wrong, these are the things I remember
I did not do as specified in the above message.  But if everything
should have worked right, then eatmydata doesn't work as I expected
in my USB stick, or it is just too slow and it can not install faster.

What do you say?

Have a good day.

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

Ok, thank you for the additional information.

El vie, 9 abr 2021 a las 1:20, ValdikSS () escribió:

> 4. ISO image should include eatmydata and libeatmydata packages in /pool 
> directory. Right now only eatmydata-udeb is included.

I have questions, isn't eatmydata-udeb enough to get it working for d-i?
Does it have other dependencies on non-udeb packages or files
that are not in the initrd of the installer?
I thought that udeb packages were made to work as standalones,
with less dependencies.  If eatmydata-udeb is not enough to do
something with it, then it should be a bug.

--
Time zone: GMT-4

PS: I forgot to send this message to the list.  Sorry.

Bug#986500: finish-install: Also install spice-vdagent for kvm/qemu guests

[Cmdte Alpha Tigre Z]

2021-04-06 23:13 GMT-04:00, Arnaud Rebillout :
> Dear Maintainer,
>
> hw-detect already installs the package qemu-guest-agent when kvm/qemu
> virtualization is detect, in 'hw-detect.finish-install.d/08hw-detect':
>
> kvm|qemu)
> apt-install --with-recommends qemu-guest-agent || true
>
> I'd find it welcome if in such case it would also install spice-vdagent.
>
> As far as I know, installing spice-vdagent in the qemu guest is the only
> way to share the clipboard between the host and the guest. I think that
> clipboard sharing is a useful feature.

Hi.

I have a question, why not install it manually?
Virtualization is used many times to isolate the guest,
why it should be the default?

Have a good day,
Santiago Pinto

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

2021-04-07 4:51 GMT-04:00, john doe :
> This move should be documented somewhere and maybe emit a warning to
> that effect before starting the installer:
>
> "Incase of failure during the installation, it is recommended to restart
> from scratch."

That warning sounds good, but perhaps it should be there
whether you are using eatmydata or not.
I would not like to finish an interrupted partial installation too.

> Could d-i verify that the installation was successfull and tell it to
> the user?

As others have said, doing that thing that eatmydata disables
just at the end before d-i reports
the end of the installation procedure,
there should not be more risk using eatmydata than not using it.

As this proposal sounds like a very good idea, and since
it doesn't look to difficult to be done now, before the release of
Debian 11, the Debian-Boot team should do this.

What do we need to do to push this proposal to d-i for Debian 11?
--
Santiago Pinto

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

El mar, 6 abr 2021 a las 18:45, Samuel Thibault
() escribió:
>
> Cmdte Alpha Tigre Z, le mar. 06 avril 2021 18:16:49 -0400, a ecrit:
> > What would happen if you were installing Debian to dual-boot
> > with another OS?
>
> That is not a concern, only the partition getting installed is at risk.

Ok.  So in case of a power cut, the other partitions remain unaffected.

> > What would happen if you were repartitioning the disk
> > with some other stuff in it? ...
>
> That, however, has to run without eatmydata.
>
> But AIUI the idea is to make only debootstrap and the apt-based install
> use eatmydata.

Hmm, if that's the case, then I do think it is a good idea
to include and activate by default eatmydata.  debian-installer must,
however, be selective when using eatmydata; for example, it should
be disabled when using partman, to avoid cases like that presented above.
If it works only when doing the Debian installation per-se, which is
the most slow process, then there is nothing to lose.

Two days ago, I was trying to install Debian on a USB stick.
I think it took around 4 hours.  It would be better to install it
a lot faster without having any real added risk.

-- 
Time zone: GMT-4

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

Emm.  Sorry.  The mail was accidentally
sent twice.

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

2021-04-06 17:41 GMT-04:00, Samuel Thibault :
> Indeed. But a fresh install is not critical information. If you lost
> power during installation you'll want to restart over anyway.
>
> Its name is there for people to indeed not think that it's a magic wand
> that makes everything faster. It makes it faster at the expense of not
> protecting it from power loss. But here the half-installed system is
> moot anyway, we do not care that the dpkg database is coherent, we'll
> want to start over anyway.

It do makes sense to start over the installation if there were a
power failure.

2021-04-06 17:46 GMT-04:00, Lennart Sorensen  The only time eatmydata does any harm is if the system looses power or
> resets during the install since the data isn't constantly flushed to disk
> to maintain a consistent state.

Thanks for this clarification,
I know understand better the risk.

> During an install, there is nothing of
> value on the system yet, so doing everything as quickly as possible and
> then when everything is done, then you issue a sync command to ensure
> everything is flushed to disk saves a ton of time with no risk at all
> (in fact since the install takes less time, the changes of a power
> interruption happening during the install is lowered).
>
> In no way does eatmydata make it possible for the data of the resulting
> install to be corrupt.  As long as the filesystem is cleanly unmounted
> or flushed before you reset, you are fine.  That should already happen
> by the fact the install does a clean reboot at the end.
>
> Using it on a normal system is a different story since anything you modify
> while using it could be lost in case the system is reset unexpectedly,
> but since the install has no user data, there is nothing to risk.
>
> So when the page says to not use when you care about the data, that
> is correct.  But a fresh install is entirely made of stuff you don't
> care about, until it is completely done, then you care.  Using it for
> running testsuites where everything is just temporary data also makes
> sense to speed that up.  If you are editing something real, don't use it.
>
> --
> Len Sorensen
>

Ok.  Thanks Mr. Thibault and Mr. Sorensen.  I now understand
what is this proposal about.

Just some little questions, I'm still in doubt:
What would happen if you were installing Debian to dual-boot
with another OS?
What would happen if you were repartitioning the disk
with some other stuff in it? ...
and suddenly, your PC had a power loss.

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

2021-04-06 17:41 GMT-04:00, Samuel Thibault :
> Indeed. But a fresh install is not critical information. If you lost
> power during installation you'll want to restart over anyway.
>
> Its name is there for people to indeed not think that it's a magic wand
> that makes everything faster. It makes it faster at the expense of not
> protecting it from power loss. But here the half-installed system is
> moot anyway, we do not care that the dpkg database is coherent, we'll
> want to start over anyway.

It do makes sense to start over the installation if there were a
power failure.

2021-04-06 17:46 GMT-04:00, Lennart Sorensen  The only time eatmydata does any harm is if the system looses power or
> resets during the install since the data isn't constantly flushed to disk
> to maintain a consistent state.

Thanks for this clarification,
I know understand better the risk.

> During an install, there is nothing of
> value on the system yet, so doing everything as quickly as possible and
> then when everything is done, then you issue a sync command to ensure
> everything is flushed to disk saves a ton of time with no risk at all
> (in fact since the install takes less time, the changes of a power
> interruption happening during the install is lowered).
>
> In no way does eatmydata make it possible for the data of the resulting
> install to be corrupt.  As long as the filesystem is cleanly unmounted
> or flushed before you reset, you are fine.  That should already happen
> by the fact the install does a clean reboot at the end.
>
> Using it on a normal system is a different story since anything you modify
> while using it could be lost in case the system is reset unexpectedly,
> but since the install has no user data, there is nothing to risk.
>
> So when the page says to not use when you care about the data, that
> is correct.  But a fresh install is entirely made of stuff you don't
> care about, until it is completely done, then you care.  Using it for
> running testsuites where everything is just temporary data also makes
> sense to speed that up.  If you are editing something real, don't use it.
>
> --
> Len Sorensen
>

Ok.  Thanks Mr. Thibault and Mr. Sorensen.  I now understand
what is this proposal about.

Just some little questions, I'm still in doubt:
What would happen if you were installing Debian to dual-boot
with another OS?
What would happen if you were repartitioning the disk
with some other stuff in it? ...
and suddenly, your PC had a power loss.

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Cmdte Alpha Tigre Z]

2021-04-06 14:24 GMT-04:00, ValdikSS :
> People on #debian-boot IRC told me to contact dpkg team. Guillem Jover,
> one of dpkg maintainer, posted the following reply in dpkg
> --force-unsafe-io still calls fsync()
>  bug from
> 2014:
>
>> If someone can perform
>> more tests showing otherwise, please feel free to reopen and I'll
>> consider extending or adding a new option for a full-unsafe-io mode,
>> but as it stands, I don't think that makese any sense, when what you
>> might want is to just use eatmydata or similar.
>
> I've contacted him but unfortunately received no reply.
> I'd want to improve installation speed, but I don't know how to proceed
> further, and since Debian Bullseye is already at freeze state, I'm
> afraid we may end with slow installation for the next 2 years. I'd
> greatly appreciate any help.
>
>
> On 14.03.2021 03:18, ValdikSS wrote:
>>
>> Debian Buster installation from DVD1 ISO file takes enormous amount of
>> time in a VM without write cache and on bare metal with older (a bit
>> wore out) HDDs due to excessive fsync() calls.
>> For example, installation from debian-10.6.0-amd64-DVD-1.iso in a VM
>> without internet access took 1 hour, 44 minutes, 30 seconds. On a bare
>> metal: more than 40 minutes (I was too impatient, didn't wait it to
>> finish and powered off the machine).
>>
>> I found out that eatmydata-udeb package, which was implemented to
>> speed up the installation process, is included into ISO images (in
>> both CD and DVD), but can't be used because eatmydata and
>> libeatmydata1 packages are missing. Enabling eatmydata-udeb does not
>> have any effect in this case.
>>
>> The issues with eatmydata-udeb in my opinion are:
>>
>>  1. eatmydata-udeb should be enabled by default, to speed up the
>> installation process. It should not require to be enabled from
>> preseed file or bootloader cmdline. It's pointless to use fsync()
>> in installation process, the user won't attempt to fix partially
>> installed system due to power loss, it only slows it down.
>>  2. eatmydata and libeatmydata1 packages should present in ISO images
>> (/pool directory) to make eatmydata-udeb possible to use without
>> the internet.
>>  3. eatmydata-udeb should also inject libeatmydata to the base system
>> installation process, which is performed by debootstrap. Base
>> system installation is also quite slow, not as slow as the main
>> system due to much less package count, but still takes much more
>> time than it should.
>> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633
>> 
>>
>>
>> I've prepared an automatic patcher script which could be found here:
>> https://bitbucket.org/ValdikSS/debian-iso-fastinstall/
>> It adds eatmydata and libeatmydata1 packages into ISO image, patches
>> debootstrap to use libeatmydata, and activates eatmydata-udeb (patches
>> boot cmdline).
>>
>> With this script, patched debian-10.6.0-amd64-DVD-1.iso ISO file which
>> previously took 1 hour, 44 minutes, 30 seconds to install, now
>> installs in 10 minutes 37 seconds.
>> Patched netinstall image, when run without the internet access,
>> installs the whole mini distro with base utilities in less than 3
>> minutes.
>>
>> Petter Reinholdtsen, the author of eatmydata-udeb, asked me to post my
>> findings here for public discussion. What do you think?
>>
>>
>

Pardon my ignorance.
I could not resist to answer to this proposal.

I read this page: https://www.flamingspork.com/projects/libeatmydata/

It looks like it is not good idea to use it for critical information.

However, your results show that it would be relevant to include
such package into the first ISO, if it is not so big, of course.
It sounds like a good idea to speed up the instalation process
for some cases.

But, I would not enable it by default.  If the package really
behaves as its name suggests,
I would not risk every user
of Debian to have a faulty installation.  What would happen
if someone wants to install Debian an suddenly, the installer
eats some data it shouldn't have.

Even if it does not access wrong places, in the worst case
you could have installed an ill OS and don't notice
it will someday fail, and not gracefully.

My humble opinion is that it should be available to use,
but not enabled by default.

Have a good day.

Installing Debian from HDD with Win7 to USB stick

[Cmdte Alpha Tigre Z]

Dear developers and mantainers,

I want to install Debian to a USB stick from a hard drive
with Windows 7.

This is what I have already done:

I put an ISO DVD image of Debian 10.8 at C:\
I put vmlinuz and initrd.gz from hd-media at C:\tmpx\
I extracted g2ldr and g2ldr.mbr from the ISO image and put it at C:\tmpx\
I extracted setup.exe and win32-loader.ini from the ISO image and put it at C:\
I modified the win32-loader.ini (without the leading spaces) from:
[installer]
kernel=linux
arch=i386
i386/linux=install.386/vmlinuz
i386/initrd=install.386/initrd.gz
i386/gtk/linux=install.386/vmlinuz
i386/gtk/initrd=install.386/gtk/initrd.gz

[grub]
g2ldr=g2ldr
g2ldr.mbr=g2ldr.mbr
to:
[installer]
kernel=linux
arch=i386
i386/linux=tmpx/vmlinuz
i386/initrd=tmpx/initrd.gz

[grub]
g2ldr=tmpx/g2ldr
g2ldr.mbr=tmpx/g2ldr.mbr
Note: g2ldr and g2ldr.mbr can not be at root, otherwise
preinstallation fails when trying to copy them there.

I ran setup.exe and went to the end of the procedure successfully.

However, I saw that win32-loader (setup.exe) modified the initrd.gz
from hd-media.
As I understood from the log of win32-loader, some "preseed" information
was added to initrd.gz.  I saw it with 7-Zip and found that the data
"inside" the
initrd that is inside initrd.gz was unmodified.  Since 7-Zip reported that the
compressed initrd was modified and it also gave a wrong compressed size,
I opened initrd.gz with an hexadecimal editor and saw that some data was
"appended to" but not "put into" initrd.gz

Perhaps it is normal behaviour for the initrd.gz from the ISO, but
since I'm using
the one from hd-media on Debian's mirrors, I want to be sure that
nothing bad happened
and that I can continue with the installation.

Thanks in advance for your time and help.

Sincerely,
Santiago Pinto.

Bug#985755: Modprobe tried to load incorrect module

[Cmdte Alpha Tigre Z]

I noticed in the "syslog" that modprobe couldn't find the module "rtw_8723de"
that was not listed on the provided "hardware-summary";
instead, lsmod shows "rtw88_8723de".  Then, the module "r8169" tried to load
the firmware, but that module belongs to the GbE card.

hardware-summary:
lspci -knn: 02:00.0 Ethernet controller [0200]: Realtek Semiconductor
Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
[10ec:8168] (rev 15)
...
lspci -knn: Kernel driver in use: r8169
lspci -knn: Kernel modules: r8169
lspci -knn: 03:00.0 Network controller [0280]: Realtek Semiconductor
Co., Ltd. RTL8723DE 802.11b/g/n PCIe Adapter [10ec:d723]
...
lspci -knn: Kernel modules: rtw88_8723de

syslog:
Mar 25 20:35:04 main-menu[262]: (process:3599): modprobe: FATAL:
Module rtw_8723de not found.
Mar 25 20:35:04 main-menu[262]: (process:3599): modprobe: FATAL:
Module rtw_8723de not found in
directory /lib/modules/5.10.0-4-amd64
...
Mar 25 20:35:10 kernel: [  133.234274] r8169 :02:00.0: firmware:
failed to load rtl_nic/rtl8168h-2.fw (-2)
Mar 25 20:35:10 kernel: [  133.234278] r8169 :02:00.0: Direct
firmware load for rtl_nic/rtl8168h-2.fw failed with error -2
Mar 25 20:35:10 kernel: [  133.234281] r8169 :02:00.0: Unable to
load firmware rtl_nic/rtl8168h-2.fw (-2)