Prev: always create the locations that need frequent I/O /home, swap on the outer tracks ?
Next: always create the locations that need frequent I/O /home, swapon the outer tracks ?
From: Aragorn on 17 Jul 2010 07:00
On Saturday 17 July 2010 01:44 in comp.os.linux.setup, somebody
identifying as Hans-Peter Diettrich wrote...

> tino schrieb:
>
>> I am very new to Linux (using it about a week or so..
>
>> [...]
>> I'm using a Windows Vista 64bit host machine, on which I installed
>> the latest VirtualBox (3.2.6).
>> The problem occured when using a guest machine image based on Linux 8
>> Helena.. being a newbie I thought this image could help me start
>> without the need of installing everything from scratch, at least till
>> I acquire enough knowledge to do so more confidently
>
> Installing Linux can be fun, depending on the distro. I'd give it a
> try, at least...

>> I've been using Virtual Rails for about a week.. pretty quick
>> and with no special effort I got 13GB out of the available fixed 15GB
>> used (I realise a more experienced Linux user could maybe have done
>> what I did with less.. but in my feeling 15 GB are pretty limiting
>> and I don't wish to constantly keep worrying about the capacity of my
>> guest machine..)
>>
>> Therefore - went ahead and read about resizing partitions..
>
> You may be better of with a second virtual drive, that you mount for
> your existing (or better a new user) home directory, or as a dedicated
> ~/Data directory. Even if Linux has only one root directory, you can
> mount additional disks (partitions) as any folder.

"Folders" are GUI constructs, and an abstraction layer at that.
A "folder" may represent a directory in a filesystem, but it may also
represent a _file_ in the on-disk filesystem, or perhaps none of the
aforementioned. Therefore, when talking of a filesystem - and
especially so in a UNIX context - it is recommended to use the
word "directory" instead.

That said, you can /technically/ mount any partition or other storage
volume on any directory, this is true, but you cannot go ahead and do
that for every directory in a GNU/Linux system, because that would
render the system unbootable.

Directories such as "/bin", "/lib", "/etc" and "/sbin" *must* have their
contents physically residing on the root filesystem - i.e. the
filesystem which holds the root directory - because the contents of
these directories are needed at boot time, before all other filesystems
are mounted.

"/boot" is an exception in this regard because it is needed at machine
boot time, but it is not needed by the kernel. It only needs to be
accessed by the bootloader in order to /load/ the kernel image (and
initrd, if required) into memory.

In the LILO bootloader, the location of the second-stage bootloader is
hardcoded via logical block offsets in the primary stage of the
bootloader - i.e. the part that resides in the master boot record, or
if so desired, in the active/bootable partition's boot sector, whatever
that partition may be. (Note: GNU/Linux does not require any partition
being marked "bootable" except in this scenario, in which case it is
rather a requirement of the bootloader than of the operating system
itself.) The second stage of LILO is typically located in "/boot" as
the file "/boot/boot.map" or something of that nature, and has in it
the hardcode logical block offsets to where the kernel images and
initrds are.

In the event of GRUB, things are slightly different, but not too much.
GRUB also has a first stage loader, which is similar to the one used by
LILO and has the same requirements. This first stage loader will then
load an intermediary GRUB stage (1.5), which contains a real mode
filesystem driver for the filesystem "/boot" resides on -
whether "/boot" is separate from the root filesystem or not - and this
in turn will load the stage 2 part of GRUB. This stage 2 can then, via
its filesystem driver be able to read (in realtime) the contents
of "/boot/grub/menu.lst" - or "/boot/grub/grub.conf", depending on the
distro and GRUB version - and can load the selected kernel and initrd
via the real mode filesystem access.

As soon as the kernel is loaded in memory, the kernel's bootstrapping
code - provided we are talking of the x86 architecture and with a
legacy BIOS version, of course - will set up the pagetables and
descriptor tables, save the boot parameters to a location in memory
accessable from within protected mode, and will then switch the boot
processor to protected mode and decompress the kernel. As of that
moment, the real operating system kernel takes over and "/boot" is no
longer needed. Driver modules are loaded either from within the in the
meantime also decompressed initrd or if applicable, directly from
the "/lib" directory on the root filesystem, once the root filesystem
has been checked and mounted.

Root-level directories which *may* have their contents residing on other
filesystems - which themselves could also reside on other hard disks or
even on other computers in the network - are...

- /boot
- /home
- /opt
- /root (see [1])
- /srv (see [2])
- /tmp (see [3])
- /usr
- /var

[1] Technically possible, but not advised as it is the home of the root
user and needs to be accessible when the system is booted up in
single-user maintenance mode, in which case no other filesystems
will be mounted. When the system is brought down to single-user
maintenance mode - i.e. runlevel 1 - from a previously working
state without having been rebooted, this does not apply, as all
mounted filesystems will still be mounted at that point.

[2] Although specified in the latest version of the FHS (Filesystem
Hierarchy Standard) and created at installation time in a number of
GNU/Linux distributions, there are just as many distributions that
do not create it, and those that do leave it empty. It is intended
to house shared data which would otherwise be put under "/var",
e.g. "/var/www", "/var/ftp" and other similar directories.

[3] "/tmp" should for good measure be kept on either a separate
partition or on a tmpfs - i.e. a RAM-based and swappable filesystem
of dynamic size. Nothing residing in "/tmp" should be required to
survive a reboot and thus the use of a tmpfs is quite feasible.
The only possible objection to that could be that in most modern
distributions aimed at desktop usage, "~/tmp" - i.e. the "./tmp"
directory in each user's home directory - is typically symlinked
to "/tmp", and this could thus pose serious capacity demands on
"/tmp" which way exceed the available RAM. Without this
requirement - i.e. if the user's own "./tmp" directories are not
symlinked to "/tmp" - the needed size for "/tmp" should not be
bigger than about 50 to 100 MB per user account. In this case
however, every user should be responsible for cleaning out their
local "./tmp" directories on a regular basis if the processes that
create entries there do not clean up after themselves. The "/tmp"
directory itself should also have the sticky bit set and be world-
writable - i.e. 1777 permissions, or otherwise put "trwxrwxrwx" -
so that users can create files there but not delete files created
by other users.

Directories which should *never* be split off from the root directory
are...

- /bin
- /dev (see [4]
- /etc
- /lib (see [5])
- /media (see [6])
- /mnt (see [6])
- /proc (see [7])
- /sbin
- /sys (see [7]

[4] The "/dev" filesystem is an abstraction layer to the underlying
hardware, represented via so-called device special files. In
modern GNU/Linux distributions with a 2.6.x kernel, the contents
of "/dev" no longer reside on the physical disk but are instead
created at boot time on a tmpfs - see the description of a tmpfs
in the comments about "/tmp" higher up - by the "udev" system.
"udev" is a system which creates and deletes device special files
on the fly as hardware is being plugged in or removed from the
system, based upon the information the kernel exports via "/sys"
about the detected hardware.

[5] On x86-64 systems with "multilib" - this is enabled in most x86-64
distributions by default, but I was told that Slackware leaves it
up to the user to decide on whether to install "multilib" or not -
"/lib" will typically be a symbolic link to "/lib64", and there
will then also be a "/lib32" directory. Neither of these two
should be split off.

[6] Technically, "/mnt" and "/media" can be split off, and it might
actually not even be such a bad idea to do so, but at the same time
it could also make things too complicated for an absolute newbie.
"/mnt" is a mountpoint for volumes which are normally not part of
the system, and "/media" is the parent directory for directories
which each form a mountpoint for removable storage media.

[7] The contents of "/proc" and "/sys" do not live on the physical disk
partition. They are virtual filesystems, and their contents are
only created as a filesystem structure when something is attempting
to read from or write to them. They are abstractions of the kernel
represented to the user as a filesystem structure.

Although most newbies opt to install everything in a single root
partition, it is generally advised to have at least "/home" be a
separate filesystem.

> Simply think of ~/Data like of a Windows D:\ drive. The only
> requirement: the mountpoint (folder) must be empty, or a new folder,
> otherwise you cannot mount anything into it.

This is not correct. Any directory can serve as a mountpoint, but when
mounting a filesystem to a directory, then the contents of that
directory - in the event that it is not empty - will be unavailable for
as long as the directory serves as a mountpoint.

In the event of people who like testing different distributions on the
same system, the actual location where the user keeps their own work
files - in most distributions, this will be "~/Documents" and similar
directories, e.g. "~/Downloads" - can be put on a separate filesystem,
while the actual home directory contains symlinks to that filesystem,
or said filesystem being mounted to the pertaining directories under
the user's home directory. This way, the actual home directory can
contain the distribution-specific "dot files", which may differ per
distribution and even create conflicts.

Although every GNU/Linux sysadmin can and may install their systems in
whatever ways they want, it is still advised not to create any extra
root-level directories, since there already are enough directories to
cover for any kind of data storage. It is generally also advised to
keep static and dynamic data separated, as well as shareable and
non-shareable data.

More information with regard to what's shareable and what not can be
found here...

http://www.pathname.com/fhs/pub/fhs-2.3.html

> Then move all important files from your home directory to that new
> directory or user, and don't forget to clear the trash folder. Then
> 15GB should be enough for the OS disk.
>
>
>> Have found some really great tutorials out there and followed a
>> procedure using GParted Live CD in order to copy the existing
>> partition into a bigger one.
>
> I never did so, moving bootable systems looks quite complicated to me
> :-(
>
>> Anyway, when I try to copy only the primary partition and resizing it
>> to the new bigger HD it works fine..but when I try to boot with the
>> new image as a primary master (after removing the smaller old vdi
>> file) - I get a blank black screen with a white static underscore at
>> the top left (there's a better name to it I think.. just can't recall
>> it now..).

It is called "a cursor". :p

> That's why I ... ;-)
>
>
>> I simoltaneously installed a fresh Ubuntu 10.04 LTS on my VB (with
>> 100GB *grin*) thinking I should be doing the whole configuration and
>> stuff by myself now..
>
> Consider to use multiple disks or partitions the next time, for e.g.
> /usr, /tmp and /home/yourname [...

Better would be to keep the entire "/home" population on another
partition, not just "~" - i.e. the actual user's home directory.

> ...] - have a look at the suggested mountpoints in GParted. Extending
> such additional partitions should be easy, later, because they do not
> affect booting from your dedicated OS drive.

Many distributions default to using logical volumes instead of
partitions. However, personally I do not recommend this to any newbie
until they've sufficiently familiarized themselves with the system.

Logical volumes offer a handy way to circumvent the "16 partitions per
disk" limitation imposed by the Linux SCSI midlayer and applicable to
all SAS, SCSI, SATA, Firewire and USB disks, and since still fairly
recently, PATA/IDE disks as well - the latter because Linux now
defaults to using the "libata" drivers for PATA/IDE disks as well; with
the old driver code, a PATA/IDE disk could hold up to 63 partitions.
(Note: you can still create more than 16 partitions, but Linux won't be
able to use all of them.)

Another advantage of logical volumes is that they can be more easily
resized if need be. However, logical volume management is an
abstraction layer above the physical partitioning layout and requires
that the kernel has the required drivers - either built-in statically
or built as loadable modules - and that the required tools are
installed to scan the disks and create the proper device special files
via "udev". LVM can also be used to create volumes that span multiple
disks, similar to the JBOD functionality in Linux's software RAID.

For newbies, I recommend using regular partitions instead, though.

--
*Aragorn*
(registered GNU/Linux user #223157)
 | 
Pages: 1
Prev: always create the locations that need frequent I/O /home, swap on the outer tracks ?
Next: always create the locations that need frequent I/O /home, swapon the outer tracks ?