I booted Lubuntu daily 20200308. Something may have been fixed. Or, I may have been mistaken when I posted above. Today, if I press “s” during the rapid (small-file) checking: it skips. If I press during the lengthy casper-file check: 1) it doesn’t interrupt that. But, 2) it essentially skips the resulting pass/fail msg because it knows “s” was pressed.
That was probably good enough when this was only available through Grub, and someone would deliberately request this check. But, as an always-on check, I think that part should work better. If it’s not possible to detect “s” was pressed, it seems like it should ignore it when pressed on the last(?) file?
FYI: Testing the 20.04 daily images (20200310) for Kubuntu & Ubuntu desktop:
Kubuntu seemed to ignore tapping the “s” key (even during the rapid, smaller-file tests). If I held the key down it was recognized.
Ubuntu desktop didn’t show me the media verification process (no msg to press “S” to skip). It took a long time to reach the Live desktop. I assume the media check executed, and the absence of visual progress contributed to the perception that it took a long time. (I booted twice to verify that I was seeing what I thought I saw.).
I could have edited that grub entry to remove “quite splash” and probably saw it. But, this particular laptop, a Ryzen 3/Vega 3, is like typing over a 300 baud modem when editing Grub that way. I try not to do it very much. It’s literally “press an arrow key, wait a second for it to move.” (If I should report that as a bug, I can. When it comes to grub, I leave well enough alone.).
You should have a ‘notify’ under the spinner about checking file integrity.
Here on a haswell laptop it takes between 3-4 min depending on image.
1st time this happened I thought I had a bad image so re-downloaded…
I agree with @mc3man. I definitely like the idea of running this by default. (I think most people aren’t ware of how bad “burns” can happen. I know I was, and I think I’m fairly knowledgeable.). But, more time should have been spent on how this works.
When I do iso testing, I check the burn using the command line. The way the now-automatic boot check works, you have to pay attention to it so you can get the “s” to catch (else it can take a long time while it’s checking the large squash file – and ignoring any key press. Even worse, if that large file is the last one, it will say “skipped” rather than tell you the results when skipping at that point doesn’t matter.).
I’ve considered not doing my own command-line test, since I often find myself forced into waiting for the automatic check to finish. But, then I have to sit there and watch because if the automatic check detects errors, it will proceed merrily on its course to install (without waiting for me to see that brief msg).
I’m surprised how this was implemented without discussion, so late in the release cycle. I guess most people will just install once and not be frustrated with these shortcomings. For me, iso testing, I’m not liking it much. If it were me, I’d replace the “press ‘s’ to skip” msg with “please watch carefully for any errors.” Half the time skip doesn’t work. And, if the user isn’t paying attention to the media-check process, it might as well not even run because nobody will be any wiser about the condition of their boot media.
That’s what most of us would think, and try to re-download. Most of us would check the md5sum, before burning. Most of the Linux distro downloaders know that. It took just few seconds to check that in Windows 10. But, self checking by the Ubuntu 20.04 live iso took a while, and booting took nearly 4 minutes!
While it booted, I clicked Esc and watched. And, it went on checking, checking…the stuff in the usb. And, most of us would think, maybe the usb is bad…
This might be the culprit iso-scan/filename=${iso_path} or this 20iso_scan. But, there should be a warning that the distro in the usb is being checked.
There is a bug report regarding the lack of feedback while the media is being checked. This is due to the plymouth theme that doesn’t support fcsk messages and it is being worked on. Expect a fix soon.
Not sure that bug report mentioned preceding post is exactly the current issue here…?
There’s plenty of mentioning about the message/press s, ect. above but currently there is none.
At least here just the oem splash & a small spinning arrow that spins for 3-4 min till the live session loads.
Seems like the live session boot is combining the attempt to reduce screen transitions and doing this time consuming file by file ck., the result is less than polished.
in the past the ubuntu installer alway had an option to install with verification.
the current 20.10 server image does not have an option to instlll without it now.
form me this is a regression.
gernelly it would not be an issue but my current usecase today is i needed to install on a remove server(in tel aviv israel) from ireland using the iso mounted over idrac routed over my company vpn hosted in aws in the US.
i have gigabit fibe at home but due to all the indrection to actully connect to the system the check was still not complete after 1 hour. i restarted the install again without the check but having no way to easily skip it and having to find an artical that says add fsck.mode=skip to make progress is also off putting.
granted when i tried using fedora first it failed because anaconda would try to swap its video output to the nvida gpus on the bug instead of the remote console so the fact the ubunut installer is working at all is an improvment but making it simple to skip the verification defintly has its uses.
by the way i know my usecase is not relevent to the destop install since im doing a server install but it seams like the same default has been applied to both.
normally i would use other tools to image servers but in this case i dont have acess to the datacenter to do it any other way so had to fall back to manual install
changing this default without an easy way to opt out made my workflow much harder so i would suggest addign a way to disable it to the boot menu like it ws in the past.
I want to chime in in favor of disabling the automatic check or at least making it optional with a simple way to skip it. My use case is installing Ubuntu Server machines over IPMI and it takes ages to get to the actual installer.
As a general comment, considering that ISO images are nowdays only “burned” on USB sticks, this is even less of a problem than it used to be (though I’ve never encountered it). So please reconsider reverting this to not checking by default.