2021-04-06 14:24 GMT-04:00, ValdikSS <i...@valdikss.org.ru>: > 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() > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428#77> 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 >> <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.
