This post has 3 aims:-
1. to acknowledge what a fine job P. Muller did with
promoting and managing the Native-Oberon project
from the 90s, when I was lucky enough to discover it.
I think he recently posted about <the file archives> ?
They must remain available.
For the last few years I use ETH Oberon 2.4.3 for Linux x86;
but I can also access my old N-O partitions via LNO, at the
same time as running LinuxETH.Oberon
2. the following [point 3] problem is an example of WHY
we need ETHO: for complex problems which need many
files simultaneously accessible; for complexly inter-related
concepts, which can be text-coloured to emphasise these
relationships.
3. the problem as described in
>Newsgroups: comp.os.linux.hardware
>Subject: Re: Fix partition 26 from its saved partition table?
>On Wed, 26 Oct 2005 03:52:55 -0500, news wrote:
has re-occurred.
Some *nix tools only accept a maximum of 16 partitions.
I tried to install Slakware13 to a high-number partition,
and [apparently the lilo script] broke the extended-partitions'
chain after partition 16.
Since the extended partitions are just linked together,
if you know the size of the next/missing partition, or can make
an iterated guess via a script loop, you can:
make a new/last partition,
check IF it's mountable.
If the size is restored to the pre-crash-size, all the files will
still be intact. NOW this recovered partition 17.
As I understand, this merely replaces the <tail/end pointer>
of partition16, with a pointer to the beginning of partition17
and writes the <tail/end pointer> on partition17's partition-table.
Understandably, I'm finding it difficult to relocate my notes from
2005; but IIRC, once I <fixed partition26> and all the rest were
immediately available! Apparently this would happen if you
restored/replaced the tail-marker of p26, with the correct
pointer to p27.
There's ample documentation on the MBR.
And ETHO's HexToDecimal/colourMarking helps with the
complexity of endian/bitshifting..etc.
And P. Muller's Partitions* is excellent and a great help.
IMO only one arg is needed: either the partition-size or
[containing the same info] the next-partitions start-adr.
But Microsoft has designed redundancy into their
system, so there's both, and possibly other traps which
make it difficult to fix.
Can someone advise me what bytes need to be edited to what?
Does the /dev/hdX17 partition table, which is visible via
<show-me blok: hdX16's start + length> have the same format
as the MBR's 4-partition entries?
How is the <end of chain of links> marked?
TIA
== Chris Glur.
