On Mon, Dec 14, 2020 at 4:33 PM Brian C. Lane <bcl@xxxxxxxxxx> wrote: > > On Sat, Dec 12, 2020 at 01:08:47PM -0700, Chris Murphy wrote: > > On Sat, Dec 12, 2020 at 10:43 AM Matthew Miller > > <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > > > On Sat, Dec 12, 2020 at 08:19:18AM -0500, Mauricio Tavares wrote: > > > > > I.... gave those reasons in my initial message? Have you experienced a > > > > > specific case where bad USB media caused a corrupt install? > > > > If by corrupt install you mean the fedora install froze after > > > > USB booted and before it told the install was successful, yes. Like > > > > early this year (so I guess it is too far in the past to be relevant > > > > to this discussion). Interestingly enough I then dd'ed ubuntu -- just > > > > needed to test hardware so any distro with the latest kernel would do > > > > -- in it because I thought it was a hardware incompatibility issue and > > > > it worked well enough to finish my tests. > > > > > > To me, the install freezing is not a lot different from the media check > > > freezing. We can tell people: if that happens, it's probably a bad USB > > > stick. The case that would be really concerning to me if bad media caused an > > > install to appear to work but then not boot. > > > > That could happen, but seems unlikely because anything corrupt that > > affects the as-installed boot, would also affect the live boot. But > > does it result in a crash or does it just result in weird behavior > > that looks like a bug? > > > > I don't know what percent of the bytes of the ISO image is read when > > booted. 25%? That leaves a chunk of programs and other content in an > > installation that could have this corruption, and transferred > > undetected to the target system. And how does it manifest? It's a rare > > upon rare event, and I expect it will be assumed to be a bug, and > > maybe we luck out and it goes away following a software update. > > > > I've suggested dropping the media check a few times over the years, > > but always in the context of replacing it with something better, > > faster, stronger. :P While the risk of dropping the media check is > > probably low, it's not zero risk. > > The problem I see with dropping it is that without it you do not know if > there are errors in the packages you are installing. With non-live > installs you can depend on rpm to detect that, but not with live since > we're just copying the files over. > > Anaconda may be able to add a check to the install process. If you run > rpm -Va on the newly installed system everything should match. But it > doesn't. Ends up there are a number of files with mode differences, and > even some with MD5 mismatches. But maybe anaconda touched them and they > can be filtered from the results? > > Without some other way to verify the installation I'm against dropping > the check from live. Not having it will result in some errors slipping > through and someone, either end users or developers, pulling out their > hair trying to debug it. Right. The two I've previously suggested: btrfs seed and dm-verity. Every read is verified, the user can't opt out, and they are more performant than checkisomd5. Upon detecting error, both emit EIO which is handled at the application level, i.e. stop the installation and notify the user. dm-verity has the advantage of optionally incorporating Reed-Solomon error correction, so that in the typical case the error is fixed seamlessly. Btrfs has the advantage of being simpler to implement. I think Will Woods had it hacked up in the Anaconda ecosystem many moons ago. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
