What modules are needed to use CF & USBstik?

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

This query applies to installations other than Slakware, so lets not
resort to foot-ball-hooligan-tribalism.

2 slak-family installations fail to boot from the CF, whereas
Debian-Etch does boot.

The one failing slak's initrd-script, at the fail-point reads:----
if [ "$DATA" = "" ]; then
# from= is not used or it didn't contain valid data
DATA=$(find_in_computer $LIVECDNAME/$SGN)
DATA=$(dirname $DATA 2>/dev/null)
if [ "$DATA" = "" ]; then fatal \
"$LIVECDNAME data not found.
You are maybe using an unsupported boot device (eg. SCSI or old PCMCIA).
Workaround: Copy the directory $LIVECDNAME from your boot device to an IDE/SATA
disk, eg. to /mnt/hda1/$LIVECDNAME or C:\\$LIVECDNAME. Then try to boot again."
--------------

So the problem is RERPORTED as "unsupported boot device: SCSI"

-> less README.initrd == ...
Here's another example: Build an initrd image using Linux 2.6.29.5
kernel modules for a system with an ext3 root partition on /dev/hdb3.
Note that you need the mbcache, jbd, and ext3 modules to use ext3:

mkinitrd -c -k 2.6.29.5 -m mbcache:jbd:ext3 -f ext3 -r /dev/hdb3
---------------------------------------------------------------

So how would you know that "you need the mbcache, jbd, and ext3 modules to use ext3"?
And what do you need to use CF & USBstik?

-> man mkinitrd.conf == ...
MODULE_LIST
This should be a colon-separated list of modules you wish to be
included in the initrd image.
Example: MODULE_LIST="ext3:mbcache:jbd"

WAIT This defines the time to wait, in seconds, until all disks are
detected.
This is useful for allowing extra time that might be needed for
slow usb disks or systems with large amounts of storage to become
ready.
If not defined, the default is 1 second.
--------------------------------

Based on the error mesage format, I'm also suspecting a timing problem.
The error trace looks like:
<found hard disk sda1 >
<found hard disk sda2 >
<some action which some times gets in here>
<found hard disk sda3 >
<found hard disk sda4 >

Is this semiconductor memory with so few lines, arranged like a
shift register, so that it's serial and not RAM, and needs more time?

== TIA.

[Dan C]

On Sun, 29 Apr 2012 20:39:19 +0000, no.top.post wrote:

> This query applies to installations other than Slakware, so lets not
> resort to foot-ball-hooligan-tribalism.

WTF is "Slakware", you ignorant fucking stooge?

Fuck off and die, troll.


--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he puked on Christopher Robin.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg

[Henrik Carlqvist]

no.to...@gmail.com wrote:
> This query applies to installations other than Slakware,

If so, please don't post your question to the Slackware NG. However,
reading on impies that the question might apply to Slackware rather than
other distribtions. If so, please stop your crossposting to those other
groups.

No, changing your username to "no.cross.post" will not help, exactly as it
once did not help to change the name to "no.top.post". Instead you will
need to understand what you are doing wrong, why it is considered wrong
and stop that behavior. I think that the web page
http://en.wikipedia.org/wiki/Crossposting might be a good start. It is
rather well written, however I disagree that multiposting would be
prefered. IMHO each question should only be posted to one relevant group.
If after a few days you get no reply it would be OK to post the same
question also in another group.

Usually, when I (by accident) reply to a message from you or any other
crossposted message I only answer to the group where I read your message.
That is, when too late find out that I am about to answer a crossposted
message. If I in time see that the message is crossposted I do not bother
to answer at all. This time I do answer to all groups to make sure that
you see what I write.

> so lets not resort to foot-ball-hooligan-tribalism.

This has nothing to do with which distribution to prefer for what reasons.
This is purely about netiquette.

> So how would you know that "you need the mbcache, jbd, and ext3 modules
> to use ext3"?

This question applies to any linux distribution. However, that is no
reason to post the question in every linux NG. The answer is:

fgrep ext3 /lib/modules/*/modules.dep

> And what do you need to use CF & USBstik?

This question applies only to your specific kernel. After you have choosen
your distribution you might choose from different versions of that
distribution. Once you have choosen your version of Slackware you might be
able to choose from different versions of the kernel and different
configurations of those version. The huge kernels usually require less
modules than the kernels optimized for size. Once you in the appropriate
NG tell which kernel you use or at least what functionality it has
compiled in you might get a good answer on which functionality is needed
as modules.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Joe Rosevear]

In alt.os.linux.slackware no.to...@gmail.com wrote:
> This query applies to installations other than Slakware, so lets not
> resort to foot-ball-hooligan-tribalism.
>
> 2 slak-family installations fail to boot from the CF, whereas
> Debian-Etch does boot.
>
> The one failing slak's initrd-script, at the fail-point reads:----
> if [ "$DATA" = "" ]; then
> # from= is not used or it didn't contain valid data
> DATA=$(find_in_computer $LIVECDNAME/$SGN)
> DATA=$(dirname $DATA 2>/dev/null)
> if [ "$DATA" = "" ]; then fatal \
> "$LIVECDNAME data not found.
> You are maybe using an unsupported boot device (eg. SCSI or old PCMCIA).
> Workaround: Copy the directory $LIVECDNAME from your boot device to an IDE/SATA
> disk, eg. to /mnt/hda1/$LIVECDNAME or C:\\$LIVECDNAME. Then try to boot again."
> --------------
>
> So the problem is RERPORTED as "unsupported boot device: SCSI"

I wish I could address this, but I'm not familiar with the code and
messages you are quoting above. The booting process has many steps
where things can go wrong. The above looks to me like it is coming
from problems with an init script in a initrd.gz for an OS that is not
Slackware, but that's all I can say about it.

> -> less README.initrd == ...
> Here's another example: Build an initrd image using Linux 2.6.29.5
> kernel modules for a system with an ext3 root partition on /dev/hdb3.
> Note that you need the mbcache, jbd, and ext3 modules to use ext3:
>
> mkinitrd -c -k 2.6.29.5 -m mbcache:jbd:ext3 -f ext3 -r /dev/hdb3
> ---------------------------------------------------------------
>
> So how would you know that "you need the mbcache, jbd, and ext3 modules to use ext3"?
> And what do you need to use CF & USBstik?

With this, however, I have some experience. Let me explain. The
answer to your question is (flagged) below, surrounded by a lot of
other needed explanation:

Put yourself in the viewpoint of the computer. Drives have partitions
and partitions have file systems. For the computer to read files it
must "understand" the file system. Grub has built into it code that
allows it to understand a few (but not all!) file systems. It's
different from Lilo in that way I think. What I understand is that
Lilo doesn't read files in this way, but instead "locates" them through
a map that was made earlier when lilo was run. This "locating" is
sufficient for booting in the way that was setup when lilo was run.

Grub doesn't do anything in advance like this, but instead has a built
in ability to understand certain file systems. It is limited in what
file systems it can read (bad), but with this ability it can actually
read files. On the fly! You don't need to tell it in advance what you
want to boot (good).

One problem that happens when booting with Grub is that partition names
change. I believe that the map that Lilo uses gets around that
problem. It refers to the map and not to a partition name when it
locates the kernel, initrd.gz, and the root directory.

Grub, on the other hand (I'm speaking of legacy Grub) needs to be told
where these things are. Instead of names like "sde3" it uses a name
like "(hd4,2)". I'll not go into that here, but these are really two
ways of saying the same thing. So the difference in terminology isn't
the issue. The issue is knowing the name of the device ("sde" or
"hd4"), since these names change from one instance of booting to
another.

Grub allows you to explore at the grub command line. The tab key and
the "configfile" command are helpful in this. With a little
exploration you can find the device name and make the changes to the
booting instructions as needed so Grub can find things and boot.

For everyday Grub booting, though, you want things to just work. I do
three things to accomplish this:

vvv

(1) I use partition labels. I label the partitions that grub needs to
find using e2label, and I fix the root system's fstab to refer to this
label ("LABEL=<label>" instead of "<device such as '/dev/hda1'>").
Labeling the root partition allows me to make a Grub config file (often
called "menu.lst") that will always work. Fixing fstab allows
Slackware to work. (Yes, Slackware needs to be told where it lives!
Look in your fstab.) You should do the same for any other partitions
that might not be located correctly, such as swap partitions.

A line in my menu.lst invokes the kernel and refers to the above label.
I sometimes use something like this:

kernel /vmlinuz-generic-2.6.37.6 (ro) root=LABEL=<label>

(You can also tell *mkinitrd* where root is. If you do and want to use
that location, then omit "root=<label>" above. If you do both, then
the above is used.)

It's an odd syntax to use "=" twice, but it works. This takes care of
locating the root directory, although it doesn't tell where the kernel
is. So the above line needs some help. See (2) below.

Note. It doesn't matter if Grub can understand the file system where
root resides. Grub runs the initrd.gz and the initrd.gz loads the
modules that were named when it was made using mkinitrd. These modules
(such as mbcache, jbd, and ext3) can have other purposes, but one
purpose *(here I will answer your question)* is to allow this line in
the init script of your initrd.gz to work:

mount -o ro -t $ROOTFS $ROOTDEV /mnt

I believe the modules are not needed when you use a huge kernel. This,
I believe, is because a huge kernel has *all* the modules compiled-in.
Modules augment a kernel's capability dynamically (so they don't have to
be compiled-in). Do not assume that a capability like "mount" is
always available. The kernel can only do it if it "understands" how.
The module "ext3" and perhaps others, for example, are needed to mount
an ext3 file system. I use these when I make an initrd.gz:


modules=ehci-hcd:uhci-hcd:ohci-hcd:usb-storage:usbhid:ext4:ext3:ext2:vfat:\
nls_cp437:nls_iso8859-1

The ehci, uhci and ohci-hcd plus usb-storage are needed because I want
to mount a root that is on a USB device. You don't need these if your
root is on an internal hard drive. This is true even if your kernel
and/or initrd.gz reside on a CF. We're talking just about mounting the
root.

I don't remember what usbhid is for. the ext4, ext3, ext2, and vfat
will allow you to mount a variety of different file systems. I don't
remember what the last two are for, but I don't think you will need
them.

When I make an initrd.gz I think about providing modules so init can
mount root at /mnt. I *also* think about what I may want to do if the
normal boot process goes to "rescue mode". This is basically a linux
command line that the init script opens. Slackware's init will do this
if it cannot mount root at /mnt. This will happen, for example, if you
fail to provide all the modules needed to mount it. You can also
request rescue mode by putting "rescue" on the boot line. Change the
kernel line in Grub's menu.lst to look like this:

kernel /vmlinuz-generic-2.6.37.6 (ro) root=LABEL=<label> rescue

(2) To locate the initrd.gz and the kernel I use a line like this in my
menu.lst:

root (cd)

This needs to come before the line above. It simple tells where "/"
is. (As in "/vmlinuz-generic-2.6.37.6...".) I boot from a CD which is
why I use this line. If you want to boot from a CF you'll need
something like "root (hd1,0). Be aware that this is not reliable. As
I explained way above, device names change. That is why I like to boot
from a CD. You can do it from a CF, but you may need to adjust the
"root" statement in your menu.lst, potentially every time you boot.
The new Grub (not legacy) may provide a solution to this.

Note. You may not know it, but a CD has a file system. It is called
iso9660. Grub can understand it. If instead you want to put your
kernel or your initrd.gz on a CF, then you may have to experiment to
find a file system (to use when you make your CF) that Grub can
understand.

(3) I use a line like this in my menu.lst to locate the initrd.gz:

initrd /initrd.gz

This comes after the line about the kernel and root.

^^^

[snip]

I guess I've droned on long enough. You're asking good questions. That
is to be commended! Stick with it, and you will learn how things work.
Take notes. I keep a directory full of lessons I've learned on
different linux subjects. It's like finding your way out of the
forest. Without a trail of bread crumbs, you're lost!

Good luck.

--
http://JosephRosevear.com
http://RosevearSoftware.com

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

In article <pan.2012.04.30....@deadspam.com>, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:

> no.to...@gmail.com wrote:
> > This query applies to installations other than Slakware,

---
This post contains ideas applicable to ALL distributions of linux.
...

> http://en.wikipedia.org/wiki/Crossposting might be a good start. It is
> rather well written, however I disagree that multiposting would be
> prefered. IMHO each question should only be posted to one relevant group.
> If after a few days you get no reply it would be OK to post the same
> question also in another group.

...
Does your 'reference' consider when the OP is an announcment/not-question?

> > so lets not resort to foot-ball-hooligan-tribalism.
>
> This has nothing to do with which distribution to prefer for what reasons.
> This is purely about netiquette.

...
Currently I uses only a minimalist USEnet-system; but before 1995, when I used
Win3:ForteAgent, IIRC it showed all posts that were cross-posted. And even
that <the post has already been read in another group> should be indicatable,
since the <same source number> is available?

> > So how would you know that "you need the mbcache, jbd, and ext3 modules
> > to use ext3"?
>
> This question applies to any linux distribution. However, that is no
> reason to post the question in every linux NG. The answer is:
>
> fgrep ext3 /lib/modules/*/modules.dep
>

What do you think about my idea, that although it's difficult,
knowledgable respondents should TRY to, instead of just
<playing the chord on the piano>, give an explanation like:
"linux distributions MUST have the <mapping of FS-type to
module used> and it's usually in modules.dep ?
Of course we acknowledge that just-playing-the-chord is a reflex.

> > And what do you need to use CF & USBstik?
>

Because you've snipped my relevant contexts, this non-trivial query
has become less understandable.

> This question applies only to your specific kernel. After you have choosen
> your distribution you might choose from different versions of that
> distribution. Once you have choosen your version of Slackware you might be
> able to choose from different versions of the kernel and different
> configurations of those version. The huge kernels usually require less
> modules than the kernels optimized for size. Once you in the appropriate
> NG tell which kernel you use or at least what functionality it has
> compiled in you might get a good answer on which functionality is needed
> as modules.
>

OK, but first I'd have to know if/that CF & USBstik are SCSI.
The error mesgs that I got from slak13, show that it's only seeing the
sda1,2,3,4 IDE of Win7, at that stage. AND the slak13-based version
specifically complains about <can't use SCSI; recommend copy the dir
to the C:\>

I'm guessing that up to the error-mesg, the BIOS was reading the CF
in the slak version; but in the Deb-Etch version, which can complete
booting, it has the ability to read CF existed in kernel/initrd.

The further complication, is that after booting via Deb-Etch, chroot
to slak and reading the USBstik & CF, would still be using Deb-Etch's
<device drivers>. Also, running all 3 distrubutions on different hardware
[an older PC, instead of the newer netbook] confirms that slak reads
USBstik [of course]. So what's the essential difference between
accessing the device before and after the OS is runing?
Isn't it about the transition between BIOS & initrd/kernel?

This query is definately NOT distribution specific; it goes right
down to kernel & hardware level and applies to ALL DISTRIBUTIONS.
It's definitely NOT a <which button must I press so that MY MODEL
of toaster works> type of question.

[Peter Köhlmann]

no.to...@gmail.com wrote:

> In article <pan.2012.04.30....@deadspam.com>, Henrik Carlqvist
> <Henrik.C...@deadspam.com> wrote:
>
>> no.to...@gmail.com wrote:
>> > This query applies to installations other than Slakware,
> ---
> This post contains ideas applicable to ALL distributions of linux.

No.
It is posted by you. So it contains pure, unadultered bullshit

[Henrik Carlqvist]

no.to...@gmail.com wrote:
>> http://en.wikipedia.org/wiki/Crossposting might be a good start.

> Does your 'reference' consider when the OP is an announcment/not-question?

Yes, absolutely. Even non-qeustions like an announcement promoting your
new software, some event or a service should be posted to one and only one
group with relevance.

I have another reference for you to consider:
http://en.wikipedia.org/wiki/Newsgroup_spam
Your crossposting does not make you any more popular than Laurence Canter
and Martha Siegel.

> What do you think about my idea, that although it's difficult,
> knowledgable respondents should TRY to, instead of just <playing the
> chord on the piano>,

I think that you as a questioner should be thankful for whatever answer
you get and in the hope of getting any more useful answers try to comply
to all the hints about netiquette that you get.

> This query is definately NOT distribution specific; it goes right down
> to kernel & hardware level and applies to ALL DISTRIBUTIONS.

As I said in my previous post. That is no reason to post in all
distribution newsgroups. It is not even a reason to post in 3 different
newsgroups.

Your trouble with your questions is that you get no useful answers.
Knowledgable people only frown upon your posts because of your behavior.
Instead of trying to reach more people with the same post in the hope of
finding some nice knowledgable person willing to answer you should try to
post in a way which does not make people upset. Crossposting to more
groups only makes more people more upset and results in flames instead of
useful answers.

[Keith Keller]

["Followup-To:" header set to comp.os.linux.misc.]

On 2012-05-01, no.to...@gmail.com <no.to...@gmail.com> wrote:
>
> Because you've snipped my relevant contexts, this non-trivial query
> has become less understandable.

GIGO

--keith



--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

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

In article <4f9f4f88$0$283$1472...@news.sunsite.dk>, Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:

> In alt.os.linux.slackware no.to...@gmail.com wrote:

Joe,

just a quick note to acknowledge your input, before I test your
recommendations.

> > The one failing slak's initrd-script, at the fail-point reads:----
> > if [ "$DATA" = "" ]; then
> > # from= is not used or it didn't contain valid data
> > DATA=$(find_in_computer $LIVECDNAME/$SGN)
> > DATA=$(dirname $DATA 2>/dev/null)
> > if [ "$DATA" = "" ]; then fatal \
> > "$LIVECDNAME data not found.
> > You are maybe using an unsupported boot device (eg. SCSI or old PCMCIA).
> > Workaround: Copy the directory $LIVECDNAME from your boot device to an IDE/SATA
> > disk, eg. to /mnt/hda1/$LIVECDNAME or C:\\$LIVECDNAME. Then try to boot again."
> > --------------
> >
> > So the problem is RERPORTED as "unsupported boot device: SCSI"
>

> The above looks to me like it is coming
> from problems with an init script in a initrd.gz for an OS that is not
> Slackware, but that's all I can say about it.

Normally I don't want to limit my knowledge to specific "models".
That trace is from something called Kongoni, which has mostly code
from <slax.org> which is CLEARLY based on Slakware -- our most
superior documented distro.

The kogi live & installable CD is more convenient & successfull that the
slak13-DVD that I've got. And when I tried to re-install Slak13 to
a <very high partition number> it messed my IDE <extended partition
chain>, so that those after hdX17 are no longer accessible.

The slak13 version hangs with a similar message & need battery
disconnect. Whereas kogi tells you to Ctrl/Alt/Del and gives you
`ash`. I think that's the initrd-mini-version.
And I was able to use that to mount a full version of slak13,
and I started investigating stuff like <pivot-root> which is going
too far.

> What I understand is that
> Lilo doesn't read files in this way, but instead "locates" them through
> a map that was made earlier when lilo was run. This "locating" is
> sufficient for booting in the way that was setup when lilo was run.

I'm going to think the process through and document it, bearing
in mind that:
at the BIOS stage the PC only knows how to:
read sector/s , which are passed in a register-pair
when it's passed 08 in reg A [H or L ?]
and interrupt 13hex is called.
I think, the location to write the sector/s to is also specifiable.
Right now my system/s are broken so I can't access my docos.

So apparently when LILO writes the eg. MBR, it can know,
at THAT time eg. at which sector /etc/lilo.conf starts.
And therefore the MBR bytes can be set to pass the correct
sector number to `INT 13`.

Having missed your post because of my broken system,
I had also yesterday posted
Newsgroups: comp.os.linux.misc
Subject: Can LILO do this too?
which you have mostly already anticipated, and
replied to.

Thanks,

== Chris Glur.

[Joe Rosevear]

In alt.os.linux.slackware no.to...@gmail.com wrote:
> In article <4f9f4f88$0$283$1472...@news.sunsite.dk>, Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
>
>> In alt.os.linux.slackware no.to...@gmail.com wrote:
>
> Joe,
>
> just a quick note to acknowledge your input, before I test your
> recommendations.

Thanks for the reply.

I can see the wheels turning in your head (if I use my imagination).

I'm not sure at this point what you are trying to do. Are you perhaps
wanting to install Slackware to a USB device and then boot it? If that
is what you want to do, then I can guide you.

Otherwise you're in territory mostly unknown to me.

> Thanks,

You're welcome.

> == Chris Glur.