[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 



Reply to: