How to increase root partition from 16 MByte to 160 MByte
Jaswinder Singh Rajput
By default Minix3 installs root partition 16MB Root partition, How can
I increase the root partition.
My root partition is becomes full very easily and getting error and
fails when I try to log in :
"No space on device 3/128"
In my case root partition is 16MB and it is 0% free.
/var/log/messages is of size 16 MB and it is full of these messages :
Dec 25 13:16:12 minix kernel: get_filp2: setting err_code to EIO for
proc 36652 fd 3
Dec 25 13:16:12 minix kernel: get_filp2: setting err_code to EIO for
proc 36652 fd 3
Dec 25 13:16:12 minix kernel: vfs:do_select: EIO after driver failure
Dec 25 13:16:12 minix kernel: get_filp2: setting err_code to EIO for
proc 36652 fd 3
Dec 25 13:16:12 minix kernel: get_filp2: setting err_code to EIO for
proc 36652 fd 3
Dec 25 13:16:12 minix kernel: vfs:do_select: EIO after driver failure
I think /var/log/messages should use some ring buffer and its size
should never exceed more than 5 MB.
Thank you,
--
Jaswinder Singh.
Jaswinder Singh Rajput
I am reposting the message because there was lot of typo in previous message :
By default Minix3 installs 16MB Root partition, How can I increase the
root partition to 160 MB.
My root partition becomes full very easily and I am not able to login :
Erik van der Kouwe
I can think of three ways:
- Change the setup script (commands/scripts/setup.sh) then
- Boot with the install CD, copy setup script to RAM disk, change it
and run it
- Manually transfer your installation to new partitions
If you use the setup script you cannot use the re-install option to
keep your data, so I think the third option is probably the preferred
choice. This does require a spare partition (or disk) to move your
data to though.
I would do it like this:
- Boot from install CD
- Create sub-partitions (s0-s2) on the destination partition using
"part" with the sizes you like
- Mount the sub-partitions of the source and destination partitions
(first s0, then s1 in its home and s2 in its usr subdirectory)
- Copy the data from the source to the target partition (a regular "cp
-r" would probably work)
- Use "installboot" to write a boot sector to he destination partition
(check the man-page for more info)
- Change your bootloader to boot MINIX from the new partition
With kind regards,
Erik
On 6 jan, 17:11, Jaswinder Singh Rajput <jaswindermi...@gmail.com>
wrote:
Antoine Leca
> - Manually transfer your installation to new partitions
I did that a couple of times, without troubles.
> This does require a spare partition (or disk) to move your
> data to though.
I am not sure, unless you count the CD as "spare partition" (which
indeed it is.)
Some steps added, and some hints too:
> I would do it like this:
> - Boot from install CD
- hint: open another session (Alt+F2), and put /bin/setup in
a viewer, to help you in the process as guideline
- before deleting everything, you might backup some part of your
old configuration; /etc/* is small and valuable (see below);
of course, the problem here is to find a place to store the
backup so that it can survive the next steps, particularly if
something goes wrong and you have to reboot...
> - Create sub-partitions (s0-s2) on the destination partition using
> "part" with the sizes you like
- mkfs the three file systems; you can tune the inodes numbers here
(particularly important when you have large disks, since too much
inodes causes firstdatazone in the superblock to overflow)
> - Mount the sub-partitions of the source and destination partitions
> (first s0, then s1 in its home and s2 in its usr subdirectory)
Since you can do the copy incrementally, you can use the mounted CD
and the regular mounting points as source, and /mnt as destination;
this means you must intertangle the mount's and the cp's (below)
> - Copy the data from the source to the target partition (a regular "cp
> -r" would probably work)
except with /, where you should use "cp -rx" instead (I prefer
-psrx as does the script, but the differences are not important)
- when the / filesystem is copied, you can edit /mnt/etc files
to reflect the target configuration; at the very least revise
/mnt/etc/fstab; you can also prefer to restore a previous backup
of your /etc directory (assuming you did back it up; see above);
while I did not test it personally (yet), it is the moment you
are supposed to launch "netconf -p /mnt" too.
> - Use "installboot" to write a boot sector to he destination partition
> (check the man-page for more info)
There are three substeps here:
* first you perhaps have to make the new disk to be bootable,
by installing a MBR boot code with installboot -m; of course
this is not necessary and even nefast if you have data on others
volumes (partitions) along with Minix...
* second you makes bootable the Minix root volume with
installboot -d (or -b, which combines -d and -i)
* third you changes the default parameters with edparams
By default Minix boots from a copy of the s0 volume transfered into
memory as a permanent ramdisk (not to be mixed with the temporary
ramdisk embeedded in the memory driver, which is used only while
booting.) You would prefer to use the harddisk as root filesystem
(which is the normal setup under Minix3 as installed.) So usually
this is done with "rootdev=c0d0pXs0" as typed in the monitor, or
equivalently autoexec'ed with edparams.
I found looking at src/commands/scripts/setup.sh to be a very
valuable help here.
> - Change your bootloader to boot MINIX from the new partition
Antoine
Roy
On 1月6日, 下午11時54分, Jaswinder Singh Rajput <jaswindermi...@gmail.com>
wrote:
> Hello,
>
> By default Minix3 installs root partition 16MB Root partition, How can
> I increase the root partition.
>
If it is full in /root only, you can move root's home to /home by "mv /
root /home/root" and editing /etc/passwd and change root's home
directory from /root to /home/root .
Antoine Leca
> If it is full in /root only, you can move root's home to /home by "mv /
> root /home/root" and editing /etc/passwd and change root's home
> directory from /root to /home/root .
Be reminded when doing such thing that it somewhat breaks the "single
user" mode (boot -s), which is used in emergency cases to repair the
system (and particularly a brocken $home file system.)
It might be possible to create a subdirectory /home/root which only
serves in single user mode, while still mounting cxdxpxs1 under /home,
but it is pretty ugly and error-prone.
Antoine
Jaswinder Singh Rajput
Thanks for your reply.
1. My request is to increase default root from 15 MB to 100 MB in next
Minix release.
2. Is there any limit for the hard disk for the Minix installation.
3. I am not able to install Minix on 60 GB hard disk.
4. How can we make dual boot with Minix and Linux.
Thank you,
--
Jaswinder Singh.
> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>
>
>
>
Antoine Leca
> 1. My request is to increase default root from 15 MB to 100 MB in next
> Minix release.
I do not understand the purpose: the basic Minix distribution (without
packages) is still well under 100 MB, indeed about 30MB.
And is supposed to run with as low as 16 MB main memory (is it still
true?) And may use a ramdisk for /; obviously, a 15-MB ramdisk won't fit
into a minimal-sized workstation, but I hope you get the point.
Or are you arguing about the size of the s0 file system to be tunable at
installation? It could be a good thing, but one should keep the
automatic process easy, particularly since there is an 'expert mode'
available where you can make the s0 file system the size you want.
> 2. Is there any limit for the hard disk for the Minix installation.
Minix only recognizes "MBR" disks, so there is a 2TB limit (with many
effects.)
Another relevant limit with big disks is the "s_firstdatazone" member in
the super block, which is a 16-bit quantity; so the total number for all
the bitmaps and all the inodes should be less than 64K blocks.
An hypothetical 1TB Minix file system would have 2^31 sectors, so 2^28
data blocks, so the zone bitmap is 2^25 bytes so 2^13 blocks (8200),
leaving 57000 blocks for inodes or a maximum of 3,600,000 inodes and a
similar maximum number of files, probably insufficient when you compare
with the size of the file system...
PS to all: Please check my maths above, and ask if you do not agree! :-)
And yes, I know 1TB is questionable with files not bigger than 2GB.
> 3. I am not able to install Minix on 60 GB hard disk.
Where does `setup` fails, and with which message (if any)?
> 4. How can we make dual boot with Minix and Linux.
There are several alternatives. It all boils down to understand that in
the so-called boot process, after the mandatory step of the masterblock
code (which selects a partition among several), you goes through a "boot
loader" (NTLDR, LILO, GRUB), or "boot monitor" as it is called in Minix,
which is somewhat configurable and accepts user entry; this piece of
code have basically two functions:
- it selects among options, e.g. various file systems, or various
kernels, or boot options, or screen configurations
- it loads into memory, from a known file system organization, the
kernel and all its mandatory components for booting: for Minix, they are
the first-class servers (like PM, VFS) and principal devices (like tty,
memory); for Linux it could be the initrd; for Windows they are the
"boot" drivers; etc. Then it jumps into the kernel initialization code.
Obviously, the second part is OS-specific; as a result, a multi-boot
organization has to make a choice:
- either one uses a versatile boot loader which can boot all the
possible kernels (for example, using GRUB4NT's GRLDR, one can boot any
*BSD, Linux or Windows kernels);
- or one use the previous phases (selection) to redirect the path into
the intended loader; this is usually done using a function named chain
loading, which is present in most "boot managers", and which basically
resets the path where the masterblock.s code left, i.e. reloading the
whole boot manager package from a (new) partition.
With Minix, two specific things occur:
- first, no general-use boot managers (like GRUB) know how to load
Minix, so the first alternative above is impossible for Minix, you are
required to end within Minix' boot monitor to load Minix;
- second, Minix boot monitor only know how to boot Minix, nothing else,
so the first alternative above is impossible for Linux as well, you are
required to end within a Linux-able boot manager to load Linux.
(Things are identical with Windows or *BSD instead of Linux here.)
However, as I said earlier, you have multiple choices about which
program(s) handles the selection phase; in general, the choice is guided
by your use of the computer, and your fluency with those tools.
I shall not comment further if you choose a Linux-based manager like
LILO or GRUB just use chainloading in these to get back into the Minix
boot monitor. If you choose Minix boot monitor as primary, setting up
multiboot is done this way:
- make the masterblock.s code to boot Minix partition (making it
"active" is the usual way to do so)
- install the Linux loader in its partition (NOT in the master block)
- to boot another OS, here Linux, at the monitor prompt, you will use
boot dXpY
where /dev/c0dXpY are the reference of the partition containing the
Linux boot loader as seen from Minix (this is slightly untrue)
- when the above works, you want it more automatic: in the boot monitor
"menu", you will add an option which does just the above boot command;
do not forget to "save" your new menu (man 8 monitor describes it better
than I do ;-) )
The "slightly untrue" note above is that dXpY are the BIOS references
for the partition; it will be the same if you are using the bios_wini
driver (unless bios_remap_first), but may be different if using at_wini,
since for example the latter won't see AHCI drives presently.
Antoine
D.C. van Moolenbroek
> Another relevant limit with big disks is the "s_firstdatazone" member in
> the super block [..]
This has been fixed in SVN trunk.
Regards,
David
Niek Linnenbank
Niek Linnenbank
WWW: http://www.nieklinnenbank.nl/
BLOG: http://nieklinnenbank.wordpress.com/
FUN: http://www.FreeNOS.org/
Antoine Leca
>> Another relevant limit with big disks is the "s_firstdatazone" member in
>> the super block [..]
>
> This has been fixed in SVN trunk.
Yes, rev. 5784, https://gforge.cs.vu.nl/gf/project/minix/scmsvn/
?action=browse&path=%2F&view=rev&revision=5784 (remove the space)
I think the best description is the one within mkfs.c (and the less
descriptive is probably in super.h)
Please David advertise this far and loud, since it affects all the tools
out there (beyond Minix, I mean) which are trying to understand the
internals of a Minix file system; an obvious possible victim could be
the Linux support for Minix filesystems (the very one which was badly
broken in 2005-2007 when V3 file system with a quite different layout of
the super block were introduced.)
For example, a quick search showed me that sbi->s_firstdatazone is quite
used in linux/fs/minix/bitmap.c, and is read without precautions from
the on-disk superblock in linux/fs/minix/inode.c; so this is likely to
break, unless some changes are done in the fetching code...
In this very case, I believe people here or there are already using
Linux so could probably easily submit patches (or have already done so);
but Linux is just the most visible summit of the iceberg...
Antoine