Subject: ARMLinux installation problems

From: ARM Linux mailing list <[email-masked]>
Date: Tue, 7 Jul 1998 18:38:31 +0000 (GMT)

I decided today that I would install ARMLinux which came on the Clan CD. I'm
using the installation guide in the Clan newsletter and the one provided by
Phil Norman.

The files were obtained from the following sources:

ARM Linux website: RPC kernel, bootloader, config, partman, writedisc,
                   root-rpc, supplemental
Phil's website:    base, instimage

My system is a:

RPC (Mark II motherboard) SA110, 32+8+1 Meg, 4 Gig IDE HD (Partioned 2.5 Gb
ADFS, 1.5 Gb Linux, 20 Mb Swap), IDE CD-ROM

Things went fine until I came to copy the RPMS zip file from my ADFS partition
to the linux partition.  It complained that it couldn't find the file, which is
probably because the directory the drive was mounted into was empty.  On
start-up the console displays the following on the partitions:

hda: [ADFS] hda1 [Linux] hda2 < hda3 hda4 >

Typing 'mount -t adfs /dev/hda1 adfs' gives a mount list of (amongst over
entries):

/tmp/hda1 adfs adfs rw 0 0

so it appears to have mounted the drive succesfully, so why is the directory
empty?

Any help appreciated

Andrew
-- 
Andrew Miles

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Phil Norman <[email-masked]>
Date: Wed, 8 Jul 1998 10:28:07 +0100 (BST)

> start-up the console displays the following on the partitions:

If the directory it was mounted into was empty, that means it didn't get
mounted.

> /tmp/hda1 adfs adfs rw 0 0

Erm.... *boggle*.  'mount' on its own should give you a list of entries,
but 'mount -t adfs /dev/hda1 adfs' should mount the thing and give no
output.

In fact, this kind of output is completely wrong for the output of
'mount'.  It looks more like the contents of /etc/fstab (the filesystem
table).  Are you >SURE< you're typing in the right thing?

-- 
Rule of programming #2: Everything that can go wrong will go wrong,
        but only on other people's configurations.

Phil Norman, mailing from Oregan Networks.
email:	[email-masked]
URL:	http://newton.ex.ac.uk/general/ug/norman

---

From: ARM Linux mailing list <[email-masked]>
Date: Wed, 8 Jul 1998 10:12:48 +0000 (GMT)

> table).  Are you >SURE< you're typing in the right thing?

Sorry, wasn't very clear an example session would be:

# mount -t adfs /dev/hda1 adfs
# mount
< Other entries>
/tmp/hda1 adfs adfs rw 0 0
# ls -al adfs
Total 0
# 

Andrew
-- 
Andrew Miles

---

From: Andrew Miles <[email-masked]>
Date: Wed, 8 Jul 1998 13:44:04 +0000 (GMT)

> to the linux partition.  It complained that it couldn't find the file, which 
> is probably because the directory the drive was mounted into was empty.  On

I've just noticed something, when I mount the directory I get the following
on tty4:

(7)ADFS: zone size 4030, IDs per zone 251, map address 2838E0 size 82 sectors
(7)ADFS: sector size 512, map bit size 8192

and when I 'ls' the directory I get (again on tty4):

(2)ADFS-fs error (devive 03:01): adfs_check_dir: corrupted directory inode
25300,253

Has mount been tested on high capacity filecore drives i.e. drives with a large
file allocation unit greater than 512 bytes?  I noticed somebody with a 4 Gb
drive was having similar problems as me, only he had managed to install Linux
before he encountered the problem.

Andrew
--
Andrew Miles

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 11 Jul 1998 12:26:05 +0100 (BST)

> (7)ADFS: sector size 512, map bit size 8192

That looks a bit strange.  The sector size is 512 bytes.  There are normally 2
maps on an ADFS disk (take map address * sector size) - yours should be at
the following disk addresses:
	0x2838e0 * 512		= 0x5071c000
	(0x2838e0 + 82) * 512	= 0x50726400

> (2)ADFS-fs error (devive 03:01): adfs_check_dir: corrupted directory inode

Ok, so this is telling me that the fragment is 2, and the sector offset is
0x53 - 1 = 0x52.  0x52 is 82.

Therefore, the second copy of the map is the root directory.  This is where
it's falling down.  I can't see anything in PRM#2 that defines a change in
the internal disc addresses.  Can you check PRM#5/5a please, especially for
anything which indicates that the structure of the internal disk address
has changed.

I did have a look in a PRM#5/5a, and I thought I had covered it all.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Andrew Miles <[email-masked]>
Date: Sat, 11 Jul 1998 17:08:27 +0000 (GMT)

> anything which indicates that the structure of the internal disk address

The PRM Volume 5a has the following to say:

Disc record

The disc record (page 2-202) has been extended to support large discs. This
uses some of the reserved bytes at the end of the record, the tail end of
which now is as follows:

Offset	Name		Meaning
36	disc_size_2	Most significant word of disc size, in bytes
40	share_size	bits 0-3: log2 (sharing granularity in sectors)
			bits 4-7: reserved - must be zero
41	big_flag	bit 0:    set -> RISC OS partition is > 512 MB
			bits 1-7: reserved - Must be zero
42-59			Reserved - must be zero

The disc_size_2 field gives the most significant word of the disc size, and so
is used for discs of over 4 GB.  (The least significant word is held in the
disc_size field.)

The big_flag bit is so FileCore can tell at mount time whether or not the
RISC OS filing system on the disc is big (ie > 512 MB in size), and hence
whether or not it uses the new logical format.  It cannot use the disc_size
fields for this, since a disc of over 512 MB may only have a small RISC OS
partition, and use the rest of the disc for RISC iX^H^H^H^H^H^H^HARMLinux.

The share_size field controls the granularity of sharing.

<Skip a bit>

Internal disc addresses

FileCore can share the use of a disc object on a new map disc (ie a logical
group of fragments) between many objects (ie files or directories).  The
objects must either be a directory and files within that directory, or files
that have the same parent directory.  There may not be more than one directory
in any disc object, since the directory must always be at the start of the
disc record.

New map discs use an internal disc address (see page 2-209) to refer to shared
objects, specifying them in terms of their fragment id (0-&7FFF), and their
offset within the disc object (0-254, stored as 1-255).  Under RISC OS 3.5
and earlier, the offset is in units of sectors, which with a 512 byte sector
size corresponds to 0-127 KB.  Thus FileCore can only share the first 254
sectors (127 KB for our example) of a shared disc object, and if the smallest
fragment size is larger than this FieCore cannot share all the space in
shared disc objects.

>From RISC OS 3.6 onwards, you can increase the granuality of the offset within
the disc object.  <Very important sentance>It now gives the offset in units
of 2^share_size sectors, where share_size comes from the disc record.  You
should ensure that if you format a disc, share_size is sufficiently large
for the following to be true:

	smallest fragment size <= (254 * s^log2secsize * 2^share_size)
	
FileCore can then share all the space within a shared disc object.

<End PRM>

The value of my share_size is 1, thus the address of my disc map is actually
calculated as follows:

(0x2838e0 + (82 * 2^1)) * 512	= 0x50730800

A look with a disc editor reveals this to be the correct address.

Andrew
-- 
Andrew Miles