Hello.
I'm hoping for a bit of advice on how to proceed.
I'm interested in creating an Alpine Xen dom0 that runs entirely from
the ESP partition (a.k.a. the EFI partition). I believe this should be
possible by combining a clean "diskless" installation with apkovl to
provide configuration. It doesn't really matter about the bootloader --
I can make Grub or xen.efi or EFISTUB work. I'm wondering about the
best way to achieve my goal.
It seems to me that I should be able to install the entire "diskless"
Alpine in the initramfs.
The instructions at
https://wiki.alpinelinux.org/wiki/Create_a_Bootable_Device seem to get
*quite* close to what I want, but of course they are creating a bootable
MBR partition, not an initramfs.
The boot sequence would be:
1. UEFI bios
2. bootloader (optional)
3. xen.efi
4. kernel
5. initramfs
6. init script
7. apkovl etc.
It seems to me that I might need to make a custom initramfs init script
that *does not* pivot to another root filesystem, since the initramfs
will *be* the diskless filesystem.
I'm writing to the mailing list to see if anyone else has achieved a
similar result, even if in a different way. Or if anyone has a
different suggestion for how I might achieve my result. Or any short
cuts for this work.
It would be nice if the final system is able to upgrade itself without a
lot of work, too.
The initramfs init script seems quite flexible, but I haven't found a
way to convince it that it's living in a finished diskless installation.
Thanks!
On 2024-11-11 17:25, Liam Proven wrote:
> On Sun, 10 Nov 2024 at 13:39, <rptb1+alpine@pobox.com> wrote:>>>> I'm interested in creating an Alpine Xen dom0 that runs entirely from>> the ESP partition> > You might find it useful to look at OneFileLinux, which does exactly this:> > https://github.com/threader/OneFileLinux
Thank you. That's quite close to what I want. I can certainly see how
that works and adapt it.
I also discovered, since I wrote my message, that Alpine's
setup-bootable *does* create a UEFI-bootable ESP. The instructions at
https://wiki.alpinelinux.org/wiki/Create_a_Bootable_Device will get you
an MBR-based system, but if you create an ESP instead with, e.g.::
sgdisk --wipe-all /dev/sda
sgdisk -n1:0:+2G -t1:EF00 -c1:ESP /dev/sda
mkfs.vfat /dev/sda1
setup-bootable -v /media/cdrom /dev/sda1
then you will get a UEFI bootable system entirely in the ESP.
It's not *quite* what I wanted (it's huge), but it's another good
starting point.
Thanks again.
> On Nov 10, 2024, at 8:39 AM, rptb1+alpine@pobox.com wrote:> > Hello.> > I'm hoping for a bit of advice on how to proceed.> > I'm interested in creating an Alpine Xen dom0 that runs entirely from the ESP partition (a.k.a. the EFI partition). I believe this should be possible by combining a clean "diskless" installation with apkovl to provide configuration. It doesn't really matter about the bootloader -- I can make Grub or xen.efi or EFISTUB work. I'm wondering about the best way to achieve my goal.> > It seems to me that I should be able to install the entire "diskless" Alpine in the initramfs.> > The instructions at https://wiki.alpinelinux.org/wiki/Create_a_Bootable_Device seem to get *quite* close to what I want, but of course they are creating a bootable MBR partition, not an initramfs.> > The boot sequence would be:> > 1. UEFI bios> 2. bootloader (optional)> 3. xen.efi> 4. kernel> 5. initramfs> 6. init script> 7. apkovl etc.> > It seems to me that I might need to make a custom initramfs init script that *does not* pivot to another root filesystem, since the initramfs will *be* the diskless filesystem.> > I'm writing to the mailing list to see if anyone else has achieved a similar result, even if in a different way. Or if anyone has a different suggestion for how I might achieve my result. Or any short cuts for this work.> > It would be nice if the final system is able to upgrade itself without a lot of work, too.> > The initramfs init script seems quite flexible, but I haven't found a way to convince it that it's living in a finished diskless installation.> > Thanks!
Okay, I’ve seen other folks discuss *how* you could accomplish this (One File Linux looks especially interesting)
But I’m curious as to *why* you want to do this. And why as a Xen dom0 specifically?
On 2024-11-11 18:33, Isaac Beckett wrote:
> On Nov 10, 2024, at 8:39 AM, rptb1+alpine@pobox.com wrote:>> I'm interested in creating an Alpine Xen dom0 that runs entirely from the ESP partition (a.k.a. the EFI partition). ...> > Okay, I’ve seen other folks discuss *how* you could accomplish this (One File Linux looks especially interesting)> > But I’m curious as to *why* you want to do this. And why as a Xen dom0 specifically?
Three reasons:
1. To subvert and virtualize an existing system without modifying it
(very much). There are many reasons that might be useful, but I'm
experimenting with PCI passthrough on a Steam Deck, running SteamOS as a
domU. I *could* of course repartition the Steam Deck's SSD and make
space for a traditional partition, or boot from an external device, but
then I started thinking what a flexible tool this might be, and how it
could be handy to have always there on a portable system.
2. To learn in detail about Alpine and its boot process.
3. Because it would be a neat trick.
Unfortunately, there's probably not enough room in the Steam Deck's
default ESP.
It probably doesn't have broad application.
I might be able to improve some of the documentation on the way through.
> On Nov 11, 2024, at 2:36 PM, rptb1+alpine@pobox.com wrote:> > Three reasons:> > 1. To subvert and virtualize an existing system without modifying it (very much). There are many reasons that might be useful, but I'm experimenting with PCI passthrough on a Steam Deck, running SteamOS as a domU. I *could* of course repartition the Steam Deck's SSD and make space for a traditional partition, or boot from an external device, but then I started thinking what a flexible tool this might be, and how it could be handy to have always there on a portable system.> > 2. To learn in detail about Alpine and its boot process.> > 3. Because it would be a neat trick.> > Unfortunately, there's probably not enough room in the Steam Deck's default ESP.> > It probably doesn't have broad application.> > I might be able to improve some of the documentation on the way through.
You might be able to shave off more space from the install by customizing the packages installed (remove stuff you don’t need) or by using e.g. buildroot to build an even smaller rootfs.