What has stopped me using chroot is that I cannot work out how to use it and how to get out of the new root directory. Do I chroot /mnt/sda9 or chroot /dev/sda9? Once finished there, do I then just reverse the commands to get back to sda1? For once, I don't want to experiment because the experience could be Kafkaesque, which is too much like real life.

You chroot to the file system so it is always /mnt/sda9.

On finishing the work inside /mnt/sda9 you must "exit" back to the Linux you booted up to.

Technically if you boot up to a Linux A and chroot into another Linux B you are using the kernel from Linux A to operate the terminal and Bash shell of Linux B.

This is one of the great strengths of Linux. Enjoy it!

Thanks. I chroot /mnt/sda9 then grub-install /dev/sda9 and exit

What I hope to accomplish by that is to make sda9 (using its menu.lst) bootable with chainloader + 1 in the boot menu of sda1.

Perhaps. Documentation is not one of the strengths of Linux. exit is not mentioned in any documentation I can find relating to chroot. Various threads I've looked at say to exit from chroot without saying how.

It actually sounds simple but the documentation shrouds it in mystery and the self-nominated sages warn that chroot should only be used by experts.

That chroot thing didn't work and "exit" does not always get me out of chroot.

I've posted this on the distro's forum as well because this just does not make sense to me. Right now, Linux has me well ticked off.

I set up the following:
sda1 - ext3 (for PCLinuxOS) (after changes, nuked)
sda2 - ext3 (for anor)
sda3 - ditto
sda4 - extended partition which included the balance of the hard drive
sda5 - swap
sda6 - /tmp (after changes -- sda8)
sda7 - /opt (after changes -- sda9)
sda8 - data (after changes -- sda6)
sda9 - ext3 (whatever) (after changes -- sda7)

(Edited by removing arrows which confused my meaning.)

I discovered that /opt needed to be larger. So, thinking that my method would avoid any problems, I reduced sda5 in size, used some of the space for /tmp, deleted sda6 and sda7 and used all the then unallocated space for /opt (now sda9). So, the number and sequence of partitions remained the same. Locations and numbering of some partitions were altered.

I could not subsequently log into sda1, even after using the live cd to alter /etc/fstab. I kept getting some message about some "superblock" problem.

Now I'm thinking that my first instinct was correct, namely, to create a very small sda1 and use it just for the MBR and partition table.

My question is: why did the changes I made make sda1 unbootable?

I will bore you with I told you so...heheh

if you use one swap partition and one / partition you will never have to concern yourself with the individual folder sizes of /opt or /var etc....if you have many users who hog disk space you can use quota to limit their home folder sizes.

Saikee is very experienced but not everyone understands Linux straight off ...and as I am an aussie I tend to be more blunt in my advice which either is a winner or creates a perception of arrogance...hence I stayed out of this post until now.

2) by going down the non-primary way...you introduce extended and logical...and this is not a system created by Linux....I think it was IBM...anyhow its a bloody mess which is easy to fix

a) keep to 4 primary partitions and if you want to try out other distros use an emulator such as Qemu or VMware etc....if you use Microsoft you may want to have a gander at http://virtualbox.org/ but I have not tried it.

b) in taking an image of the first primary partition using ww.partimage.org...which Saikee as correctly stated contains the mbr as its actually a part of the first partition .....you get an option to restore mbr for later use

altho I also tend to write down my settings as well

anyhow end of rant...for now

Thanks for your comments. I hope Linux has progressed beyond such primitive arrangements.

The /opt thing was an experiment. I was thinking I could share the files in it between distros. They are mostly unpacked tarballs like Thunderbird.

I posted on the GParted forum and the administrator there is looking into why this happened. The MBR worked in the sense that the grub menu still appeared. But I got a superblock error message saying sda1 was not a valid ext2 file system, which was correct because it was an ext3 system. There is no reason (AFAIK) why it should have been affected.

Theoretically, there was nothing wrong with what I did and I want to get to the bottom of it. I don't want to use emulators. I want to establish decent working systems. I'm hedging my bets because I cannot tell which distros are here to stay - apart from the three largest commercials (?), which I've tried and dislike. Also, I'd like to get away from rpm, even though it's inveigled its way into the LSB.

Nuke the lot and start over again.
Even more blunt... you will likely end up doing this eventually anyway.
You can also do this for both security and performance considerations
(culled from one or more of the above) using solely the Knoppix liveCD:

1. Backup all data and configurations made since the past distro was 1st installed. Do this by consolidating all such SW into one organized directory with subdirectories, do a on the top directory of this to make a more compact tarball, use k3b for burning all this onto a CD.
So what if you already made a backup. Another backup never really hurts.... unless that is, the original hard drive contents are somehow corrupted.

2. Blow away all hard-disk partitions with
3. Double-check that MBR is really gone too, with a
4. Wipe and zero-out the contents of the entire hard-drive with
a You can use -n2, -n3, ... etc. if you want to have shred make more passes to more completely and securely wipe out the drive.

5. Run a and then hit Ctl-c the instant the command appears. Enter the exact command that just appeared, substituting -svvw in one piece for any separate -s -v or -w options.
Check for the reporting of any bad blocks after this finishes.

6. Reboot PC and re-run fdisk
Partition as follows assuming that this will be a general-purpose desktop workstation(justification in smallsize):
sda1 20 MB
for /boot
sda2 ?
recommended space for another OS to be run dual-booted without added apps or data

sda3 Extended
to end of hard-drive
sda5 ?
recommended apps plus data space for other OS in dual-boot system, e.g., 6GB vfat or ntfs for Win9x or Win2K/WinXP respectively but disrespectfully
sda6 250 MB
maximum for /<root>, dependant upon total hard drive space
sda7 2 X RAM
[/SIZE]swap partition, fdisk type 82
sda8 400 MB-500 MB
for /tmp
sda9 1 GB - 2 GB
for /var
sda10 4 GB - 8 GB
for /usr
sda11 2 GB +
for /home, dependant upon amount of data generated or downloaded
sda12 1-2 GB
for /opt, dependant upon number of 3rd-party apps added

Dont forget to write this to disk with fdisk's 'w'!

6. Format and install whatever dual-boot OS you are also using 1st. and make certain that it is working fine off of /dev/sda2 -- not /dev/sda1 !. Make an extended partition from this OS when prompted to, create a recommendeded apps-plus-data logical partition space (will be /dev/sda5 automatically) for that other OS when in dual-boot e.g., 6GB vfat or ntfs for Win9x or Win2K/WinXP respectively but disrespectfully Format this with that "other" OS.

7. Re-run fdisk from the Knoppix liveCD as follows.
sda6 250 MB
maximum for /<root>, dependant upon total hard drive space
sda7 2 X RAM
swap partition, fdisk type 82
sda8 400 MB-500 MB
for /tmp
sda9 1 GB - 2 GB
for /var
sda10 4 GB - 8 GB
for /usr
sda11 2 GB +
for /home, dependant upon amount of data generated or downloaded
sda12 1-2 GB
for /opt, dependant upon number of 3rd-party apps added[SIZE="1"]

Enter the 'a' option for /dev/sda1 to make this partition an active bootable one, before writing and exiting fdisk with the 'w' option.

8. When using the Linux distro of choice's formatting utility in the re-installation, format Linux partitions as follows
/dev/sda1 /boot ext3
/dev/sda6 /<root> ext3 or another journaling filesystem
/dev/sda7 swap swap
/dev/sda8 /tmp ext3
/dev/sda9 /var ext3 or another journaling filesystem
/dev/sda10 /usr " ditto "
/dev/sda11 /home " ditto "
/dev/sda12 /opt " ditto "

Minimize surface checking at the install and formatting stages.

9. After Linux re-installation, check to be certain that the distro boots okay, is optimized for acceptable efficieny, and then has any immediately-necessary patches/downloads for HW and SW. Restore, copy and then and your backed up tarball from the CD. Make any necessary changes in LILO or GRUB so that the "other" dual-boot OS can also boot.

10. Test that the other OS can boot fine using this dual-mode scenario.

Thanks, nycace36, for going to so much trouble. I'm interested in this statement because no one else supports it:
What is the reason for not using /dev/sda1 for an OS installation?

On the subject of using tar as a backup, I think you are way off course. Have a gander at this article.

Might want to seriously review the LQ thread 'LINUX Partition SETUP' at http://www.linuxquestions.org/questi...hlight=backups
IMHO, special attention should be given to the reply bskrakes gives, as this is much more explanatory. saikee provides some good links at the bottom of his reply in that thread --- same saikee as above.

I have not kept in touch with this thread. Is there still a problem?

Thanks, nycace36. Unless I'm blind and the find feature in my browser isn't working, there's nothing there to explain the contention that the first primary partition should NOT be used for an OS.

Hi, saikee. I thought I was immune after using GParted but deleting and replacing two logical partitions nuked my first primary partition. Trying to log in --> block error: not an ext2 partition. This is the relevant post.

A moderator on the GParted forum was going to test this but I've heard nothing more. For the time being, I have other issues and this is of no present concern - I'm just interested in getting to the bottom of the problem. I should have saved several relevant files so that the problem could be verified later but, at the time, I needed to get an OS up and running again ASAP and did not think about a post-mortem.

chroot is a very powerful command to enable a user employing a kernel from boot-up Linux A in combination with the Bash shell of the unbootable Linux B.

Since grub-install or Lilo are both part of the terminal commands of Linux B and so using just any Live CD to "source" the kernel from a Linux A becomes a method universally applicable to rescue any unbootable Linux.

The chroot command implementation has not been standardised and can vary between distros. The root privilege can also affect its use too. Therefore if it works we use it. If it doesn't we try other alternative Live CD.

However I have documented two methods to restore Grub in my signature (Task B4 and B5 refer)

(1) Using chroot from a boot-up Live CD Linux A into the unbootable Linux B

(2) Using a bootable Grub floppy to get a Grub prompt.

The second method is more robust than the first one as only Grub is involved. At this stage neither a kernel or the Bash shell has been loaded and so whatever problem you have it can only be Grub-only.

If you can't make a bootable Grub floppy booting up a Live CD and invoking a Grub shell may do the same trick because without the need to chroot you will be isolated from any problem associated with the unbootable Linux.

After over two years of working with Linux my current view is that a huge amount of tools have been invented and so it is nearly impossible to document every details and combination on how to use various parts of just a program. I am convinced those nice folks who wrote programs like Grub legacy haven't got time to try out all the possible combinations, on different machines, in interaction with many other systems or kernels that come out since the last version of Grub 0.97 was released.

I survive mainly by reasoning it out according to the known rules and restrictions. The bootable Grub floppy is possible the best teacher of all because you interact with Grub directly. If Grub can't do it tells you and so you can move on. If the rules say it can be done I find Grub always delivers.

Grub was fine. The menu was there and I booted after changing /etc/fstab on sda1 using a live cd. The boot process started, then sda1 was identified as not an ext2 file system.