Very Computer

Andreas
--
*  Andreas Helke,  Institut fuer molekulare Genetik, Universitaet Heidelberg
**                        Im Neuenheimer Feld 230, 69122 Heidelberg, Germany
***                                 WWW: http://orion.mgen.uni-heidelberg.de
**** ftp://orion.mgen.uni-heidelberg.de - filemanager and Unix tools for DOS

: >I just remade a DOS partition into a ext2 file sytem. Since I forgot to
: >update the rc scripts, this partition was mounted as an umsdos file system.
: >This actually worked despite of the lack of a DOS FAT file system. First
: >suspicions came when df and du gave different answers about the contents of
: >this partition. Then I noticed that directory size was 8 KB and that file
: >names were truncated to 8 characters. Then I umounted the file system and
: >checked it with e2fsck. This program could not handle what if found and gave
: >up with a memory allocation error.
: >I think either mount or the kernel should check wether a DOS FAT file system
: >is present when mounting a partition as umsdos. My kernel was 1.2.8.

: This has been discussed before...
: It is caused by the fact that "mke2fs" does not overwrite the first sector
: of the partition, which is where the DOS filesystem stores its parameters.
 No, it is caused by the fact that the msdos filesystem checks for its
magic numbers in the first sector *only*. It should also do some consistency
checks using the FAT sectors. Moreover, msdos filesystems made by very old
DOS versions don't have any meaningful information in their first sector.
(Only the bootprogram, which is too variable to be used as "magic number").
For these old systems, all geometry information is encoded in the media
descriptor byte (first byte of the FAT).

 All other Linux filesystem check for magic numbers in the *second* sector.
The first sector is reserved for a boot program, and should not be overwritten
nor used by mk*fs.

: Hence, when you change a partition from DOS to ext2fs type, the DOS filesystem
: code still recognizes it.

: This can be avoided by clearing the bootsector of the partition, e.g.:

: dd if=/dev/zero of=/dev/sda1 bs=512 count=1

: (don't mis-type that command, or you will cause even greater havoc...)
 A good workaround, until the dosfs code is fixed.

: I think there was also some consensus that mke2fs should (optionally?)
: erase the first sector of the partition, but I don't know if this was
: really implemented or in what release that was done.
 I hope it was not :-) First, it wouldn't fix the problem (which would still
exist for the zillions of other filesystem types that Linux supports), and
second, it might make some disks unbootable.

: Rob
: --
: +------------------------------------+--------------------------------------+


: +------------------------------------+--------------------------------------+

--
 Alain

: >: I think there was also some consensus that mke2fs should (optionally?)
: >: erase the first sector of the partition, but I don't know if this was
: >: really implemented or in what release that was done.
: > I hope it was not :-) First, it wouldn't fix the problem (which would still
: >exist for the zillions of other filesystem types that Linux supports), and
: >second, it might make some disks unbootable.

: I don't believe that.
: The bootcode in the partition bootsector (or first sector on a floppy) os
: too dependent on the structure of the filesystem to survive a change of
: filesystem type.  A disk that had a DOS filesystem with a valid bootsector
: will never boot after it has been changed to ext2fs, no matter if you
: preserve the bootsector.

 Not true. One example: On my floppy disks, I have a boot sector which
transfers the boot process to hard disk. This way, I don't need to
remove disks from my drive when rebooting (Yes, I know about viruses,
but these are Linux only disks, and thus the risk is quite
small). With your proposed change, this boot sector would go away
after e2fsck. (Yes, it is easy to replace, but why cause an
inconvenience just to work around a bug in the msdos fs code, which
could be easily fixed in the msdos fs code?)

: Rob
: --
: +------------------------------------+--------------------------------------+


: +------------------------------------+--------------------------------------+

--
 Alain

:   If I'm not mistaken, the signature 0xAA55 is the last word on the
: first sectory of _any_ MSDOS file system. All mke2fs should do is
 But unfortunately not _only_ of MSDOS file systems...

: make _SURE_ that those two bytes are zeroed.  Since this signature
: is required, all MSDOS boot sectors should have it, and all MS-DOS
: boot sector routines shouldn't ever use those last two bytes.
 No, 0xAA55 is the signature of any bootable sector. It has nothing to
do with msdos per se. We shouldn't make mke2fs inconvenient to use
just to work around a bug in msdosfs. Bugs in msdosfs should be fixed
in msdosfs itself.

: --
: Copyright 1995 Jason McMullan.  License for the Microsoft Network to distribute
: this text for $100,000 U.S. dollars per copy is hereby granted.  All other use
: of this text by the Microsoft Network, including storing, relaying, or reuse is
: expressly prohibited. Distribution by the Microsoft Network indicates full
: acceptance of the licensing terms.

--
 Alain

: :   If I'm not mistaken, the signature 0xAA55 is the last word on the
: : first sectory of _any_ MSDOS file system. All mke2fs should do is
:  But unfortunately not _only_ of MSDOS file systems...

: : make _SURE_ that those two bytes are zeroed.  Since this signature
: : is required, all MSDOS boot sectors should have it, and all MS-DOS
: : boot sector routines shouldn't ever use those last two bytes.
:  No, 0xAA55 is the signature of any bootable sector. It has nothing to
: do with msdos per se. We shouldn't make mke2fs inconvenient to use
: just to work around a bug in msdosfs. Bugs in msdosfs should be fixed
: in msdosfs itself.

I beg to differ: the BIOS looks for the byte 0xE9 as the first byte of a
drive to determine bootablity. Take a floppy and try zapping the "signature"
and it will _still_ boot, but take out that jump opcode (0xE9) and the bios
won't think it's bootable.

--
Copyright 1995 Jason McMullan.  License for the Microsoft Network to distribute
this text for $100,000 U.S. dollars per copy is hereby granted.  All other use
of this text by the Microsoft Network, including storing, relaying, or reuse is
expressly prohibited. Distribution by the Microsoft Network indicates full
acceptance of the licensing terms.

  If I'm not mistaken, the signature 0xAA55 is the last word on the
first sectory of _any_ MSDOS file system. All mke2fs should do is
make _SURE_ that those two bytes are zeroed.  Since this signature
is required, all MSDOS boot sectors should have it, and all MS-DOS
boot sector routines shouldn't ever use those last two bytes.

--
Copyright 1995 Jason McMullan.  License for the Microsoft Network to distribute
this text for $100,000 U.S. dollars per copy is hereby granted.  All other use
of this text by the Microsoft Network, including storing, relaying, or reuse is
expressly prohibited. Distribution by the Microsoft Network indicates full
acceptance of the licensing terms.

 Wrong on the first part. Just look at any non-lilo linux bootdisk, and
tell me which byte you find there :-)
 Maybe you're confusing with the method that Dos uses to differentiate
between Dos 1.x disks and later disks. If the jump opcode is present,
Dos assumes that it is a later disks, and looks for the geometry
information in the boot sector. If the jump opcode is not present, Dos
assumes that it is a Dos 1.x disk, and uses the media descriptor byte
(first byte of FAT) as an index into a table of predefined geometries.
Btw, it doesn't have to be 0xE9, 0xEB (short jump) is recognized too.

 You're right about the 0xAA55 signature: it is indeed ignored
by many BIOSes.

 Alain

--
Daniel Quinlan          Member of the League for Programming Freedom