Can slakware 13 boot from a CF-partition?

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

I repeatedly tried to install Salkware13, from my DVD
to a ContactFlash, on a netbook.

It's really annoying after waiting all the time to be
told AT THE END that if you've got a USBstik ready;
IT can be setup as a booter.

I'm getting a <can't read the root partn/File & can only
see the Win7 sda1,2,3,4 partitions> ERROR mesg.

I crashed the Slak13 that I had installed on my PC
and was able to install a smaller-CD version of a
similar slak-based, called kongoni.

Here's what the 2 look like in comparison:
lrwxrwxrwx 1 root root 29 2011-04-18 17:41 vmlinuz -> vmlinuz-huge-smp-2.6.29.6-smp
-rw-r--r-- 1 root root 2386000 2009-08-17 08:18 vmlinuz-generic-2.6.29.6
-rw-r--r-- 1 root root 2495952 2009-08-17 07:20 vmlinuz-generic-smp-2.6.29.6-smp
-rw-r--r-- 1 root root 4768048 2009-08-17 08:32 vmlinuz-huge-2.6.29.6
-rw-r--r-- 1 root root 4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
== that's slak13, and the folowing is kogi:-----------
-rw-r--r-- 1 root root 2375866 2009-07-11 16:56 initrd.gz
-rw-r--r-- 1 root root 4907792 2009-07-11 16:56 vmlinuz
-----------------------------------------------------

I've got a minimal Debian Etch which I don't want to lose
because it allows me to edit files, and shows the partitons as:

sda1,2,3,4 is the Win7 stuff.
sdb1 = DebEtch
sdb2 = attempted slak13 install.
sdb3 = ? maybe a swap?
Obviously /dev/sdb is the CF.

I can't understand how `grub` achieves a fully editable
script, without loading linux! It's marvelous, so I don't
want to replace it by `lilo`. `grub` allows me to live-edit
various combinations of 'root' and 'kernel' and 'initrd' for
Etch & kogi & slak.

When I try to boot slak13, using kogi's kernel ? initrd
I get a more informative error message, directly:
that it can't handle SCSI ?!!

And if that was the case for the slak-kernel, it would
explain WHY slak too shows only the sda1,2,3,4 crap
available as root.

So I'm suspecting that, unlike Etch, slak can't boot from
a CompactFlash. Eg. only 'later' are the SCSI drivers loaded?

Please advise.

==TIA.

[Sylvain Robitaille]

On Mon, 16 Apr 2012 16:27:17 +0000 (UTC), no.to...@gmail.com wrote:

> So I'm suspecting that, unlike Etch, slak can't boot from
> a CompactFlash. Eg. only 'later' are the SCSI drivers loaded?

Booting is not distribution-specific. If one can do it, they all
can do it. Slackware can boot from any device that the system will
permit booting from, including USB disks, CF and SD cards, SSDs, etc.
It looks to me, though, like you haven't created an initrd for your
Slackware installation, thus it doesn't have access to the driver(s)
it needs to see the CF disk.

--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

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

In article <slrnjoou3...@charlotte.encs.concordia.ca>, Sylvain Robitaille <s...@alcor.concordia.ca> wrote:

> On Mon, 16 Apr 2012 16:27:17 +0000 (UTC), no.to...@gmail.com wrote:
>
> > So I'm suspecting that, unlike Etch, slak can't boot from
> > a CompactFlash. Eg. only 'later' are the SCSI drivers loaded?
>
> Booting is not distribution-specific. If one can do it, they all
> can do it.

By 'boot' I mean the total process from power-up till 'login'

>
> Slackware can boot from any device that the system will
> permit booting from, including USB disks, CF and SD cards, SSDs, etc.

The "system" being Slackware: that's my very question ??

> It looks to me, though, like you haven't created an initrd for your
> Slackware installation, thus it doesn't have access to the driver(s)
> it needs to see the CF disk.

That would have been my first guess too, thats's WHY I pasted
the <ls -l *linuz* *init*> which you've snipped.

Also this kogi, running NOW on the PC shows `ls -l`:
4907792 2009-07-11 16:56 /boot/vmlinuz
2375866 2009-07-11 16:56 /boot/initrd.gz
whereas looking into my slak13 on this PC:
-> ls /mnt/slak/boot/*init*
/mnt/slak/boot/README.initrd

So on the PC, where slak13 DOES boot, there's ALSO
no initrd. I think I read that slak13's HUGE kernel doesn't
need an <initrd>

But I guess that vmlinuz-huge-smp-2.6.29.6-smp
lacks the SCSI driver for the CompactFlash.

OK, let me check the PC's slak:/etc/lilo.conf to if *initrd*
is perhaps not in /boot.
It has only "image=..", no <initrd>

Oh crap, so has PC's kogi:/etc/lilo.conf !!
This is realy confusing: with PC & netbook;
kogi & slak; lilo & grub !!

[Sylvain Robitaille]

On Tue, 17 Apr 2012 06:17:49 +0000 (UTC), no.to...@gmail.com wrote:

>> Booting is not distribution-specific. If one can do it, they all
>> can do it.
> By 'boot' I mean the total process from power-up till 'login'

So do I.

>> Slackware can boot from any device that the system will
>> permit booting from, including USB disks, CF and SD cards, SSDs, etc.
> The "system" being Slackware: that's my very question ??

The "system" being "the hardware", as I'm referring to it. If the
hardware will boot from a CF drive, you can boot Slackware from the CF
drive on that system.

>> It looks to me, though, like you haven't created an initrd for your

>> Slackware installation, ...

>
> That would have been my first guess too, thats's WHY I pasted
> the <ls -l *linuz* *init*> which you've snipped.

There was no initrd in that listing from your Slackware installation,
thus my suggestion that you didn't create one.

> So on the PC, where slak13 DOES boot, there's ALSO no initrd.

Are you booting the PC from a CF drive? If not, the comparison isn't as
significant as you might believe.

> I think I read that slak13's HUGE kernel doesn't need an <initrd>

That may be true in most cases, but it might be worth your while to
check if there's a driver there that can see a CF drive as a SCSI disk
without loading any modules. I suspect it might still need an
additional module or more.

> But I guess that vmlinuz-huge-smp-2.6.29.6-smp
> lacks the SCSI driver for the CompactFlash.

I think that's a reasonable guess. I'd even say the evidence you've
presented points quite clearly in that direction.

> OK, let me check the PC's slak:/etc/lilo.conf to if *initrd*
> is perhaps not in /boot.
> It has only "image=..", no <initrd>
>
> Oh crap, so has PC's kogi:/etc/lilo.conf !!
> This is realy confusing: with PC & netbook;
> kogi & slak; lilo & grub !!

Best to stick with one combination and eliminate as many variables
as you can. Since you have it working on the PC, you don't need to
consider any combination that includes that, unless the PC's hardware
is identical to the netbook's.

What you want is to have the netbook working. I would concentrate
on Netbook+Slackware+LILO. You need to find out what modules are
required for the kernel to see your CF drive as a SCSI disk, make an
initrd that includes those, and point LILO to that initrd.

Other distributions won't help, other than they might help you
determine what's needed to make it work. But you can't compare
non-Slackware to Slackware and wonder why they don't behave the same.
The answer is simple: they don't behave the same because they aren't
the same. Still, what you're trying to do is certainly possible.

I hope I've helped.

[Joe Rosevear]

no.to...@gmail.com wrote:
> I repeatedly tried to install Salkware13, from my DVD
> to a ContactFlash, on a netbook.

How are you doing the install? Did you just copy a few files?

> It's really annoying after waiting all the time to be
> told AT THE END that if you've got a USBstik ready;
> IT can be setup as a booter.

Ah. I see that you ran the normal Slackware 13 install. Was this
Slackware 13.37 that you installed?

Where did you install to? Did you install Slackware to the netbook?

Why did you find the above annoying? Did you allow the Slackware
install to setup the USBstik (CF) as a booter? I would guess that you
did not. I think the process wipes your CF.

I haven't used the CF made by the Slackware install, but I have
made my own CF that boots Slackware 13.37 installed on a USB hard drive.

> I'm getting a <can't read the root partn/File & can only
> see the Win7 sda1,2,3,4 partitions> ERROR mesg.
>
> I crashed the Slak13 that I had installed on my PC
> and was able to install a smaller-CD version of a
> similar slak-based, called kongoni.
>
> Here's what the 2 look like in comparison:
> lrwxrwxrwx 1 root root 29 2011-04-18 17:41 vmlinuz -> vmlinuz-huge-smp-2.6.29.6-smp
> -rw-r--r-- 1 root root 2386000 2009-08-17 08:18 vmlinuz-generic-2.6.29.6
> -rw-r--r-- 1 root root 2495952 2009-08-17 07:20 vmlinuz-generic-smp-2.6.29.6-smp
> -rw-r--r-- 1 root root 4768048 2009-08-17 08:32 vmlinuz-huge-2.6.29.6
> -rw-r--r-- 1 root root 4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
> == that's slak13, and the folowing is kogi:-----------
> -rw-r--r-- 1 root root 2375866 2009-07-11 16:56 initrd.gz
> -rw-r--r-- 1 root root 4907792 2009-07-11 16:56 vmlinuz
> -----------------------------------------------------

Is the above what you have on your CF?

> I've got a minimal Debian Etch which I don't want to lose
> because it allows me to edit files, and shows the partitons as:
>
> sda1,2,3,4 is the Win7 stuff.

The above leads me to guess that you have Windows7 installed on your
netbook. Yes?

> sdb1 = DebEtch
> sdb2 = attempted slak13 install.
> sdb3 = ? maybe a swap?
> Obviously /dev/sdb is the CF.
>
> I can't understand how `grub` achieves a fully editable
> script, without loading linux! It's marvelous, so I don't
> want to replace it by `lilo`. `grub` allows me to live-edit
> various combinations of 'root' and 'kernel' and 'initrd' for
> Etch & kogi & slak.
>
> When I try to boot slak13, using kogi's kernel ? initrd
> I get a more informative error message, directly:
> that it can't handle SCSI ?!!
>
> And if that was the case for the slak-kernel, it would
> explain WHY slak too shows only the sda1,2,3,4 crap
> available as root.
>
> So I'm suspecting that, unlike Etch, slak can't boot from
> a CompactFlash. Eg. only 'later' are the SCSI drivers loaded?
>
> Please advise.
>
> ==TIA.
>

Here's what I have at the root of my CF. I use it, as I said to boot a
Slackware 13.37 system that is on a USB hard drive:

vvv
13.37 <A configfile that contains instructions for Grub.>
boot <A directory that the configfile refers to.>
^^^

Here is what is in file 13.37:

vvv
hiddenmenu
default 1
timeout 5


title JBD jango.2-jimel.1: krnl generic-2.6.37.6
root (hd1,0)
kernel /boot/13.37/vmlinuz-generic-2.6.37.6 (ro) box=any root=LABEL=120225aa2source
initrd /boot/13.37/initrd.gz

title JBD jango.2-jimel.1: krnl generic-smp-2.6.37.6
root (hd1,0)
kernel /boot/13.37/vmlinuz-generic-smp-2.6.37.6-smp (ro) box=any root=LABEL=120225aa2source
initrd /boot/13.37/initrd.gz
^^^

Here is what is in directory boot:

vvv
13.37 <This is a directory.>
jango <This is a directory, not needed by you.>
whiz <This is a directory, not needed by you.>
^^^

Here is what is in directory boot/13.37:

vvv
initrd.gz <I made this using mkinitrd.>
vmlinuz-generic-2.6.37.6 <I copied this from Slackware.>
vmlinuz-generic-smp-2.6.37.6-smp <I copied this from Slackware.>
^^^

To use this CF I first get to the Grub command line. You can do that
right?

Then I give a command like this:

root (hd1,0) <This tells grub where to find the CF.
It may be different on yours. You can type
root (hd
Then press tab to see what the choices are. That
use of tab is a great trick.>

Then I use a grub command, I think it is "configfile". You can get
help in Grub with the command "help" if you need to check this:

configfile /13.37

Now I am in the Grub menu defined by file 13.37, but it won't display
unless you pres Esc in the first five seconds. After five seconds
stanza 1 is run automatically. Note that the first stanza is 0.

I hope this gets you going. Are you using Legacy Grub or the new Grub?
I think I am using Legacy Grub. You may have to deal with changes if
you are using the new Grub.

-Joe

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

[Joe Rosevear]

Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:

[snip]

> Here's what I have at the root of my CF. I use it, as I said to boot a
> Slackware 13.37 system that is on a USB hard drive:

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.

> vvv
> 13.37 <A configfile that contains instructions for Grub.>
> boot <A directory that the configfile refers to.>

[snip]

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

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

> Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
>
> [snip]
>
> > Here's what I have at the root of my CF. I use it, as I said to boot a
> > Slackware 13.37 system that is on a USB hard drive:
>
> 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.
>

OK. I never considered that the problem is during *grub* reading
the partition/s. I assumed that grub handed over reading to slack
VERY early. But your suggestion seems confirmed, since kogi
[which is slak-based] wrote that <the critical dir could be placed
on Win: C:\bla-bla> and the slak-mesg listed the 4 Win7 partitions,
saying <these are the partitions which can be read>.

I was thinking of getting the same newer krnl like you, plus its
initrd, but I fear I'd still have the same problem.

I'm wondering why the older Debian Etch can boot.
Oh, BTW it's the DebEtch's grub which I'm using.

The 2nd partition on the CF was installed with slak13, via
the DVD, via one of the 3 USB connections of the netbook.

And I also installed kogi [slak-based around the same date as
slak13] onto a USBstik.

DebEtch, the only one which boots, can't `chroot` to the
2 slak-types, because "Fatal: kernel too old".

And I've got a Debian-Lenny on another stik: partition2.,
but which I can't get Etch-grub to boot, although it can
`chroot` to it.

Theoretically, I'd expect a proper grub to be able to
combine & test the 4 different <roots> with the 4
<knl+initrd> .

Can you remember the talk around slak13-days that
kernel-<HUGE> didn't need an initrd?
It's been suggested that initrd would be able to handle
the CF:ext2. But then WHY are you using CF:FAT32?

Since I once had good experiences with `loadlin`, I was
thinking of using that, but apparently FAT-resident
kernel is limited to 2MB?

IMO linux has got out of control.
I can't get individual packages for Debian which I was
dabbling in, because there's a zillion versions and platforms,
and a whole on-board data-base engine to manage the
package dependencies. It's like the Soviet Union economic
plannig machine.

== TIA.

[Joe Rosevear]

From: Joe Rosevear <Joe_Ro...@localhost.invalid>
Subject: Re: Re (2): Can slakware 13 boot from a CF-partition?
Newsgroups: alt.os.linux.slackware
References: <4f8de397$0$292$1472...@news.sunsite.dk> <jmnkk7$ja5$1...@dont-email.me>

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

[snip]

> OK. I never considered that the problem is during *grub* reading
> the partition/s. I assumed that grub handed over reading to slack
> VERY early. But your suggestion seems confirmed, since kogi
> [which is slak-based] wrote that <the critical dir could be placed
> on Win: C:\bla-bla> and the slak-mesg listed the 4 Win7 partitions,
> saying <these are the partitions which can be read>.

Can you get to a Grub command line? You can find out at the Grub
command line if Grub can read a CF.

> I was thinking of getting the same newer krnl like you, plus its
> initrd, but I fear I'd still have the same problem.

Use a kernel and initrd.gz that are compatible with your Slackware
installation. My kernel belongs to Slackware 13.37. I made a
compatible initrd.gz. I don't think Slackware comes with an initrd.gz
that is ready to use.

[snip]

> Theoretically, I'd expect a proper grub to be able to
> combine & test the 4 different <roots> with the 4
> <knl+initrd> .

Yes, I think tests can be made like that, but for each root you will
want to use a kernel and initrd.gz that are compatible with your
Slackware installation. It may satisfy your curiosity, but not much
good otherwise to mix them up.

> Can you remember the talk around slak13-days that
> kernel-<HUGE> didn't need an initrd?
> It's been suggested that initrd would be able to handle
> the CF:ext2. But then WHY are you using CF:FAT32?

Yes, I remember. That may be right, but I don't know how to do it with
Grub.

This may help you to understand...

Use

mount

or

blkid /dev/<partition such as "sda1">

to discover a *file system* type.

Use

fdisk -l /dev/<device such as "sda">

to learn a *partition* type. fdisk calls it "System" which I think is
misleading.

I used a *partition* of type "c W95 FAT32 (LBA)", because Grub can
read it. The Slackware that Grub boots is installed to an ext4 file
system in a partition of type "83 Linux". Grub can't read that one,
but it doesn't matter. It has the kernel and the initrd.gz. The
initrd.gz takes over from here.

> Since I once had good experiences with `loadlin`, I was
> thinking of using that, but apparently FAT-resident
> kernel is limited to 2MB?

It might help you to see what is in an initrd.gz.

I learned from Helmut Hullen (in this news group) that this will
extract the contents from an initrd.gz:

zcat <path to initrd.gz> | cpio -vim

and this will make an initrd.gz (as an alternative to using mkinitrd):

find . | cpio -o -H newc | gzip > <path to initrd.g>

If you do open up an initrd.gz, then look at file init. That is the
script that takes over from Grub and finishes the job.

The initrd.gz also contains lib/modules/<kernel version>. It contains
modules that init uses until it passes control to the Slackware
installation that you are booting.

> IMO linux has got out of control.
> I can't get individual packages for Debian which I was
> dabbling in, because there's a zillion versions and platforms,
> and a whole on-board data-base engine to manage the
> package dependencies. It's like the Soviet Union economic
> plannig machine.

Yes. Debian has a lot of packages, and Linux has been growing in
complexity. I hope it is all for good.

> == TIA.

You're welcome! Hope you can make some sense out of my ramblings.

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

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

Thanks Joe,
your idea of expanding initrd.gz and looking at init for the
error message, and seeing what was trying to be done THEN is good!

>
> It might help you to see what is in an initrd.gz.
>
> I learned from Helmut Hullen (in this news group) that this will
> extract the contents from an initrd.gz:
>
> zcat <path to initrd.gz> | cpio -vim
> and this will make an initrd.gz (as an alternative to using mkinitrd):
>
> find . | cpio -o -H newc | gzip > <path to initrd.g>
>
> If you do open up an initrd.gz, then look at file init. That is the
> script that takes over from Grub and finishes the job.
>
> The initrd.gz also contains lib/modules/<kernel version>. It contains
> modules that init uses until it passes control to the Slackware
> installation that you are booting.
>

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

zcat <path to initrd.gz> | cpio -vim

is a punishing journey and you don't want to see my massive
log of attempt at various combinations.
= on the PC's slak-based-kogi it gave "cpio: Malformed number"
and hung. Suspecting an oveflowed buffer/pipe, I tried on my
net-book which has a 2GB RAM [I think], and saw the expanded
dir-tree, with <the init script>.
I remember that I was not happy that the dir-tree had been
written to the dir of the initrd.gz, but I can't find the expanded
initrd.gz or re-create it!? Even with the assumption that the seen
one was created by live-CD and was thus written to RAM & lost.

An alternate approach to your suggestion is to:
<gunzip> initrd.gz | fold | \
<grep key-word in error message plus some lines before & after>
which should show what it was trying to do when it put the
error-message.

Perhaps someone can diagnose the problem from this manually
copied extract of the error-message:---
md: ..autorun DONE. VFS: Cannot open root device "812" or unknown-block(8,18)
...avaible paritions <sda1,2,3,4 <-- Win7 hard-disk> !!
------------------------------
Between Slak13 and Slak-kogi it complains about block(8,18) and block(0,0)
and it suggests that it only likes/finds-readable FAT-partitions.

== TIA

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

In article <slrnjor0m...@charlotte.encs.concordia.ca>, Sylvain Robitaille <s...@alcor.concordia.ca> wrote:

> On Tue, 17 Apr 2012 06:17:49 +0000 (UTC), no.to...@gmail.com wrote:
>
> >> Booting is not distribution-specific. If one can do it, they all
> >> can do it.
> > By 'boot' I mean the total process from power-up till 'login'
>
> So do I.
>

> -[snip]-

> > I think I read that slak13's HUGE kernel doesn't need an <initrd>
>
> That may be true in most cases, but it might be worth your while to
> check if there's a driver there that can see a CF drive as a SCSI disk
> without loading any modules. I suspect it might still need an
> additional module or more.
>
> > But I guess that vmlinuz-huge-smp-2.6.29.6-smp
> > lacks the SCSI driver for the CompactFlash.
>
> I think that's a reasonable guess. I'd even say the evidence you've
> presented points quite clearly in that direction.
>

> -[snip]-

>
> Best to stick with one combination and eliminate as many variables
> as you can. Since you have it working on the PC, you don't need to
> consider any combination that includes that, unless the PC's hardware
> is identical to the netbook's.
>
> What you want is to have the netbook working. I would concentrate
> on Netbook+Slackware+LILO. You need to find out what modules are
> required for the kernel to see your CF drive as a SCSI disk, make an
> initrd that includes those, and point LILO to that initrd.
>
> Other distributions won't help, other than they might help you
> determine what's needed to make it work. But you can't compare
> non-Slackware to Slackware and wonder why they don't behave the same.
> The answer is simple: they don't behave the same because they aren't
> the same. Still, what you're trying to do is certainly possible.
>

I can't afford the comfort of a single goal.
If that goal fails, there's no planB & planC to pay for the expensive
journey. Besides Debian-Etch /dev/sdd1 is the only one bootable,
to allow me to see the contents and experiment with `grub`, and
DebLenny @ sdc2 has got a working `mc` and `gpm` and `gpm`
doubles your power; kogi & sdb? has got a slak13-based initrd.gz,
and slak13 @ sdc3 is the goal. Real life is complex.

So I'm taking this thread to alt.os.linux.debian too and hoping
for some input from there.

== TIA.