Date: Wed, 12 Apr 2017 14:28:23 +0800 From: Julian Elischer <julian@freebsd.org> To: Leif Pedersen <bilbo@hobbiton.org>, freebsd-cloud@freebsd.org Cc: Toomas Soome <tsoome@me.com>, freebsd-xen@freebsd.org Subject: Re: amazon/xen... any way at all to pass a message/signal/semaphoere/morse-code to the boot loader? Message-ID: <b06362f1-4af3-6127-9fe8-d3a11fce5cbd@freebsd.org> In-Reply-To: <CAK-wPOifEdC46G%2Bd5g3BPWqSn87Sr3Fsti5k70X1F=C-=oNGMg@mail.gmail.com> References: <bf761b5c-63ad-bb14-4a9b-4e1fedced5bd@freebsd.org> <0100015b6070c546-05c6cf24-36e1-487f-be5e-b2bb6efd4472-000000@email.amazonses.com> <CAK-wPOifEdC46G%2Bd5g3BPWqSn87Sr3Fsti5k70X1F=C-=oNGMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/4/17 1:30 pm, Leif Pedersen wrote: > I keep an extra EBS volume handy that has a simple recovery image. > If I get stuck into a trouble, I change the normal boot disk to sdb, > and attach my recovery volume as sda1. Essentially, the extra volume > is my "recovery partition". To make it cheaper, keep only a snapshot > of it. yes that's a technique I've used in the past. I'd prefer to find something simpler to do, which is why it'd be nice if one could just control some single bit that the bootloader could read. > > Same idea on Google Compute Engine. > > > > > On Apr 11, 2017 11:34 PM, "Colin Percival" <cperciva@tarsnap.com > <mailto:cperciva@tarsnap.com>> wrote: > > [CCing freebsd-cloud, which is the right place for discussions > of FreeBSD/EC2] > > On 04/11/17 21:03, Julian Elischer wrote: > > In Amazon ec2 they have no console access (though I heard > rumors that it was > > available I have not seen any sign of it) so I'd like to put a > "recovery > > partition" into an AMI. > > The trick is how to convince it to boot to that instead of the > regular action. > > Can you get what you want via gptboot's support for selecting > the partition > to boot via "bootonce" and "bootme" flags? > > > The ideal thing would be if there was way to 'influence' one > of the smbios > > values in some way, and have the boot code see it, but I'm > open to any > > suggestions. > > I really need only 1 bit of information to get through. > > > > Possibilties include "changing the VM to have only 2G of ram" > (we'd never do > > that in a real machine). > > or maybe temporarily removing all the disks other than the > root drive? Almost > > anything I could do to signal the boot code to behave differently. > > I don't think adding/removing disks will be useful, since the > extra disks will > be Xen blkfront devices; AFAIK the boot loader doesn't know > anything about > these. (The boot device is also a blkfront device but gets ATA > emulation for > the benefit of boot loaders.) > > Maybe you can repurpose some of the logic used for booting over > NFS? I've > never heard of people booting over NFS when the initial > bootstrap comes from > disk rather than PXE, but I assume it's possible...? > > -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com <http://www.tarsnap.com>; | > Online backups for the truly paranoid > _______________________________________________ > freebsd-cloud@freebsd.org <mailto:freebsd-cloud@freebsd.org> > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-cloud > <https://lists.freebsd.org/mailman/listinfo/freebsd-cloud>; > To unsubscribe, send any mail to > "freebsd-cloud-unsubscribe@freebsd.org > <mailto:freebsd-cloud-unsubscribe@freebsd.org>" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b06362f1-4af3-6127-9fe8-d3a11fce5cbd>