RPi image: Bad short file name

fsck on linux complains about some files on the FAT partition of the “RC15 SD card image” for Raspberry Pi. RISC OS boots fine on the RPi and I also can edit CONFIG.TXT on linux. Is this anything we have to worry about?

$ sudo fsck -n /dev/sde1
fsck from util-linux 2.30.1
fsck.fat 4.1 (2017-01-24)
/BOOTCODE.BIN
  Bad short file name (BOOTCODE.BIN).
  Auto-renaming it.
  Renamed to FSCK0000.000
/CONFIG.TXT
  Bad short file name (CONFIG.TXT).
  Auto-renaming it.
  Renamed to FSCK0000.001
/FIXUP.DAT
  Bad short file name (FIXUP.DAT).
  Auto-renaming it.
  Renamed to FSCK0000.002
/START.ELF
  Bad short file name (START.ELF).
  Auto-renaming it.
  Renamed to FSCK0000.003
/RISCOS.IMG
  Bad short file name (RISCOS.IMG).
  Auto-renaming it.
  Renamed to FSCK0000.004
Leaving filesystem unchanged.
/dev/sde1: 8 files, 3981/24519 clusters

fsck on linux complains about some files on the FAT partition of the “RC15 SD card image” for Raspberry Pi. RISC OS boots fine on the RPi and I also can edit CONFIG.TXT on linux. Is this anything we have to worry about?

The RPi RC15 SD card image is a slightly fiddled overlay of the FAT and the normal RO filesystem.

The worst thing you can do to it is to run fsck and allow it to “fix” anything. The moment you do you have a broken SD card install that you need to re-image with the card to get it working again.

You might see other people commenting on this but the big thing to remember is RISC OS is not Linux and it is not even vaguely similar to Linux. That includes the file system which currently has no understanding of partitions and thus when someone uses a partition/file system “fix” tool for some other file system it promptly breaks.

There is a bounty for file system wok that would incorporate partition handling so there may well come a time when such tools might be useful, meanwhile probably best regarded as the file system equivalent of a tactical nuke with a trigger sensitive enough to be activated by a butterfly sneeze.

I tried to blow it up, but it didn’t work:

I reformatted the FAT partition on the sd card, copied the files back to the empty partition and RISC OS still boots. Now fsck doesn’t complain any more.

Looks to me like a bug that is fixable.

And what does DiscKnight say about the RISC OS partition? It’s that also good?

I ask because “still boots” doesn’t imply there isn’t an impending catastrophe…

It doesn’t matter if I run DiscKnight on the sd card with the unmodified FAT partition or the reformatted FAT partition. It’s always the same output / error.

DiscKnight 1.53 (20-Aug-2017) [32bit] *CHECK ONLY*

Arguments: SDFS 0 

Boot Block - Defect List
  Boot Block CRC is OK

Map 1 - Checksums
  Zone Checks  OK
  Cross checks OK
Map 2 - Checksums
  Zone Checks  OK
  Cross checks OK
Map - Disc Record
  Map disc record matches boot record
* Zone 1889 disc end marker is incorrect (is &0 should be &1)

Checking directory structure
........................................................................

---------------------------------------------
    Disc is bad, 1 faults found
    Run a repair (-f and -u flags) to fix
---------------------------------------------

All Oliver did only concerned the FAT partition. I am not sure why anyone thinks that this would be a problem on the RISC OS side, as long as the partition is the same size as before (and maybe, for CMOS functionality, DOSFS can still read it OK). Filecore does not care about that FAT partition, the only “link” is that the “Loader” file is mapped to the FAT partition to keep Filecore from using that discspace for other files (which would ruin things of course).

Filecore does not care about that FAT partition, . . .

Back to the original problem :). I’m no FAT expert and I don’t know if the “PiBoot” FAT partition has real errors or if the linux fsck.fat tool has a bug / is picky. I assume that linux fsck.fat is extensively tested and should be quite stable and standard-conform.

Anyway, if someone runs linux’ fsck on the FAT partition, the sd card could easily rendered unbootable.

I’m just reporting the problems or potential bugs I’m discovering as a user. That’s all.

Zone 1889 disc end marker is incorrect (is &0 should be &1)

Any idea what it means? The image is written to a 4GB card. Everything above 2GB is some data from a previous linux image.

Zone 1889 disc end marker is incorrect (is &0 should be &1)

Any idea what it means?

This came up, somewhere, a long time ago. As I recall it is to do with the formatter used and is not of any real significance.

Some light reading

I have been ignoring this non-issue for years.

HTH