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
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
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.
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
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
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
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
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
