[WIP] Add structure to enable baking Moby Linux AMI #116
Conversation
|
I think you don't need to mount the ISO, it only contains the kernel/initrd and uses syslinux as the boot loader (syslinux is kinda like grub for cdroms). Your build should depend on initrd.img and then just copy initrd.img and kernel/vmlinuz64 into the container. I also think it would be good to split the build process into two steps. One which creates a bootable raw disk (which can be tested with qemu etc) and a second step which then turns this into a AMI. |
|
Still a bit baffled on why this isn't booting correctly. I'm most suspicious of the ( @justincormack Maybe there's still another kernel config option we're overlooking for the console? Even the instances that can boot "properly" don't output anything to the system log.
Next steps are to break the build into two steps as @rneugeba mentioned, so that I can iterate faster and hopefully get more information using |
|
I also added a (admittedly hacky) script, |
|
Might remove the grub stuff as well since I'm using syslinux / extlinux now, I couldn't even find a |
|
Maybe |
|
As for why it won't boot, maybe there needs to be |
Yeah on second thought this probably isn't it, I don't know if we even need an |
| @@ -26,7 +26,10 @@ mknod -m 666 zero c 1 5 | |||
| mknod -m 666 tty c 5 0 | |||
| mknod -m 600 console c 5 1 | |||
|
|
|||
| mknod -m 600 tty0 c 4 11 | |||
There was a problem hiding this comment.
Check these changes out @justincormack. Do they seem right to you? @ncopa and I were discussing and he mentioned that we should either create these devices here in order to have them in place when we boot, or we need to use devtmpfs
There was a problem hiding this comment.
We are using devtmpfs now as of a few weeks ago, I just left some devices
in case someone does not.
On 6 May 2016 02:51, "Nathan LeClaire" notifications@github.com wrote:
In alpine/mkinitrd.sh
docker/engine#116 (comment):@@ -26,7 +26,10 @@ mknod -m 666 zero c 1 5
mknod -m 666 tty c 5 0
mknod -m 600 console c 5 1+mknod -m 600 tty0 c 4 11
Check these changes out @justincormack https://github.com/justincormack.
Do they seem right to you? @ncopa https://github.com/ncopa and I were
discussing and he mentioned that we should either create these devices here
in order to have them in place when we boot, or we need to use devtmpfs—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/docker/moby/pull/116/files/92164619a12fd912c3a0553b679028f5c8fa45ac#r62280786
There was a problem hiding this comment.
Hm, so probably I should take these changes out?
There was a problem hiding this comment.
well, doesnt really matter, maybe should remove all of them but they are pretty harmless.
|
OK I pulled the GRUB stuff out and everything has the latest changes. It's still not booting properly or showing anything to the console so I wonder which piece of the puzzle is still missing. Conflicting information about whether |
|
@nathanleclaire you can have multiple Are you running in an HVM instance now? |
|
Its currently only starting a getty on the serial console, but if you get boot output we can fix that easily (will try to fix that anyway) |
|
Running a getty on all three (in a dev/debug purposes) means you will get something like |
|
added the xen blockdev in master |
|
@ijc25 Yes, it's HVM. Nice, thanks @justincormack. Will rebase and try that out. Adding all the "console=" options and that option manually I still didn't have any success booting though. I think I might take a crack at a booting a Hdt (http://www.syslinux.org/wiki/index.php?title=Hdt_(Hardware_Detection_Tool)) to see if our assumptions about console devices are correct, or if I can get anything to display on the logs at all. |
|
Calling |
|
Re-trying now with latest master changes (and adding all |
|
|
|
|
|
Yay! Odd there is no network, should be easy to fix. What does So it was |
|
I'm not 100% positive, but it seems the needed change was to set This table might have something to do with it ? (From http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html) |
|
I think the AWS "System Logs" console is read only, sadly. Maybe I can dump |
|
Yes, just dump it from any of them... doesnt really matter which. |
|
Right on |
|
Its not finding the drive either, which is also a bit odd, maybe dump |
|
I'll post the whole dump for you to take a look at too |
|
|
I just pushed a change that should fix the disk detection (untested, hope it works, no internet at new house yet!) |
|
<3 |
|
Odd, no sign of ethernet, any way you can boot up another VM and see what the ethernet driver is? |
|
Sure -- I also noticed that I set |
|
Will push out that change shortly. |
|
It looks like I didnt enable most of the ethernet drivers, other than virtual ones. Odd though as the Xen PV device is enabled. Maybe it has a pci passthrough dev, though I dont remember seeing one on the last machine I booted... |
Signed-off-by: Nathan LeClaire <nathan.leclaire@gmail.com>
|
EDIT: Something else might be to blame. |
|
The output you asked about...
|
|
Maybe we need |
|
Yeah, |
Signed-off-by: Nathan LeClaire <nathan.leclaire@gmail.com>
|
|
|
Weird I thought I had enabled that... |
|
Ok, added now. I thought I checked yesterday, but it wasnt set... |
|
Lets merge this now its working... |
|
🎉 |
Allow specifying the kernel and tarball names, or omitting tarball
This does not actually render a bootable instance, but introduces some boilerplate that hopefully should help to get us there sooner rather than later.
It's a bit messy so we probably shouldn't merge right away, and some parts aren't really used (e.g. the GRUB Dockerfile), but are around since they might be useful. If it behooves us we can keep them and if not I'm happy to take them out.
To build an AMI from scratch using the Moby Linux BIOS ISO, the idea is that you simply have to:
in the
alpine/directory, and the process of making a volume + formatting and writing it (including GRUB conf) + snapshotting + creating an AMI from the snapshot is then done for you automatically. Currently, it works "in place", so existing build resources will all be removed before attempting a new build from scratch.(This assumes that you have run
aws configureon the host OS. I'm not really sure what the best approach is here so for a quick fix I just mount in~/.awsread-only to the build container).The operations being performed on
$EBS_DEVICEare obviously wrong and need to be fixed, presently they are mostly copied from the Alpine Linux on AWS guide, just using the Moby BIOS ISO instead of theirs -- we could probably convert this to just boot Alpine if feeling pressure to deliver something ASAP, but I really want to boot Moby specifically.There are a few rough edges so let me know if you run into anything and/or how to fix.
This is mostly the AWS boilerplate and the process of actually writing the proper things to the EBS volume device is still a little hazy to me (but I'm learning!). I really welcome any guidance people have here. If no one has any ideas, Monday I'll take a whack at making a small GRUB partition and booting directly into Moby like Justin mentioned in the other thread.
Once we get this OS booting, next steps will probably be to polish up init to work well in cloud.
FYI and please take a look @justincormack @mavenugo @kencochrane @rneugeba @ijc25
Signed-off-by: Nathan LeClaire nathan.leclaire@gmail.com