live-bootstrap
live-bootstrap copied to clipboard
fosslinux
Call for (bare metal) testing!
Testing would be appreciated for the 1.0 branch - of all kinds is great, but particularly;
chrootorbwrapmode on a variety of Linux systems- bare metal tests.
Please post a report below for any bare metal tests at all, any interesting other tests, or tests that fail.
An associated bug report for failures would be appreciated, as long as you can tell where it failed and what the error was.
A good report format follows:
Kind of bootstrap: (chroot/bwrap/qemu/bare metal) Success or Failure: ... Machine/OS Information: (for bare metal, hardware information, including laptop model or motherboard model, CPU, amount of RAM, boot device; for others, Linux distribution, etc) Failure information: (if relevant) Additional Information:
I have been able to successfully run the build on chroot, bwrap and qemu modes.
- For chroot and bwrap, I used
--build-kernels --external-sources. - For qemu, I used kernel bootstrapping with
--external-sources.
Done on Fedora 40.
However, I have not been able to complete the build on bare metal. I used kernel bootstrapping with --external-sources.
The laptop I used is a PackardBell Easynote ML65, which is quite old (~16 years).
- Intel Core 2 Duo T5800
- 4 GB RAM
- SATA DVD burner without any disk in it
- Two 2.5" empty SATA slots
- 4 USB 2.0 ports, with a USB stick on two of them (with
init.imgandexternal.img)
The builds goes through the builder-hex0 and Fiwix stages, but it freezes while booting the Linux kernel.
Here is a recording of the moment it freezes.
Can we get some better instructions on how to do this? In particular, I'd like to know:
- What are the system requirements for the full bootstrap?
- In case my system isn't fully supported, can I bootstrap using a prebuilt linux kernel?
- Is there a kernel you'd recommend? I think e.g. slackware's might contain enough modules. Alternatively, do you recommend a livecd to grab a config and
lsmodfrom to domake localyesconfig?
- Is there a kernel you'd recommend? I think e.g. slackware's might contain enough modules. Alternatively, do you recommend a livecd to grab a config and
- What
bootstrap.pycommands would I use for any of this? I'm a bit confused wrt those, as I haven't managed to use a linux kernel for bootstrapping, but I find the "full" bootstrap equally confusing.
Sure!
What are the system requirements for the full bootstrap?
- x86 system
- for the kernel bootstrap, ability to boot in CSM (BIOS) mode
- 4GB+ of RAM
- some kind of mass storage device (USB, SDD, HDD, etc)
- Ethernet connection (optional)
In case my system isn't fully supported, can I bootstrap using a prebuilt linux kernel?
Yes, but we would love to know about any cases where the full kernel bootstrap doesn't work!
The way to do this is by using the (I have only just noticed, poorly named) -qk argument to rootfs.py, which will instruct rootfs.py to NOT use the kernel bootstrap and rather generate an initramfs.
Regarding the kernel, I haven't tried to figure out a minimal Linux kernel requirement recently - been focusing more on the full kernel bootstrap. I know the requirements are fairly minimal though, so I'd recommend just giving it a go with a kernel you have around. An important point: you should build in any modules that are needed! Modules are not supported for the bootstrap kernel.
What bootstrap.py commands would I use for any of this? I'm a bit confused wrt those, as I haven't managed to use a linux kernel for bootstrapping, but I find the "full" bootstrap equally confusing.
At a minimum, you want the -b option (bare metal), so at minimum, you'd need ./rootfs.py -b. This will then give you a path to a disk image after a little bit, that you can write to some mass storage device and attempt to boot off.
Thank you for pointing out some deficiencies in documentation :)
3GB RAM is sufficient, if you use swap (-qs 4G option), or limit parallelism to 1 core (-c 1 option).
Reporting in with a possibly invalid build failure:
| Item | Detail |
|---|---|
| Motherboard | ASUS P5QL-CM |
| CPU | Intel Pentium Dual-Core E5200 |
| Architecture | x86 |
| RAM | /!\ 2G /!\ |
rootfs.py command |
./rootfs.py -s 8G -b -a x86 --cores 1 |
live-bootstrap commit |
71ff0a0 |
This is the only 32-bit BIOS machine I have kicking around, so despite insufficient RAM, I figured I'd give it a go anyway. It managed to build all the way to Fiwix, but failed to kexec from the builder-hex0 environment into Fiwix itself, hanging (at least overnight) at the jump. I needed to reclaim desk space in the morning, so I turned the machine off after that. If there are specific debugging steps you'd like me to try, please let me know.
Thank you! There is a good chance that this is caused by a lack of RAM space, I believe (but do not know for sure)
By the way, 64-bit x86_64 BIOS machines should also be able to run live-bootstrap, as they are just an extension of 32-bit x86 :)
I wonder if --external-sources can build with less RAM. It stores more of the bootstrap on disk rather than RAM.
I have successfully completed a full bootstrap on bare metal. It was completed on a NUC style mini-pc running a J4105 celeron. The machine has 12 gigs of ram. The box is UEFI only so I created a mini boot environment using buildroot with just enough in it to clone the repository and download the files. The bootstrap was run in chroot mode and completed successfully. From the live bootstrap environment I was able to build a Gentoo live cd and a stage 3 tarball. (Thanks mid-kid, your bootstrap repository was instrumental in getting that to work). I was able to install Gentoo from the output with no issues.
I just tried to do some bare metal bootstraps on the 1.0 Branch, as well as the master branch, on a few different systems, my results are below:
| Item | HP Laptop | Lenovo Yogabook |
|---|---|---|
| Kind of bootstrap | bare-metal | bare-metal |
| Success or Failure | Failure | Failure |
| Machine/OS Information | HP Pavilion - 13-an1076tu w/ i3 1005G1 processor, 8GB ram, 128GB Kingston USB boot drive, legacy bios mode | Lenovo Yoga 300-11IBR w/ Pentium N3060 processor, 4GB ram, 128GB Kingston USB boot drive, BIOS in legacy boot mode |
| Failure information | Hung on trying to run kaem.x86 script | trying to run kaem.x86 script caused flashing blue + symbols to cover the screen |
| Additional Information | Tried only on master | tried on both master & 1.0, both failed |
If you need me to do anything else, let me know. I'm happy to play around with these, just need a few directions to look into to try and fix this.
edit: fix the table
It’s been a while since I’ve had a modern machine with legacy boot but I seem to remember limitations when booting from USB sticks. Check your bios settings for something like “legacy usb support”. I would also try with a smaller USB stick.
Can you boot a regular Linux kernel on those machines, and quote the "e820" lines from dmesg? I suspect you might have a discontiguous memory map, sometimes seen on UEFI machines.
Reporting a failure with ./rootfs.py -q bootstrapping x86. The bootstrap proceeds all the way into Linux and starts building Linux versions of some utilities before failing to get libtool-2.4.7 sources:
libtool-2.4.7: beginning build using script pass1.sh
libtool-2.4.7: getting sources.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 992k 100 992k 0 0 522k 0 0:00:01 0:00:01 --:--:-- 522k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
curl: (22) The requested URL returned error: 400
curl: (1) Protocol "https" not supported or disabled in libcurl
libtool-2.4.7.tar.xz: OK
(and then the kernel panics)
Has http://mirrors.kernel.org started redirecting all traffic to HTTPS?.
Reporting another failure with ./rootfs.py -q bootstrapping x86. The bootstrap proceeds all the way into Linux and starts building Linux versions of some utilities before failing to get libtool-2.4.7 sources for a different reason:
libtool-2.4.7: beginning build using script pass1.sh
libtool-2.4.7: getting sources.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 992k 100 992k 0 0 764k 0 0:00:01 0:00:01 --:--:-- 765k
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 190 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 1 seconds. 5 retries left.
0 190 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 2 seconds. 4 retries left.
0 190 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 4 seconds. 3 retries left.
0 190 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 8 seconds. 2 retries left.
0 190 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 429
Warning: Problem : HTTP error. Will retry in 16 seconds. 1 retries left.
0 190 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 429
curl: (1) Protocol "https" not supported or disabled in libcurl
libtool-2.4.7.tar.xz: OK
Do we need special handling for 429s when building on a fast machine?
Failure with rootfs.py -q
Kind of bootstrap: qemu Success or Failure: Failure Machine/OS Information: Ubuntu 24.04 / Qemu
Host: AMD Ryzen 7 3700X 8-Core Processor
qemu-system-x86_64 --version
QEMU emulator version 8.2.2 (Debian 1:8.2.2+ds-0ubuntu1.4)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers
Failure information: (if relevant)
Just a hard freeze with no progress. After 5 minutes - this was all I saw below:
SeaBIOS (version 1.16.3-debian-1.16.3-2)
iPXE (https://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+BEFCAF30+BEF0AF30 CA00
Booting from Hard Disk...
Additional Information:
Same result with qemu-system-i386 vs qemu-system-x86_64.
Commit fcfc7bdef6fb73f7dceb9e140737aa80989fe0ca from 1.0
I have successfully completed a full bootstrap on bare metal. It was completed on a NUC style mini-pc running a J4105 celeron. The machine has 12 gigs of ram. The box is UEFI only so I created a mini boot environment using buildroot with just enough in it to clone the repository and download the files. The bootstrap was run in chroot mode and completed successfully. From the live bootstrap environment I was able to build a Gentoo live cd and a stage 3 tarball. (Thanks mid-kid, your bootstrap repository was instrumental in getting that to work). I was able to install Gentoo from the output with no issues.
Could you tell us more about the gentoo bootstrap on live bootstrap?
I have tried countless times using the official gentoo bootstrap script (live bootstrap in WSL), but without success.
I have successfully completed a full bootstrap on bare metal. It was completed on a NUC style mini-pc running a J4105 celeron. The machine has 12 gigs of ram. The box is UEFI only so I created a mini boot environment using buildroot with just enough in it to clone the repository and download the files. The bootstrap was run in chroot mode and completed successfully. From the live bootstrap environment I was able to build a Gentoo live cd and a stage 3 tarball. (Thanks mid-kid, your bootstrap repository was instrumental in getting that to work). I was able to install Gentoo from the output with no issues.
Could you tell us more about the gentoo bootstrap on live bootstrap?
I have tried countless times using the official gentoo bootstrap script (live bootstrap in WSL), but without success.
Ok, but this is not for the faint of heart. The first thing to understand is that you can’t go directly to a gentoo install from the live bootstrap. There is just too much missing. You need things like cmake, ninja, wget, git, etc. The path forward is to use the live bootstrap to cross build an environment with the tools and quality of life programs you need to build the next step. It turns out that you can build Linux from scratch on top of the live bootstrap. So phase one is to build Linux from scratch V12 (it’s the last version that should work with the kernel in the live bootstrap). Phase two is to build emerge and the related tools in the LFS environment. Phase three is to manually emerge the equivalent of a stage one and then stage three. Phase four is to chroot into the gentoo environment you made and run catalyst to create an install iso and stage three file. Then you boot into the ISO and install per the handbook.
For the gentoo related steps I found midkid’s bootstrap git repository invaluable to figuring out how to get the initial gentoo environment up and running. Understanding how catalyst works and being able to interpret the .spec files is an extremely useful skill to have to troubleshoot issues. So if you haven’t built LFS before or played with the gentoo catalyst tool, I would recommend those tasks as prerequisites to attempting a gentoo install from live bootstrap.
I have successfully completed a full bootstrap on bare metal. It was completed on a NUC style mini-pc running a J4105 celeron. The machine has 12 gigs of ram. The box is UEFI only so I created a mini boot environment using buildroot with just enough in it to clone the repository and download the files. The bootstrap was run in chroot mode and completed successfully. From the live bootstrap environment I was able to build a Gentoo live cd and a stage 3 tarball. (Thanks mid-kid, your bootstrap repository was instrumental in getting that to work). I was able to install Gentoo from the output with no issues.
Could you tell us more about the gentoo bootstrap on live bootstrap? I have tried countless times using the official gentoo bootstrap script (live bootstrap in WSL), but without success.
Ok, but this is not for the faint of heart. The first thing to understand is that you can’t go directly to a gentoo install from the live bootstrap. There is just too much missing. You need things like cmake, ninja, wget, git, etc. The path forward is to use the live bootstrap to cross build an environment with the tools and quality of life programs you need to build the next step. It turns out that you can build Linux from scratch on top of the live bootstrap. So phase one is to build Linux from scratch V12 (it’s the last version that should work with the kernel in the live bootstrap). Phase two is to build emerge and the related tools in the LFS environment. Phase three is to manually emerge the equivalent of a stage one and then stage three. Phase four is to chroot into the gentoo environment you made and run catalyst to create an install iso and stage three file. Then you boot into the ISO and install per the handbook.
For the gentoo related steps I found midkid’s bootstrap git repository invaluable to figuring out how to get the initial gentoo environment up and running. Understanding how catalyst works and being able to interpret the .spec files is an extremely useful skill to have to troubleshoot issues. So if you haven’t built LFS before or played with the gentoo catalyst tool, I would recommend those tasks as prerequisites to attempting a gentoo install from live bootstrap.
Wow, there are so many difficulties. Have you tried this https://wiki .gentoo.org/wiki/Project:Prefix/Bootstrap?
I almost made it, but I'm stuck in the middle of the road...
I spent about eight months trying to get the Gentoo prefix to work. I never could get it to build reliably. That's why I switched to the method I described. I was able to automate the build in a "it works for me" kind of way. If you want to try my scripts you can pull my public fork of this repository. It's usually a few commits behind but it works. It's at https://github.com/ajherchenroder/live-bootstrap-with-lfs.git. To use it do the following:
- Clone it just like you do the main repository
- Run the live bootstrap.
- After it completes go to /steps/lfs and run lfsmain.sh and let it build.
- In the lfs environment, run lfstarget.sh in the root. (that will pull down the Gentoo build scripts)
- Exit back to the live-bootstrap environment and cd into /target
- Run the gentoomain.sh to build the Gentoo ISO and stage files.
- The files will be found in the /gentoo/output directory.
- Then you can install as per the handbook.
You will need at least 128Gigs of additional space to complete the bootstrap in addition to the live-bootstrap disk. I just use a usb stick. for both.
I spent about eight months trying to get the Gentoo prefix to work. I never could get it to build reliably. That's why I switched to the method I described. I was able to automate the build in a "it works for me" kind of way. If you want to try my scripts you can pull my public fork of this repository. It's usually a few commits behind but it works. It's at https://github.com/ajherchenroder/live-bootstrap-with-lfs.git. To use it do the following:
- Clone it just like you do the main repository
- Run the live bootstrap.
- After it completes go to /steps/lfs and run lfsmain.sh and let it build.
- In the lfs environment, run lfstarget.sh in the root. (that will pull down the Gentoo build scripts)
- Exit back to the live-bootstrap environment and cd into /target
- Run the gentoomain.sh to build the Gentoo ISO and stage files.
- The files will be found in the /gentoo/output directory.
- Then you can install as per the handbook.
You will need at least 128Gigs of additional space to complete the bootstrap in addition to the live-bootstrap disk. I just use a usb stick. for both.
Thank you so much! I'll try your way.
I have the same problem as @sempiternal-aurora, once my laptop tries to enter kaem.x86, it shows flashing blue +s over the entire screen.
Laptop is a Acer TravelMate B117-M, I've attached a dmesg log from booting an installed Arch Linux kernel.
Relevant part:
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000074a2dfff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000074a2e000-0x0000000074aadfff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000074aae000-0x000000007a1adfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007a1ae000-0x000000007a5adfff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007a5ae000-0x000000007a6adfff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007a6ae000-0x000000007a6edfff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x000000007a6ee000-0x000000007b485fff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007b486000-0x000000007bd85fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bd86000-0x000000007bffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007c400000-0x000000007fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000e3ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fea00000-0x00000000feafffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed03000-0x00000000fed03fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed08000-0x00000000fed09fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1cfff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fedbffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffc00000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable
Several reserved ranges between 0x100000 and 0xc0000000 (the critical range for builder-hex0).
Kind of bootstrap: qemu (from master, ./rootfs.py -q -i --external-sources --cores 8)
Success or Failure: Success
Machine/OS Information: qemu 9.2.1 Ubuntu 25.04 Beta
Failure information: (if relevant)
Additional Information: I'm planning to do this on bare metal but I'm curious, are there instructions on how to continue using the machine after the bootstrap is over, either bare metal or qemu?
I'm planning to do this on bare metal but I'm curious, are there instructions on how to continue using the machine after the bootstrap is over, either bare metal or qemu?
The live bootstrap isn’t the end, it’s just the beginning. When the bootstrap is finished you end up with a 32 bit musl based system running on an older kernel. The only text editor is ED and you can’t even run a proper lsblk. The environment is best considered as a build environment for whatever you want the final system to be. The first thing I did when I had a working bootstrap, was to use it to cross compile a 64 bit Linux from scratch system. The bootstrap works great as a barebones host system for LFS. Since then, I have bootstrapped several Gentoo installs. If you are interested in the BSDs, I have also successfully cross compiled and installed NetBSD from the bootstrap. If you’re not sure which way to go I suggest building an LFS/BLFS system. That’s probably the best documented route to a usable system. The Gentoo and NetBSD routes are both temperamental and require advanced knowledge of their build systems to complete successfully.
I guess I'll ask a simpler question. If the computer is power cycled after the bootstrap is complete, what happens? Does it run the bootstrap again from scratch or end up at the same prompt at the end of the bootstrap or something else?
There’s no Linux boot loader in the live bootstrap so you can’t go directly back into the environment if you reboot. The final system is still there in the target directory but getting back into it requires some effort. The way I do it is to boot into a live environment on a USB stick (I use a Gentoo install media). Then mount the original live bootstrap environment and chroot into the target directory. At that point you can kexec into the bootstrap kernel if you really want to. Then you are basically back to where you were. To be honest I almost never kexec into the live bootstrap kernel. I do what I have to do from the running Gentoo kernel.
@ajherchenroder since the goal is to beat the trusting trust attack though, doesn't this slightly defeat the point? i.e. we want to not trust the pre built kernel at any point since presumably it's compiler inserted exploit will immediately reinsert itself into the live bootstrap kernel and libc and whatever.
I would imagine what I want to do is use the live-bootstrap to get enough connectivity going to source build the rest of my world and a bootloader to let me stay there.
@ajherchenroder since the goal is to beat the trusting trust attack though, doesn't this slightly defeat the point? i.e. we want to not trust the pre built kernel at any point since presumably it's compiler inserted exploit will immediately reinsert itself into the live bootstrap kernel and libc and whatever.
I would imagine what I want to do is use the live-bootstrap to get enough connectivity going to source build the rest of my world and a bootloader to let me stay there.
The short response to your comment is the Gentoo media was built from the live bootstrap environment as part of installing Gentoo on another machine. As someone who has for better or worse committed to rebuilding his homelab from the ground up via the live-bootstrap tool chain, there are some practical issues I've had to deal with when moving to "production" bare metal. Dealing with those issues requires some compromises to the live bootstrap philosophy in order to get back to working machines. My home lab consists of a series of mostly intel NUCs that run from ninth through fourteenth gen. In addition there is an old gaming machine that I have repurposed as a backup NAS to my Synology unit. The NAS runs Truenas, most of my 12th and thirteenth gen NUCs run Proxmox and everything else runs Gentoo, Netbsd or Freebsd. The first major hurdle to getting things running in my home lab is that only 2 of my NUCs theoretically support bios boot. In practice they both have memory discontinuities that prevent successful bootstrapping. So the first major practical compromise is the need to find a way to boot from UEFI. The next major hurdle was the fact that any twelfth gen and beyond Intel has a combination of P and E cores. As a minimum you need a late 5.X or early 6.x Linux kernel to run those machines. the live bootstrap kernel is at version 4.14.341-openela. My solution was to spin up a VM and run a complete bootstrap with kernel bootstrap. That environment was used to compile a mini UEFI boot shim image using buildroot. That shim is basically a UEFI Grub boot loader, a 6.X Linux kernel that supports all of my machines, basic POSIX utilities, wget, nano and an SSH daemon. The whole thing will just about fit on an old school zip 250. When I need to bootstrap bare metal, I boot from my shim and then do a chroot bootstrap. The point of this too long screed is that if you are planning to use this on reasonably modern bare metal you will be forced to make practical compromises in order to get to a working system.
There’s no Linux boot loader in the live bootstrap so you can’t go directly back into the environment if you reboot. The final system is still there in the target directory but getting back into it requires some effort. The way I do it is to boot into a live environment on a USB stick (I use a Gentoo install media). Then mount the original live bootstrap environment and chroot into the target directory. At that point you can kexec into the bootstrap kernel if you really want to. Then you are basically back to where you were. To be honest I almost never kexec into the live bootstrap kernel. I do what I have to do from the running Gentoo kernel.
We do install Grub in bare-metal and qemu mode, so rebooting should get you back to the bootstrapped system.
As for what happens after the bootstrap is complete - if -i is given, then an interactive shell is opened; otherwise, the machine powers off.
I guess that grub is poorly tested with external sources, because the second hard drive gets used and then grub is misconfigured and so is qemu, because it will boot from the bootstrap drive which doesn't have grub installed.