Salix Forums

I installed a full Rat Poison edition of Salix OS on a SDHC card (sdb) for my EeePC 2g Surf (701). As I use GRUB to boot, I wanted to follow the process here. However, after I boot from the CD with

Code: Select all

hugesmp.s root=/dev/sdb1 rdinit= ro

, Salix starts loading gets a kernel panic when it can't find /dev/sdb1. I assume this is because the SD card isn't being mounted early enough during the boot process. Any ideas on how to modify the boot code so that /dev/sdb1 is detected and the system boots, so that I can install GRUB to the SD card?

A second question in this context, is that having reverted the internal HD to original state, but not wanting Win XP, how do I clear the master boot record on the internal HD? In case anyone is wondering, I returned the internal HD to it's original state with the OEM CD, because I wanted the original formatting configuration on the internal HD, with the special format partition that is part of the EeePC setup.

globetrotterdk wrote:A second question in this context, is that having reverted the internal HD to original state, but not wanting Win XP, how do I clear the master boot record on the internal HD? In case anyone is wondering, I returned the internal HD to it's original state with the OEM CD, because I wanted the original formatting configuration on the internal HD, with the special format partition that is part of the EeePC setup.

What's "original" to you? You can e.g. use fixmbr on Windows or lilo -M <dev> mbr|ext on linux to install a simple bootloader which is usually on factory disks.

globetrotterdk wrote:, Salix starts loading gets a kernel panic when it can't find /dev/sdb1. I assume this is because the SD card isn't being mounted early enough during the boot process. Any ideas on how to modify the boot code so that /dev/sdb1 is detected and the system boots, so that I can install GRUB to the SD card?

You don't need to modify any bootcode. Either you recompile the kernel with the modules needed to access your sd card built in. Or you generate an initrd with mkinitrd that contains those modules.

I think there's a way of going about it where you have /boot on the HD, so you are actually booting from that, but everything else including / is on the other medium/partition. I believe this used to be done quite commonly to get around some problem of limited address space. I'm not sure if it would work in this situation or if you would want to do it like that - but anyway, perhaps another possibility and easier than recompiling the kernel

mimosa wrote: I think there's a way of going about it where you have /boot on the HD, so you are actually booting from that, but everything else including / is on the other medium/partition. I believe this used to be done quite commonly to get around some problem of limited address space. I'm not sure if it would work in this situation or if you would want to do it like that - but anyway, perhaps another possibility and easier than recompiling the kernel

If there is NO device driver to access a device, you can't access that device. The problem you're mentioning ONLY affects BIOS and BOOTLOADERS using BIOS facitlities to access those devices.
If you don't know how to build a house and don't know anybody who could help you, you can't build a house. If there's somebody to help you (BIOS), you can.

Just putting the kernel on another device wouldn't solve the problem either. Obviously the system is able to load the kernel properly (--> kernel panic). The problem is that it's lacking drivers to access its root filesystem, which are on its root filesystem (--> chicken-egg-problem). Just moving /boot won't change anything. The drivers need to be loaded alongside the kernel image through BIOS facilities, which can access that device.

After all I never said you need to recompile the kernel. Actually it would be a last resort for me. Building an initrd is a whole lot easier, much more flexible and usually recommended:
http://slackware.osuosl.org/slackware-1 ... DME.initrd

Right so it seems that won't work in this case. Good luck Globetrotter!

Shador wrote:
globetrotterdk wrote:A second question in this context, is that having reverted the internal HD to original state, but not wanting Win XP, how do I clear the master boot record on the internal HD? In case anyone is wondering, I returned the internal HD to it's original state with the OEM CD, because I wanted the original formatting configuration on the internal HD, with the special format partition that is part of the EeePC setup.
What's "original" to you? You can e.g. use fixmbr on Windows or lilo -M <dev> mbr|ext on linux to install a simple bootloader which is usually on factory disks.

Original for me is the original OEM configuration as it was when I originally purchased the EeePC. The point being that I don't want any boot loader on the internal HD. If or when I get GRUB installed, it will be installed on the SD card where the Ratpoison system resides. That is where that "special partition" comes into play.

Shador wrote:
globetrotterdk wrote:, Salix starts loading gets a kernel panic when it can't find /dev/sdb1. I assume this is because the SD card isn't being mounted early enough during the boot process. Any ideas on how to modify the boot code so that /dev/sdb1 is detected and the system boots, so that I can install GRUB to the SD card?
You don't need to modify any bootcode. Either you recompile the kernel with the modules needed to access your sd card built in. Or you generate an initrd with mkinitrd that contains those modules.

So this isn't supported out of the box? This would imply that I need to remaster the install CD, to boot into my system, to install GRUB. That seems a little drastic.

Edit:
I still don't really understand this issue as there was support for the SD card from the system on the CD when I installed Salix OS 13.37 Ratpoison on the SD card in the EeePC. This would suggest to me that it is a question of when the SD card is mounted, and not whether the correct modules are loaded in the kernel.

globetrotterdk wrote:Original for me is the original OEM configuration as it was when I originally purchased the EeePC. The point being that I don't want any boot loader on the internal HD. If or when I get GRUB installed, it will be installed on the SD card where the Ratpoison system resides. That is where that "special partition" comes into play.

That is original then more or less. But you have no chance to get exactly that code into the mbr that was in there once you received it unless you made a backup. Anyway there is always some code/bootloader in the MBR or the drive is not bootable. By default that's usually a so called MBR loader which just scans all primary(/extended) partitions and boots the one marked as active. Exactly that code/bootloader is written by fixmbr or lilo -M.

globetrotterdk wrote:So this isn't supported out of the box? This would imply that I need to remaster the install CD, to boot into my system, to install GRUB. That seems a little drastic.

No, you just need to build an initrd, that's stored alongside your kernel. I posted the corresponding Slackware readme too. Instead of just loading the kernel when booting you need to load the initrd too.
Such an initrd is needed for any uncommon setup regarding block devices, encryption, filesystems, ... If you use the generic kernel it's needed for any hardware setup, so no unneeded code is built into the kernel.
Never said, you need to remaster the install cd and it's actually far from that.

Shador wrote:
globetrotterdk wrote:Original for me is the original OEM configuration as it was when I originally purchased the EeePC. The point being that I don't want any boot loader on the internal HD. If or when I get GRUB installed, it will be installed on the SD card where the Ratpoison system resides. That is where that "special partition" comes into play.
That is original then more or less. But you have no chance to get exactly that code into the mbr that was in there once you received it unless you made a backup. Anyway there is always some code/bootloader in the MBR or the drive is not bootable. By default that's usually a so called MBR loader which just scans all primary(/extended) partitions and boots the one marked as active. Exactly that code/bootloader is written by fixmbr or lilo -M.

The OEM CD "ghosted" an HD image over to the internal HD, so I would expect it to be an exact copy of the original system.

Shador wrote:
globetrotterdk wrote:So this isn't supported out of the box? This would imply that I need to remaster the install CD, to boot into my system, to install GRUB. That seems a little drastic.
No, you just need to build an initrd, that's stored alongside your kernel. I posted the corresponding Slackware readme too. Instead of just loading the kernel when booting you need to load the initrd too.
Such an initrd is needed for any uncommon setup regarding block devices, encryption, filesystems, ... If you use the generic kernel it's needed for any hardware setup, so no unneeded code is built into the kernel.
Never said, you need to remaster the install cd and it's actually far from that.

Sorry, your correct about having posted the info about initrd in response to mimosa's posts. I believe that there still is some confusion however, maybe I am not formulating myself clearly enough? I am having some difficulty wrapping my head around this.

The scenario is that I am trying to boot the kernel on the SD card from the install CD, so that I can install GRUB. Where is it that I would build the initrd? From the install CD? If it is from the SD card, that won't happen until I can get GRUB installed, at which time I don't believe that I will need it.

globetrotterdk wrote:The OEM CD "ghosted" an HD image over to the internal HD, so I would expect it to be an exact copy of the original system.

Why you're asking then?

globetrotterdk wrote:The scenario is that I am trying to boot the kernel on the SD card from the install CD, so that I can install GRUB. Where is it that I would build the initrd? From the install CD? If it is from the SD card, that won't happen until I can get GRUB installed, at which time I don't believe that I will need it.

You create it from within the install CD. Drop to a shell and chroot to the installed system. Then run mkinitrd with the appropriate arguments. From there you can install grub2, too. But you probably need to bind mount /proc, /sys and possibly /dev, before entering the chroot:

Code: Select all

mount /dev/sdXN /mnt
mount /dev/sdXM /mnt/home
...
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev # most likely you can omit this
chroot /mnt
mkinitrd ...
dhcpcd eth0 # or whatever to bring up your network
slapt-get -u
slapt-get -i grub2
grub-install /dev/sdX

That should be one way to do it.

Shador wrote:
globetrotterdk wrote:The OEM CD "ghosted" an HD image over to the internal HD, so I would expect it to be an exact copy of the original system.
Why you're asking then?

As I stated before, the only reason I did this was to restore the "special partition" on the internal HD. I am not interested in keeping Win XP and the MS boot loader on the internal HD.

Shador wrote:
globetrotterdk wrote:The scenario is that I am trying to boot the kernel on the SD card from the install CD, so that I can install GRUB. Where is it that I would build the initrd? From the install CD? If it is from the SD card, that won't happen until I can get GRUB installed, at which time I don't believe that I will need it.
You create it from within the install CD. Drop to a shell and chroot to the installed system. Then run mkinitrd with the appropriate arguments. From there you can install grub2, too. But you probably need to bind mount /proc, /sys and possibly /dev, before entering the chroot:
Code: Select all
mount /dev/sdXN /mnt
mount /dev/sdXM /mnt/home
...
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev # most likely you can omit this
chroot /mnt
mkinitrd ...
dhcpcd eth0 # or whatever to bring up your network
slapt-get -u
slapt-get -i grub2
grub-install /dev/sdX
That should be one way to do it.

Thanks. I found this about the Asus EeePC 701 (2g surf) card reader interface:

Booting from card without initrd

Let's say you decided to install Arch Linux on a card and compiled your own
kernel (or used the kernel26eee kernel) without initrd. Card reader on EeePC is
connected as an USB device. Unfortunately, USB storage devices are detected with
a delay, so we must tell the kernel to wait until this device becomes available.
You do this with "rootwait" option passed to kernel at boot time.

Does this give some hints about what module needs to be loaded in mkinitrd? It sounds to me like it would be the same procedure used to boot a system installed on a USB pen drive, should someone want to use GRUB rather than Lilo.

Salix Forums

(Solved) Kernel panic at boot from CD to install GRUB.

(Solved) Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.

Re: Kernel panic at boot from CD to install GRUB.