RPi3B, /Boot resize, UBmate 14.04.2

gparted with card in another computer.

Done that repeatedly, on my Pandaboard workhorse...

--
Mark J 
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B 
- and Linux on a PandaBoard ES and Raspberry Pi3B

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:

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 
          | dot org

:-) 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 
- and Linux on a PandaBoard ES and Raspberry Pi3B

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!

You do now though, because UbuntuMate says that one of your partitionins is too small.

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.

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.

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.

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 
          | dot org

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...

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

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...

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.

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

Hmmm... murky ground.

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

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 
- and Linux on a PandaBoard ES and Raspberry Pi3B

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'

Good news.

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.

Again, no comment as I've not tried to run anything but Raspbian on my RPi, an early 522MB PI model B.

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.

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

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.

Should have typed 'print' to see the list of partitions before typing 'quit'.

That looks pretty similar to what I see from Raspbian except that my /dev/root is 7.2 GB with 3.1 GB used.

Pass. If nobody on here chips in, try asking on one of the forums at

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 
          | dot org

On Fri, 8 Dec 2017 18:07:41 +0000 (UTC), Kiwi User declaimed the following:

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 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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 
          | dot org

On Fri, 8 Dec 2017 23:48:19 +0000 (UTC), Kiwi User declaimed the following:

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 -- 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]).

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 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[snip]

OK. Thanks for your time and thoughts

--
Mark J 
From RISCOS 5.23 on a BeagleBoard-xM and Raspberry Pi2B 
- and Linux on a PandaBoard ES and Raspberry Pi3B

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 
          | dot org

On Sat, 9 Dec 2017 15:55:40 +0000 (UTC), Kiwi User declaimed the following:

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.

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 ! great way to obscure a file name since the audio delay when listing the directory didn't reveal where in the name the 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 ). 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 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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.

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 
          | dot org

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