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

[Arnaud Rebillout]

Package: hw-detect
Severity: normal
User: de...@kali.org
Usertags: origin-kali

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.

To go a bit more into details, clipboard sharing requires two things to
work.

1) Host-side: Enable spice while running the VM with qemu. It means that
   the qemu command-line must have the following arguments:

-spice port=3001,disable-ticketing \
-device virtio-serial \
-chardev spicevmc,id=vdagent,debug=0,name=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \

2) Guest-side: The package spice-vdagent must be installed.

For more details, refer to:


The package spice-vdagent Depends on the Xorg stack, among other things:

$ apt show spice-vdagent | grep Depends
Pre-Depends: init-system-helpers (>= 1.54~)
Depends: libasound2 (>= 1.0.22), libc6 (>= 2.14),
 libdbus-1-3 (>= 1.9.14), libdrm2 (>= 2.4.3),
 libglib2.0-0 (>= 2.50), libgtk-3-0 (>= 3.22),
 libpciaccess0, libsystemd0, libx11-6, libxinerama1,
 libxrandr2 (>= 2:1.2.99.2)

So maybe it would be acceptable to install it with something like:

if detect_desktop; then
  apt-install --with-recommends spice-vdagent || true
fi

What do you think?

Regards,

  Arnaud

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: Can't install Grub on SSD (bullseye)

[Steve McIntyre]

Please respond to the mailing list too - that way other people may be
able to help, and solutions may help other users too.

On Tue, Apr 06, 2021 at 01:58:06PM +0200, Xavier Brochard wrote:
>Le 06.04.2021 12:57, Steve McIntyre a écrit :
>> On Tue, Apr 06, 2021 at 12:11:54AM +0200, Xavier Brochard wrote:
>> > I'm currently testing the new installer for bullseye. I ran into a
>> > strange
>> > problem with grub-install, using "bios" grub, not EFI. Basicaly grub
>> > files
>> > are not copied in /boot/grub if my carget is a SSD.
>> > Could you tell me if this is a known issue before I write a bug
>> > report ?
>> 
>> Ummm. That's a very odd situation that should not happen. When you say
>> SSD, is that SATA or NVME?
>
>SATA. It is an 1TB Crucial SSD. It's the only writable device (when I tried
>with a hardrive, the HD was also the only writable device pluggged in in the
>exact same SATA connector).

OK, thanks for confirming that!

...

>I forgot to mention that I tried also to install Grub from CLI, with /proc
>/sys /dev  mounted in /target, chroot with bash from /target. I got the exact
>same error.

OK.

>> Can you show us the partitioning on both the SSD and the hard drive
>> please? (fdisk -l is probably easiest).
>
>SSD SSD SSD SSD
>Disque /dev/sdd : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
>Modèle de disque : 500SSD1
>Unités : secteur de 1 × 512 = 512 octets
>Taille de secteur (logique / physique) : 512 octets / 512 octets
>taille d'E/S (minimale / optimale) : 512 octets / 512 octets
>Type d'étiquette de disque : dos
>Identifiant de disque : 0x49b255ac
>
>Périphérique Amorçage  DébutFin   Secteurs Taille Id Type
>/dev/sdd1*  2048 780287 778240   380M 83 Linux
>/dev/sdd2 780288 1953523711 1952743424 931,1G 8e LVM Linux

OK, so that's set up with a DOS partition table and there should
definitely be space there for embedding the grub core image before
partition 1.

>HD HD HD HD  HD
>Disque /dev/sde : 465,76 GiB, 500107862016 octets, 976773168 secteurs
>Modèle de disque : 02-1BD142
>Unités : secteur de 1 × 512 = 512 octets
>Taille de secteur (logique / physique) : 512 octets / 512 octets
>taille d'E/S (minimale / optimale) : 512 octets / 512 octets
>Type d'étiquette de disque : dos
>Identifiant de disque : 0x9cea469a
>
>Périphérique AmorçageDébut   Fin  Secteurs Taille Id Type
>/dev/sde1*2048  19531775  19529728   9,3G 83 Linux
>/dev/sde2 19533822 976771071 957237250 456,4G  5 Étendue
>/dev/sde5 19533824 976771071 957237248 456,4G 8e LVM Linux

And you have a similar setup here.

OK, all looks fine here so far. Next questions...

1. What filesystem(s) have you set up on each disk, please? Where are
   they mounted in each case? Your initial problem report said
   "grub-install: error: cannot open
   `/boot/grub/i386-pc/sleep_test.mod': No space left on device." -
   can you confirm that /dev/sdd1 is mounted on /boot OK?

2. Is there anything showing in the syslog complaining about disk
   errors?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

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

[Samuel Thibault]

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.

> 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.

Samuel

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.

Bug#986491: fails to fully configure with debconf low priority

[Samuel Thibault]

Nick Gawronski, le mar. 06 avril 2021 17:01:16 -0500, a ecrit:
> Package: debian-installer
> Severity: important
> Tags: d-i a11y
> X-Debbugs-Cc: n...@nickgawronski.com

I guess the reportbug tool didn't work out that well. Pasting below the
text received previously on debian-boot.

Samuel

“
Hi, I had written about this to mailing lists several years ago but never got
the proper bug number as I think the bug was reported.  I often like to run
the installation at low priority so I can configure everything correctly at
the start of the installation process and so that when the system reboots into
the newly installed system things are all setup and ready to go. After the
base system is installed I then exicute a shell and chroot into /target and
run dpkg-reconfigure adduser to tell it not to have system readable home
directories.  If I then do dpkg-reconfigure debconf still in the chroot and
set it to low priority the installation continues up until it gets to the pam
profiles selection screen.  No matter what I select here even when everything
is selected the system tells me that no pam profiles are enabled for the
system and would grant all users access with authenticating which is not
allowed.  I can not preceed past this screen as even trying to go to another
shell and change the priority back to medium will not work as I am still stuck
at that screen when I return to the console.  I also think that if a user sets
the priority to low in the installation process that at least for the
installation even in the target the priority remain at that setting and if a
user wants to change it back to medium they could do this after the
installation.  How would I be able to submit further information on how to get
the proper information to someone so it could be looked into and get fixed?
Nick Gawronski
”

Bug#986491: fails to fully configure with debconf low priority

[Nick Gawronski]

Package: debian-installer
Severity: important
Tags: d-i a11y
X-Debbugs-Cc: n...@nickgawronski.com



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

[Lennart Sorensen]

On Tue, Apr 06, 2021 at 05:35:19PM -0400, Cmdte Alpha Tigre Z wrote:
> 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.

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.  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

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

[Samuel Thibault]

Cmdte Alpha Tigre Z, le mar. 06 avril 2021 17:35:19 -0400, a ecrit:
> I read this page: https://www.flamingspork.com/projects/libeatmydata/
> 
> It looks like it is not good idea to use it for critical information.

Indeed. But a fresh install is not critical information. If you lost
power during installation you'll want to restart over anyway.

> But, I would not enable it by default.  If the package really
> behaves as its name suggests,

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.

Samuel

issue with configuring a debian installation with debconf set to low priority both at the beginning and after the base system is installed

[Nick Gawronski]

Hi, I had written about this to mailing lists several years ago but 
never got the proper bug number as I think the bug was reported.  I 
often like to run the installation at low priority so I can configure 
everything correctly at the start of the installation process and so 
that when the system reboots into the newly installed system things are 
all setup and ready to go. After the base system is installed I then 
exicute a shell and chroot into /target and run dpkg-reconfigure adduser 
to tell it not to have system readable home directories.  If I then do 
dpkg-reconfigure debconf still in the chroot and set it to low priority 
the installation continues up until it gets to the pam profiles 
selection screen.  No matter what I select here even when everything is 
selected the system tells me that no pam profiles are enabled for the 
system and would grant all users access with authenticating which is not 
allowed.  I can not preceed past this screen as even trying to go to 
another shell and change the priority back to medium will not work as I 
am still stuck at that screen when I return to the console.  I also 
think that if a user sets the priority to low in the installation 
process that at least for the installation even in the target the 
priority remain at that setting and if a user wants to change it back to 
medium they could do this after the installation.  How would I be able 
to submit further information on how to get the proper information to 
someone so it could be looked into and get fixed?  Nick Gawronski

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.

Re: issue with configuring a debian installation with debconf set to low priority both at the beginning and after the base system is installed

[Samuel Thibault]

Nick Gawronski, le mar. 06 avril 2021 16:22:27 -0500, a ecrit:
> How would I be able to submit further information on how to get the
> proper information to someone so it could be looked into and get
> fixed?

You can report a bug against the debian-installer package. Sending what
you sent in your previous email should be already a good start.

Samuel

Re: instructions for building the non-free debian installation images with the latest gtk network installation for testing the latest espeakup changes

[Daniel Leidert]

Am Montag, dem 05.04.2021 um 12:58 -0500 schrieb Nick Gawronski:
> Hi, I have uncommented that setting and so if I were interested in 
> building the latest CD image with non-free firmware and having this 
> image after about 4 seconds automatically launch the talking installer 
> what files would I change?  I am also interested in after the installer 
> starts having it automatically set debconf priority to low and put me at 
> the main menu is this possible? Nick Gawronski

start automatically -> BOOT_TIMEOUT
debconf priority -> debconf/priority (priority)

https://www.debian.org/releases/buster/i386/ch05s03.en.html

With simple-cdd this is a matter of adding those to KERNEL_PARAMS and/or the
preseed-file(s).

Regards, Daniel

-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

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

[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?





OpenPGP_signature
Description: OpenPGP digital signature

Re: Can't install Grub on SSD (bullseye)

[Steve McIntyre]

On Tue, Apr 06, 2021 at 12:11:54AM +0200, Xavier Brochard wrote:
>Hi
>
>I'm currently testing the new installer for bullseye. I ran into a strange
>problem with grub-install, using "bios" grub, not EFI. Basicaly grub files
>are not copied in /boot/grub if my carget is a SSD.
>Could you tell me if this is a known issue before I write a bug report ?

Ummm. That's a very odd situation that should not happen. When you say
SSD, is that SATA or NVME?

>Here's more details :
>
>This was tried several times on an intel server with hard-drive or SSD as
>target. Both using a /boot partition anl LVM for everything else. Problem
>happened only with SSD. I've used Bullseye images with firmware, build on the
>end of march or the beginning of april.
>
>Trying to install grub on SSD failed, saying "no space left" while there is
>tons on free space in the /boot partition and folder /boot/grub is empty :
>===
>Apr  5 21:21:07 grub-installer: info: Installing grub on '/dev/sda'
>Apr  5 21:21:07 grub-installer: info: grub-install does not support
>--no-floppy
>Apr  5 21:21:08 grub-installer: info: Running chroot /target grub-install
>--force "/dev/sda"
>Apr  5 21:21:08 grub-installer: Installing for i386-pc platform.
>Apr  5 21:21:08 grub-installer: grub-install: error: cannot open
>`/boot/grub/i386-pc/sleep_test.mod': No space left on device.
>Apr  5 21:21:08 grub-installer: error: Running 'grub-install  --force
>"/dev/sda"' failed.
>===
>
>Booting with rescue option doesn't give the choice to fix Grub install if SSD
>is the target. While testing with hard drive as target, the option is there.

Can you show us the partitioning on both the SSD and the hard drive
please? (fdisk -l is probably easiest).

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?

choose-mirror_2.110_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 06 Apr 2021 11:20:24 +0200
Source: choose-mirror
Architecture: source
Version: 2.110
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Changes:
 choose-mirror (2.110) unstable; urgency=medium
 .
   * Team upload
   * Update Mirrors.masterlist.
 .
   [ Updated translations ]
   * Latvian (lv.po) by Tranzistors
   * Tamil (ta.po) by Vasudevan Tirumurti
   * Traditional Chinese (zh_TW.po) by louies0623
Checksums-Sha1:
 58c1f2f25ff52ec7e50816dd0e1957d33a0bdd48 1860 choose-mirror_2.110.dsc
 4881550ab591b0e15e03ca6c830a27be38de514c 191280 choose-mirror_2.110.tar.xz
 0900c1534aa3b5a45563a8843e9138fa9056f6a8 6654 
choose-mirror_2.110_amd64.buildinfo
Checksums-Sha256:
 1e254bc1041b34993de8df9859a7f4caa1195bc99de5d8c63307265f20589518 1860 
choose-mirror_2.110.dsc
 d18a8fa9172bb7e323b8d8b6f234b61db15d304eadf72541fcfc4b6f72420e79 191280 
choose-mirror_2.110.tar.xz
 193214855df7c7d2f757887fe1a85c7f4f0a03aca18785abfb86afcefebcd776 6654 
choose-mirror_2.110_amd64.buildinfo
Files:
 5ee04ddf039debb561692f27099a9846 1860 debian-installer optional 
choose-mirror_2.110.dsc
 00b7e1ea8c8b35e06721d0c503fbf832 191280 debian-installer optional 
choose-mirror_2.110.tar.xz
 3fd8e85956fd082c11eff4feef408031 6654 debian-installer optional 
choose-mirror_2.110_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAmBsLDUVHGh3YW5zaW5n
QG1haWxib3gub3JnAAoJEFnxh8oVbrB20ZgQAJ6yX6JYqiShnuYYKiIk7cfZ5AS7
BxwFJAtvhuq2AGHzo3bNE8EJFjrNVkQAS0vF8FeU+H+c8wM06jxfbcB2fPvyi7aS
/9JGbPXiRDqteyaLaCwC9eQu0Ql83jDJmq/QdNq5l8py8VNa/pN971zFArOMFzZu
xIFckDAMG9/gfhz3u1+x9mWNOXrXpv0BD+i5ToFxA+0JaI1w56E5nCim1ew86rF1
5ijnSdsRKVWVWYAhvENDRmNg/PPkC8GrBF1f51/LwKVgtwtj7ZCQ7OSFA3oO7lFy
3HbdFEkd/B+jlvKiN7MwQVmSeVSkLusaogvVsvKFu4TIyo9xfhJ/AE6SVfAGxwiX
khgPRtkgHHk3h8SOjC4VYBjU4Mw63jyQGElIgp8mrUG2JJQ7X+glGFmzfgPqjXon
urs7SoPb+NdEzr8EYLpYgKaGtDzFPRTxn/ezv/9rUvHKLhn+WrD3ko0HeDia11ho
iMqu0kWxSrapzns3MocFjerRypEAThZZK/ITPYwu3W3HtafO0HgVVxqiWeWgfg5Q
miVJLigyd0Pq65u2KMijiCiw6fvYzSTUvVKZi5VDFjYBj/JdDsDXVjNGbQPYLvLw
z+oiVM8U270TikJWY+5y3BAeoQcaedpTMAZEjPizKn9HJQLDVla8a+6ITg0VPt0u
r0y9FfeRXou5S7nj
=EgYo
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of choose-mirror_2.110_source.changes

[Debian FTP Masters]

choose-mirror_2.110_source.changes uploaded successfully to localhost
along with the files:
  choose-mirror_2.110.dsc
  choose-mirror_2.110.tar.xz
  choose-mirror_2.110_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Re: choose-mirror upload

[Julien Cristau]

On Fri, Apr 02, 2021 at 12:47:40PM +0200, Holger Wansing wrote:
> Hi Julien,
> 
> would it be ok to upload choose-mirror with the attached diff?
> There is a translation update pending, and I wonder if I should include a
> "make Mirrors.masterlist" ?
> 
Yes I think that should be fine.  I'll try to do another pass through
the mirror issues in the next weeks and make another upload then, but
an update in the mean time can't hurt (and helps if I don't actually get
to it).  Thanks!

Julien