Recently I found this (for me) really usefull tool kexec which can load a new Kernel while running one.
I tested it some times with the same kernel I was running, "rebooting" the system without powering it off at any time
But I need kexec basically just for live usbs. I want to start a live USB within my running Linux, what works, but at one point it "exits" the loading process and give me a BusyBox...
It's something like
[xxxx] loading blablabla USB-Keyboard blablabla.
ALERT! does not exist. Returning to a shell.
BusyBox vX.xx
(initramfs)
This was working with the kernel on the main HDD that I was running, but won't work with my live-usb...
The idea behind that is that I want to check if the right USB-Stick is plugged in (checking UUID), then boot it and install the new system. Didn't get it to work over grub 2 and booting it with the BIOS isn't what I want (I want to boot one specific stick and not a hundreds others).
Anyone knows why it gives the the ALERT! ?
Thanks in advance!
greetz, alex
Knowing what "blablabla" actually said would be really, really useful. But if I had to guess?
There's a delay of 5 seconds between Linux detecting a USB storage device and Linux making it available, to let it "settle"(most USB doesn't need this, some really badly-behaved ones do); so it may be trying to mount devices that don't exist yet. Try adding rootdelay=10 to the kernel commandline, which will make it wait a bit. This parameter was created specifically for USB booting as I understand it.
Or if usb-storage is loaded in the initrd instead of being a builtin, you might add your own delay of a few seconds after there somewhere with sleep.
And it may also be that your USB kernel and your running one just don't agree on which device is which, especially since the order of module-loading can easily change it, and/or your USB kernel may not have detected your main disks at all depending on its configuration. For this reason you should be handling UUID inside the initrd, not outside it! When it crashes to the busybox prompt, try mounting sysfs on /sys/ to see what's in /sys/class/block/. That's your window into kernel block devices.
What devices it finds (or doesn't find) seems quite related to me! And the message might possibly mean something different than you think it means, but I can't tell that if you omit it or rephrase it according to your understanding of it. I know you can't copy/paste from a crashed terminal prompt, but still; paraphrased error messages are a big pet peeve of mine.
Finally I got time to test your suggestion.
But it doesn't change anything, it's still dropping to the BusyBox.
Here's everything I'm getting:
[ 2.425343] generic-usb 0003:0603:00F2.0002: input,hiddev96,hidraw1: USB HID v1.10 Device [NOVATEK USB Keyboard] on usb-0000:00:06.0-1.1/input1
[ 2.425417] usbcore: registered new interface driver usbhid
[ 2.425427] usbhid: v2.6:USB HID core driver
[ 2.428139] [drm] nouveau 000:03:00.0: 0x1191: parsing clock script 0
[ 2.429200] Console: switching to colour frame buffer device 160x64
[ 2.457653] usb 4-1.2: new low speed USB device using ohci_hcd and address 4
[ 2.578848] usb 4-1.2: configuration #1 chosen from 1 choice
[ 2.591682] input: Logitech USB-PS/1 Optical Mouse as /devices/pci000:00/000:00:06.0/usb4/4-1/4-1.2/4-1.2:1.0/input/input5
[ 2.592047] generic-usb 0003:046D:C050.0003: input,hidraw2: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:06.0-1.2/input0
[ 2.670624] usb 4-1.3: new low speed USB device using ohci_hcd and address 5
ALERT! does not exist. Dropping to a shell!
BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) _
There shouldn't be any typos...
Thanks for an answer!
Wow, "ALERT! does not exist" has to be the most useless error message I've ever heard. You have my sympathies.
Do you know what script produces that? Look inside that script and see what it was looking for. Maybe it's expecting some previously unknown variable and not getting it. Maybe it's supposed to print something between alert and does...
Please also review my earlier suggestions. looking in /sys/, fiddling with rootdelay, putting in sleep, etc. I'd add to that, building usb-storage into the kernel instead of making it a module.
I don't know which script produces that, it's part of the booting process of a Lubuntu Live USB-Stick (10.04) made with the universal USB installer. I'm not very familiar with this process...
I tried rootdelay but it didn't work, I'm trying sleep and other similar commands right now...
still doesn't work...
Everything seems mounted and working fine, every driver needed as loaded and it should just start the desktop...
I looked in /sys/class/block/ and there was a sdb and sdb1 folder whith all the stats my USB-Stick has, so I'm pretty sure /dev/sdb1 is the Stick from which I'm booting
You'll have to look into the boot scripts in that initrd to figure out why they're messing up. It'll all be started by a program named init, probably a shell script. Meanwhile you could try mounting and chrooting manually in the prompt, to see if that works at all. Something like
Can you fdisk -l ? What filesystem do you have on /dev/sdb1? It has to be something the kernel or the initrd supports. Best to build it into the kernel.
fdisk isn't implemented...
sdb1 is fat32 which is supported by the kernel.
It would really help if the ALERT! gives more information than " does not exist!"
I will try it again with other sticks, filesystems and linux versions. Maybe theres a problem not related to the live-system directly... I should be able to give more information on friday!
You're trying to boot linux from FAT32!? That's probably not going to work. It lacks nearly all the features of a proper UNIX filesystem. Security features prevent you from running any executables on it, too. How'd you ever install Linux in that?
Then you need to take a closer look at the USB stick's boot process. Just kexec-ing a kernel and mounting sdb1 might not be the way to go. It may be mounting some image inside the DOS filesystem or something. Or it may be running purely from some image in RAM for all I know. I really can't tell what it's doing from here but it's sounding weirder by the second.
I'm not convinced your device files in the initrd are even right. It's quite possible for the device file to exist but the device not to exist, which would cause 'invalid argument' or 'no such device'. Look under /sys/class/block/ and post what's there.
Good to know!
Would changing the filesystem change anything? It doesn't matter which I'm using I just had my Stick formatted in FAT32 and leaved it like that...
As said before I will try your suggestions friday, I don't have access to the system until then, sorry!
Depends entirely on what it's doing. But it doesn't sound like it's booting the normal linux way, there'd be trickery necessary to get a bootable Linux system out of a FAT32 partition.
What files are inside /dev/sdb1 ? I suspect there's a clutter of small inscrutiable files (bootloader stuff) and one great big file(disk image).
When the initrd crashes again, try cat /proc/filesystems to see what partition types your kernel really supports. Also try just running blkid to see what disks it thinks are really disks.
And the message might possibly mean something different than you think it means, but I can't tell that if you omit it or rephrase it according to your understanding of it. I know you can't copy/paste from a crashed terminal prompt, but still; paraphrased error messages are a big pet peeve of mine.
And I can't test it until mondey 
