The following are some notes from my install experiences.
(Thanks to Katolaz and Golinux for your help.)
I downloaded a fresh copy of netinstall to do a fresh install on bare
metal to an SSD on which I had Devuan working before; an upgrade from
Jessie. I started from scratch. I had previously set the drive up like
this:(below) During the Netinstall using Graphical Mode, I found some
interesting behavior and I thought I would try and document it. I had
the hard drive (250GB SSD) set up for some possible experimentation
with dual booting DOS/Windows later and to create a possible corner case for
the install.

(BTW, the Screenshot captures during Graphical Install
mode do not appear to be preserved.)


Here's the drive:

/dev/sda1    2GB  /dos    FAT16  (first partition  – previously formatted)
/dev/sda2    2GB  /boot   ext2
/dev/sda3    Extended Partition
/dev/sda4    2GB  /       ext2
/dev/sda5   40GB  /usr    ext3
/dev/sda6  150GB  /home   ext3 
/dev/sda7    5GB  /var    ext3 
/dev/sda8    5GB  /opt    ext3
/dev/sda9    5GB  /usr/local ext3

The installation got to some point in the "Select and Install software" step and stopped with a failure to mount on one of the ext3 drives. Continue, took me back to the "Select and Install software" list. I tried 2-3 times with the same result: back to the list on the same step. So I backed up to partition the drives step and selected each partition in order to re-format them. There is no option to force a format of FAT partitions so I let it go. After continue, I got a "found uncorrected errors" on the FAT16 partition. Since I didn't have a format option, I decided to change it to FAT32 to force a format. This got past that error. As I recall, the install got back to about the same point deep in the Select and Install step and produced the same mount error. Continue, took me back to the list. So I backed up to the partitioning step again and went through and selected the "erase all data" option to clear the data fields on all partitions. This did not change the failure, so I went back to the partition step. Next time through the partitioning step, I got the "found uncorrected errors" message but on the FAT32 partition. Upon changing it to back to FAT16, I could get past this error.

Then I got an "unable to mount" failure on the ext3 partition. Since there is no way to force a re-format option on that failing drive (the option is missing from the menu at that point --and I didn't change the fs type), the only way I could figure out to reformat that partition was to change the file system type so I changed it to ext4. This solved the error on that partition, but the problem immediatly moved to another ext3 partition. This kept happening on each install pass until I had visited all but one of the ext3 partitions.

This looks like reusing stale data without properly re-intializing the variable(s). I suspected the graphical presentation software at the time but I have no hard evidence.

[At the point of install mount failure, it indicates that there is more information in /var/log/syslog and/or Terminal4. (I think that's alt-F4?) Of course, not having finished the install, i don't think there is enough functionality to get to those. I'm thinking I should be able to live-boot Knoppix (is that a bad word?) and maybe mount the /var partition and look at the syslog if I knew what to grep for in the log.]
So I left the Graphical Mode and started using the "Install" option. Installation went through to completion.
Booted and logged in. Everything is so slooooow. Don't know who is sucking up the cpu. Also there is no wireless connection to the internet even though it just finished installing via the internet. Launching wicd does not find anything. I don't know how to use the ip commands to debug that or get the status of the adapter.

Continuing the next day I did some testing. I could not induce a mounting error, so

that's a different problem. The question is:

“Does the Graphical Install option recover correctly from a “failure to

mount” condition?"

Here's the pattern I've discovered. If I have the partitions set up as described above, and I go through the manual setup process I can consistently reproduce the "uncorrected errors" error found on the FAT partitions.


IIRC, I formated the drive earlier using the GParted (gksu) option found in my Refracta fall-back setup that's on a different SSD. So I assume its standard bios/FAT partitions. The 'partman' partitioner does not complain that the first partition on the drive is a 2GB FAT partition. However, I did reduce the size to 200 MB and that was accepted. 2GB was now rejected. 268 MB works but 269 does not. If you attempt 269MB or greater, partman will ask if you want to change a FAT16 to a FAT32 partition, and if so, it warns that any installed windows OS will be destroyed.

With 'no format F' option scheduled for the FAT partition, you will encounter the "Uncorrected Errors" problem every time.

At one point I encounted the following error message:

"GNU Parted cannot resize this partition to this size. We're working on it!"
This message can be found at this link:

https://ubuntuforums.org/showthread.php?t=2225043

And here:

https://unix.stackexchange.com/questions/365704/gparted-gives-problems-with-fat32/366182

And here:

https://bugzilla.gnome.org/show_bug.cgi?id=649324

Some copy from the bug and its workaround is included here:
<copy>
Unfortunately support for resizing FAT16 and FAT32 file systems is being removed from the libparted library. The last version of libparted that does support resizing is the recently released parted-2.4. The announcement regarding removal of FAT16 and FAT32 file system resizing from parted is available at the following link:


http://lists.gnu.org/archive/html/bug-parted/2011-05/msg00010.html


The commit that removes the resizing capability can be viewed at the following link:

http://lists.gnu.org/archive/html/bug-parted/2011-05/msg00061.html


Hopefully someone will develop a resizing utility to fill this void.
Curtis Gedak 2016-01-05 18:00:04 UTC

Status Update:


libparted 3.0 - removed FAT16/FAT32 and HFS/HFS+ file system resize capabilitylibparted 3.1 - added back FAT16/32 and HFS/HFS+ file system resize capability in a separate library

libparted 3.2 - also has this separate resize library

The inability to resize FAT16/FAT32 file systems that are less than 256 MB remains.

Workaround: Resizing FAT16/FAT32 Partitions (less than 256 MB)
---------------------------------------------------------------

1. Backup the data in the FAT16/FAT32 partition

2. Reformat the partition to EXT4

3. Resize EXT4 partition to desired partition size

4. Reformat the partition back to FAT16/FAT32

5. Restore the FAT16/FAT32 files from backup

Note that if you use file system labels you may wish to re-label the partition at this time.</copy>

Here is an associated patch:

http://lists.gnu.org/archive/html/bug-parted/2011-05/msg00061.html

And here is a note from that patch:

<copy>

Note that we are removing the resize command, even though parted
appears to be the only free tool that provides the ability to
resize FAT16 and FAT32 file systems.

</copy>

One commenter says "...you didn't do anything wrong, the FAT resizer is buggy."
Does this mean that the workaround "Solves" the problem?

If 'partman' is the default install partitioner in Devuan, what is the following warning all about?

https://packages.debian.org/jessie/partman-partitioning

<quote from that (partman-partitioning) link >

debian-installer udeb package
Warning: This package is intended for the use in building debian-installer images only. Do not install it on a normal Debian system.
</quote>

I haven't found the history of partman or its inheritance tree. It appears to ride on top of parted.

Question: How does any of this affect Devuan and its install process as it may affect users who want to dual boot devuan/windows? Should there be a notice somewhere so they don't have to repeat this discovery process?


Finally, I decided
to let it do an automatic install with minimum intervention. It
installed completely but after reboot, there is no network

connection. (Which I now understand is fixed.) And I've timed it;
after clicking on the network button,it takes ~18 seconds for the wicd window to open. Running top,
nothing seems to be hogging the cpu. Wicd fails to find any
networks.


(BTW,There is nothing in my G555 bios settings related to gpt or UEFI.) (BTW, I notice that us.dev/devuan/org always fails)

Just one last note,
I believe it was during one of the install passes using Graphical,
the install got near the finish line and dumped me into a TTY1
terminal screen. I didn't know what I might look for at that point. Any
suggestions should it happen again (with verbose commands)?

Finally, I'd just like to say
a big Thank You for all you VAU's for a back-to-sanity preservation
of the *nix philosophy. If there are any experiments you would like
run, let me know. I'll try.


Lastly, even tho my dng config is set to receive a copy of my emails, I don't get them. Rather, I get an email from dng-bounces saying that they received my email. what does this mean? thanks.