Hi Eric, > Hi Jerome, thanks for your answers!
:-) > It would be cool if it included the drivers for that > and a readme. Only so much fits on a floppy. With the basic tools required to partition and format, run the installer and perform some essential recovery tasks. It is getting kind of cramped as it is. > Doing it automatically would be too > complicated, because you do not know what exactly > users would like to use as strategy, but I think it > is common that people are able to drop an ISO on a > FAT drive as part of the preparations for installing > a FreeDOS system on a computer without CD/DVD drive. Instead of copying the ISO, they could just copy the package directories directly to the HDD. To copy them correctly, the user just needs to make sure all of the required directories are present. In fact, they should be able to just XCOPY the entire contents of the CD to the HDD root directory. I used to have support in the installer (FDI) to also look for the package directory structure under a PACKAGES\ directory. I don’t think I have removed or broken support for that. I know FDIMPLES still supports it. After copying the packages, boot installer (FDI) from floppy. It will locate and use those packages to perform an installation. FDI does not permit installing FreeDOS to the same drive where the installer is running. This is mostly a design decision. There is no restriction on the location of the packages. > How about having the "lite" choice of packages pre-installed > in the "live" part of the CD / DVD, while having the "full" > set of packages zipped? It would make the download a bit > larger but use less RAMDISK space for actually using DOS? That is more or less how the new LiveCD is setup. Generally speaking, the new live CD functions like this… SYSLINUX/MEMDISK boots a floppy image on the CD. The floppy contains only the bare minimum programs to make the rest of this happen. This is roughly 1/2 the of that on the normal install boot floppy. The floppy loads some drivers and it does some platform detection prevent some compatibility issues. On most platforms, it will attempt to create a ram disk between 16MB and 384MB. If successful, it will extract a “LIVE” set of packages onto that drive. With less than 64MB of RAM the entire set will not be extracted and the user will be warned. After package extraction, the running system is reconfigured to use the RAM drive as the OS drive. In a system with 16MB of RAM or less, it will attempt to create a RAM drive between 1MB and 8MB to use for I/O redirection and temporary files. If that fails, it will switch RAM drivers and attempt to create one between 512K and 8MB for the same purpose. If it could not create a RAM drive 16MB or larger, it will switch over using the pre extracted BASE packages on the LiveCD for the OS. On some platforms (QEMU), it skips the initial RAM driver and falls back to the smaller RAM disk and driver. Thats an over simplification of the boot process. Far more happens. But, it should have covered your question. > >> In 1.2, the lite USB included both the BASE and FULL install package >> sets. However, It did not include all of the EXTRA and uninstalled >> packages that came on the big USB and CD media. > > So how large were BASE, FULL and EXTRA, respectively, both > in compressed and in installed form? And what are the top, > say, 5 largest FULL packages in 1.3, how much space would > be needed to install FULL when skipping those? I have not figured out the exact numbers. But off the top of my head as a rough guide, without sources the installed BASE is around 12MB and FULL is somewhere around 250MB. Installing FULL with sources requires nearly 500MB. Installing all the EXTRAS requires an additional 500 or 700MB. Maybe I’ll add some code to the build environment to automatically figure out those numbers. Possibly even have it embed them automatically in the README doc. > >> The USB images rely strictly on the BIOS to be able to use >> a attached USB drive to emulate an internal drive and boot >> them as a hard disk. > > I think there was some variation on how well BIOSes worked > with that? Some might work better with ZIP DRIVE geometry, > for example? Of course if you can use more LBA and less CHS > in the boot process and in DOS, things might be more stable > and exotic kernel and boot sector config options might help > with that, configurable via special SYS options ;-) It’s even worse than you mention. During the testing phase of 1.2, it was discovered that some systems boot the USB media in a read-only mode. Any attempt whatsoever to test for writability to the USB drive would result in loud beeps and sometimes the system would go completely insane. However, the majority of machines that could boot it just treated it like a regular internal drive. Ugh. > > Regards, Eric > :-) Jerome _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
