RPi3B, /Boot resize, UBmate 14.04.2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Now that UbuntuMate resizes the Root partition on installing, I cannot  
see how to resize /Boot after a fresh install; but with a fresh  
install any attempt at updating results in being told that there is  
insufficient room on /Boot. I have resized /Boot, but that involved  
deleting /Root, and resizing /Boot removes its contents, so back to  
square one...

I obviously must be missing something as to why an install is expected  
to do what it does, but with me it repeatedly does it, on several 32GB  
sdcards

Any solution, anyone?

--  
Mark J
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Wed, 06 Dec 2017 16:48:22 +0000, Mark J wrote:

Quoted text here. Click to load it



gparted with card in another computer.

Re: RPi3B, /Boot resize, UBmate 14.04.2

Quoted text here. Click to load it





Done that repeatedly, on my Pandaboard workhorse...

--  
Mark J
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Wed, 06 Dec 2017 16:48:22 +0000, Mark J wrote:

Quoted text here. Click to load it
The last time I needed to resize the main Raspbian partition, I used  
cfdisk to set up the partitions I wanted on a new SD card and dd to copy  
partition contents from the old to the new SD card. IIRC this pretty much  
just booted off the new card, but it was a fair time back, when wheezy  
was the default Raspbian version.

gparted can resize partitions pretty much painlessly.

I've used CloneZilla (a bootable Linux DVD image with installed
partition manipulation tools) in the past to do this, though that was  
Fedora on an Intel Core Duo chip. I don't think there is an ARM version.  
  
You  may also get some ideas from this:

http://www.libelle-systems.c3487738.myzen.co.uk/free/linux/
easier_upgrades.html

I wrote it to describe how I used to do clean installs of Fedora  
upgrades. That was back when Fedora used the yum package manager and had  
no ability to upgrade from one version to the next. Since then Fedora  
replaced yum with dnf and now can do in-situ version upgrades, but I've  
retained the filesystem tweaks because it makes backups a bit easier to  
do.


--  
Martin    | martin at
Gregorie  | gregorie
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2

Quoted text here. Click to load it







:-) My area of expertise is far removed from the minutia of modern  
computing, and I am a bear of but little brain; but the Raspberry  
series was supposed to be for youngsters to learn programming - so I  
am surprised that any Distro should be handed out that needed  
undocumented partition editing. Hence my assumption that I am doing  
something foolish. A rehash is called-for. I have settled upon  
UbuntuMate because it is the nearest thing to a straightforward OS  
that I have found that is still being updated. For years RISCOS and  
Ubuntu have done all that I need, but times move on.

I have downloaded UBmate 16.04.2 and do a sha256sum which it passes. I  
had previously decompressed using xz, and dd or ddrescue to write to a  
64GB sdcard, but that was prone to errors, so I have recently used xz  
to decompress, passing the data over to dd via pipe. Installation  
progresses without problems, but updates cannot be done because /Boot  
has insufficient space. Autoclean and Autoremove make no difference.  
But why? I surely cannot be the only one to stumble at this point. Why  
updates, when they cannot be done?

To progress: I am a user, not a programmer, and have had no need to  
meddle with partitions; but I have tried to get to grips with gparted,  
and have not found it a "painless" as you do. I have been able to  
delete the Root partition, and increase the size of /Boot, but must  
presume that I have changed the start sector, because its contents  
have vanished.

All this should not be necessary...

--  
Mark J
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Thu, 07 Dec 2017 13:46:48 +0000, Mark J wrote:

Quoted text here. Click to load it
In that case didn't you choose to use UbuntuMate, rather than Raspbian,  
the default OS? This is just a question because I'm curious, not  
criticism!

Quoted text here. Click to load it
You do now though, because UbuntuMate says that one of your partitionins  
is too small.

Quoted text here. Click to load it
Fair point. I've done my own sysadmin for years (and some professional  
sysadmin on a variety of hardware and OS flavours and tens to assume that  
anybody who has successfully installed a modern OS knows more or less  
what a partition is (a part of the storage medium that contains files and  
directories) and a little bit about cresting and deleting them.

I suggested gparted because, if its installed, it comes up showing all  
the partitions without needing any inputs from you. Its on my usual  
systems but is not included with Raspbian, though 'parted' is, and  
outputs copyable text, which is why I'm suggesting it now.
  
Quoted text here. Click to load it
Have you got backups?  

Deleting the boot partition means that the RPi is probably no longer  
bootable.

If the UbuntuMate installer lets you do a custom install it may be able  
to recreate the boot partition while leaving not harming your stuff  
(which will be in /home). Otherwise it will just to a mongo install by  
recreating and reformatting all partitions and then filling them with the  
system as it was when the installer was built.
  
Quoted text here. Click to load it
As I said above, if you run out of space that means you've filled a  
partition, so you'll have to do some messing about with partitions to  
increase the size of the one that's too small.  

The painless way to do this is to set up a new set of partition(s) on a  
bigger SD card with the full partition increased in size. The new card is  
in a USB cardreader plugged into the RPi. Use a partition manager  
(parted, gparted, cfdisk, ... your choice) for this. Then use dd to copy  
the partition contents across. You have to be careful to keep the  
partition types and order the same on the new card and the copy each  
partition on the old card to the correct partition on the new one. Then  
put the new card into the built-in mount on the RPi and it should boot.

====================

Raspbian Installation via the Noobs download is simple and leaves you  
with two partitions (numbers below are from my Raspbian system):
- a small FAT16 (DOS type) 56 MB partition  
  containing the bootstrap code.  
  It is 39% full on my system

- a large EXT4 (Linuc partition containing everything else
  It occupies 7.2GB of and 8GB SD card and is 45% full

I've never run UbuntuMate, so don't understand how it partitions the SD  
card.  

Quoted text here. Click to load it
To get some idea of what's going on, it would be helpful to see how  
UbuntuMate partitions the card and how this directories are mapped onto  
it. Run the following commands in a console window and paste the results  
into your reply:

$ sudo parted
GNU Parted 3.2
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: SD 00000 (sd/mmc)
Disk /dev/mmcblk0: 7888MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:  

Number  Start   End     Size    Type     File system  Flags
 1      6656B   59.0MB  59.0MB  primary  fat16        boot, lba
 2      59.0MB  7888MB  7829MB  primary  ext4

(parted) quit                                                              
$  

In the above the commands was "sudo parted". This prompted for my login  
password (not shown) and then prompted for a command with "(parted) ".
I entered "print" and "quit" and the next prompt to exit from parted

As you can see, I have two partitions on 59MB and 7829MB.

Now run "df -h". I got this output:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  3.1G  3.8G  45% /
devtmpfs        213M     0  213M   0% /dev
tmpfs           218M     0  218M   0% /dev/shm
tmpfs           218M  6.1M  211M   3% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           218M     0  218M   0% /sys/fs/cgroup
/dev/mmcblk0p1   56M   22M   35M  39% /boot
tmpfs            44M  4.0K   44M   1% /run/user/106
tmpfs            44M     0   44M   0% /run/user/1001
$  

Which shows that /boot points the the first partition, '/' points to the  
second (big) partition and that both are only 40-465% full.


--  
Martin    | martin at
Gregorie  | gregorie
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2

Quoted text here. Click to load it


I can't really answer your question. It's historic. Modern OSs are  
"upgraded|", as in "can do, must do" rather than "can do, but why  
do?".  Bells and whistles for no purpose... I did try Raspbian, but  
was affronted by what I perceived as being irrelevant changes for the  
sake of changes. I started computing (literally : to compute) in about  
1980, which says it all...

Quoted text here. Click to load it




Nothing to backup yet, so no, and nothing put at risk.

Quoted text here. Click to load it

Did I write that? Must have, but I didn't mean to. My understanding is  
that if you change the start sector then the directory contents are  
effectively deleted. This is where I perceive gparted is not so  
transparent, and why I've left partitions well alone...

Quoted text here. Click to load it

I have, yet again, gone back to basics. The RaspberryPi.org website  
makes mention of zip and xz, and dd and ddescue, and writing to an  
sdcard,but no mention of any custom install or resizing /Boot. The  
.img.xz has already been sha256sum'ed, and has passed. On my Panda  
running Disc Utility the sdcard shows PI_BOOT 66MB FAT, PI_ROOT 4.9GB  
Ext4, Free 26GB.

Running xz and dd as Root:

# xz -cd ubuntu-mate-16.04.2-desktop-armhf-raspberry-pi.img.xz | dd  
bs=4M of=/dev/sdb
0+491596 records in
0+491596 records out
5000000000 bytes (5.0 GB) copied, 938.209 s, 5.3 MB/s
# sync

This is where I read somewhere that DOS has a problem with writing  
files greater than 4GB, which is why I migrated to xz to dd via pipe,  
but I'm not using Windows, so can't see this is part of the problem,  
but piping avoids an intermediate step.

Quoted text here. Click to load it

But this card is not yet being used, so any fill-up was not down to  
me; and again, why have a distro that requires a raw beginner to  
resize partitions?

Back to this new installation: Running it in the RPi3B gives a window  
saying that Root is being resized, and a reboot will happen in 5  
seconds. Then:

 - the usual four raspberries, and text with "OK"s, save for the first  
line warning that a load module has not been loaded, or words to that  
effect, but this has always happened to no deleterious effect on  
different installations, and the installation progresses as usual.

Disc Utility now shows /Boot as before, at 66MB FAT and the Root  
partition as 31GB ext4.

/Boot now has 21.8MB used, 44.2MB free, and is Bootable

Quoted text here. Click to load it

Hmmm... murky ground.

Quoted text here. Click to load it



The card is 31GB, and is freshly formatted

Disc Utility now shows /Boot as before, at 66MB FAT and the Root  
partition as 31GB ext4.

/Boot has now 21.8MB used, 44.2MB free, and is Bootable

Quoted text here. Click to load it










mark@RPi3B:~$ sudo parted
[sudo] password for mark:
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) quit                                                            

mark@RPi3B:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  3.6G   25G  13% /
devtmpfs        459M     0  459M   0% /dev
tmpfs           463M  272K  463M   1% /dev/shm
tmpfs           463M  6.8M  457M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           463M     0  463M   0% /sys/fs/cgroup
/dev/mmcblk0p1   63M   21M   43M  34% /boot
tmpfs            93M   24K   93M   1% /run/user/1000

mark@RPi3B:~$

Attempting to update fails because there are 512MB to be downloaded,  
which "needs 48.2MB on /Boot" so "please free at least 4063KB on  
/Boot"

Case rests: why should a Distro fail to update a new install because  
it makes /Boot too small?

--  
Mark J
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Fri, 08 Dec 2017 16:18:02 +0000, Mark J wrote:

Quoted text here. Click to load it
Noted. I started with mainframes in 1968, when what we now call a  
'partition' was known as a 'diskfile' and allocated and initialised with  
programs that were equivalent to a partition editor, e.g. parted, and a  
formatter, e.g. mke2fs. As a concession to programmers, you could store  
program source in 'subfiles' withing a 'diskfile'  
  
Quoted text here. Click to load it
Good news.
  
Quoted text here. Click to load it
Yes. If you delete a partition and then create a new partition starting  
at the same sector and with exactly the same size you may be able to  
access the data therein because IIRC within a partition sectors tend to  
be numbered from the partition start.
  
Quoted text here. Click to load it
Again, no comment as I've not tried to run anything but Raspbian on my  
RPi, an early 522MB PI model B.

Quoted text here. Click to load it
Yes, that's a limitation of the FAT filesystem. FAT16 partitions are  
limited to 2 GB with FAT32 increasing that the 4GB and allowing filenames  
longer than the original DOS 8.3 filename.
  
Quoted text here. Click to load it
I can't help further with this: never used an RPi 3 or any flavour of  
Ubuntu apart from once installing Mint on my sister's laptop. Apart from  
my RPi model B all my computers are running RedHat Fedora.
  
One or two generic tips that may help:

- the 'man' command shows usually extensive help for using a program or
  library function, e.g. "man parted"

- the 'apropos' command lists programs whose manpage has the search  
  term in its one-line summary description, e.g. "apropos ext4" lists
  tools for formatting and maintaining Linux EXT4 partitions. EXT4 is
  a journalling filing system, so is fairly resilient when dealing with
  power failures and system crashes.

- bookmark http://www.debian.org/doc/manuals/debian-reference/
  This is an main Debian reference manual, so is relevant to both
  Raspbian and Ubuntu. It can be quite technical, but there's very little
  that you might want to know that isn't covered.

- Since you other OSen, you may find a copy of "Linux in a Nutshell"
  would be a useful book to buy.

- you may also find "The RaspberryPi User Guide" worth a glance, though  
  its may be more noobish than you want.  

Quoted text here. Click to load it
Should have typed 'print' to see the list of partitions before typing  
'quit'.
  
Quoted text here. Click to load it
That looks pretty similar to what I see from Raspbian except that my  
/dev/root is 7.2 GB with 3.1 GB used.

Quoted text here. Click to load it
Pass. If nobody on here chips in, try asking on one of the forums at  
www.raspberrypi.org or on a forum dedicated to Ubuntu on ARM chips if  
there is one.

Sorry that I can't say any more, but it would be speculation if I did.


--  
Martin    | martin at
Gregorie  | gregorie
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Fri, 8 Dec 2017 18:07:41 +0000 (UTC), Kiwi User

Quoted text here. Click to load it
    Sounds suspiciously like what I know as "partitioned data set" -- of
which my only exposure was a utility for LS-DOS/TRS-DOS which created a
file on the disk, said file itself then having an internal directory
structure containing sub-files (take into account that subdirectories were
not an OS feature; each disk directory had a limit to the number of files
it could reference -- a PDS allowed storing lots of small application files
without using a lot of limited OS directory entries, and without lots of
wasted partially filled last sectors on the files).

    Granted, that form of PDS was likely inspired by the IBM mainframe
version. The LS-DOS/TRS-DOS version was a third-party package to
create/modify them (though much of the OS command set was stored in a
similar PDS format, just no tools provided to extract/build such files)
--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: RPi3B, /Boot resize, UBmate 14.04.2
On Fri, 08 Dec 2017 14:36:44 -0500, Dennis Lee Bieber wrote:

Quoted text here. Click to load it
of
I was an ICL guy back then, but talking to other 'foreign' mainframers  
made me think that almost all mainframes handled their disks this way.
There were weren't many things you could do with a disk allocation once  
you'd claimed and named it:

- you could read and write it sequentially pretty much as though it was
  magnetic tape

- you could format it as a random file and treat it as a set of  
  fixed-length, self-indexed records, i.e. the record number was the
  index. I don't recall whether the record size had to be a submultiple
  of the block size because I don't ever remember using a random file.

- you could format it as an indexed file. Records were fixed length
  submultiples of the block size. The file could extend over more than
  one disk and had three index levels arranged as a tree structure:  
    file level (indexing partitions)
    partition level (indexing tracks in the partition)
    track-level (indexing records in that track)

- you could set up a subfile structure to hold source code (usually
  stored as card images), which had a subfile index and put no
  restrictions on the subfile size or content except that they all had
  to fit in the fixed size 'file'

- there were also proprietary databases (structure depending on whether
  the DB was hierarchic (IBM's IMS was typical) or, a bit later, pointer
  linked systems: Goodyear's IDMS was the archetype, of which ICL's IDMSX
  was a superclass. IDMS was the basis of Codasyl-compliant databases.

This way of handling disk is surprisingly long-lived, certainly  
persisting through IB< S/360, 370 and (I think) into System Z.  

System/38, which was IBM's Future Series that was killed off in 1971 and  
then resurrected as S/38 before becomming the AS/400 series and then the  
I-series also used this type of disk management: it basically supported  
two disk filing systems:  
 - subfiles with a common record length and index structure for all the
   subfiles in a file. Used to store card-image type text files, compiled
   binaries and sets of fixed length indexed records

 - relational databases

The first hierarchical filing system I used was provided by ICL's George  
3 mainframe OS. I met that in late 1969 or early 1970 and, give or take a  
few strangenesses like automatic incremental backups and the tendency of  
unused backed up files to disappear from disk (they automatically  
reappeared if you needed them), the G3 filing system was fairly similar  
to UNIX filing systems. Unsurprising, since I have a feeling that MULTICS  
was a common ancestor.


--  
Martin    | martin at
Gregorie  | gregorie
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Fri, 8 Dec 2017 23:48:19 +0000 (UTC), Kiwi User

Quoted text here. Click to load it

    I'd have to dig up my manuals (in a storage locker) for Xerox
Sigma/CP-V... From my college days I don't recall ever having to consider
disk /drives/. An account just had some directory on the disk, and one
could access files of another account by providing that account as a part
of the file name ( filename<.password><.account> -- no extensions in use;
college practice was to prefix filenames with S:, R:, and L: for Source,
Relocatable object module [ROM], and Load Module [for some reason LMN]).

    
Quoted text here. Click to load it

    CP-V supported three file organizations: consecutive (and possibly
contiguous) -- your common UNIX stream file; indexed (aka: keyed --
multilevel alphanumeric key, in a way the most common file format as the
text editor used the key for line number [one normally set the editor to
increment by 10, with periodic renumbering] and the FORTRAN-IV run-time
used it for direct access -- index=> record number); and last, random,
which was just that -- one specified the size of the file on creation and
was given that much contiguous disk space, one had total control over the
content, the OS did nothing but treat the file as a unit.

    CP-V also had four I/O modes: read, write, update, scratch. The first
two are as expected, the last two relied up having two current I/O
pointers: read position and write position; update required reading one or
more records before (over)writing, scratch required writing one or more
records before reading back. No equivalent of C's seek(). (Random
organization probably supported seek, but not the OS managed files)

--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: RPi3B, /Boot resize, UBmate 14.04.2
On Fri, 08 Dec 2017 21:45:34 -0500, Dennis Lee Bieber wrote:

Quoted text here. Click to load it
first

I'd believe that minis were somewhat different from mainframes. After all  
they were a generation later. I did some preliminary design and coding  
for a PDP8 job before being yanked off it and sent to NYC in a project  
involving an ICL 2903 [1]. But, IIRC the PDP-8 used 8.3 format filenames  
in a single directory per disk and had no concept of file ownership - IOW  
CM/M, DRDOS, FLEX and MSDOS (before it got directories) filing systems  
were virtually direct copies of the venerable PDP-8 filing system.

[1] ICL 2903 was a real wolf in sheep's clothing, being effectively a  
small mainframe disguised as a desk-sized office environment computer. It  
was actually a 2900 disc file controller running microcode that emulated  
a 1900 mainframe, so it ran unmodified 1900 software under a tweaked  
version of George 1 OS and supported a variety of greenscreen terminals.  
It was programmed in COBOL and RPG, but would run any of the other  
compilers - I wrote a single threaded timesharing TP monitor in PLAN 3  
assembler for it because 1900 COBOL required subroutine names to be  
literal constants.  

5-6 years later I did something very similar on a 2900 mainframe, but  
this time it was entirely in COBOL because this version supported  
variable subroutine names, which meant you could do something like:

  01 module-name    pic x(20).
  ...

  move "DISP-COMPOSER-DETS to module-name.
  call module-name using param-1 param-2 .....

as the procedure dispatcher that lies at the heard of any TP monitor.


--  
Martin    | martin at
Gregorie  | gregorie
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On Sat, 9 Dec 2017 15:55:40 +0000 (UTC), Kiwi User

Quoted text here. Click to load it

    Just an FYI: The Sigma was a mainframe -- using four refrigerator sized
boxes for the 4-port/4-bank, interleaved, core, one such box for CPU, and a
few others for the various I/O Processors (serial/sequential IOP for tape
drives I think, and Multiplexed IOP for terminal server, disk drives,
printers/card readers) -- meant to compete with the IBM 360. I don't recall
the actual sizes of the drives used by the college (mere students don't
need to know such) but as I recall, a high point came when they obtained
two new drives dedicated to swap space (considering we supported some 50+
terminals/users in a machine with around 512kB of core) -- swap drives were
whopping 300MB as I recall.

Quoted text here. Click to load it

    Sigma filenames were, as I recall, 32-characters (not counting
file-password/owner-account -- which is a misnomer as logging in required
user-ID, billing account, and password); filename could include some
punctuation (including <BEL>! great way to obscure a file name since the
audio delay when listing the directory didn't reveal where in the name the
<BEL> was hidden). Files were "owned" as their space was accounted for in
the user's quota (deleting a large file using the cross-account access
could temporarily result in a quota increase for the account that did the
deletion). Obviously no protection levels other than the optional password
field.

    Unlike TRS-DOS 3 (and carried into LS-DOS 5). A full filespec was
filename/ext.passwod:# (8.3.8 and # being logical drive # 0-7). Files had
two passwords: master (needed to invoke the attrib command on the file) and
user. The user password only had access as specified in the attrib command
-- so one could set a program file to be execute-only and STILL require a
password to run it. LS-DOS/TRSDOS 6 lost the user password when a change
was made to allow for more than a 7-year date range (you thought Y2K was
bad, TRSDOS 6 was something like 1980-1987 <G>). Most people never set a
user password anyway. Supplying drive numbers wasn't done much either on
most (dual floppy) systems -- one would write protect the system disk,
leaving the other drive for data. The OS would scan mounted disks for
existing filenames, and would create new files on the first write-enabled
drive.


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: RPi3B, /Boot resize, UBmate 14.04.2
On Sat, 09 Dec 2017 12:44:59 -0500, Dennis Lee Bieber wrote:

Quoted text here. Click to load it
I beg its pardon: I've heard of Sigmas but never seen or used one. I sort  
of assumed they were roughly equivalent to a VAX or IBM System/3 - IOW a  
small one was pretty much a mini but by adding bits you could get  
supermini or small/medium mainframe capabilities.  

Quoted text here. Click to load it
Wild! Very different from anything I've used too.

George 3 had a hierarchical filing system with :master as the root, used  
only by the OS. It had two subordinates, :lib and :manager. :lib was the  
top of a hierarchy holding the system software and :manager was the top  
of the user hierarchy.

Users with appropriate privileges could create users under them.  

These were either inferior users who were given part of their superior's  
budgets for disk space, mill time and mag tapes. These were both the  
user's top-level directory and his login, so recorded both his password  
and his budget details.

A user could also create pseudo-users, which were just directories  
belonging to the user.  

File and directory names were 12 characters long and, like UNIX you could  
use partial names, so  

  :manager:martin:project:myfile  

was the absolute name a file called 'myfile'. It could be referred to
by partial name too, so it was referred to as :project:myfile  
from :martin and as myfile from :project.

There was a defined search path, so if you tried to run, say, myprog, the  
search path looked locally first in the current directory, then searched  
down the :lib tree and, if still not found, it searched back up the user  
inheritance chain from your immediate superior directory to :manager.  
This worked surprisingly well, since a co-operative group could put  
common programs in the project user and know they'd always be on all  
project member's search paths.

The AS/400 OS, OS/400 had three level names: username/filename/subfile  
and again you referred to your own files as filename (a data file) ir  
filename/subfile (a source file) but that was as far as it ever went.  
Names were limited to 9 characters! System command names were actually  
very logical and guessable but so short they looked like gibberish. OK,  
the source editor was called EDIT, but the PL/1 compiler was called  
CRTPLIPGM and after a while you saw the pattern: the COBOL compiler was  
CRTCBLPGM and the RPG III compiler (ugh!) was CRTRPGPGM


--  
Martin    | martin at
Gregorie  | gregorie
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2

[snip]

Quoted text here. Click to load it


OK. Thanks for your time and thoughts


--  
Mark J
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B
We've slightly trimmed the long signature. Click to see the full one.
Re: RPi3B, /Boot resize, UBmate 14.04.2
On 09/12/2017 18:58, Kiwi User wrote:[Snip previous dozen messages]

As much as I love reading these fascinating contributions to  
comp.sys.mainframe.nostalgia, it's not really answering the question  
about partitions on the Raspberry Pi (and no, I haven't answered it either).

---druck

Site Timeline