Menu
▾
▴
#301 Installation hanging at final stage - "Installing fresh configuration files."
Booting from a FreeDOS 1.3RC3 Legacy CD and installing to a freshly formatted partition, using a Toshiba Satellite 4000CDT. Two attempts produced the same result, no error thrown, it just stays on this screen indefinitely. The machine boots after a hard reset, but OS doesn't function properly / isn't fully configured.
I was actually able to complete the installation after a few tries- I noticed that it was still possible to input text while in the installer (it was showing up awkwardly in the vertical center of the display) and typing a random command woke up the installation routine, it then completed the last stage in a split second and asked me to restart.
No idea if this is hardware-specific or a general bug, as I have no other suitable machines to test on, but if there is anything I can do on a diagnostic level to confirm this, I'm happy to try.
This is an interesting issue. Without additional trouble shooting information, it will be dificult to tell if it is hardware or software related. Since, it does not appear to occur on other machines I'd suspect it is hardware-specific. But, that is pure speculation.
Do you still encouter this issue with the new 1.3-RC4?
Hi! I just stumbled upon exactly the same issue while installing FreeDOS on VirtualBox.
I blindly tapped "dir<enter>" and the installation has completed.</enter>
I used the LiveCD. The Legacy CD hung up at gathering information step, before copying files. Maybe I'll try that again and see if the same trick works as well.
I'm installing it on a CF card that will go into Pentium 166 terminal, that has no other drives. To emulate the environment closely, I selected no LAN, sound etc. An outstanding feature is 128MB of RAM - perhaps this may be your lead.
Good luck, and thanks for this software!
Tom
Last edit: Tomek Szczęsny 2021-12-01
Hi, the Freezing issue on the "Gathering Information" screen was being caused by an incompatibility with some systems. More or less there was a built in delay to prevent the screen from disappearing to quickly. The utility was using a high precision timer. Some systems and Virtual Machines would end up sitting forever wainting for a timer event that never occured. I don't recall if this fix made it into RC4 or not. However, it should no longer happen in RC5.
Now the -- lets call it "hit enter" bug -- would be something else. I've tested the install in several machines, VMs, Hardware and with different settings and have not seen this issue. That does not mean it is not a bug in the installer or one of the utilities it uses. There were a lot of changes going from RC3 to RC4, and even more in the upcoming RC5.
This is what I mostly need to know to determine what is causing the issue your seeing.
If I were to guess, it could possibly be a piece of data that is being passed from one utility to another is getting lost somehow or being discarded. Causing the utlity that is expecting data not to receive it. That could cause a utility to wait for input from the keyboard.
But, that is only speculation. I need more information to try and discover what may be causing the "hit enter" bug.
Hello,
I used both LegacyCD and LiveCD RC4. LegacyCD hung while gathering system information, and LiveCD has exposed "hit enter" bug.
In both cases, installer medium were mounted on VM as CD-ROM drive.
I'm repeating the installation process because I can't remember the details. I'm trying "LiveCD" now.
In case of LegacyCD I invoked setup.bat" because I was informed the installer won't work on this hardware. Rightly so, it didn't. In case of LiveCD installation started after selecting appropriate option in LiveCD Boot menu.
I tried with preinstalled system and Linux gibberish on my HDD, did not make difference. Partitioning tool worked as expected.
I don't remember exact installation options that I chose before , I think I tried both Polish and US keyboard. This time I'm trying with US keyboard and full set of games and software.
The last dialog I saw read "Installing fresh configuration files.", and as the original author of this bug described, I was able to type characters right after the "files.". After I hit enter, I got the question if I want to reboot now or not.
Sorry for not being more helpful than that. Thanks again for showing your interest. :)
Yes, VirtualBox did not like booting a CD the way the LegacyCD boots. It's not a bug in the installer or tools. It came down to VM hardware implementation compatibility. The LiveCD boots using a more complx and completely different method. I don't know if the bug in VirtualBox still exists or not. But, generally everyone should use the LiveCD unless they really need to use the LegacyCD. There is only a very limited range of hardware that can boot from CD and not boot the LiveCD. At sme point, we may drop the LegacyCD and just say to boot the Floppy CD Image if your system cannot boot the LiveCD. If you select the "install to hard disk" option on the LiveCD, it is actually the same booting the LiveCD except for the actual method used to boot it.
A lot has changed since RC4 for the upcoming RC5 in the installer, the tools it uses and the shell itself. I'm hoping it is a bug that no longer exists. There are several bugs that exist in other software that the installer "knows about" and compensates accordingly. There are also a bunch of things it does bacause of specific hardware. When running it looks simple, which is the point. But in reality it handles some external bugs, performs clean and update installs, can backup an existing OS or maybe start fresh, performs a bunch of automatic decisions, manages different package sets, multiple languages, multiple keyboard settings, runs from multiple install media. We are talking hundreds of possible scenarios. Then throw advanced mode into it and start tweaking installation directories, drives and more, it becomes nearly infinite. It is probably one of the most complex batch program every to run on DOS.
One more thing... Are you using the latest version of VirtualBox? On Windows, Linux or Mac?
Most of the testing I perform is on a Mac running the latest version of VirtualBox. Usually in English with Default Settings. But, I haven't seen the "hit enter" bug.
1.3-RC5 is coming outvery soon (probably in the next couple days). So hopefully the "hit enter" bug has either resolved itself or can be eradicated by then.
:-)
Last edit: Shidel 2021-12-05
Thanks a lot for looking into all this. Frankly my FreeDOS attempt was an one-off project to test some ancient military hardware I got in my hands. Sadly it doesn't appear to be in full working condition (or requires a hardware key to boot anything, don't know). FreeDOS didn't boot, but neither TinyCore. But that's outside of the scope of this bug.
Since you took this issue seriously I'll be happy to do more tests on RC5, or attempt some debugging if you pointed me in the right direction. For example, perhaps this vastly complex batch script has some sort of logging capabilities? :)
I'm using VirtualBox 6.1.28 on Manjaro.
Perhaps the best idea for now is to wait for RC5 to roll out and see if the problem persists.
Unfortunately, there is no logging support in it. Going forward, if we don't migrate to a diferent installer, I may add logging or additional functionality for debugging.
6.1.28 is fairly new. So, probably not an issue.
As for the ancient hardware... It could possibly not be 386 compatible. The CD's and CD boot floppy all use the 386 kernel to boot. It could be you require the 8086 kernel instead. The FloppyEdition boots the 8086 kernel. However, at present it will always assume it is installing to a 386 or better system. Basically, the utility the detects the CPU has some issues detecting older CPU's and reports some machines as lower than what they really are. For example, I have a 486 notebook it thinks is a 80186 based system. Until I find the time to fix that issue, the FloppyEdition always installs a 386+ version of the OS.
The FloppyEdition uses a completely different installer. It is mostly a "side-project". However, it is an official version and was included as diskette images and on the LiveCD in RC4 & RC5. Both as a EasterEgg boot and in a subdirectory on the CD itself.
Possibly good news. I think I may have found the issue. I was looking at the area of the installer that creates the new config files in hopes of seeing something that could be causing the issue.
This lead my to discovering an additional minor bug in FreeCOM that was probably causing it. So, I made a small change to the installer that would compensate for that bug. I'm hopeful that it is resolved now.
For more info on this specific shell bug that I think was resposible...
see https://github.com/FDOS/freecom/issues/63
Hi,
The hardware I was testing was not that ancient :) IT was Pentium 166 based on DigitalLogic SBC.
Thanks for follow up, I've subscribed to GitHub issue and test the solution when it's available :)
This was reported on RC3. Since then, we had FreeDOS RC4 and FreeDOS RC5 and now FreeDOS 1.3 "official."
Can you reconfirm this issue exists on FreeDOS 1.3?
Hi, I have the same issue when trying to install from FD 1.3 Live CD. I have a Compaq Armada 1573D.
Br, Eeli