Re: PWS 433au (Miata) recovery update
On Wed, 16 Jan 2019, Bob Tracy wrote:
> Odd thing about the disk partitioning scheme. The disk label definitely
> has to be "bsd" for SRM to be happy, but if Linux is the only OS on the
> disk, all the rest of the BSD partitioning conventions don't have to be
> observed as far as slice "c" spanning the entire disk, slice "a" being
> the "boot" slice, slice "b" being "swap", and so forth. I doubt dual-
> booting with Digital UNIX or one of the *BSD variants is a practical
> possibility for most people, particularly those with PWS systems having
> limited disk space.
SRM doesn't actually care about or know the disk partitioning scheme,
however it does require a signature and a pointer to the location of the
boot loader (with `aboot' being the usual choice for Linux) in the first
physical sector, and these structures happen to clash with the location of
the IBM PC's DOS-style partition table.
As you observe the partitions for Linux use can be arbitrary. I used to
install `aboot' outside any partition by just leaving a number of sectors
at the beginning of the disk unassigned; `aboot' takes some 80KiB only.
This is analogous to disks using a DOS-style partition table where you'd
often leave the whole (simulated) first track of first cylinder unassigned
for boot loader use. This saves a partition table entry for a data area
that can hardly be used through the corresponding block device anyway.
NB be aware if you ever boot Windows NT on an Alpha machine that has an
SRM signature on some disks, then the first sector of these disks will get
corrupted under NT's assumption that these disks have no data and need to
have a DOS-style partition table installed in the first sector. Any OSF/1
disk label will be retained, however the SRM signature will be lost making
such disks unbootable and will have to be restored to make them bootable
again. Also the presence of the DOS-style partition table marker may
confuse the Linux kernel if support for such partition tables has been
compiled in in the addition to support for OSF/1 disk labels.
> A brief note about partitioning programs: "fdisk" is NOT your friend
> on the Alpha, especially in "modern" times. Use "parted" and save
> yourself much frustration.
I had a look at the GIT history of `util-linux' and it looks like in the
conversion of the tool to use `libfdisk', also included with `util-linux',
support has been lost, which I find rather unfortunate.
It should be pretty straightforward to resurrect with the aid of old
code, however it was never particularly clean (as has not been what still
remains in `fdisk') due to the use of `#ifdef __alpha__' to select the
label type, meaning you could not work with a disk intended for an Alpha
system using fdisk compiled for a different host architecture. It looks
to me like the current framework would make it easier to avoid this #ifdef
hack, but obviously any remains would have to be cleaned up.
There used to be a tool called `minlabel' too that you could use to
partition your Alpha disk, but it was rather crude.
> (1) "systemd" (and "udevd" by extension) don't play well with "/usr"
> being on a separate partition from "/". If I have *any* advice to offer
> both the battle-scarred veteran and the newbie, it would be to consider
> consolidating those two partitions into a single partition. Me? I'd
> prefer the younger generation of system programmers consider the
> perfectly valid reasons why those filesystems might have been separate
> to begin with, and respect those reasons. (Hint: much smaller disks.)
In the old days it used to be a common practice to have /usr NFS-mounted
in some installations, often where NIS was also used; perhaps it is not
anymore.
FWIW,
Maciej
Reply to: