LinuxQuestions.org - booting 13.37 install off usb stick, and getting panic

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - booting 13.37 install off usb stick, and getting panic (https://www.linuxquestions.org/questions/slackware-14/booting-13-37-install-off-usb-stick-and-getting-panic-4175412922/)

booting 13.37 install off usb stick, and getting panic

I'm tyring to boot Slackware 13.37 install, on a USB stick, on a i7 machine I am building.

The machine boots off harddrive with slack install.
The machine boots clonezilla off a USB stick.
The machine crashes with a kernel panic when booting the 13.37 install system. The panic starts after the opportunity to input boot parameters.

Does this ring any bells?

The processor is a Intel 3770 and the MB is a GA Z77 D3H.

Thanks for any thoughts.

I will continue to mess around.

Still investigating, but it appears that neither the harddrive or the SSD are recognized by Clonezilla.

It also appears that the USBstick boot of Slackware crashing with a kernel panic may be the result of the UEFI bios on this motherboard. At first blush, apparently Slackware does not recognize the hardware, because it was not built to include the EFI library.

I don't have a CD on this system, but I can see that perhaps I should get a CD/DVD reader because I don't see a short path. I will most likely have to modify the install DVD, and all this will probably take quite a few iterations. Agh.

Stay tuned. And I welcome any ideas. I'm sure this can be done, and I am not sure I have a good analysis of the problem.

I am a bad boy for not consulting the compatible hardware list. Eventually, it wouldn't matter. New MBs new BIOS, it's just the cycle of life.

Meanwhile, I took the HD and the SSD and placed in a 775 chipset system I had, which booted right up with a Clonezilla USBstick boot, and also booted with a Slackware DVD copy on a USB stick. Harumph, I guess the says of easy bootsticks are over.

Well, I cloned the HD onto the SSD, MD5SUMed them, and then booted the SSD drive, just to convince me that it works OK. Then I put the SSD drive into the new system, and it boots to the Slackware splash page and then goes black. Sounds like Linux is unable to live a normal life on that system.

Searching LinuxQuestions, I found that some have luck running with UEFI. Others don't. My simplistic assumption is that not all UEFIs are created equal.

Well, that's the update for tonight. I really home that someone who has the same MB I do, GA Z77 H3D chimes in and says "No problem linuxbird, you just need to configure the UEFI BIOS like this, and bingo, everything works." Somehow, I am not optimistic. Change my day.

Quote:

Originally Posted by linuxbird (Post 4709824)

Then I put the SSD drive into the new system, and it boots to the Slackware splash page and then goes black.

The lilo splash? Ok, so then this system is already configured to provide a BIOS compatibility layer (otherwise you couldn't have had lilo come up).

Just a guess but perhaps the reason for the black screen is due to the lack of EFI Framebuffer support in the kernel (since Slackware does not have this enabled by default). If this suspicion is correct, you should be able to wait until you think booting has complete and login blind, then (assuming you have X and a window manager installed) type startx. At this point the X driver for your video card should take over from the Framebuffer and you should hopefully see something. Alternatively if that is difficult to do or you don't have X but do have network and sshd configured on startup you could try sshing into the machine from another machine on your network to check that Slackware is actually running.

If this is the problem the simple work around is to have Slackware start in runlevel 4 by customising /etc/inittab. The only downside is that you will miss the boot sequence and won't have access to your virtual terminals. The best solution however would be to recompile the kernel with EFI Framebuffer support (CONFIG_FB_EFI=y).

In case you don't solved your probleme, I've recently try to boot a rsync backup of my systeme on a usb boot stick and encounter a kernel panic, to solve it i have to build a Generic Kernel initrd following README.initrd and add some delay to the usb device to boot, also include some usb module in the initrd:

using mkinitrd -F:

Code:

# mkinitrd.conf.sample

# See "man mkinitrd.conf" for details on the syntax of this file

#

SOURCE_TREE="/boot/initrd-tree"

CLEAR_TREE="0"

OUTPUT_IMAGE="/boot/initrd.gz"

KERNEL_VERSION="$(uname -r)"

KEYMAP="fr"

MODULE_LIST="ext4:uas:usb_storage:ehci-hcd:uhci-hcd:ohci-hcd:mbcache:jbd2"

#LUKSDEV="/dev/sda2"

#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"

#ROOTDEV="/dev/sda1"

ROOTDEV="UUID=fe2f192c-7764-423b-9a1d-8dabe4279fb5"

ROOTFS="ext4"

#RESUMEDEV="/dev/sda2"

RAID="1"

LVM="1"

UDEV="1"

#MODCONF="0"

WAIT="10"

my lilo.conf:

Code:

# LILO configuration file

# generated by 'liloconfig'

#

# Start LILO global section

lba32 # Allow booting past 1024th cylinder with a recent BIOS

# Append any additional kernel parameters:

append=" vt.default_utf8=1 label=usb-bkp"

boot = /dev/sda



# Boot BMP Image.

# Bitmap in BMP format: 640x480x8

bitmap = /boot/slack.bmp

# Menu colors (foreground, background, shadow, highlighted

# foreground, highlighted background, highlighted shadow):

bmp-colors = 255,0,255,0,255,0

# Location of the option table: location x, location y, number of

# columns, lines per column (max 15), "spill" (this is how many

# entries must be in the first column before the next begins to

# be used. We don't specify it here, as there's just one column.

bmp-table = 60,6,1,16

# Timer location x, timer location y, foreground color,

# background color, shadow color.

bmp-timer = 65,27,0,255

#

prompt

# Timeout before the first entry boots.

timeout = 120

# Override dangerous defaults that rewrite the partition table:

change-rules

reset

# VESA framebuffer console @ 1024x768x64k

vga = 791

# Normal VGA console

image = /boot/vmlinuz

  root = "LABEL=usb-bkp"

  initrd = /boot/initrd.gz

  label = USB-bkp

  read-only

# Linux bootable partition config ends

i use UUID and LABEL to boot on any sd[a,b,c, ect] the key boot on, and that's what take me most time searching/testing ;)

blkid /dev/sdX1 to get your UUID
e2label /dev/sdX1 usb-bkp to LABEL the key

I think Eeel raises a good point here that I missed as you have so many threads on this issue. I see in this one you mention USB booting. It may well be the fact that the kernel modules needed for USB booting are not available.

Read Slackware 13.37 installation on an external USB hard disk - nano how-to by Didier Spaier.

Quote:

Originally Posted by Eeel (Post 4714118)

Code:

# mkinitrd.conf.sample

# See "man mkinitrd.conf" for details on the syntax of this file

#

SOURCE_TREE="/boot/initrd-tree"

CLEAR_TREE="0"

OUTPUT_IMAGE="/boot/initrd.gz"

KERNEL_VERSION="$(uname -r)"

KEYMAP="fr"

MODULE_LIST="ext4:uas:usb_storage:ehci-hcd:uhci-hcd:ohci-hcd:mbcache:jbd2"

#LUKSDEV="/dev/sda2"

#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"

#ROOTDEV="/dev/sda1"

ROOTDEV="UUID=fe2f192c-7764-423b-9a1d-8dabe4279fb5"

ROOTFS="ext4"

#RESUMEDEV="/dev/sda2"

RAID="1"

LVM="1"

UDEV="1"

#MODCONF="0"

WAIT="10"

This was helpful, and reminded me to look at timing issues, which solved a problem related, but not the intent to this post. Thanks for passing on.

With respect to your using lilo, I think the use of elilo may be appropriate, in my instance, over lilo. I did find that there was another UEFI configuration which when I set, allowed me to get further in my boots.

I can now run the install kernel, but cannot actually accomplish an install, but that is in a different thread.

Thanks.