Re: [Freedos-user] fdupdate
Hello, I do agree with Rugxulo. Just adding my 2cts regarding FDUpdate (I'm the one responsible for creating the monster). Since I too often don't have networking in native DOS, I've never relied on FDupdate. Presumably it can (or could) do so, but I don't know the specifics. I don't know if it updates your install or (presumably) only the .ZIP files themselves. The idea of FDUpdate was to provide some kind of semi-graphical manager that would allow the average joe to add/update whatever packages in its system. To do so, FDUpdate downloads a list of available pakages from the FreeDOS repository (the URL of the repository is configurable via a configuration file), then it presents the list in a pseudo graphical menu with some descriptions about every package, and let the user to choose packages to install. FDUpdate is, however, just a nifty frontend. In the background it calls wget or htget (the downloader backend is configurable) to download the *.zip files into a temp directory, and then it calls FDPKG to install these zip files. All this would be great, but - as Rugxulo already noted - there is far too few packages online to make FDUPDATE actually useable in real life. There are also some minor (mostly cosmetic) bugs here and there, which I didn't ever cared to fix, as I quite quickly lost hope, as the whole packaging work was way more than what I could ever handle on my free time... and without packages, a packager is, well, useless. Yes, you pretty much have to install or update things manually. I hate to say it, but FDupdate seems like a failed experiment. Indeed. 'Failed experiment' is a term that describes FDUpdate quite accurately. Altough I prefer to think about it as a 'proof of concept' work ;) In other words - don't put any hope into using FDUPDATE for any serious update of your FreeDOS system. FDUPDATE will probably never be useable - unless suddenly there is an army of volunteers that starts massively populating the FDUPDATE repository (which is highly unlikely to ever happen anyway). Ciao, Mateusz -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] adding executable file to FreeDOS 1.1 installation image
Geraldo, you are probably correct. If I use fdboot.img as a floppy drive image like this: qemu -fda /home/martin/FreeDOS/isolinux/fdboot.img -boot a -m 128m ..I end up on the very same A:\ prompt. So I should: A) mount the CD mount point on the A:\ prompt Is this possible at all? As much as I browsed Wikipedia List of MS-DOS commands and checked utilities available on the A:\ prompt, there was no possibility to mount or access files other than included into fdboot.img floppy image. B) add BIOS flashing tool and BIOS ROM files to fdboot.img New fdboot.img should be much larger than the original one because flash tool itself is ~2MB. I did this: 1) Created 10MB raw file: root@debian64:~# dd if=/dev/zero of=10MB bs=10M count=1 1+0 records in 1+0 records out 10485760 bytes (10 MB) copied, 0,02243 s, 467 MB/s root@debian64:~# 2) Created partition table to MBR using fdisk. Results are following: root@debian64:~# fdisk -lu 10MB You must set cylinders. You can do this from the extra functions menu. Disk 10MB: 0 MB, 0 bytes 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x3009589f Device Boot Start End Blocks Id System 10MB1 * 1 1606499 803249+ 6 FAT16 root@debian64:~# 3) Mounted this 10MB file with 32256 offset: root@debian64:~# echo 63*512 | bc -l 32256 root@debian64:~# losetup --offset 32256 /dev/loop1 10MB root@debian64:~# 4) Created FAT16 file system: root@debian64:~# mkdosfs -F 16 -v /dev/loop1 mkdosfs 3.0.9 (31 Jan 2010) Loop device does not match a floppy size, using default hd params /dev/loop1 has 64 heads and 32 sectors per track, logical sector size is 512, using 0xf8 media descriptor, with 20416 sectors; file system has 2 16-bit FATs and 4 sectors per cluster. FAT size is 20 sectors, and provides 5085 clusters. There are 4 reserved sectors. Root directory contains 512 slots and uses 32 sectors. Volume ID is e2c98373, no volume label. root@debian64:~# 5) Umounted 10MB image: root@debian64:~# losetup -d /dev/loop1 root@debian64:~# 6) Copied MBR boot code to 10MB disk image: root@debian64:~# dd if=/usr/lib/syslinux/mbr.bin of=10MB bs=1 count=440 conv=notrunc 440+0 records in 440+0 records out 440 bytes (440 B) copied, 0,000622907 s, 706 kB/s root@debian64:~# file -s 10MB 10MB: x86 boot sector; partition 1: ID=0x6, active, starthead 0, startsector 1, 1606499 sectors, code offset 0x31 root@debian64:~# 7) Installed syslinux to 10MB1 partition(that is the reason I used 32256 byte offset): root@debian64:~# syslinux --install --offset 32256 10MB root@debian64:~# 8) Mounted this 10MB1 partition: root@debian64:~# mount 10MB /media/10MBfiledir/ -o loop,offset=32256 root@debian64:~# 9) Copied files from fdboot.img floppy image and few additional ones: root@debian64:~# ls /media/10MBfiledir/ atiflash.exe CHOICE.EXE DEVLOAD.COM ELTORITO.SYS FDCONFIG.SYS fdisk.iniHD5870.rom KERNEL.SYS MDISKCHK.COM SHSUCDX.COM UIDE.SYS USB2 XMSSIZE.COM AUTOEXEC.BAT COMMAND.COM EDIT.EXE FDAPM.COM FDISK.EXE GETARGS.COM jemmex.exe ldlinux.sys SHSUCDHD.EXE TDSK.EXE UPDATE.BAT vmsmount.exe root@debian64:~# 10) Unmounted 10MB image: root@debian64:~# umount /media/10MBfiledir root@debian64:~# As much as I understand, everything is done- 440 byte boot code in MBR is present, partition table in MBR is present, syslinux is installed to first partition, FAT16 file system is created to first partition and finally all the files from floppy image are copied to this 10MB image. However, I'm not able to boot into DOS with qemu. If I execute qemu with qemu -hda 10MB -boot c -m 128m I end up with: Booting from Hard Disk... Missing Operating System. No bootable device. Image as well: http://i.imgur.com/G45gj.png Any suggestions? regards, martin 2012/6/25, Geraldo Netto geraldone...@gmail.com: Hi Martin, files are probably not on your a:\ but on your cd mount point (maybe d:\?) in order to add to your files on a:\ you will need to edit the img file which represents a virtual floppy disk as far as i know isolinux has the magic configuration which points out to the img file i said before... maybe Bern or Eric can give you more details... (or any other FreeDOS fellow, of course :P) Kind Regards and Best Wishes, Geraldo Netto Non dvcor, dvco = Sapere Aude São Paulo, Brasil, -3gmt site: http://exdev.sf.net/ On 24 June 2012 19:40, Martin T m4rtn...@gmail.com wrote: I would like to add atiflash.exe(DOS application for flashing ATI graphics cards BIOS) and few BIOS image files(each are 128KB in size) to FreeDOS installation image. I downloaded 40MB FreeDOS 1.1 Base installation image, mounted it as a loop device, copied all the files from mount point to another directory, added atiflash.exe and ROM files and created a new bootable
Re: [Freedos-user] fdupdate
I think official freedos release must be just 2 or 3 floppies, as MSDOS was Boot system + basic drivers and tools (and both, cdrom and floppy image are required). No package manager needed for this base system Aditional to this, the community or any interested user can release cdroms with software collections. Such collections may include a package manager or a centralized install menu but is not required. Simpler to understand and mantain. Any person will install only the apps really need, and the install or update of base system is simple and quick -- -- +-+-+-+-+-+-+-+ Marco A. Achury Tel: +58-(212)-6158777 Cel: +58-(414)-3142282 Skype: marcoachury http://www.achury.com.ve El 25/06/2012 05:23 p.m., Mateusz Viste escribió: Hello, I do agree with Rugxulo. Just adding my 2cts regarding FDUpdate (I'm the one responsible for creating the monster). Since I too often don't have networking in native DOS, I've never relied on FDupdate. Presumably it can (or could) do so, but I don't know the specifics. I don't know if it updates your install or (presumably) only the .ZIP files themselves. The idea of FDUpdate was to provide some kind of semi-graphical manager that would allow the average joe to add/update whatever packages in its system. To do so, FDUpdate downloads a list of available pakages from the FreeDOS repository (the URL of the repository is configurable via a configuration file), then it presents the list in a pseudo graphical menu with some descriptions about every package, and let the user to choose packages to install. FDUpdate is, however, just a nifty frontend. In the background it calls wget or htget (the downloader backend is configurable) to download the *.zip files into a temp directory, and then it calls FDPKG to install these zip files. All this would be great, but - as Rugxulo already noted - there is far too few packages online to make FDUPDATE actually useable in real life. There are also some minor (mostly cosmetic) bugs here and there, which I didn't ever cared to fix, as I quite quickly lost hope, as the whole packaging work was way more than what I could ever handle on my free time... and without packages, a packager is, well, useless. Yes, you pretty much have to install or update things manually. I hate to say it, but FDupdate seems like a failed experiment. Indeed. 'Failed experiment' is a term that describes FDUpdate quite accurately. Altough I prefer to think about it as a 'proof of concept' work ;) In other words - don't put any hope into using FDUPDATE for any serious update of your FreeDOS system. FDUPDATE will probably never be useable - unless suddenly there is an army of volunteers that starts massively populating the FDUPDATE repository (which is highly unlikely to ever happen anyway). Ciao, Mateusz -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
