Is `grub` black-magic?!

[no.to...@gmail.com]

Someone wrote that <grub's root is the partition containing /sbin/init>.

Check this log of my tests:-----------
-> grub> find *

Error 15: File not found

grub> find menu.lst

Error 15: File not found

grub> find /sbin/init
(hd0,4)
(hd0,6)
(hd1,2)
(hd1,4)
(hd1,5)
(hd1,13)
(hd1,15)
(hd2,1)
(hd2,2)
(hd2,4)
(hd2,34)
(hd2,35)
(hd2,36)
(hd2,37)
(hd2,38)
----------- end of log ----------

That's very clever: to find which partitions has these files, without even
mounting the partitions. And even the initial grub, before the system has
booted, claims to do this AFAIK. And I can confirm that some of those
listed are valid. But I'm wondering why it doesn't list (hd0,9) which is
the current-partition.

And I've confirmed that grub shows the `found` file's contents eg, by
-> cat /<fileID>

As I explained in another thread: if your CF is sdb and you plug other
USBstiks, the CF may become sdd. And you can't use `fdisk -l` yet
to see how the devices are identified, because linux is not yet running.
So I've put /id in each [installed] partition, so that grub could:
`find /id` & then it could 'cat (hdx,y)/id` to see the /id telling
"This is USBstik <ID>". But `find /id` fails. Why?

This whole grub thing seems like black-magic!

== TIA

[Martin]

On 04/22/2012 02:19 AM, no.to...@gmail.com wrote:

> This whole grub thing seems like black-magic!

That's why I use LILO. A boot loader bringing its own redundant file
system drivers is potentially problematic, as is a boot mechanism that
*requires* an initrd to complete the boot process.

[no.to...@gmail.com]

In article <jn0lmb$sk9$1...@online.de>, Martin <n...@spam.invalid> wrote:

> On 04/22/2012 02:19 AM, no.to...@gmail.com wrote:
>
> > This whole grub thing seems like black-magic!
>
> That's why I use LILO.
>

I didn't actively use LILO, like I put sugar in my coffee.
It's just that the package constructors some times used it.
I just did klikA, klikB.
But I did like LILO's simple/effective method of 4 stages of
confirmation-signals.

> A boot loader bringing its own redundant file
> system drivers is potentially problematic, as is a boot mechanism that
> *requires* an initrd to complete the boot process.

While I used other's old discarded PCs I had no trouble and when LILO
failed [mostly] I just used a fd0. But when USB and cheap semiconductors
arrived I was tempted to move to the bleeding-edge.

Apparently I didn't explain why it seems that you NEED a smart
live-editable loader like `grub` for the new hardware eg.
= a Win7 netbook can take a 8GB CF for linux for a few dollars;
= the Win7 may be /dev/sda1,2,3,4
= and Linux: CF may be sdb1,2...
= and later you might put an installation/S on USBstiks
= but if you plug 2 stiks, CF changes its NAME from sdb to sdd
= so your fixed LILO fails

The solution is to recognise the NEEDED power of a grub-like,
but to clean it up. And make proper documentation.

AFAIK if you set up LILO for the CF & 2 stiks to be plugged,
then if a stik got lost, the lilo settings would be invalid.
And you can't fix it without a running system.
Or ?

And since you know about file system drivers, which I don't,
can you diagnose the following:--
`grub` on CF:Debian-Etch with initrd.img CAN boot;
same `grub` for CF:Slak13 with no initrd fails with messageX;
same `grub` for USBstik:Slak-derivative with initrd.gz fails & mesgY

messageX & mesgY are to the effect <I can't load the required file;
I can only load FAT>.

I tried to inspect USBstik:Slak-derivative:initrd.gz to see if a script
would show what it was trying to do, just before the error message,
But I didn't succeed - yet.

== TIA.

[Robert Heller]

At Sun, 22 Apr 2012 16:58:43 +0000 (UTC) no.to...@gmail.com wrote:

>
> In article <jn0lmb$sk9$1...@online.de>, Martin <n...@spam.invalid> wrote:
>
> > On 04/22/2012 02:19 AM, no.to...@gmail.com wrote:
> >
> > > This whole grub thing seems like black-magic!
> >
> > That's why I use LILO.
> >
> I didn't actively use LILO, like I put sugar in my coffee.
> It's just that the package constructors some times used it.
> I just did klikA, klikB.
> But I did like LILO's simple/effective method of 4 stages of
> confirmation-signals.
>
> > A boot loader bringing its own redundant file
> > system drivers is potentially problematic, as is a boot mechanism that
> > *requires* an initrd to complete the boot process.
>
> While I used other's old discarded PCs I had no trouble and when LILO
> failed [mostly] I just used a fd0. But when USB and cheap semiconductors
> arrived I was tempted to move to the bleeding-edge.
>
> Apparently I didn't explain why it seems that you NEED a smart
> live-editable loader like `grub` for the new hardware eg.
> = a Win7 netbook can take a 8GB CF for linux for a few dollars;
> = the Win7 may be /dev/sda1,2,3,4
> = and Linux: CF may be sdb1,2...
> = and later you might put an installation/S on USBstiks
> = but if you plug 2 stiks, CF changes its NAME from sdb to sdd
> = so your fixed LILO fails

The senario seems to suggest that what is needed is for the USBstiks to
have a boot load system that 'behaves' like a CD/DVD rom boot or a
MS-DOS bootable floppy -- eg using SYSLINUX, using some sort of
self-referant boot loader. You probably don't want to use either Lilo OR
grub here -- you don't want to use either for any sort of 'removable
media' (such as CD/DVD-ROMs, USB drives, or floppies).

>
> The solution is to recognise the NEEDED power of a grub-like,
> but to clean it up. And make proper documentation.
>
> AFAIK if you set up LILO for the CF & 2 stiks to be plugged,
> then if a stik got lost, the lilo settings would be invalid.
> And you can't fix it without a running system.
> Or ?
>
> And since you know about file system drivers, which I don't,
> can you diagnose the following:--
> `grub` on CF:Debian-Etch with initrd.img CAN boot;
> same `grub` for CF:Slak13 with no initrd fails with messageX;
> same `grub` for USBstik:Slak-derivative with initrd.gz fails & mesgY
>
> messageX & mesgY are to the effect <I can't load the required file;
> I can only load FAT>.
>
> I tried to inspect USBstik:Slak-derivative:initrd.gz to see if a script
> would show what it was trying to do, just before the error message,
> But I didn't succeed - yet.
>
> == TIA.
>
>
>
>

--
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

[no.to...@gmail.com]

Yes, to run linux from a CF or Stik on this HP-mini, you need to <esc>
after <powerUp> to turn-off from the route to Win7. Then you're given
a `fdisk -l` equivalent-menu, showing the bootable-devices; which are
ordered in a sequence which is not understood by me.
Re. "self-referant": grub's first line needs to be edited to "hd(0,0)"
even if eg. you're booting from grub on sdd to the instalation on
sdc2.

> >
> > The solution is to recognise the NEEDED power of a grub-like,
> > but to clean it up. And make proper documentation.
> >
> > AFAIK if you set up LILO for the CF & 2 stiks to be plugged,
> > then if a stik got lost, the lilo settings would be invalid.
> > And you can't fix it without a running system.
> > Or ?
> >
> > And since you know about file system drivers, which I don't,
> > can you diagnose the following:--
> > `grub` on CF:Debian-Etch with initrd.img CAN boot;
> > same `grub` for CF:Slak13 with no initrd fails with messageX;
> > same `grub` for USBstik:Slak-derivative with initrd.gz fails & mesgY
> >
> > messageX & mesgY are to the effect <I can't load the required file;
> > I can only load FAT>.
> >
> > I tried to inspect USBstik:Slak-derivative:initrd.gz to see if a script
> > would show what it was trying to do, just before the error message,
> > But I didn't succeed - yet.
> >

There are multiple PROBLEMS here [and let's not PeeCee morph
them to "issues"]:-
1. with pluggable [SCSI apparently?] bootable-devices, they
arrange themselves, so that the original LILO/grub settings
become invalid.
2. there's potential confusion/incompatibility for the various
boot-stages: BIOS, LILO/grub, kernel, initrd; not being able
to read the SSSI-pluggable-devices. And Joe Rosevear' s post
}> I failed to mention that this CF uses a partition of type
}>
}> c W95 FAT32 (LBA)
}>
}> containing vfat file system. Grub can be a little picky about what
}> kinds of partitions and file systems it can read.
seem to confirm that.
PLUS, my Slak-based error messages say <I can only see FAT>.

It's worth noting that Debian-Etch can work around problem-1,
by a live-grub-edit, and it's krnl/initrd can apparently read the
semiconductor devices.

Perhaps I WILL put the required file on the Win7-FAT, as suggested
by the one error-mesg; but you'd want to keep your linux
installations separate from Micro$loth stuff. [It's called apartheid].
And a further new complication, is that the Win7 sda1,2,3,4 is
write-protect, from linux. How/why ?

I used to think that I was the only one using only old trash
PCs; so I hope some of this info gets up to the linux developers.

> > == TIA.

[Martin]

On 04/22/2012 06:58 PM, no.to...@gmail.com wrote:
> Apparently I didn't explain why it seems that you NEED a smart
> live-editable loader like `grub` for the new hardware eg.
> = a Win7 netbook can take a 8GB CF for linux for a few dollars;
> = the Win7 may be /dev/sda1,2,3,4
> = and Linux: CF may be sdb1,2...
> = and later you might put an installation/S on USBstiks
> = but if you plug 2 stiks, CF changes its NAME from sdb to sdd
> = so your fixed LILO fails

what exactly fails? There are three phases u need to keep apart: the
LILO install time, the LILO boot time, the kernel run time.

LILO boot time only knows BIOS devices and fixed sector numbers. There
is no such thing as /dev/sdb. The boot device is always assigned number
0x80 by the BIOS. I reckon, if BIOS device numbers change you will be
stuffed with any loader.

If your problem is mounting the root file system once the kernel has
taken control (and then indeed the name /dev/sdb might change to
/dev/sdd), you can override that at the LILO prompt.

Note however, that the root file system itself might contain fixed
references to partitions, like in /etc/fstab. But again, this is
unrelated to the boot loader.

> And since you know about file system drivers, which I don't,
> can you diagnose the following:--

unfortunately i cannot. I am not familiar with grub and have no idea why
it may fail in certain scenarios.