Fdutils

fdutils@fdutils.linux.lu

80 discussions

fdutil 5.5/5.6 cannot compile
by Brian Hagen 20 Mar '21

20 Mar '21

Hello, all: I went to put together my first run of fdutils. I entered "./configure", all went well. Using "make" went through several stages, then bombed out with a fatal error message, posted at the end of this message. I am using an Ubuntu Studio 18.04 host system, all is up to date with it. I followed the trail, installing (via apt-get) bison, flex, and fdutils. I am not certain how to get a version level on "mtools". At this point, there is only a broken make sequence, and it will go no further until I find out what is causing it. Header files not included? Environment variables not set? I am not certain. The message: fdmount.c:25:10: fatal error: linux/ext2_fs.h: No such file or directory #include <linux/ext2_fs.h> ^~~~~~~~~~~~~~~~~ compilation terminated. <builtin>: recipe for target 'fdmount' failed make[1]: *** [fdmount] Error 1 rm enh_options.o measure.o calc-format.o oldfdprm.o parse.o driveprm.o misc.o lex.mediaprm.o lex.driveprm.o printfdprm.o skews.o lex.mediaprm.c mediaprm.o lex.driveprm.c make[1]: Leaving directory '/sdl1/bharts/midi-stuff/Ensoniq/SQ80/dox/utils/FD5-5/fdutils-5.5/src' Makefile:8: recipe for target 'compile' failed make: *** [compile] Error 2 ========================= (additional efforts to track down internal functions, e.g., fdmount, and compile separately resulted in): fdmount.c:25:10: fatal error: linux/ext2_fs.h: No such file or directory #include <linux/ext2_fs.h> ^~~~~~~~~~~~~~~~~ compilation terminated. <builtin>: recipe for target 'fdmount' failed --------fdmount.c: In function ‘id_fstype’: fdmount.c:453:13: error: dereferencing pointer to incomplete type ‘struct ext2_super_block’ if (ext2->s_magic==EXT2_SUPER_MAGIC ^~ fdmount.c: In function ‘canonicalize’: getcwd (canonical, PATH_MAX); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ fdmount.c: In function ‘do_mount’: read(fd,super,sizeof(super)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ fdmount.c: In function ‘main’: chdir ("/"); /* no current directory. */ ^~~~~~~~~~~ make[1]: *** [fdmount] Error 1 make: *** [all] Error 2 --------------------------------------------- Ideas, anyone? Brian

2 1

Re: [Fdutils] fdutil 5.5/5.6 cannot compile
by Stefan Fiedler 20 Mar '21

20 Mar '21

Hello Brian, it seems like the header linux/ext2_fs.h is missing on your build system: fdmount.c:25:10: fatal error: linux/ext2_fs.h: No such file or directory You can check if it is there with: |ls -l /usr/include/linux/ext2_fs.h| |If it isn't, installing this package should solve the problem:| ||sudo apt-get install e2fslibs-dev|| ||It might be necessary to re-run ./configure afterwards, if it depends on the existence of this package. || ||- Stefan || Am 20.03.2021 um 12:00 schrieb fdutils-request(a)fdutils.linux.lu: > Message: 1 > Date: Fri, 19 Mar 2021 21:23:15 -0500 > From: Brian Hagen <bdhagen(a)fastmail.com> > To: fdutils(a)fdutils.linux.lu > Subject: [Fdutils] fdutil 5.5/5.6 cannot compile > Message-ID: <5fbb5d98-7f23-20af-65da-05769458c61a(a)fastmail.com> > Content-Type: text/plain; charset=utf-8 > > Hello, all: > > ??? I went to put together my first run of fdutils. I entered > "./configure", all went well. Using "make" went through several stages, > then bombed out with a fatal error message, posted at the end of this > message. > > ??? I am using an Ubuntu Studio 18.04 host system, all is up to date > with it. I followed the trail, installing (via apt-get) bison, flex, and > fdutils. I am not certain how to get a version level on "mtools". > > ??? At this point, there is only a broken make sequence, and it will go > no further until I find out what is causing it. Header files not > included? Environment variables not set? I am not certain. > > ??? The message: > > fdmount.c:25:10: fatal error: linux/ext2_fs.h: No such file or directory > ?#include <linux/ext2_fs.h> > ????????? ^~~~~~~~~~~~~~~~~ > compilation terminated. > <builtin>: recipe for target 'fdmount' failed > make[1]: *** [fdmount] Error 1 > rm enh_options.o measure.o calc-format.o oldfdprm.o parse.o driveprm.o > misc.o lex.mediaprm.o lex.driveprm.o printfdprm.o skews.o lex.mediaprm.c > mediaprm.o lex.driveprm.c > make[1]: Leaving directory > '/sdl1/bharts/midi-stuff/Ensoniq/SQ80/dox/utils/FD5-5/fdutils-5.5/src' > Makefile:8: recipe for target 'compile' failed > make: *** [compile] Error 2 > ========================= > > (additional efforts to track down internal functions, e.g., fdmount, and > compile separately resulted in): > > fdmount.c:25:10: fatal error: linux/ext2_fs.h: No such file or directory > ?#include <linux/ext2_fs.h> > ????????? ^~~~~~~~~~~~~~~~~ > compilation terminated. > <builtin>: recipe for target 'fdmount' failed > > --------fdmount.c: In function ?id_fstype?: > fdmount.c:453:13: error: dereferencing pointer to incomplete type > ?struct ext2_super_block? > ???? if (ext2->s_magic==EXT2_SUPER_MAGIC > ???????????? ^~ > fdmount.c: In function ?canonicalize?: > ????? getcwd (canonical, PATH_MAX); > ????? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > fdmount.c: In function ?do_mount?: > ???? read(fd,super,sizeof(super)); > ???? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > fdmount.c: In function ?main?: > ????? chdir ("/"); /* no current directory. */ > ????? ^~~~~~~~~~~ > make[1]: *** [fdmount] Error 1 > make: *** [all] Error 2 > > --------------------------------------------- > > Ideas, anyone? > > > Brian

1 0

Make ends with error @ Fedora 32 64 Bit
by Jürgen Wich 27 Jan '21

27 Jan '21

2 1

[Bug] fdrawcmd partid command
by Stefan Fiedler 23 Sep '19

23 Sep '19

There is a bug in fdrawcmd.c as the 'partid' name is associated with the FD_SAVE command but should use FD_PARTID instead. Attached is a patch that fixes this, tested with the latest fdutils release.

1 0

Fwd: fdrawcmd: format_n_write IO error
by Stefan Fiedler 23 Sep '19

23 Sep '19

Hello everyone, when trying to use the fdrawcmd format_n_write command it gives an IO error and does not write the data. Reading the FDC data sheet did not reveal any hints either. Attached is a sample script that shows how I use the format_n_write command. When the variable format_n_write is set to 0 the script also uses the more common way of formatting and then writing a track, which works without problems. Does anyone have a clue what I may be missing, or maybe the FDC is buggy? Reading the source code of fdrawcmd it appears that the ioctl call for the FDRAWCMD fails with errno EIO. The floppy module then stops working and needs to be reloaded. The kernel output at that point is: [19580.077949] floppy driver state [19580.077983] ------------------- [19580.078102] now=4819734 last interrupt=4818815 diff=919 last called handler=main_command_interrupt [floppy] [19580.078147] timeout_message=floppy start [19580.078181] last output bytes: [19580.078226] 8 80 4818474 [19580.078269] 8 80 4818474 [19580.078313] f 80 4818815 [19580.078356] 0 90 4818815 [19580.078398] 0 90 4818815 [19580.078440] 8 81 4818815 [19580.078483] 13 80 4818982 [19580.078525] 0 90 4818982 [19580.078568] 1a 90 4818982 [19580.078610] 0 90 4818982 [19580.078652] 8e 80 4818982 [19580.078695] 3 80 4818982 [19580.078738] c1 90 4818982 [19580.078779] a 90 4818982 [19580.078822] ef 80 4818982 [19580.078864] 0 90 4818982 [19580.078906] 2 90 4818982 [19580.078949] 9 81 4818982 [19580.078991] 50 91 4818982 [19580.079033] 0 91 4818982 [19580.079069] last result at 4818982 [19580.079106] last redo_fd_request at 4818815 [19580.079160] 00 00 00 00 c1 0a 09 04 1a 00 .......... [19580.079209] status=91 [19580.079243] fdc_busy=1 [19580.079312] do_floppy=main_command_interrupt [floppy] [19580.079356] cont=c6bbfda4 [19580.079393] current_req= (null) [19580.079430] command_status=-1 [19580.079514] floppy0: floppy timeout called Best regards, Stefan Fiedler #!/bin/bash drive_nr=0 drive_type="DD" drive_side="DS" drive_geom="5 1/4" drive=/dev/fd$drive_nr format_n_write=1 case $drive_type in "HD") rate=0 # for HD track_step=1 track_max=80 read_id_count=32 ;; "DD") track_step=2 track_max=40 read_id_count=18 case "$drive_geom" in "5 1/4") rate=1 ;; # for DD 5 1/4" "3 1/2") rate=2 ;; # for DD 3 1/2" esac ;; esac case $drive_geom in "5 1/4") gpl1=0x2a ; gpl2=0x50 ;; "3 1/2") gpl1=0x1b ; gpl2=0x54 ;; esac if [ "$drive_type" = "ED" ] ; then gpl1=0x38 ; gpl2=0x53 ; fi szgap=0x1b # default for 3,5" drives with 512 bytes/sector? Unused by FDC? track=0 drvsel=0 echo fdrawcmd drive=$drive rate=$rate seek $drvsel $(( $track * $track_step )) fdrawcmd drive=$drive rate=$rate seek $drvsel $(( $track * $track_step )) 2>rawcmd_stderr >rawcmd_stdout nr_sectors=9 szcod=2 for (( x=1; $x <= $(( 2 ** ($szcod + 4) )); x=$(( $x + 1 )) )) ; do printf "\x01\x23\x45\x67\x89\xab\xcd\xef" done > tmp_sector.data for (( x=1; $x <= $nr_sectors; x=$(( $x + 1 )) )) ; do C=$(( $track * $track_step )) H=0 R=$x Z=$szcod printf "\x${C#0x}\x${H#0x}\x${R#0x}\x${Z#0x}" done > tmp_id.data length=$(( 2**($szcod+7) * $nr_sectors + 4 * 9 )) spt=$nr_sectors gpl3=$gpl2 fmtfill=0x0 if [ "$format_n_write" = 0 ] ; then echo fdrawcmd drive=$drive rate=$rate format $drvsel $szcod $spt $gpl3 $fmtfill fdrawcmd drive=$drive rate=$rate format $drvsel $szcod $spt $gpl3 $fmtfill < tmp_id.data length=$(( 2**($Z+7) * $nr_sectors )) C=$(( $track * $track_step )) H=0 R=1 Z=$szcod for (( x=1; $x <= $nr_sectors; x=$(( $x + 1 )) )) ; do cat "tmp_sector.data" done > tmp_track2.data szcod2=0xff echo fdrawcmd drive=$drive rate=$rate length=$length write $drvsel $C $H $R $Z $spt $szgap $szcod2 fdrawcmd drive=$drive rate=$rate length=$length write $drvsel $C $H $R $Z $spt $szgap $szcod2 < tmp_track2.data else for (( x=1; $x <= $nr_sectors; x=$(( $x + 1 )) )) ; do C=$(( $track * $track_step )) H=0 R=$x Z=$szcod printf "\x${C#0x}\x${H#0x}\x${R#0x}\x${Z#0x}" cat "tmp_sector.data" done > tmp_track.data length=$(( 2**($Z+7) * $nr_sectors )) echo fdrawcmd drive=$drive rate=$rate length=$length format_n_write $drvsel $szcod $spt $gpl3 $fmtfill strace fdrawcmd drive=$drive rate=$rate length=$length format_n_write $drvsel $szcod $spt $gpl3 $fmtfill < tmp_track.data fi szcod2=0xff echo fdrawcmd drive=$drive rate=$rate length=$length read $drvsel $C $H $R $Z $spt $szgap $szcod2 fdrawcmd drive=$drive rate=$rate length=$length read $drvsel $C $H $R $Z $spt $szgap $szcod2 > tmp_track3.data

2 2

EPERM error using fdmount
by Paul Ausbeck 20 Oct '15

20 Oct '15

I am running Debian Wheezy 7.9 on a D815EEA2 motherboard system and I recently had occasion to use its 1.2MB 5.25" floppy drive. I can mostly use fdtools and mtools successfully. I can format the drive using fdformat and mformat. I can mount the drive conventionally: sudo mount -t vfat /dev/fd0 /mnt/test. #Successful But I can't mount the drive using fdmount: sudo fdmount fd0 /mnt/test#Error fdmount (/dev/fd0): ioctl(code) failed: Operation not permitted I've tracked things down a bit and the failure occurs at line 741 of fdmount.c: DO_IOCTL(fd,FDSETPRM,&F); I've also looked at the kernel a bit and the failure occurs at lines 3236-3237 of floppy.c: if (!capable(CAP_SYS_ADMIN)) return -EPERM; I don't know much or anything about linux capabilities but they appear at first glance to be implemented via some sort of per-thread security structure. I'm posting a query to the mailing list before opening a bug report as I don't know whether or not this is a bug or some sort of system administration issue. Any help would be greatly appreciated. Regards, Paul Ausbeck

1 0

Physical order of sectors of interleaved disks
by Cristian Savu 11 Aug '15

11 Aug '15

Hi everybody, I have some floppy disks (both 5.25" and 3.5") for an old Spectrum compatible computer that uses Spectrum Basic with floppy disks. Anyway, these are 720K DD disks with 80 cylinders, 2 sides, 18 sectors per track per side and interleaved like this: [UTILS1.TD0] 82 Cyls, 2 Heads: 250Kbps MFM, 18 sectors, 256 bytes/sector: 0.0 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 17 9 18 1.0 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 17 9 18 2.0 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 17 9 18 3.0 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 17 9 18 .............. and so on I'm trying to find a way to copy these disks as raw image files in Linux, while preserving the physical order of sectors on the physical disk. If I do: setfdprm /dev/fd0 dd cyl=80 head=2 sect=18 ssize=256 and then: dd if=/dev/fd0 of=/home/knoppix/none/disk.img I get the raw image containing the sectors in the logical order (1 2 3 4 5 6 ... instead of 1 10 2 11 3 12 ...) So the next thing I tried was to use fdrawcmd and send a raw command to the FDC. The thing is, what I need is a READ TRACK command to 82072, which according to the data sheet would copy one side of a cylinder in the physical order of sectors, exactly as they are laid on disk. I'm not sure why, but the READ TRACK command is not mentioned in the fdrawcmd documentation, only the READ command ... (???) Also the need_seek parameter is not mentioned, nor the track= parameter... I had to check the fdutils sources to figure out the actual argument to pass to fdrawcmd... (read_track) So I tried this: fdrawcmd read_track 0 0 0 1 1 0 0x1b 0xff rate=2 length=4608 need_seek track=0 > track.bin but to my disappointment I still get the sectors in their logical order in the 4608 byte data chunk saved. So bottom line, is there any way to save the sectors in their physical order using fdutils? Or maybe I should change the sources and rebuild fdutils? Thank you Cristian

2 2

Thanks a lot, guys
by Patrick Serru 26 Jul '13

26 Jul '13

Hello All, A French proverb says, "A rolling stone gathers no moss." The statement is a bit silly, but the semantics is telling the truth. I traveled a lot and therefore did not "keep" a lot (nor won much anyway). I thought I had thrown everything, related to a micro computer based on the MC6801, entirely designed and produced by me, and animated by Flex2. But no! I did not have throw the cards, and even kept some floppies! These disks are dated from 1985 - 1986. And having them found, I wanted to retrieve the contents. I spoke to the ancients always addicted to Flex, which told me that the PC could read only the disks whose sectors are 512 bytes. But I am still hitched looking for a 5.25 "drive, and I ended up found. Tonight, I finally begin to create images of these disks. I'm happy and considers should thank you all. Even if the Developer(s) at the origin of "fdutils" is not (are not) listening to this list, the listeners whom I have read some answers, did realy help me. So here: thank you, thank you and thank you. Patrick

3 2

fdutils for OS/9 256 sector disks
by Martin Gregorie 07 Jun '13

07 Jun '13

Some time back my 68000-based OS/9 system died and I needed to get stuff off the 3.5" floppies I use to back it up. I'm a Linux user, so I used setfdprm to fiddle with the parameters in the 'floppy' driver and was able to image the disks successfully and then use the os9exec OS/9 emulator to access their contents. The reason I'm mentioning this is that I used a standard Linux driver, which normally uses 512b blocks and a standard 3.5" drive to read OS/9 floppies while the parameters needed to read the OS/9 floppies were: hd sect=34 ssize=256 head=2 cyl=80 tracksize=8704 dtr=0 zerobased I haven't yet tried it on any Flex-09 disks: mine all use single density for track zero and deduce the format of the other tracks from its contents. I wrote the drivers and may have diddled with the formatter when I replaced the original two disk FD card with a Windrush card that that handles 4 drives off a pair of FDC chips. I'm posting this to say thanks for writing such a good "get out of jail free" utility and as an indication to any other Linux users of just what setfdprm is capable of. Martin

3 3

Anomalies on fdutils 5.5
by Martin Gregorie 14 Oct '12

14 Oct '12

I have been using fdutils 5.5 and dd on a Linux system (Fedora 16, kernel 3.4) to read HD 3.5" floppy disks (2 sides, 80 tracks, 1.4MB) written by a MC68020 based system that runs OS-9/68000 version 2.4. The disks are backups containing LHZ archives. By using setfdprm and dd I was able to make images of the floppys which were successfully read by the os9exec emulator and the archives unpacked, so many thanks for helping me get out of a sticky situation. However, in the process I have uncovered some problems with the fdutils package which you'll probably want to fix. Problems with the zero based parameter ====================================== The name of this parameter is inconsistent: setfdprm calls it 'zerobased', which works as a command line argument, but it fails to read the COCO360 and COCO720 entries in the floppy disk parameter table. In fact, the parameter is referenced three times in the code base: mediaprm.c:83: { "zerobased", F_ZEROBASED, 1}, printfdprm.c:146: print("zerobased",0); superformat.c:672: { '\0', "zero-based", 0, EO_TYPE_SHORT, 1, 0, My solution was to change "zero-based" in superformat.c line 672 and mediaprm lines 787,789 and 792 to "zerobased", recompile and reinstall. More seriously, the only references to the zero based parameter in the manual are in the superformat context. There is no mention of it in the setfdprm instructions or in section 4 (Media Description). This is a big problem: initially dd would only read the first track on the first side of a disk, skipping the first sector and then failing to read past the end of the track. Inspecting a hex dump made it obvious that the first sector was being skipped and hence that the sector ID needed to be rebased. Much time was wasted scanning the manual for stuff about rebasing the sector ID with setfdprm until a search for info about OS-9 disks in mediaprm showed me that there *was* a zero-base parameter. Please add references to the 'zerobased' parameter into the setfdprm and 'Media Description' sections where they belong. Media Description anomalies =========================== There is no detectable consistency in this file's name in the manual and the source code: it is variously referred to as: /etc/fdprm - in mediaprm (!),convert.c,oldfdprm.c, and the manual /usr/local/etc/fddriveprm - in the manual /etc/fdmediaprm /usr/local/etc/fdmediaprm yet "make install" installs it as /usr/local/etc/mediaprm - about the only name that doesn't appear in the manual! Build and install problems ========================== fdmount no longer compiles because (in my distro, anyway it can't find linux/ext2_fs.h, which is in /usr/src/kernels/3.4.11-1.fc16.i686.PAE/include As I don't need the program, I commented it out of the build, but this does need to be fixed. Also, for some relatively non-obvious reason, mediaprm was not copied to /usr/local/etc - I manually copied it to save time. A contribution ============== You may like to add this disk definition to mediaprm: "OS9HD3.5": hd sect=34 ssize=256 head=2 cyl=80 tracksize=8704 dtr=0 zerobased This parameter set works from the command line, but for some reason the command "setfdprm /dev/fd0 OS9HD3.5" gets the error: "Syntax error in /usr/local/etc/mediaprm at line 789 col 40: zerobase unexpected" - this in the "COCO360" definition! Why? Best regards, Martin Gregorie

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Fdutils