Sponsored Content
Full Discussion: Kexec with Live USB/CD
Operating Systems Linux Kexec with Live USB/CD Post 302476350 by Corona688 on Wednesday 1st of December 2010 01:29:00 PM
Old 12-01-2010
Quote:
Originally Posted by al0x
Really?
It worked before.. xD
It's just a live usb and it works if I just plug it into my computer and boot it via BIOS Smilie
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.
 

9 More Discussions You Might Find Interesting

1. Linux

Live Knoppix on usb sdb2 kernel not found

Hi all I have a usb external drive with two partitions sdb1 ntfs and sdb2 ext3 with label Linux I copied a knoppix live distro in the second partition, then I installed grub on the drive. Now in the directory /media/sdb2/boot/grub i have the file device.map with the following content: (hd0) ... (4 Replies)
Discussion started by: guast
4 Replies

2. UNIX for Dummies Questions & Answers

From Knoppix Live-USB to Old-school CLI Debian Linux.

Alright. Here we go... The other day, I was referred to this neat little command-line Unix simulator called Cygwin. To put it lightly, I fell in love. I found Knoppix, and from what I can tell, it's a viable OS once I strip off the KDE desktop environment to make it 'old-school'. I'm... (2 Replies)
Discussion started by: dev_squid
2 Replies

3. UNIX for Dummies Questions & Answers

USB-USB cable between linux and windows computers

Is there an easy way to setup a cross-over cable (USB-USB) between a linux box and a windows PC? My 2 machines are next to each other but I really do not want to keep transfering my files using my USB drive. Thanks! (4 Replies)
Discussion started by: Xterra
4 Replies

4. Red Hat

How to install fedora 13 from a usb media....it should not like 'live'?

im using Dell Inspiron with windows 7 as operating system.....in my hard drive there is some 34 gb unpartitioned space and now i want to install fedora 13 into it, after installation it should be dual boot. problem here is... i have the fedora 13 image file ie fedora13-i386-DVD.iso file. ... (13 Replies)
Discussion started by: karthik437
13 Replies

5. UNIX for Dummies Questions & Answers

kcore and a live persistent linux usb distro

I have 2 computers, from now on i shall call these computers A and B. Made a live linux distro (bodhi) on A which has 1GB internal memory , because windows is unstable on B, which has 512MB internal memory. I mean with memory the internal memory of the computer, not the memory of the usb... (0 Replies)
Discussion started by: anno
0 Replies

6. BSD

Freebsd live usb

Hello. I'm going to make freebsd live usb based on FreeBSD-8.3-RELEASE-i386-livefs.iso. The iso is 257 Megabytes, but after i copy its content to usb drive its volume increases to 971 Megabytes. I tried different methods of copying (tar,cp,cpio) but with the same result. Could anyone help? (0 Replies)
Discussion started by: urello
0 Replies

7. Solaris

Usbcopy fails with the error message sol-11_1-live-x86.usb is not a multiple of 512

I am trying to create a live image of solaris 11.1. I have used #pkg image-update to upgrade from 11 to 11.1 already. (since only 11.1 can make images of 11.1 due to using new grub) then from within 11.1 I used pkg install install distribution-constructor to get latest usbcopy that should be... (1 Reply)
Discussion started by: taltamir
1 Replies

8. Solaris

Solaris 11 install via live usb

Hello All, I am attempting to boot and install Solaris 11 via live USB on a HP DL580 Gen9 Server. Unfortunately, when I do this it boots into System Maintenance Mode. The attachment (Pic1) shows what I am seeing via the console. The BIOS is in UEFI boot. Does not work on legacy mode as I... (15 Replies)
Discussion started by: Kerbi
15 Replies

9. What is on Your Mind?

Update: UserCP Screeching Frog 0.7641 - Changed Live Chat to Live Updates

Update: UserCP Screeching Frog 0.7641 - Changed Live Chat to Live Updates In this version of the UserCP, I have changed "Live Chat" to "Live Updates" by disabling the ability to post in the "live chat" area and changed the name to "Live Updates" The reason for this change is that experienced... (6 Replies)
Discussion started by: Neo
6 Replies
BOOTUP(7)                                                             bootup                                                             BOOTUP(7)

NAME
bootup - System bootup process DESCRIPTION
A number of different components are involved in the system boot. Immediately after power-up, the system BIOS will do minimal hardware initialization, and hand control over to a boot loader stored on a persistent storage device. This boot loader will then invoke an OS kernel from disk (or the network). In the Linux case, this kernel (optionally) extracts and executes an initial RAM disk image (initrd), such as generated by dracut(8), which looks for the root file system (possibly using systemd(1) for this). After the root file system is found and mounted, the initrd hands over control to the host's system manager (such as systemd(1)) stored on the OS image, which is then responsible for probing all remaining hardware, mounting all necessary file systems and spawning all configured services. On shutdown, the system manager stops all services, unmounts all file systems (detaching the storage technologies backing them), and then (optionally) jumps back into the initrd code which unmounts/detaches the root file system and the storage it resides on. As a last step, the system is powered down. Additional information about the system boot process may be found in boot(7). SYSTEM MANAGER BOOTUP
At boot, the system manager on the OS image is responsible for initializing the required file systems, services and drivers that are necessary for operation of the system. On systemd(1) systems, this process is split up in various discrete steps which are exposed as target units. (See systemd.target(5) for detailed information about target units.) The boot-up process is highly parallelized so that the order in which specific target units are reached is not deterministic, but still adheres to a limited amount of ordering structure. When systemd starts up the system, it will activate all units that are dependencies of default.target (as well as recursively all dependencies of these dependencies). Usually, default.target is simply an alias of graphical.target or multi-user.target, depending on whether the system is configured for a graphical UI or only for a text console. To enforce minimal ordering between the units pulled in, a number of well-known target units are available, as listed on systemd.special(7). The following chart is a structural overview of these well-known units and their position in the boot-up logic. The arrows describe which units are pulled in and ordered before which other units. Units near the top are started before units nearer to the bottom of the chart. local-fs-pre.target | v (various mounts and (various swap (various cryptsetup fsck services...) devices...) devices...) (various low-level (various low-level | | | services: udevd, API VFS mounts: v v v tmpfiles, random mqueue, configfs, local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...) | | | | | \__________________|_________________ | ___________________|____________________/ |/ v sysinit.target | ____________________________________/|\________________________________________ / | | | | | | | | v v | v v (various (various | (various rescue.service timers...) paths...) | sockets...) | | | | | v v v | v rescue.target timers.target paths.target | sockets.target | | | | v \_________________ | ___________________/ |/ v basic.target | ____________________________________/| emergency.service / | | | | | | v v v v emergency.target display- (various system (various system manager.service services services) | required for | | graphical UIs) v | | multi-user.target | | | \_________________ | _________________/ |/ v graphical.target Target units that are commonly used as boot targets are emphasized. These units are good choices as goal targets, for example by passing them to the systemd.unit= kernel command line option (see systemd(1)) or by symlinking default.target to them. timers.target is pulled-in by basic.target asynchronously. This allows timers units to depend on services which become only available later in boot. BOOTUP IN THE INITIAL RAM DISK (INITRD) The initial RAM disk implementation (initrd) can be set up using systemd as well. In this case, boot up inside the initrd follows the following structure. The default target in the initrd is initrd.target. The bootup process begins identical to the system manager bootup (see above) until it reaches basic.target. From there, systemd approaches the special target initrd.target. Before any file systems are mounted, it must be determined whether the system will resume from hibernation or proceed with normal boot. This is accomplished by systemd-hibernate-resume@.service which must be finished before local-fs-pre.target, so no filesystems can be mounted before the check is complete. When the root device becomes available, initd-root-device.target is reached. If the root device can be mounted at /sysroot, the sysroot.mount unit becomes active and initrd-root-fs.target is reached. The service initrd-parse-etc.service scans /sysroot/etc/fstab for a possible /usr mount point and additional entries marked with the x-initrd.mount option. All entries found are mounted below /sysroot, and initrd-fs.target is reached. The service initrd-cleanup.service isolates to the initrd-switch-root.target, where cleanup services can run. As the very last step, the initrd-switch-root.service is activated, which will cause the system to switch its root to /sysroot. : (beginning identical to above) : v basic.target | emergency.service ______________________/| | / | v | initrd-root-device.target emergency.target | | | v | sysroot.mount | | | v | initrd-root-fs.target | | | v v initrd-parse-etc.service (custom initrd | services...) v | (sysroot-usr.mount and | various mounts marked | with fstab option | x-initrd.mount...) | | | v | initrd-fs.target \______________________ | | v initrd.target | v initrd-cleanup.service isolates to initrd-switch-root.target | v ______________________/| / v | initrd-udevadm-cleanup-db.service v | (custom initrd | services...) | \______________________ | | v initrd-switch-root.target | v initrd-switch-root.service | v Transition to Host OS SYSTEM MANAGER SHUTDOWN
System shutdown with systemd also consists of various target units with some minimal ordering structure applied: (conflicts with (conflicts with all system all file system services) mounts, swaps, | cryptsetup | devices, ...) | | v v shutdown.target umount.target | | \_______ ______/ / v (various low-level services) | v final.target | _____________________________________/ \_________________________________ / | | | | | | v v v v systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service | | | | v v v v reboot.target poweroff.target halt.target kexec.target Commonly used system shutdown targets are emphasized. SEE ALSO
systemd(1), boot(7), systemd.special(7), systemd.target(5), dracut(8) systemd 237 BOOTUP(7)
All times are GMT -4. The time now is 06:00 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy