debian-installer-netboot-images_20170127_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 02 Feb 2017 08:09:04 +0100 Source: debian-installer-netboot-images Binary: debian-installer-9-netboot-amd64 debian-installer-9-netboot-arm64 debian-installer-9-netboot-armel debian-installer-9-netboot-armhf debian-installer-9-netboot-i386 debian-installer-9-netboot-mips debian-installer-9-netboot-mips64el debian-installer-9-netboot-mipsel debian-installer-9-netboot-ppc64el Architecture: source Version: 20170127 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Didier Raboud Description: debian-installer-9-netboot-amd64 - Debian-installer network boot images for amd64 debian-installer-9-netboot-arm64 - Debian-installer network boot images for arm64 debian-installer-9-netboot-armel - Debian-installer network boot images for armel debian-installer-9-netboot-armhf - Debian-installer network boot images for armhf debian-installer-9-netboot-i386 - Debian-installer network boot images for i386 debian-installer-9-netboot-mips - Debian-installer network boot images for mips debian-installer-9-netboot-mips64el - Debian-installer network boot images for mips64el debian-installer-9-netboot-mipsel - Debian-installer network boot images for mipsel debian-installer-9-netboot-ppc64el - Debian-installer network boot images for ppc64el Changes: debian-installer-netboot-images (20170127) unstable; urgency=medium . * New 20170127 debian-installer release Checksums-Sha1: 0d9bddc574dfe1cd931b263191e3e4dc45547187 2426 debian-installer-netboot-images_20170127.dsc cbb139378cfdaeab52c34fe440613acd1d581d97 6804 debian-installer-netboot-images_20170127.tar.xz c0f6520db40cd3f868b616352697f3115e0bf826 5224 debian-installer-netboot-images_20170127_source.buildinfo Checksums-Sha256: 29eda032172fbc3cea6a14507733431a1cb55c358d82815aec133e4ce46475d7 2426 debian-installer-netboot-images_20170127.dsc cae2158c80676f3661167e634cb5da8516c39d4ca89adbee87e7fd43fe7a6f8d 6804 debian-installer-netboot-images_20170127.tar.xz f14a3290d8e51b58ff24b23fe16fe51294e15b936aff440737c629092707feef 5224 debian-installer-netboot-images_20170127_source.buildinfo Files: af301b5dc54ed92dee4eb0e84df87aed 2426 misc optional debian-installer-netboot-images_20170127.dsc 8a9503f8f4feb2acccac40edea141900 6804 misc optional debian-installer-netboot-images_20170127.tar.xz 386aeb3f880839b12da0e626d398573a 5224 misc optional debian-installer-netboot-images_20170127_source.buildinfo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEe+WPIRpjNw1/GSB7i8+nHsoWNFUFAliS3GIACgkQi8+nHsoW NFXkugwAiwwZTMwBI3UFwlxOPnN7NhFnODnlLyTSA7aeKXAUdEsnhwMKBMe6DwVv zUCq2uyd4Kie2BEn/KpyI6HDC+3MVQmE+5syUdqTGGe02jkFeD6WiQeLcz1xLS1F eGyXA4oqd6CAlo+F12MEUq7KkINWHs//Da8uT9oJxcHTMXfkiw2Yhe93QTd4hChn 52qkRwyL8LPX7eRXb8+4VgEPnygiGuhI9WUEiICbPRFP78/6EhrXuqlJuqmfIuKk K4jED2VkIY6jGI9RviFjzXly6cHMEsgsKo4rwyyT2OoostOA+EixblECEWpnmAxW QPfgMeTIVFsM/NQURNV3ZAelUbRfiEd+HxxmXy/oYomqKGgXh3N173guk6DyFHNe wvdtudN3pA+bmGgH1ha/SSTWctAXq5vCA7cByVDxKGFjfexS73WZXaWQoZbnb9RG z6Jt5fQNMzgbp+9+i8aKPgdejOtL+TcE+vaNDtIsEeOhUtZo2sLSnVZUU2csvIg1 ziZcrp3y =58/y -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of debian-installer-netboot-images_20170127_source.changes
debian-installer-netboot-images_20170127_source.changes uploaded successfully to localhost along with the files: debian-installer-netboot-images_20170127.dsc debian-installer-netboot-images_20170127.tar.xz debian-installer-netboot-images_20170127_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#853921: fonts-android-udeb: broken rendering for Korean glyphs in debian-installer
Package: fonts-android-udeb Version: 1:6.0.0r26-1 Severity: serious Tags: d-i Justification: breaks d-i for Korean (Please keep both debian-boot@lists.debian.org and myself in copy when replying.) Hi, I've reported this regression for Korean support against debian-installer a few minutes ago: “debian-installer: missing glyphs for Korean / broken rendering” → https://bugs.debian.org/853917 As documented there, checking Alpha releases led me to a regression between Alpha 5 and Alpha 6. Since pkg-lists had no changes related to fonts-* packages in between, I looked at fonts-android as a prime suspect, and that wasn't too bad a try. :) I've built d-i images systematically for all versions between the one in Alpha 5 and the one in stretch right now, and all versions including and after 1:6.0.0r26-1 have the same issue, while 1:4.4.4r2-7 does the job properly: | ./mini+1:4.4.4r2-7.iso : OK | ./mini+1:6.0.0r26-1.iso: KO | ./mini+1:6.0.1r3-1.iso: KO | ./mini+1:6.0.1r3-2.iso: KO | ./mini+1:6.0.1r16-1.iso: KO debdiff on the udeb shows: | $ debdiff fonts-android-udeb_4.4.4r2-7_all.udeb fonts-android-udeb_6.0.0r26-1_all.udeb | […] | Files in second .deb but not in first | - | -rw-r--r-- root/root /usr/share/fonts/truetype/droid/DroidSansFallbackFull.ttf | | Files in first .deb but not in second | - | -rw-r--r-- root/root /usr/share/fonts/truetype/droid/DroidSansFallback.ttf which matches the packaging changes documented in changelog: | +fonts-android (1:6.0.0r26-1) unstable; urgency=medium | + | + * Imported Upstream version 6.0.0r26 | ++ Upstream no longer ships Droid fonts except, DroidSansFallback, | + DroidSansFallbackFull and DroidSansMono. | […] | + * Install DroidSansFallbackFull as part of fonts-android-udeb. I've just checked, for the avoidance of doubt, that adding a symlink from the old filename to the new filename doesn't change anything. We'll need to have a fix for stretch, otherwise that means no Korean support in d-i, which doesn't seem reasonable. I might try and check whether the needed codepoints are present in the new version (through fontforge) but I'm no expert at all… Maybe that's just some fontconfig stuff that needs adjusting. I can easily test any patches against fonts-android, since building d-i against local packages only takes a minute here; so feel free to use me as a puppet to experiment fixes. ;-) Thanks for your time, and sorry for not detecting this sooner. KiBi.
Bug#853917: debian-installer: missing glyphs for Korean / broken rendering
Source: debian-installer Version: 20160516 Severity: important Tags: l10n (debian-l10n-kor...@lists.debian.org in X-Debbugs-Cc for informational purposes; maybe someone there will find out what happened before someone from the installer team does.) Spotted by victory and mentioned on IRC: we're currently lacking support for Korean in the installer, since both the menu entry for Korean at the language selection step and later prompts are only showing the usual boxes for unknown glyphs. :( I've just tracked this down as a regression from Stretch Alpha 5 to Stretch Alpha 6. I'll try and investigate further in a few hours. KiBi.
Re: d-i manual: 3 "jessie" remain in current guide
Hello, victory, on Mon 30 Jan 2017 21:53:52 +0900, wrote: > no idea if these are still valid also for stretch; > > boot-installer/arm.xml:55- > The graphical installer is not enabled on the arm64 &d-i; images > for jessie so the serial console is used. > > boot-installer/arm.xml:108- > ... Also USB is not supported in the jessie kernel so > installing from a USB stick does not work. ... I have no idea either. debian-arm people, any idea? Samuel
Debian Installer Stretch RC 2 release
The Debian Installer team[1] is pleased to announce the second release candidate of the installer for Debian 9 "Stretch". Important change in this release of the installer = * A major update of os-prober was included in this release. This component is responsible for finding other operating systems so that entries can be added to the bootloader's menu. This update should fix serious bugs, some of which leading to file system corruption, but might also trigger some regressions. As usual, running "reportbug os-prober" from the installed system lets you report any issues. Improvements in this release * debian-installer: - Bump Linux kernel version from 4.8.0-2 to 4.9.0-1. - Adjust *.so files handling (#851790). * os-prober: - Improve logging of mounting and setting partitions to ro/rw. - Use a read-only device-mapper entry when appropriate. - Skip partition when FS type is LVM2_member (#853277). - Make os-prober-udeb depend on grub-mount-udeb, and make os-prober depend on grub-common, so that grub-mount is consistently available (#776275). - Fix detection of /usr partition as a GNU/Linux root partition when /lib* directories are moved to /usr completely (#698733). - Make the yaboot parser more tolerant (#674561). - Call dmraid only once. - Add os-release support (#794409). - Work harder to avoid trying to mount extended partitions (#784709). - Drop " (loader)" suffixes on Microsoft operating systems (#787418). - For more improvements, see: #698598, #694668, #803155, #801631, #851983. Hardware support changes * debian-installer: - Drop armel/versatile flavour since kernel support was removed. - mips*: install all NIC modules in the netbood initrd. * flash-kernel: - Add machine db entry for Pine64+. * linux: - udeb: Add switch (DSA) drivers to nic-modules (#845075). Localization status === * 75 languages are supported in this release. * Full translation for 12 of them. Known bugs in this release == * There seems to be no known major bug as of yet. See the errata[2] for details and a full list of known issues. Feedback for this release = We need your help to find bugs and further improve the installer, so please try it. Installer CDs, other media and everything else you will need are available at our web site[3]. Thanks == The Debian Installer team thanks everybody who has contributed to this release. 1. http://wiki.debian.org/DebianInstaller/Team 2. http://www.debian.org/devel/debian-installer/errata 3. http://www.debian.org/devel/debian-installer -- Cyril Brulebois on behalf of the Debian Installer Team signature.asc Description: Digital signature
Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?
at bottom :- On 01/02/2017, Lennart Sorensen wrote: > On Wed, Feb 01, 2017 at 02:27:39PM +0530, shirish शिरीष wrote: >>> My patch was fix for bug which was spotted on large disk arrays, >>> 36 in my case. So itable initialization was active all the time >>> while holding global lock. >> >> From this, it seems there aren't any limits except for 10% of whatever >> the link between > > Why would a large array make a difference to the algorithm if it aims > to use 1/10 of the bandwidth? Hi Lennart, I dunno (not an expert in large disk arrays) . For this you would have to look at https://patchwork.kernel.org/patch/9285509/ titled - "Patchwork ext4/023: add regression test for ext4lazyinit_task deadlock V2" >From the title it seems some sort of deadlock was occurring. For what reason can probably be garnered by reading the code or/and talking with Dmitry Monakhov who wrote that patch. FWIW he wrote couple of patches this month as well - https://patchwork.kernel.org/project/fstests/list/?submitter=172391 > -- > Len Sorensen > -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#853755: installation-reports: ppc64el fails to boot after installation
Hi, Erwan Prioul (2017-02-01): > Unfortunately, I don't have a working image. > The issue has appeared since last Saturday, Jan 28th. Could this be due to latest kernel updates? 4.9.6-x were accepted on the 27/28th. You could either use rescue mode or redo an installation, and in /target (before rebooting into the installed system), try installing an older version of the linux-image package. Older binaries are available on snapshots: http://snapshot.debian.org/package/linux/ Anyway, I think this should be filed against src:linux since the installation process itself seems to have worked fine. Feel free to reassign once you have found in which version the regression was introduced (if that's indeed a regression). KiBi. signature.asc Description: Digital signature
Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?
On Wed, Feb 01, 2017 at 02:27:39PM +0530, shirish शिरीष wrote: > Basically the article's statement is wrong. > There is no such thing as explicit itable initialization IO bandwidth > restriction in MB/s. itable initialization rate is controlled by init_itable=N > see: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt > """ > The lazy itable init code will wait n times the > number of milliseconds it took to zero out the > previous block group's inode table. This > minimizes the impact on the system performance > while file system's inode table is being initialized. > """ > By default init_itable=10, so it use 1/10th bandwidth of the disk. > And if we back to original article this means author used generic > HDD with 160Mb/s sequential write performance. Oh OK, that sounds even better. > My patch was fix for bug which was spotted on large disk arrays, > 36 in my case. So itable initialization was active all the time > while holding global lock. > > From this, it seems there aren't any limits except for 10% of whatever > the link between Why would a large array make a difference to the algorithm if it aims to use 1/10 of the bandwidth? -- Len Sorensen
Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?
On Wed, Feb 01, 2017 at 04:53:34AM +0530, shirish शिरीष wrote: > hmm From what little I understand, it always the slowest interface > that needs to be supported. > > And IIUC , in ext4lazyinit's case it is probably some of the MMC cards > due to which the 16 MB/S transmission is kept - although some of them > are at 104 MB/S as well. > > https://en.wikipedia.org/wiki/MultiMediaCard#Table > > Whereas USB are at - > > https://en.wikipedia.org/wiki/USB_3.1 > > USB 2.0 - 35 MB/S > > USB 3.0 - 400 MB/S > > USB 3.1 - Gen 1 - 400 MB/S > > USB 3.2 - Gen 2 - 1280 MB/S > > For HDD - > > https://en.wikipedia.org/wiki/Serial_ATA > > SATA 1 - starts at 150 MB/S Well they wanted to keep the rate low enough that you could still use the disk while it was doing the background init work. Most disks can do more than 16MB/s so that leaves some for other use, like doing your install. > Another query - if instead ext4lazyinit IF - > > mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root > > is applied then would it would start formatting and making inodes at a > much faster rate - i.e. slowest between the USB Drive and HDD in a > typical workstation - which probably would be a jump 3-4 times the > speed that ext4lazyinit would employ. Well it would have to do the whole init up front, meaning you have to wait for all of it to finish before doing the install. > WDYT ? > > If yes, how as a user could I apply/use the above command while using > debian-installer ? Not sure. It has been a while since I poked at the installer code. I don't think it's worth trying to poke at it. I think the default behavour sounce very sensible and I doubt for most use cases doing it differently would be an improvement, most like it would make it worse. -- Len Sorensen
Bug#853855: di-utils: Kernel boot options containing a dot are not propagated to the installed system
Package: di-utils
Version: 1.117
Severity: minor
Tags: d-i
A kernel boot param like net.ifnames=0 will be skipped when the installer
parses the boot option for setting the bootloader.
Found in di-utils:
# Skip module-specific variables
varnodot="${var##*.*}"
if [ "$varnodot" = "" ]; then
continue
fi
So basically any option containing a dot is not propagated to the
installed system. This was introduced by
7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-specific
parameters in user-params.")
I found no documented or obvious reason for this behaviour.
-- System Information:
Debian Release: 8.7
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Lo que se viene en 2017: No te quedes afuera
No te quedes afuera de lo que se viene en http://fileserver.itsitio.com/descargas/itsitio/ITSitio_100116_HTML_Gadgets.html
partman-nbd_0.43_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 01 Feb 2017 05:23:37 +0100 Source: partman-nbd Binary: partman-nbd Architecture: source all Version: 0.43 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-nbd - Adds support for NBD to partman (udeb) Changes: partman-nbd (0.43) unstable; urgency=medium . [ Updated translations ] * Catalan (ca.po) by Jordi Mallach * Spanish (es.po) by Javier Fernández-Sanguino Peña Checksums-Sha1: 90bba18bd6b8131c9f65615342ad0336c7c7828f 1635 partman-nbd_0.43.dsc 1ab8dcc5b0a3e0cd208c793d1ea735dedc59198e 66620 partman-nbd_0.43.tar.xz dc865642aefc254fb3b27b6b765476abfe73a837 39368 partman-nbd_0.43_all.udeb 1edc50cdd1909002f82069e86a72b6554cfdc632 4609 partman-nbd_0.43_i386.buildinfo Checksums-Sha256: 1987d5ce9fe26b03bf2ffb1ba84cf0d239dc534c87171c80ecfa728f229ba695 1635 partman-nbd_0.43.dsc 7083a40a4f2f69f84e026ed9fb5fcb761ef7b9f55e9d613da004aa9419105109 66620 partman-nbd_0.43.tar.xz 2ce44ce2d201280053c21b76f63a39fe6b026429d27927c53e4fae0c62ef0aca 39368 partman-nbd_0.43_all.udeb c442ae1e9d757491c8f856e97db4fee76865a282886794cb47917eacfc07d3a6 4609 partman-nbd_0.43_i386.buildinfo Files: 70fc657ecde53353f16e3cea63c30829 1635 debian-installer optional partman-nbd_0.43.dsc 5177a2252d3c6d6da279683c5c4beacc 66620 debian-installer optional partman-nbd_0.43.tar.xz 21427904f9dd0847259ab03985171390 39368 debian-installer optional partman-nbd_0.43_all.udeb 7417c9437ce5dbee54d96d762801486d 4609 debian-installer optional partman-nbd_0.43_i386.buildinfo -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYkaOJAAoJEIcvcCxNbiWoYiAQAImADkblvyAuXyxjlS081cbA nrepD2ArIWYbBlKhPvexNSOMisFMs1JLZ2IgwkcNt2Uenw2aHO9TFffI4oGhKwWg raXjJuAwWNmbxdAhnUD0V9khdFjmoqsVHIYp1LdX3+XO8lYrRMvvyRpyxxXGZc+U U2OFDSw/4saqOZYjjM+XERgcSIMRT5oraaqw5hbXujlOBc6mD0j/Kuj7D8LL1x1q s4vsqFzdgm3vBY10LO8DJL3ExG6kHolA/q7YE8hPOpWMMF1s4+ras8Iq/SFQBfzm JB2gb2vzzp15kL0WLaS0QJWBRBGTeBP1jSG+/iBPLPevhhdPsAJjPzCpYrtMuruc ygUty2bxUQIdGEr7zcxswZyRMKODjdFnIyF8d6qk/yz1Yl7lInq4ObP7yd+79rHE AtdoKGPv+zuL52lGj0OSVHEmx6KqHZho7wLxamSr/S0gXc4o90EjN7I+DZkPH6h/ mmRNuEeuaBCAURIBIjS4quMe3h8nYX/ysSEFCkxpLjFvBwVwf5tsEbnZuKdihCkY k81SRrSlYDbjWgmUZm9Roi/Na9uCD1ouw3hxoA2zxpuq0lp4OtSdGaaihc8JpbU5 rE/Gva+xoM/OAx2x3noikOOGlD2937X8v03HaKbHdGEYV35eYm/blZ+17GQ4SpZa ZdUCs/GV9Nj/M4qZYrVE =Yhec -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#853755: installation-reports: ppc64el fails to boot after installation
Hi KiBi, On 01/31/2017 08:04 PM, Cyril Brulebois wrote: > Hi Erwan, > > Erwan Prioul (2017-01-31): >> Package: installation-reports >> >> Boot method: ISO image >> Image version: >> http://cdimage.debian.org/mirror/cdimage/daily-builds/daily/current/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso >> Date: Tue Jan 31 16:18:45 2017 >> >> Machine: qemu VM >> Processor: ppc64el >> Memory: 4Gb >> Partitions: >> /dev/sda1 7.3 MBPowerPC PReP boot partition >> /dev/sda2 6.6 GBext4 >> /dev/sda3 4.2 GBswap >> >> Initial boot: [O] >> Detect network card:[O] >> Configure network: [O] >> Detect CD: [O] >> Load installer modules: [O] >> Detect hard drives: [O] >> Partition hard drives: [O] >> Install base system:[O] >> Clock/timezone setup: [O] >> User/password setup:[O] >> Install tasks: [O] >> Install boot loader:[O] >> Overall install:[O] >> >> Comments/Problems: >> >> Using qemu, I created a ppc64el virtual machine. >> I selected the guided partitioning to use the entire disk (all the >> default options). >> The installation went well but it failed to boot then. >> I got the same on P8 PowerVM and P8 baremetal. > > Do you have a reference image which managed to boot after installation, > which might help us pinpoint the regression (since it looks like one)? Unfortunately, I don't have a working image. The issue has appeared since last Saturday, Jan 28th. Erwan. signature.asc Description: OpenPGP digital signature
Processing of partman-nbd_0.43_i386.changes
partman-nbd_0.43_i386.changes uploaded successfully to localhost along with the files: partman-nbd_0.43.dsc partman-nbd_0.43.tar.xz partman-nbd_0.43_all.udeb partman-nbd_0.43_i386.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?
Hi all, Please see below - shirish शिरीष writes: > Dear Dmitry, > > I saw your patch about regression testing for ext4lazyinit > > https://patchwork.kernel.org/patch/9285509/ - that is where I got your mail > id. > > > I am a bit curious to know as to why the author/ess chose to > keep 16 MB/S as the highest speed ? > > https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem Basically the article's statement is wrong. There is no such thing as explicit itable initialization IO bandwidth restriction in MB/s. itable initialization rate is controlled by init_itable=N see: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt """ The lazy itable init code will wait n times the number of milliseconds it took to zero out the previous block group's inode table. This minimizes the impact on the system performance while file system's inode table is being initialized. """ By default init_itable=10, so it use 1/10th bandwidth of the disk. And if we back to original article this means author used generic HDD with 160Mb/s sequential write performance. My patch was fix for bug which was spotted on large disk arrays, 36 in my case. So itable initialization was active all the time while holding global lock. >From this, it seems there aren't any limits except for 10% of whatever the link between On 01/02/2017, shirish शिरीष wrote: > in-line :- > > On 01/02/2017, Lennart Sorensen wrote: >> On Wed, Feb 01, 2017 at 12:46:48AM +0530, shirish शिरीष wrote: > > > >>> Now I have few queries - >>> >>> a. Are my assumptions wrong ? >> >> About the doing the init on a future boot, yes you are wrong. > > Ah...ok. > > > >> >> 2.6.37 apparently. > > My bad ... > > > >> >> I believe it is on by default. However, the lazy init takes >> place in the background on first mount (so that means during >> the install), not some later boot. It apparently will use >> up to 16MB/s for initializing in the background according to >> https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem >> >> I suspect it is already doing the best you are going to get. > > hmm From what little I understand, it always the slowest interface > that needs to be supported. > > And IIUC , in ext4lazyinit's case it is probably some of the MMC cards > due to which the 16 MB/S transmission is kept - although some of them > are at 104 MB/S as well. > > https://en.wikipedia.org/wiki/MultiMediaCard#Table > > Whereas USB are at - > > https://en.wikipedia.org/wiki/USB_3.1 > > USB 2.0 - 35 MB/S > > USB 3.0 - 400 MB/S > > USB 3.1 - Gen 1 - 400 MB/S > > USB 3.2 - Gen 2 - 1280 MB/S > > For HDD - > > https://en.wikipedia.org/wiki/Serial_ATA > > SATA 1 - starts at 150 MB/S > > Another query - if instead ext4lazyinit IF - > > mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root > > is applied then would it would start formatting and making inodes at a > much faster rate - i.e. slowest between the USB Drive and HDD in a > typical workstation - which probably would be a jump 3-4 times the > speed that ext4lazyinit would employ. > > WDYT ? > > If yes, how as a user could I apply/use the above command while using > debian-installer ? > >> -- >> Len Sorensen >> > > > -- > Regards, > Shirish Agarwal शिरीष अग्रवाल > My quotes in this email licensed under CC 3.0 > http://creativecommons.org/licenses/by-nc/3.0/ > http://flossexperiences.wordpress.com > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 > -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
