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

badblocks and ... Re: Lower memory install tip (example from yesterday's meeting)

Yes, I'd considered possibly creating and *using* swap on
the target install drive *while* doing the installation.

That does have some key advantages, notably there's generally ample
space there, and generally faster and more reliable than USB flash,
less write wear on the USB flash, etc.

However it's got some key disadvantages.
Most notably, as it's the target drive for the installation,
and Linux doesn't play as well with disk partitions (or equivalent)
on disks that are open (mounted, active swap, etc.) and repartitioning,
in fact Linux doesn't play so well with that and anything at all being
open on the entire drive.  Other operating systems are much more reasonable
about that - e.g. they'll allow one to make any changes to partitioning
on a drive, except can't remove or change start location of a partition
(or equivalent) that's in use nor reduce its size.  Some further restrict
to not changing such that its partition number (or equivalent) changes.
Some others don't even have or enforce even those restrictions.
Some Linux utilities (and relevant system calls, etc.) do allow more
mucking about with partitions on drive, where thing(s) are in use (open)
on the drive - including even updating the kernel's idea of what the
active partition table looks like - but still, many Linux partitioning
utilities won't allow the kernel's idea of what the active partition
table looks like to be updated while anything at all on the drive is open
- and many installers still behave that way.

Another key disadvantage, is trying to determine exactly how one wants
to lay out the partitioning for the install, "vs." where to use swap
during the install itself.  E.g. if one wants to lay out the drive
partitioning exactly the way the distribution install would do it by
default, it can be difficult to determine exactly what that looks like
if one has an active live swap partition already on the target drive.

Anyway, those were some of the reasons I opted for doing the temporary
swap during install on the USB flash, rather than the target install
drive - notably that left it completely out of the way of the target
install drive.

... badblocks.  If one is going to use badblocks or equivalent, I'd
generally recommend using it *before* formatting (e.g. before mkswap).
Actually, what I often like to do - particularly on larger drives,
and when not in any great rush (probably more on this later, but ...):
o Figure out exactly how I want to lay out the partitioning.
o Determine exactly what areas of the drive are not entirely
  within the data areas of the partitions themselves.
o Use badblocks on all areas that won't be within partitions themselves.
o Put the predetermined partitioning in place.
o Run badblocks on the contents of each partition (excepting extended).
o Note also if one isn't going to immediately put partition(s) to use,
  one may wish to defer their checking with badblocks - this can be very
  handy with quite large (e.g. >~= 1 TiB) drives ... e.g. I did this rather
  recently on an ~2 TiB drive ... each partition well tested with badblocks
  over a period of days - but OS installation was already on the drive and
  up and running long before completion of all the badblocks checking,
  however any and all areas used for data storage of any type whatsoever
  were always checked with badblocks before any actual data was stored
  there.


From: ace36 <acohen36@gmail.com>
Subject: Re: Lower memory install tip (example from yesterday's meeting)
Date: Mon, 27 Nov 2017 09:34:07 -0800



On Mon, Nov 27, 2017 at 7:25 AM, Michael Paoli <
Michael.Paoli@cal.berkeley.edu> wrote:


Lower memory install tip (example from yesterday's meeting)

Got an installation that's a bit intensive on memory, struggling with /
not quite making it through the installation on account of that?
But ... the distribution/installation itself is (semi-?)reasonable as
far as (virtual) memory goes ... at least once it's been installed?
Installing from ISO image on USB flash?
But the flash is fair bit bigger than the size of the ISO image itself?
Well, try adding, early in the installation process, some swap on that
USB flash!




Nice writeup of this!
OTOH, I've found that another easier and faster option is to use a
partition on the pre-existing hard-disk drive that's dedicated to swap.
How might you go about this?

1. You'd first have to obtain a good live-media (liveUSB) rescue-type
distro to dedicate onto a separate USB flash drive.
I myself highly recommend using KNOPPIX for this [1] because this distro is
so incredibly versatile for this and for practicaliy any other task you
might want to perform with such live-media (see [2]). KNOPPIX 8.x is also
flexible enough to support low-memory i686 machines in addition to
low-memory machines with amd64 CPU's. Another good live-media rescue-type
distro I and many others have used for this purpose in the past is
SystemRescueCd [3].

2. Once you've downloaded and successfully created your liveUSB flash
drive, you'd use it to boot up your machine in question; preferably using
the option to boot into a command-line for a low-memory machine ---- for an
amd64 machine using KNOPPPIX, that's entering "knoppix64 2" at the initial
boot-prompt.
I'm assuming for the sake of these instructions that the pre-existing
hard-disk drive is recognized as "/dev/sda".

3. Once you have just the command-line (a.k.a., the terminal) up and
running, you'd then probably want to repartition the pre-existing hard
drive -- maybe by running fdisk/cfdisk -- to delete and recreate a few of
the drive's partitions that you'll need. You can almost always go back to
resize these very hard drive partitions using gparted from your installed
desktop environment/window manager at a later time. I myself like to create
a 1GB /boot partition on /dev/sda1 (default type 83) followed by the
required swap partition on /dev/sda2 (sized as 1.5 x physical RAM, type
82). Once this initial partitioning is complete, then I'd **immediately**
run a formatting and disk integrity check on both partitions using
something like
'mke2fs -t ext4 -ccvv /dev/sda1 && mkswap /dev/sda2 && badblocks -svvn
/dev/sda2' (a better check on the swap partition if you have more time is
using the write option on the badblocks command, as in 'badblocks -svv*w*
/dev/sda2')
-----> Please check the results of this disk integrity check!
If the badblocks disk integrity check on both partitions finishes without
error
  then you'd go ahead and activate the swap partition with 'swapon
/dev/sda2'
Else (if the disk integrity checks shows disk errors on **either**
(partition)
  then you should seriously reconsider using that particular hard drive for
your Linux installation

4. Once you've successfully activated the hard disk's swap partition using
your liveUSB flash drive, then you would shutdown your machine, remove this
rescue-type USB drive, grab your *installation* USB with your Linux distro
of choice, and then boot up your machine using the latter.
On the vast majority of every Linux distros I've used (Debian, Ubuntu,
Mint, Slackware, Arch-based, RPM-based, ...etc.), there's almost always an
opportunity to activate that pre-existing hard drive swap partition in
order to gain more useful memory resources before proceeding with a full
distro installation on low-memory machines.
IIRC, Ubuntu and Mint allow you to run an xterminal session from the
initial GUI (before full installation is started) and to then switch to the
root user via 'sudo su -' before running 'swapon /dev/sda2' to activate the
required hard drive swap partition. Other distros allow you to open a
command-line virtual terminal during installation to activate the swap
partition, e.g., by hitting the Ctl-Alt-F2 keyboard combination, becoming
the root user if not already, and then entering 'swapon /dev/sda2'.

Using such a hard drive swap partition instead of a USB flash drive's might
even save a bit of wear-and-tear for repeated installations using that same
USB flash drive.

References
[1] http://www.knopper.net/knoppix-info/index-en.html
[2] http://www.knopper.net/knoppix-mirrors/index-en.html
[3] http://www.system-rescue-cd.org/

-A

--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com. 
To post to this group, send email to berkeleylug@googlegroups.com.
Visit this group at https://groups.google.com/group/berkeleylug.
For more options, visit https://groups.google.com/d/optout.




--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To post to this group, send email to berkeleylug@googlegroups.com.
Visit this group at https://groups.google.com/group/berkeleylug.
For more options, visit https://groups.google.com/d/optout.