5

I have a 64-bit dual-boot system running Windows 7 and Linux Mint 17 Cinnamon. I use rEFInd to graphically choose which system to boot.

A little bit about rEFInd:

  • It is an EFI bootloader.
  • It uses external, text-based configuration files (*.conf)
  • Configuration files can reference others. However, at runtime, only the external files referenced by the first file (refind.conf), are honored.
  • Particular properties that are referenced multiple times are handled as a cascade - that is, each reference overrides all previous references; only the last is honored.

...I have a few configuration files stored on my efi drive. At (efi) boot time, these configuration files are loaded:

  • refind.conf - the default, boilerplate settings file. This file references the following two files, in order.
  • settings.conf - a separate, clean slate for my favorite settings. It is referenced by refind.conf. Any settings here will override refind.conf.
  • auto_settings.conf - contains settings dynamically handled by programmatic means. It is also referenced by refind.conf. Any settings here will override refind.conf.

In addition to these files, i also have some alternative files that are programmatically swapped out with auto_settings.conf:

  • auto_default.conf - when the contents of this file is contained within auto_settings.conf this brings about the default state for my system. This shows me a menu at boot time, prompting me to choose between windows and linux. The system waits for my input.
  • auto_mint.conf - when the contents of this file is contained within refind.conf, rEFInd will skip the GUI menu, and proceed directly to booting Linux Mint.
  • auto_win7.conf - when the contents of this file is contained within refind.conf, rEFInd will skip the GUI and boot windows.

That is all (i think) you need to know about rEFInd in order to solve this problem.

Next, the System:

When i boot my system, it asks me which OS to load. Say i choose windows.

It boots windows.

Then, I want to go into Linux.

I can right-click on my desktop, and click "Boot to Linux".

Using the registry, I have created an entry in the desktop's context menu that triggers a custom batch file. This registry entry, when calling the batch file, also passes particular arguments to the batch file that dictates its function at runtime.

So, at this moment, my batch file (lovingly called bootfacilitator.bat) is doing its job quite wonderfully. On the EFI partition, my batch file replaces the contents of auto_default.conf with the contents of auto_mint.conf. If that operation is successful, which it is, it then reboots the system.

Additionally, upon booting windows, bootfacilitator was also called
transparently, that time for the function of replacing the contents of auto_settings.conf with the contents of auto_default.conf.

The system shuts down, and boots into rEFInd, which skips the GUI, and boots Linux.

I need Linux to replace the contents of auto_settings.conf with the contents of auto_default.conf, or I am stuck in a linux-only boot scenario. Me no likey. All I have to do is replace the contents of a file at boot.

I have a script (bootfacilitator.sh) that is contained in /mnt/data/Backup/Software/Linux.

In linux, bootfacilitator.sh should replace the contents of /mnt/efi/EFI/boot/auto_settings.conf with the contents of /mnt/efi/EFI/boot/auto_default.conf.

Additionally, I have some other goals for this project. I would also like to have two context menu entries on my linux desktop to mirror the entries in the context menu in my windows desktop: "Boot to Windows" and "Reboot Linux".

The end result of this is to have a fluid workflow from one OS to another, with the scalability to incorporate additional OSs.

PS my fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1   /mnt/efi    vfat    defaults    0   0
UUID=f9750eee-576b-46b2-a0a1-f6ad34f4d526 /               ext4    errors=remount-ro 0       1
UUID=1f49ddc3-88d1-40e6-b706-7623a4fb47ac none            swap    sw              0       0
/dev/sda4   /mnt/osx    hfsplus defaults    0   0
/dev/sda3   /mnt/win_7  ntfs    defaults    0   0
/dev/sda5   /mnt/data   ntfs    defaults    0   0
/mnt/data/Videos    /home/rich/Videos   none    bind    0   0
/mnt/data/Documents /home/rich/Documents    none    bind    0   0
/mnt/data/Music /home/rich/Music    none    bind    0   0
/mnt/data/Pictures  /home/rich/Pictures none    bind    0   0
/mnt/data/Downloads /home/rich/Downloads    none    bind    0   0
/mnt/data/Public    /home/rich/Public   none    bind    0   0

bootfacilitator.sh:

#!/bin/sh 
#description: Re-Enables EFI multi-select boot menu (in case of forced selection scenario) 
sudo cp /mnt/efi/EFI/Boot/auto_default.conf /mnt/efi/EFI/Boot/auto_settings.conf
Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
  • What does `bootfacilitator.sh` contain at the moment? Is the correct partition mounted at `/mnt`? – muru Jan 04 '15 at 21:20
  • rEFInd is not a bootloader. Your firmware is the bootloader in this context. rEFInd is the boot manager. The desktop question is going to depend on your wm - it has nothing whatsoever to do with linux - which is the kernel.Also - are you directly loading the kernel in EFI - or are you chainloading through grub or some other stuff? – mikeserv Jan 04 '15 at 21:23
  • @mikeserv im trying to copy one file to another in linux at boot time... and these files in question happen to be in the efi partition. and they happen to be files that are used by the bootloader rEFInd. coincidentally, my configuration file, auto_mint.conf, is set up to load the linux kernel directly. the kernel happens to be version 3.13.0-24-generic running on a AMD FX 6100 Six-Core. –  Jan 04 '15 at 21:30
  • @muru and yes, the mounts are correct –  Jan 04 '15 at 21:32
  • @RichardLeClair - I get what you're after - I do something pretty similar - and with rEFInd. But - I'm just saying - rEFInd is not a bootloader. Anyway, if you want the script bit to work you're going to need to ensure that whatever user runs it has permissions - which are not usually assigned for `/mnt` mounts as `/etc/fstab` is the general place user mounts are setup and `/mnt` is an ad-hoc type deal - by convention. Probably the `sudo` covers that - but that is not likely to work in a windowing system. – mikeserv Jan 04 '15 at 21:33
  • @mikeserv updating post to include my fstab... –  Jan 04 '15 at 21:35
  • ok, so your current config is likely to cause problems with kernel updates - unless you have already handled that elsewhere. when your distro updates its kernel its probably going to want to affect `/boot` - which might be what your `auto_mint.conf` is designed to handle, I dunno. You can add a line to `fstab` like `/mnt/EFI/BOOT /path/to/some/dir bind noauto,user 0 1` so your user can mount your boot directory. And in your script you can drop `sudo` - which shouldn't be playing with boot files anyway - and then the window management stuff will likely be a matter of changing `.desktop` files. – mikeserv Jan 04 '15 at 21:47
  • oh - but your script will have to do the mount first. like `mount /path/to/some/dir; cp ...; umount /path/to/some/dir` – mikeserv Jan 04 '15 at 21:48
  • By the way... You might be going at this wrong. A UEFI firmware will support running scripts, as well, you know. If you were to write an EFI shell script and run it from rEFInd you could do without this. Else you could write scripts for both Windows and your linux systems that directly affect the the `BootOrder-{GUID}` vars and so alter the firmware's boot order directly without the rEFInd middleman. I mean, I really like rEFInd - but its whole purpose is to provide a menu selection system and your goal seems to be bypassing that - which doesn't make much sense to me. – mikeserv Jan 04 '15 at 21:57
  • @mikeserv I was not aware of the existence of UEFI scripts. But even though I'm temporarily bypassing rEFInd, i'm also keeping it there for the times (many) where I'm starting my system from its cold slumber. Otherwise, in the event I have already booted the system and now want to change OSs, then i would need the OS thats already running to change the boot files around, not EFI. –  Jan 04 '15 at 22:10
  • Of couse - I don't suggest you remove it. But if you just bump it down in the boot order for those times when you don't want the menu and bump it up for those that do, you should arrive at your solution more directly. A widely available app for manipulating UEFI var from a linux userspace is `efibootmgr`. – mikeserv Jan 04 '15 at 22:11
  • @mikeserv there is obviously something crucial i am missing here. how do i edit my boot order? ..programmatically, I mean. hah –  Jan 04 '15 at 22:12
  • From linux use the `efibootmgr`. You can also *(almost definitely)* see all of your UEFI vars in `/sys/firmware/efi/efivars`. You can directly manipulate these even - given the proper permissions - but they're encoded in UTF-16 and will likely look pretty funky without some clever pipe-filtering. Else, just use `efibootmgr`. – mikeserv Jan 04 '15 at 22:14
  • @mikeserv, efibootmgr reports as such: BootCurrent: 0001 Timeout: 3 seconds BootOrder: 0000,0001 Boot0000* EFI DVD/CDROM Boot0001* OsLoader0000 –  Jan 04 '15 at 22:17
  • @mikeserv I would assume everything I am doing is happening within OsLoader0000. –  Jan 04 '15 at 22:19
  • Ok, you need to `man efibootmgr` - there are good examples in there. And `efibootmgr --help` but when you list those, you're going to want to use `-v`erbose for gathering information. I'm sorry - but I won't directly answer this question. Nor will I provide a step-by-step - UEFI, while *(kind of)* standardized - is a manufacturer specific thing. The `fstab` part will allow you to handle it from rEFInd, which is one way. More directly you're going to have to - *carefully* - feel your way until you're comfortable. I can't know all of your EFI env vars, for example. You just have to learn it. – mikeserv Jan 04 '15 at 22:19
  • All I need is to move a file over at boot, but I (think) am having permission issues. All of this refind stuff and boot order stuff is merely peripheral to this finishing piece of my puzzle: getting bootfacilitator.sh to run at linux boot and copy a file over. –  Jan 04 '15 at 22:25
  • Right - so you do that by giving the appropriate user the appropriate permissions to the targeted filesystem. As I said - this is conventionally done in `/etc/fstab` - which is why I suggested you add a line that would enable your script to `mount` the directory where the files are located, do the `cp...` then `umount` it. Still, I think your goals and your methods are at cross-purposes - you're manipulating the menu manager to not provide a menu rather than just manipulating the bootloader to not load the menu manager. – mikeserv Jan 04 '15 at 22:27

1 Answers1

0

A couple ways to accomplish this:

  • Make a .desktop file in ~/.config/autostart/. This will run when you log in. Us something like sudo cp input.txt output.txt as the command.
  • A more robust solution would be to create an Upstart job, which will run when your system boots.
Free Bullets
  • 643
  • 1
  • 6
  • 7