4

I have a laptop with more than one OS.

Is there any command by which I can shut down current OS and boot into another OS?

windows->Ubuntu and vice versa

thank you

2
  • 1
    That depends on how to choose to boot into the different OSes, BIOS boot selection, LINUX bootloader or Windows bootmanager. Jan 25, 2015 at 21:50
  • @PeterHahndorf Can you tell it for all of these (if you know)? its a good question.
    – TechLife
    Jan 25, 2015 at 23:38

3 Answers 3

2

Yes, it's possible if you use Grub for boot selection:-

  • Boot into Linux.
  • Enable root privileges by logging in, or by using su or sudo -s.
  • Copy /boot/grub.cfg to either /boot/grub.win or /boot/grub.lin, depending on your default.
  • Edit /etc/default/grub to change GRUB_DEFAULT= to the number of the alternative OS in the boot list (counting from zero).
  • Run update-grub, then copy /boot/grub.cfg to /boot/grub.lin or /boot/grub.win, as appropriate.
  • Restore GRUB_DEFAULT= to its previous value in /etc/default/grub.
  • Create bootlin and bootwin containing:
    cp /boot/grub.lin /boot.cfg or cp /boot/grub.win /boot.cfg
    shutdown -r now

Now you can can call bootlin or bootwin from Ubuntu.

In Windows you will need to do the same sort of thing:-

  • First install ext2fsd.
  • Assign a drive letter (eg U:) to the Ubuntu partition and make it writable.
  • Now you can create bootlin.cmd and bootwin.cmd containing the appropriate copy command to overwrite U:\boot\grub.cfg, followed by:
    shutdown -r

If you boot with ntldr you can use a similar technique with two copies of boot.ini (you may need to clear Read-only, System and Hidden attributes first). There may be a similar technique that you can use with other boot loaders, but I leave it to others to suggest what will work with these.

CAUTION: I find ext2fsd works well in read-only mode, but I have never used it in writable mode: be aware that it could corrupt your Ubuntu system, so make sure it is well backed up until you have tried it a few times and reassured yourself that it works correctly. It might be safer from Windows to edit grub.cfg in situ, which will not require directory changes, but you will need some sort of Windows in-line editor which does not use work files in the same file system, or knock up a few lines of C to do it.

2

These details might not exactly match how UEFI handles GPT systems, but it does describe MBR-based systems.

The official (old) standard is to use what is on the Master Boot Record. The "fdisk" command can be used to change the details of the MBR.

The traditional MBR contains some bits that specify whether a partition is flagged. The standard specifies that only one partition is flagged, although that isn't necessarily enforced by the boot code. When a user specifies that a specific partition should be flagged, a traditional fdisk program will typically check for another flagged partition and, if one is found, unflag it. There might be alternative words used to describe a "flagged" partition, like a "selected" partition.

Then, the traditional MBR contains some "code" (instructions). When the system is booted, this code is run. The code will check the MBR to see how big each partition is, and see which partition is flagged. It will then continue to booting process by running some additional code which is located in the partition that is flagged.

So, that's the standard that is widely supported. Unfortunately, this standard method involves going into fdisk and interacting with it manually. So that's not just a single program that you can run. It is, however, the most widely supported standard.

To quote OpenBSD FAQ: Multibooting:

Virtually every OS offers a program to do this; OpenBSD's is fdisk(8), similar named programs are in Windows 9x and DOS, and many other operating systems. This can be highly desirable for OSs or systems which take a long time to shut down and reboot -- you can set it and start the reboot process, then walk away, grab a cup of coffee, and come back to the system booted the way you want it -- no waiting for the Magic Moment to select the next OS.

It's funny how, with all of the fancy replacements people have made, the advantages of the most widely supported official process can be overlooked so often.

I know this may not be quite as automated as what is desired, although the question that was asked did not specify non-interactivity. So, the simple answer is that yes, there is such a command. It is "fdisk".

Now, there are some other variations, and so automation is probably possible if you're seeking such a solution. You may wish to check your operating systems for a command named "boot" or something like that; I know the old OS/2 operating system did contain a "BOOT" command that could modify which operating system was started. The precise command(s) you would need to run depends on what boot code you actually use. There's multiple "boot manager" programs available, and this functionality is now built into more operating systems. That's the good news. The bad news is that the process isn't quite as standardized, so I can't just provide you with one specific process that integrates well with everybody's different variations. Basically, you need to pick a solution and use it. The primary concern is likely to find a process that can be done from multiple operating systems, and which can be used to write to the sections of the disk that are handled while the system boots up. Those sections are typically not part of a filesystem, and anti-virus features may try to limit a person's ability to write to those critical sections of the disk.

Basically, the process is going to involve changing the flag bits of a partition, or changing the boot code of the MBR, or changing the behavior of the code that is on the partition that the MBR uses to continue booting. So that's three different approaches, and each of those approaches are actually used by some of the different options that are available.

A fourth approach may be to alter which disk the BIOS boots from. However, this approach has traditionally been much less compatible between different systems, so that approach is more of a theoretical possibility than something that is actually used. (Although, many users have used this approach interactively, often by pressing F12 or something to pull up a boot menu; sometimes they just enter BIOS setup and change the default disk that will be used on subsequent boots.)

The most common method is probably to create a 512-byte image of the entire MBR when the system boots in one operating system, and then save a 512-byte image of the entire MBR when the system boots with a different operating system. Then, use whatever software you need to, to directly write those 512 bytes to the first 512 bytes of the disk. (Something like "dd" would do the trick.) The biggest challenge with that might just be having permission by the operating system.

AFH's answer seems to show how this can be done from Linux with grub. The Windows Boot Manager from the XP/2003 days would use these sort of sector images (which would be referenced by a "Boot.ini" file), so getting out of Windows could be done by altering the Boot.ini text file. (That process might have changed in Vista/2008, so check into the new boot manager before trying that on newer systems.) A precise way to implement any of these solutions will depend on which operating system you're trying to stop using. (For example: which version of Microsoft Windows.)

0

while when we call a hardware reboot , it is more or less identical to a power-off and a power-on subsequently . thus all ram memory are lost . and when we power-on , the boot process is handled by the motherboard firmware . if we want to tell motherboard firmware some message , we must not leave such message in the ram . but we can write something ( anything ) on the disk ( or some other permanent media , and i believe efi provides mechanism to set non-volatile variable ) .

besides the forementioned approches , linux kernels have kexec functionality to "surrender control" to another system without hardware going down . though a windows kernel may not be directly kexec'ed into , a workaround exist , by kexec'ing into a loader programme and let the loader programme initialise the windows system .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .