Fdutils

fdutils@fdutils.linux.lu

80 discussions

format_n_write for faster disk-from-image creation?
by Charles R. Anderson 22 Jul '03

22 Jul '03

It seems possible to shorten the time to make e.g. Linux boot floppies by combining the formatting and dd'ing from a disk image file, using the 82078's Format with Write command. Has any thought been given to implementing this in superformat? I think it would be a neat addition, and would be willing to do this work if I got some pointers describing where this would need to hook into the code, feasibility, etc. Thanks in advance. _______________________________________________ fdutils mailing list fdutils(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

3 5

Appreciate your help
by William Blunn 02 Apr '03

02 Apr '03

Norman Ding <yuanshanding(a)hotmail.com> wrote: > I need to verify that the floppy that is mounted is the same one that > is actually in the drive prior to writing to it (otherwise it erases > the disk). Novice Linux users are accidentally erasing disks when > copying files from one floppy to another. The current plan is to > either verify the disk label/serial ID, or else unmount and re-mount > before each write. Any suggestions on what changes I will actually > need to make to implement this (ideas on better approaches are also > appreciated)? Have your users use mtools instead of mounting the floppy drive. http://mtools.linux.lu/ Presumably your /etc/fstab has '/floppy' with the option 'user'? If you take that off, then users can't mount the floppy drive. Presumably your users are in the group ('floppy' on my system) which is allowed write access to the floppy device ('/dev/fd0' on my system) ? Leave them on there, and then they can use mtools. Bill _______________________________________________ fdutils mailing list fdutils(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

1 0

Appreciate your help
by Norman Ding 30 Mar '03

30 Mar '03

Hello everybody, I need to verify that the floppy that is mounted is the same one that is actually in the drive prior to writing to it (otherwise it erases the disk). Novice Linux users are accidentally erasing disks when copying files from one floppy to another. The current plan is to either verify the disk label/serial ID, or else unmount and re-mount before each write. Any suggestions on what changes I will actually need to make to implement this (ideas on better approaches are also appreciated)? Thank you very much, Norman _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ fdutils mailing list fdutils(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

2 1

Re: Missing fdutils List.
by Ralph Corderoy 22 Nov '02

22 Nov '02

Hi, > That webpage needs to be updated; the fdutils(a)tux.org mailing list has > been migrated from Majordomo to Mailman. The webpage should now say > something like: > > There is an fdutils mailing list at fdutils(a)tux.org . Please > send all bug reports to this list. You may subscribe to the list > by sending a message with 'subscribe' in its body or subject to > fdutils-request(a)tux.org, or by visiting: > > http://www.tux.org/mailman/listinfo/fdutils Thanks for that. Alain, I guess the same goes for the Mtools web page and list. Cheers, Ralph.

1 0

Re: Missing fdutils List.
by mailman＠tux.org 22 Nov '02

22 Nov '02

On Thu, 21 Nov 2002, Ralph Corderoy wrote: > http://fdutils.linux.lu/ says > > "There is an fdutils mailing list at fdutils(a)tux.org . Please send > all bug reports to this list. You may subscribe to the list by > sending a message with 'subscribe fdutils(a)tux.org' in its body to > majordomo(a)tux.org." > Is this a problem with Majordomo(a)tux.org or the fdutils web page? That webpage needs to be updated; the fdutils(a)tux.org mailing list has been migrated from Majordomo to Mailman. The webpage should now say something like: There is an fdutils mailing list at fdutils(a)tux.org . Please send all bug reports to this list. You may subscribe to the list by sending a message with 'subscribe' in its body or subject to fdutils-request(a)tux.org, or by visiting: http://www.tux.org/mailman/listinfo/fdutils Regards, ---------------------------------------------------------------- Mailman Administrator - http://www.tux.org/mailman/listinfo/

1 0

creating high-capacity disks without --verify_later does not work
by Jochen Voss 02 Nov '02

02 Nov '02

Hello Alain, there seems to be a severe bug in fdutils-5.4-20020222. At least for me superformat is not able to format high capacitiy disks without the --verify_later option. The original bug report I received is at http://bugs.debian.org/148587 It seems, that the verify code uses the _old_ drive parameters (either whatever was autodetected for media that was in the drive before, set with setfdprm, or the default) to verify the tracks, which are formatted with the new parameters. You can reproduce this as follows: # insert a disk with the usual 1440/1440 format into the drive # and make sure that the floppy driver uses this format. voss@automatix [~] setfdprm /dev/fd0 1440/1440 voss@automatix [~] mdir Volume in drive A has no label Volume Serial Number is 682D-7F39 Directory for A:/ No files 1 457 664 bytes free voss@automatix [~] superformat /dev/fd0 ds hd sect=21 This command results in a lot of I/O errors and noises like the floppy drive is suffering. The first few error messages are Jun 30 14:31:39 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 60 Jun 30 14:31:40 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 62 Jun 30 14:31:43 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 81 Jun 30 14:31:44 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 82 Jun 30 14:31:46 automatix kernel: end_request: I/O error, dev 02:00 (floppy), sector 102 If I try the same with the "--verify_later" option, everything works fine: voss@automatix [~] superformat --verify_later /dev/fd0 ds hd sect=21 Formatting cylinder 79, head 1 mformat -s21 -t80 -h2 -S2 -M512 a: Verifying cylinder 79, head 1 I hope this helps, Jochen PS.: if you reply to this mail, please send (via Cc:) a copy to 148587-forwarded(a)bugs.debian.org -- http://www.mathematik.uni-kl.de/~wwwstoch/voss/

2 1

minor fix for the clean target of doc/Makefile
by Jochen Voss 02 Nov '02

02 Nov '02

Hello, the clean target of doc/Makefile from fdutils-5.4-20020222 fails to remove some files. It tries to remove files of the form "fdutils.*" where is generates files of the form "Fdutils.*". The script "cleanup" is also affected. This can be fixed with the following patch. == patch starts at following line ========================== --- fdutils-5.4-20020222.orig/doc/Makefile.in +++ fdutils-5.4-20020222/doc/Makefile.in @@ -61,10 +61,10 @@ $(TEXI2DVI) Fdutils.texi clean: - rm -f fdutils.aux fdutils.cp fdutils.cps fdutils.dvi fdutils.fn - rm -f fdutils.log fdutils.pg fdutils.ps fdutils.toc fdutils.tp - rm -f fdutils.ky fdutils.vr fdutils.info fdutils.pgs - rm -f fdutils.info-1 fdutils.info-2 fdutils.info-3 + rm -f Fdutils.aux Fdutils.cp Fdutils.cps Fdutils.dvi Fdutils.fn + rm -f Fdutils.log Fdutils.pg Fdutils.pgs Fdutils.toc Fdutils.tp + rm -f Fdutils.ky Fdutils.vr Fdutils.pgs + rm -f fdutils.info* --- fdutils-5.4-20020222.orig/doc/cleanup +++ fdutils-5.4-20020222/doc/cleanup @@ -1,5 +1,5 @@ #!/bin/sh -rm -f fdutils.aux fdutils.cp fdutils.cps fdutils.dvi fdutils.fn fdutils.ky -rm -f fdutils.log fdutils.pg fdutils.ps fdutils.toc fdutils.tp fdutils.vr -rm -f fdutils.info* +rm -f Fdutils.aux Fdutils.cp Fdutils.cps Fdutils.dvi Fdutils.fn Fdutils.ky +rm -f Fdutils.log Fdutils.pg Fdutils.pgs Fdutils.toc Fdutils.tp Fdutils.vr +rm -f fdutils.info* fdutils.ps == patch ends at previous line ============================= I hope this helps Jochen PS.: this is my last report for today :-( -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html

2 1

Re: superformat does not work on m68k machines (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from TrippleEggs.dorchain.net (TrippleEggs.dorchain.net [213.183.72.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA00846 for <fdutils(a)tux.org>; Mon, 8 Jul 2002 05:35:05 -0400 Received: (from joerg@localhost) by TrippleEggs.dorchain.net (8.12.2/8.12.2) id g689YSHe016278; Mon, 8 Jul 2002 11:34:28 +0200 Date: Mon, 8 Jul 2002 11:34:28 +0200 From: Joerg Dorchain <joerg(a)dorchain.net> To: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Michael Schmitz <schmitz(a)zirkon.biophys.uni-duesseldorf.de>, Jochen Voss <jvoss2(a)web.de>, fdutils list <fdutils(a)tux.org>, alain(a)linux.lu Subject: Re: superformat does not work on m68k machines (fwd) Message-ID: <20020708113428.C15757(a)TrippleEggs.dorchain.net> References: <Pine.GSO.4.21.0207081020520.3341-100000(a)vervain.sonytel.be> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <Pine.GSO.4.21.0207081020520.3341-100000(a)vervain.sonytel.be>; from geert(a)linux-m68k.org on Mon, Jul 08, 2002 at 10:22:24AM +0200 X-message-flag: Formating hard disk. please wait... 10%... 20%... --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, (disclaimer: If I left out interested parties in the Cc, please correct) On Mon, Jul 08, 2002 at 10:22:24AM +0200, Geert Uytterhoeven wrote: > Subject: Re: superformat does not work on m68k machines >=20 > > > AFAIK, this is an m68k linux kernel limitation. > > Yes, I know. But fdformat is said to work, > > so formatting floppies should not be completely > > impossible. > >=20 > > Do you know, is anybody working on the m68k kernel > > floppy driver? >=20 > Nope. It works, why should anybody tamper with it?=20 >=20 > Adding the missing ioctls to the Amiga floppy driver does not seem to make > sense (though it would be easy: just add a fourth drive type for user > defined parameters at the head of the drive type list, then set=20 > unit[drive].type to &drive_types[0] and modify those parameters if a > matching set isn't found). Well, once I thaught about autorecognition features for the driver. The theory was easy: After the whole track is read, enter a stae machine and read enough bytes till you can make a decision instead of assuming a specific format slected by the minors. I boggled implementing it as bitwise state machines are scary monsters to me (character based ones are bad enough ;-). For writing, due to the nature of the amiga hardware, it is easiest to deal with whole tracks and not with single sectors (or even smaller units). So for this, I once calculated the gap lengths (which at that time PC hardware needed ;) and hardcoded them in the code for the supported formats. To get the disired flexibility here, the calculation has to be done at runtime. At least the first implemation will be prone to errors. The trackwise operation has two effects:=20 - it will read and write (and, along with the process, de- and encode) a whole track if only a single bit in it is written. - Formatting is easy: Write a whole track without reading it first. I.e. a track is reformatted everytime something is written to it. (Sidenote, the amigaos trackdisk.device does the same, but I discovered only afterwards.) BTW, there wre tools like this for the amiga to get more out of floppies. IIRC they still exists on Aminet.=20 Additionally, these non standard formats are not wide spread. So I decided for myself to dig into the problem when I get my first strangly formatted floppy disk. In the past five years I encountered none. This shall not prevent anyone from implementing it. In contrast, I can offer some help with testing the stuff and answer questions about programming the floppy hardware and MFM-encoding. It is just that I do not have the time anymore to go deeper into this.` To start experimenting, there is a special ioctl that I used for debugging that returns the content of the raw track buffer as it is read by the hardware, so you can leave the driver alone and test in user space wether the detections works. (Erorrs in user space are core dumps, errors in kernel space are oopses, errors in interrupts just freeze - YMMV ;-) >=20 > Disclaimer: I don't even know if the floppy hardware can be programmed to > support arbitrary formats. Drive formats are selected by opening the > corresponding device on the Amiga. Amiga floppy hardware is very flexible. It can basically read everything (even 1541 GCR disks) and also write it. The hardware is cabable of doing DMS from/to memory (within limits), and can syncronize the sync hole. The downside of this is that all de- and encoding has to be done is software between the raw format on disk and what is presented to the upper layers. Bye, Joerg --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9KVyhjY4+4PdzvOARAtXLAKCInNQaP+L1rjjLox8BUiTR49bhHgCghgHx Jie86k3n2nivjwHZLQwFQP0= =+SFV -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq--

1 1

Re: superformat does not work on m68k machines (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from zirkon.biophys.uni-duesseldorf.de (zirkon.biophys.uni-duesseldorf.de [134.99.176.3]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA27202 for <fdutils(a)tux.org>; Mon, 8 Jul 2002 03:09:42 -0400 Received: from localhost (schmitz@localhost) by zirkon.biophys.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id JAA24395; Mon, 8 Jul 2002 09:09:37 +0200 Date: Mon, 8 Jul 2002 09:09:37 +0200 (CEST) From: Michael Schmitz <schmitz(a)zirkon.biophys.uni-duesseldorf.de> To: Jochen Voss <jvoss2(a)web.de> cc: Taral <taral(a)taral.net>, fdutils list <fdutils(a)tux.org>, Michael Schmitz <schmitz(a)opal.biophys.uni-duesseldorf.de>, 78915-forwarded(a)bugs.debian.org, alain(a)linux.lu, geert(a)linux-m68k.org Subject: Re: superformat does not work on m68k machines In-Reply-To: <20020707222911.GA9843(a)tatonka.pfalz.de> Message-ID: <Pine.LNX.4.10.10207080855260.24312-100000(a)zirkon.biophys.uni-duesseldorf.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > AFAIK, this is an m68k linux kernel limitation. > Yes, I know. But fdformat is said to work, > so formatting floppies should not be completely > impossible. > > Do you know, is anybody working on the m68k kernel > floppy driver? Nope. It works, why should anybody tamper with it? Adding the missing ioctls to the Amiga floppy driver does not seem to make sense (though it would be easy: just add a fourth drive type for user defined parameters at the head of the drive type list, then set unit[drive].type to &drive_types[0] and modify those parameters if a matching set isn't found). Disclaimer: I don't even know if the floppy hardware can be programmed to support arbitrary formats. Drive formats are selected by opening the corresponding device on the Amiga. CC: to Geert who might know more about Amiga floppy hardware. Michael

1 0

Re: superformat does not work on m68k machines (fwd)
by David C Niemi 08 Jul '02

08 Jul '02

Received: from zirkon.biophys.uni-duesseldorf.de (zirkon.biophys.uni-duesseldorf.de [134.99.176.3]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA26511 for <fdutils(a)tux.org>; Mon, 8 Jul 2002 02:53:52 -0400 Received: from localhost (schmitz@localhost) by zirkon.biophys.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id IAA24362; Mon, 8 Jul 2002 08:53:44 +0200 Date: Mon, 8 Jul 2002 08:53:44 +0200 (CEST) From: Michael Schmitz <schmitz(a)zirkon.biophys.uni-duesseldorf.de> To: Jochen Voss <jvoss(a)rhrk.uni-kl.de> cc: fdutils list <fdutils(a)tux.org>, Michael Schmitz <schmitz(a)opal.biophys.uni-duesseldorf.de>, 78915-forwarded(a)bugs.debian.org, alain(a)linux.lu Subject: Re: superformat does not work on m68k machines In-Reply-To: <20020707190052.GA10341(a)automatix.mathematik.uni-kl.de> Message-ID: <Pine.LNX.4.10.10207080840440.24312-100000(a)zirkon.biophys.uni-duesseldorf.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It is reported that on an Amiga2000 with a DD floppy drive, > fdutils 5.4-20020222 and kernel 2.2.20 the following error > occurs: > > root@aahz:~>superformat /dev/fd0 > get drive characteristics: Function not implemented > > It is rumored, that this is a general problem of the Linux > kernel for the m68k architecture. Is there any way to work > around this? Or is m68k unsupported? This rumor might be substantiated by a quick look at the Atari and Amiga floppy drivers. My prediction: the ioctl in question isn't implemented, or the ioctl data size mismatches. Both Amiga and Atari implement FDGETPRM. Atari also implements FDSETPRM and FDDEFPRM (and those used to work at the time they were written). Michael

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