(old)Puppy Linux Discussion Forum

The boot partition lets me boot either to Fedora 8 (on an 8 GB thumbstick) or to Puppy 3.01ee frugal (on a 1GB thumbstick); I *think* the hard drive now has EeeDora on it -- it should.

But F8 is messed up; I need to boot it init3 (I think) and can't figure how.

I might be able to manage in eeedora. But I can't boot to it. The boot partiton doesn't know about eeedora yet; I need to edit that into /boot/grub/grub.conf

Puppy let me mkdir /TEST, and also did "mount -t ext3 /dev/hdc1 /TEST" and then cd /TEST, ls, cd grub, and so on.

But puppy doesn't have nano -- the only editor I know -- and I can't find the way to install it.

Neither can I find any other simple text editor I even *might* be able to tweak /boot/grub/grub.conf with

<sob, gasp, whimper, sniff ...>

I just need to add a couple lines of rootnoverify and chainload ...

<... whimper, sniff ...>

No Nano

You have Minimum Profit, run it by typing mp at the prompt.

Many thanks! Worked like a charm. What's more, once my ancient eyeballs spotted the Ctrl-a hint, it was all easy. (I'm doing this on an EeePC, as I may have mentioned : *tiny* fonts!)

Now all I have to do is figure out what grub is calling the main partition of the hard drive -- and I can get there by process of elimination, I think. (It did offer to boot to EeeDora, but failed when trying to take me up on it. I'll just start trying (hd0,1) etc, and (hbc0,0), etc.,till something works.

Many, many thanks!

I'll just start trying (hd0,1) etc, and (hbc0,0), etc.,till something works.

Trial and error would go along these lines:

(hd0,0)
(hd1,0)
(hd2,0)
(hd3,0)

As for filling in the second integer '0' you should be able to determine the Linux partition by running probepart or fdisk -l , then subtract 1

If probepart shows a /dev/hdb7 and you think that's the one Puppy is on then the second number would be 6

Consider also:

(sd0,0)
(sd1,0)
(sd2,0)

Consider also using GRUBs command line search. Criteria I think would be /boot/vmlinuz or where vmlinuz actually exists.

GRUB will echo back the drive / partition as GRUB sees it when it finds the match.

You don't just type a command. I can get the list of commands, all right, with the tab key from a grub command line.

But that doesn't help.

Most of them seem to need parameters, or flags, or objects, or something. With no hint what -- you're supposed to know.

And yes, I've tried once again to slog through man grub or info grub -- with the usual ending in despair. Those guys that write that stuff remind me of the famous story about the "obvious" (which I suppose all know by now).

I've heard or read, somewhere, that there is supposed to be a command to get grub to tell you its names for drives and what other names those drives have; but I can't seem to uncover it.

I'll go try your sequence of trials; and yes, I do know that Fedora calls everything sd instead of hd (though I hadn't gotten to that yet). What's more, I *think* some OS or other calls some of the EeePC drives hb ...

I did try editing hd(x,0) and sd(x,o) in the various combinations. No joy.

I also tried, from the grub command line, 'find /boot/vmlinuz' with variations leaving out one thing or another, or using initrd instead of vmlinuz. Also no joy.

I have it booting to Puppy now, to try the probepart and other command.

I'll also compare what gparted shows with wiat it shows on a PC which does triple-boot, and whose frontmost /boot/grub/grub.config I can display ....

# probepart
/dev/hdc1|ext3|401562
/dev/hdc2|ext2|7405964
/dev/sdb1|vfat|1993576
/dev/sda1|swap|2054554
/dev/sda2|ext2|5898060
/dev/sr0|iso9660|0
#

That is with Puppy on the 1 GB USB stick, and with a 4GB SD card in the right front corner. It's supposed to be the swap.

If I can save it to a file, maybe I can scp it to this machine, and then paste it into a message here. Maybe. Ssh and scp between this machine and the EeePC are none to happy ...

From your first post:

But F8 is messed up; I need to boot it init3 (I think) and can't figure how.

I ignored that, because I wasn't sure how it figures in.

• Presuming Fedora?
  
  Presuming it boots to the GUI and you want it to boot to the TUI
  
  Understanding that I'm unfamiliar with Fedora and equally unfamiliar with EeeDora as well as your computer. With all this understood.

I think in Fedora's /etc directory you will find a file called inittab. Open it with a text editor. Probably the 'default run level' is set to 5, edit and set it to 3 or 2, probably 3 is better. You'll probably need root permissions to do this.

------------------

Next where exactly are the GRUB support files installed? If you can tell me, do so by telling the GRUB system (hd0,0) and the Linux way of seeing things, /dev/hdc1

Hint: usually the support files are on some partition under /boot/grub

I've got the probepart output, next post a copy of menu.lst, maybe the one for Fedora

Are the GRUB files in the Fedora partition doing the booting?

I still in the dark about some things, but we're making progress. Try and answer as best as you can.

> Presuming Fedora?

Yes. I've been trying to cut it down enough to run on this machine; I have it installed on an 8 GB thumb drive -- which was not in the machine at the time I ran the probe.

> Presuming it boots to the GUI and you want it to boot to the TUI

Worse than that.When I put the thumbdrive in and tried to boot to it, booting failed; it still does, but in a different way.

It used to hit a point where it said something was spawning (or re-spawning) too fast, and it would wait five minutes; then it gave the same message every five minutes.

Now (also with the 8 GB thumb drive in) it gets as far as trying to find volume groups; fails, then fails to find /dev/root, or /dev, or /proc, or/sys. So setuproot fails, and mount fails.

I can still mount and read that thumb drive on a running machine; I may eventually try to modify it that way, if I can figure out what to add back in.

For now, though, I want to leave it aside. That means I can boot neither to it (can't anyway, because of pruning something I shouldn't've), nor to EeeDora (because grub doesn't know yet where it is) -- but only to puppy.

------------------

> Next where exactly are the GRUB support files installed? If you can tell me, do so by telling the GRUB system (hd0,0) and
the Linux way of seeing things, /dev/hdc1

> Hint: usually the support files are on some partition under /boot/grub

Well, I can't in those terms, but I think I can if you can stand a long-winded account.

When I installed Puppy this time, from a USB CD, I did manual partitioning, putting a small /boot partition and a large / partition on the hard drive -- and then accepted the option to put puppy onto the 1 GB thumbstick instead of the hard drive.

When I installed Fedora this time, I did much the same, using the 8GB thumb drive -- and started pruning.

At that point, the hard drive should still have been one big free partition, except for the boot partition.

Then, when I hosed Fedora (not for the first time, and in spite of pruning like an amorous porcupine), I installed EeeDora (also not for the first time) from the USB CD, and told it to take the hard drive -- but not to touch the boot sector.

When I now invoke gparted from puppy, I see /dev/hdc1 ext3, label /boot, with 196 MB (150 used), and /dev/hdc2 ext2, label /1, with 3.5 GB (1 used). I presume hdc2 must be eeedora -- as it certainly should.

If on a puppy termminal I now do "mount -t ext3 /dev/hdc1 /TEST," then "cd /TEST," then ls, then ls grub, I
see both menu.lst and grub.conf inside grub; and puppy tells me menu.lst is just a symlink to grub.conf. That's why I speak of it instead of menu.lst.

I can get into grub/grub.conf with mp -- thanks to yourself, earlier in this thread.

Notice, with /dev/hdc1 *labelled* /boot but *mounted* under /TEST, and with root in the working directory /TEST, I'm seeing not /boot/grub, but simply grub. Maybe that's obvious -- to those who know more than I.

Anyway, I'm pretty sure I want to add a section to grub.conf. Something with a title line saying eeedora -- but should it have a full panoply of entries? I don't want to lose it the first time the kernel gets updated -- something I understand grub is prone to ...

A testbed machine on my desk does triple-boot in this kind of way; I've been trying to clone it. I have already mounted /TEST on it, and done cd to grub there, then cat grub.conf.

It has a whole long wad of entries for one OS; but the other two have entries of much shorter form. Here's the latter end of that file :

title CentOS (2.6.18-53.el5xen)
root (hd0,0)
kernel /xen.gz-2.6.18-53.el5
module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/
module /initrd-2.6.18-53.el5xen.img
title Fedora
rootnoverify (hd0,2)
chainloader +1
title Ubuntu
rootnoverify (hd0,4)
chainloader +1
[root@localhost grub]#

So if you can tell me what to put in for hd(0,4) in the comparable file on the EeePC, using mp, I *think* it should work.

Am I making sense, after all this??

GRUB'S Menu:

title CentOS (2.6.18-53.el5xen)
root (hd0,0)
kernel /xen.gz-2.6.18-53.el5
module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/
module /initrd-2.6.18-53.el5xen.img

title Fedora
rootnoverify (hd0,2)
chainloader +1

title Ubuntu
rootnoverify (hd0,4)
chainloader +1
[root@localhost grub]#

Various comments:

hd0 means the first disk GRUB finds, usually it corresponds with Linux /dev/hda, but in your case hd0 would correspond with Linux /dev/hdc. At least that's what it appears from you probepart output, but there is no accounting for anything more than two Linux partitions on either the USB or IDE

The hard disk in mention is an internal IDE, I think? Please confirm.

It appears to me that you have been installing GRUB on the partition boot sector at least in part.

Allow me some lecture on theory if you please.

One must not confuse the MBR with a Boot Sector.

The MBR is sector zero (first sector on a hard disk)

The Boot Sector is logical sector zero (first sector on a partition)

Microsoft uses boot sectors, Linux doesn't. The chainloader +1 instructions say: execute the 'file' at first sector in the specified partition. This supposed 'file' is the 512 byte boot sector.

The fact that you are booting Linux using the chainloader command is what tells me that GRUB is/was installed there, at logical sector zero for the appropriate partition.

Is there something wrong with installing GRUB on the boot sector? No, it has some advantages, but it's not the conventional way of doing it, especially when running multiple OSes. Mostly it needs to be understood in terms of running multiple OSes.

Let me explain what would happen if you installed Puppy with GRUB on the boot sector.

Basically you would be booting the Microsoft way. That is run the code in the boot sector for the active partition which is what the standard MS type MBR does.

Suppose we installed Puppy on hdc1 which would be the first partition on what appears to be your first disk. Then we install GRUB on the boot sector. Our GRUB support files will be found at /dev/hdc1/boot/grub and /dev/hdc1 must be marked as the active or boot partition.

When you boot the computer this file will be displayed in a user friendly way by GRUB: /dev/hdc1/boot/grub/menu.lst

All your boot options for other operating systems as well as the Puppy on /dev/hdc1 will need be in /dev/hdc1/boot/grub/menu.lst

GRUB elsewhere (on other boot sectors) will not be used.

-----------------------------

Taking things some steps further.

Here is an outline of problems any of us will run into regardless of where we first installed GRUB, when we install multiple Linuxes.

Suppose we've installed Puppy on /dev/hdc1, now we want to install CentOS on /dev/hda2 and we've already prepared the disk with a Linux filesystem.

At some point CentOS will ask us if we want to install GRUB. Actually we don't because GRUB is already installed. But actually we do for the reason of seeing how CentOS wants to boot Linux. Look at the example below:

root (hd0,0)
kernel /xen.gz-2.6.18-53.el5
module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/
module /initrd-2.6.18-53.el5xen.img

We cannot Divine this is how CentOS wants to boot. If we tell it not to install GRUB, it probably won't install menu.lst and we won't have the booting instructions.

Suppose we tell it to install GRUB on the boot sector of hda2. When we reboot we will boot Puppy's menu.lst which doesn't have instructions for booting CentOS.

Why does Puppy get booted? The reason why is we have hdc1 marked as the active or bootable partition. Unless the CentOS marked hdc2 as the bootable partition, in that event we have the reverse situation. And we would have to use a partition software tool to mark hdc1 as the active partition.

Presuming we are still booting Puppy, then we want to mount hdc2 and copy the GRUB booting instructions for CentOS to Puppy's menu.lst

As long as you continue installing Linuxes as above on the boot sectors you'll do fine. You'll have far many more GRUBS installed than you will or can use, but what else to do in order to get the data on booting each Linux?

-------------------------------------------

More considerations

It appears that you are starting GRUB from some partition's boot sector, but which one?

I guess probepart didn't show the active partition.

fdisk -l (lower case L) will list the partitions and show the boot partition.

You can only have one bootable partition per disk. Fdisk will display the boot partition with a *

I'm making a strong presumption that you don't have GRUB installed on the MBR, rather on a boot sector. The bootable partition will contain your menu.lst or grub.conf file and that's the one responsible for sending instructions for all other OSes. For all intents and purposes that's the one you will need to be working with in order to boot all other Linuxes.

I hope you have found this theory helpful.

---------------------

I'll have more questions later.

But will you confirm which partition is booting and make sure you post that menu.lst? Which you may have done? Just confirm the booting partition.

In the meantime I'll re-read your post.

Meanwhile, I'm working on the rest of it -- and that raises a Zwischenfrage. ('Intermediate question' is about the closest Engliish has.)

To do this properly, I ought to be putting up a lot of stuff by c&p from the EeePC directly, not trying to retype it. But my trifocal fingers and arthritic eyeballs're not up to that.

The obvious solution is to use scp -- and there's the rub. I can ssh both ways, but when I try to scp from my main machine to get something from puppy that I can then post, it refuses the connection. It makes no difference whether I try to do it as root or as user.

A couple of times I've been able to do ssh; mostly not, and scp never.

Once, while I did have an ssh connection, I even ssh'd back, and tried to do the scp -- I've known that to work. But not this time.

All this despite the fact that both machines can browse into the router.

Since I can't scp between my PC and the EeePC, and also can't do serious typing on the latter, here -- maybe -- is an awkward workaround.

I have the EeePC also logged into this thread. I'll open a reply with it,and then -- I hope -- c&p the results of fdisk -l. With nothing else. Even highlighting is bad there, and I'm far from sure of any way to c&p; but maybe I can manage that much.

So if you see a post (probably next after this) with nothing else, that's what it is.

# fdisk -l

Disk /dev/hdc: 4001 MB, 4001292288 bytes
255 heads, 63 sectors/track, 486 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdc1 * 1 25 200781 83 Linux
/dev/hdc2 26 486 3702982+ 83 Linux

Disk /dev/sdb: 1021 MB, 1021125120 bytes
32 heads, 63 sectors/track, 989 cylinders
Units = cylinders of 2016 * 512 = 1032192 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 989 996788+ 6 FAT16

Disk /dev/sda: 4075 MB, 4075290624 bytes
126 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 7812 * 512 = 3999744 bytes


Device Boot Start End Blocks Id System
/dev/sda1 1 263 1027277+ 82 Linux swap
/dev/sda2 * 264 1018 2949030 83 Linux
#

... the post between the last *written* by me and this one *is* the requested output fromthe EeePC.

> Various comments:

> hd0 means the first disk GRUB finds, usually it corresponds with Linux /dev/hda, but in your case hd0 would correspond with Linux /dev/hdc. At least that's what it appears from you probepart output, but there is no accounting for anything more than two Linux partitions on either the USB or IDE

OK; so what is it going to *call* /dev/hdc?? (hd0,1)?? Didn't we try that? (If so, only with grub's editor, and maybe wrongly; I'm for editing it actually into the file with mp, backing out, and rebooting.)

> The hard disk in mention is an internal IDE, I think? Please confirm.

Puppy says so. (It also says it's a Celeron, whereas it's know to be some sort of solid state drive.) The owner's manual actually does not give hardware specs. Puppy says, agreeing with other distros I've triied, that it's a siliconmotion SM223AC

> It appears to me that you have been installing GRUB on the partition boot sector at least in part.

So I believe,yes; I certainly tried to do it that way.

> Allow me some lecture on theory if you please.

> One must not confuse the MBR with a Boot Sector.

> The MBR is sector zero (first sector on a hard disk)

> The Boot Sector is logical sector zero (first sector on a partition)

> Microsoft uses boot sectors, Linux doesn't. The chainloader +1 instructions say: execute the 'file' at first sector in the specified partition. This supposed 'file' is the 512 byte boot sector.

> The fact that you are booting Linux using the chainloader command is what tells me that GRUB is/was installed there, at logical sector zero for the appropriate partition.

> Is there something wrong with installing GRUB on the boot sector? No, it has some advantages, but it's not the conventional way of doing it, especially when running multiple OSes. Mostly it needs to be understood in terms of running multiple OSes.

> Let me explain what would happen if you installed Puppy with GRUB on the boot sector.

> Basically you would be booting the Microsoft way. That is run the code in the boot sector for the active partition which is what the standard MS type MBR does.

I dislike the sound of that. otoh, I've been known to render a machine completely unusable by messing up an MBR -- and I'm quite sure that my testbed machine, running CentOS, Fedora, and Ubuntu, does its booting from a boot partition, which I created for the purpose. I have endeavored to repeat that whole install process on the EeePC -- because it's the only one I've succeeded with.

> Suppose we installed Puppy on hdc1 which would be the first partition on what appears to be your first disk.

I'm quite sure puppy is in fact on the 1 GB thumb drive, *not* on the hard drive (nor yet the 4 GB SD card -- that's swap). And I believe /dev/hdc2, when we get to it, willprove to be EeeDora.

> Then we install GRUB on the boot sector. Our GRUB support files will be found at /dev/hdc1/boot/grub and /dev/hdc1 must be marked as the active or boot partition.

> When you boot the computer this file will be displayed in a user friendly way by GRUB: /dev/hdc1/boot/grub/menu.lst

> All your boot options for other operating systems as well as the Puppy on /dev/hdc1 will need be in /dev/hdc1/boot/grub/menu.lst

That's the way of it on the testbed PC; I boot at will from any one OS to any other, and always update at once; all the kernels have been updated at least once.

> GRUB elsewhere (on other boot sectors) will not be used.

There I have my doubts, but don't know how to check ...
-----------------------------

> Taking things some steps further.

> Here is an outline of problems any of us will run into regardless of where we first installed GRUB, when we install multiple Linuxes.

> Suppose we've installed Puppy on /dev/hdc1, now we want to install CentOS on /dev/hda2 and we've already prepared the disk with a Linux filesystem.

> At some point CentOS will ask us if we want to install GRUB. Actually we don't because GRUB is already installed. But actually we do for the reason of seeing how CentOS wants to boot Linux.

Yup. Catch-22. I was stymied dead in the water at that point, till a kind soul on a local LUG instructed me in mounting the boot partition (a/o any other) to a test directory, changing to it, and editing at will there.

That's why I think the machine does in fact use grub four times, or in four places; each OS keeps track of its own current kernel, and thus the overall boot partition gets by with only one.

> Look at the example below:

root (hd0,0)
kernel /xen.gz-2.6.18-53.el5
module /vmlinuz-2.6.18-53.el5xen ro root=LABEL=/
module /initrd-2.6.18-53.el5xen.img

> We cannot Divine this is how CentOS wants to boot. If we tell it not to install GRUB, it probably won't install menu.lst and we won't have the booting instructions.

> Suppose we tell it to install GRUB on the boot sector of hda2. When we reboot we will boot Puppy's menu.lst which doesn't have instructions for booting CentOS.

Iirc, in fact the testbed could not boot to more than one OS till I put it through the mounting and editing procedure, adding grub entries from the others.

> Why does Puppy get booted? The reason why is we have hdc1 marked as the active or bootable partition. Unless the CentOS marked hdc2 as the bootable partition, in that event we have the reverse situation. And we would have to use a partition software tool to mark hdc1 as the active partition.

> Presuming we are still booting Puppy, then we want to mount hdc2 and copy the GRUB booting instructions for CentOS to Puppy's menu.lst

> As long as you continue installing Linuxes as above on the boot sectors you'll do fine. You'll have far many more GRUBS installed than you will or can use, but what else to do in order to get the data on booting each Linux?

-------------------------------------------

> More considerations

> It appears that you are starting GRUB from some partition's boot sector, but which one?

Looking at the display in Gparted on the EeePC, I believe /dev/hdc1. It's the first of two partitions on the hard drive; it's so labelled; it's the right size; and finally, there is the result of the mounting.

> I guess probepart didn't show the active partition.

> fdisk -l (lower case L) will list the partitions and show the boot partition.

> You can only have one bootable partition per disk. Fdisk will display the boot partition with a *

> I'm making a strong presumption that you don't have GRUB installed on the MBR, rather on a boot sector. The bootable partition will contain your menu.lst or grub.conf file and that's the one responsible for sending instructions for all other OSes. For all intents and purposes that's the one you will need to be working with in order to boot all other Linuxes.

I concur -- and I think my next post, from the EeePC, showing the process of mounting /dev/hdc1 and its contents, will enable us to prove that.

> I hope you have found this theory helpful.

Very much so. many thanks!
---------------------

> I'll have more questions later.

> But will you confirm which partition is booting and make sure you post that menu.lst? Which you may have done? Just confirm the booting partition.

Stay tuned. Next post, from the EeePC, will drill down to grub.conf on /dev/hdc1 and cat its contents. Comin atcha shortly.

> In the meantime I'll re-read your post.

# mount -t ext3 /dev/hdc1 /TEST
mount: mounting /dev/hdc1 on /TEST failed
# cd
# umount /TEST
# mount -t ext3 /dev/hdc1 /TEST
# cd /TEST
# ls
config-2.6.23.14-107.fc8 lost+found System.map-2.6.23.14-107.fc8
grub memtest86+-1.70 vmlinuz-2.6.23.14-107.fc8
initrd-2.6.23.14-107.fc8.img puppy301Eee
# cd grub
# ls
device.map grub.conf minix_stage1_5 stage2
e2fs_stage1_5 iso9660_stage1_5 reiserfs_stage1_5 ufs2_stage1_5
fat_stage1_5 jfs_stage1_5 splash.xpm.gz vstafs_stage1_5
ffs_stage1_5 menu.lst stage1 xfs_stage1_5
# cat grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title Fedora (2.6.23.14-107.fc8)
root (hd0,0)
kernel /vmlinuz-2.6.23.14-107.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.23.14-107.fc8.img

title Puppy Linux 301 frugal
rootnoverify (hd0,0)
kernel /puppy301Eee/vmlinuz pmedia=ided psubddir=puppy301Eee
initrd /puppy301Eee/initrd.gz

title EeeDora
rootnoverify (hd0,0)
chainloader +1
#

.... with mp, making only a single change, (hd0,1) instead of (hd0,0) for EeeDora.

It failed.

I notice, though, that there's an extra blank line or two above the word EeeDora. Could *that* be the problem? Grub giving up before it finds the direction??

Or am I barking up the wrong tree yet again?? <sigh>

I got into grub.conf one more time; there were no extra lines above the EeDora line. I disremember now whether it was showing (hd0,1) or (hd1,0) ; but I reversed it to the other one, unmounted, and rebooted. Now at least I get a new (and very enigmatic, if not contradictory) error message.

Invalid System Disk
Replace the disk, and then Press Any Key

Seems as how hd<whatever> is not the hard drive after all, and it's seeing something else.

I have the 1 GB thumb drive and the 4 GB SD card in the machine. I'll try (later) taking each out, then both.

Sorry I've been unavailable.

I suppose booting to the hard disk hdc and using grub files and menu.lst on hdc1 is the best way to manage the booting for all your other Linux installations.

Make sense?