GNOME.org
 

Re: ostree host from scratch w/o anaconda


> BTW, I also think grub2 sucks, and as I am using intel hardware, I was thinking on migrating to extlinux, which is way simpler and less complicated. 


You might want to take a look at https://github.com/ostreedev/ostree/pull/228 It makes using GRUB much simpler.


> as it generates the kernel and initrd paths like /ostree/..., when in my single partitioning setup, it should be /boot/ostree/....


This is not really an issue with the above patch, see my comments in https://github.com/gatispaeglis/ostree/blob/ostree-grub-generator/src/boot/grub2/ostree-grub-generator


I see that there is a WIP patch to fix the "boot on its own partition" for uboot and syslinux boot loader backends as well.

https://github.com/ostreedev/ostree/pull/215


From: ostree-list <ostree-list-bounces gnome org> on behalf of Leandro Santiago <leandrosansilva gmail com>
Sent: Wednesday, March 30, 2016 11:41 AM
To: Colin Walters
Cc: ostree-list gnome org
Subject: Re: ostree host from scratch w/o anaconda
 
Hi Colins, my system is based on Centos7, and I am using Fedora 22 installer to deploy my ostree images. This installer is quite old now, not supporting btrfs or tmpfs partitions or even /boot in the same partition. Then I decided to try the one from Fedora 23, but it generates a lot of garbage, which result in a non-bootable system, specially regarding plymouth, which I don't have and is not required in my use case. I'll be glad to report such issues, but I confess for now it will be quicker for me to drop anaconda and do stuff by hand :-)

In my use case, I have a single partition with both system and /boot, instead of a separated /boot. Then I also need to keep volatile data in a separated partition, to prevent data corruption and avoid / to fill out. All those stuff seem impossible to be done on anaconda + ostree, and I understand totally this limitation, which is out of its scope.

But it turns out deploying ostree manually is not that hard :-) I believe I am almost done, and there is a few manual fixes I need to do.

For example, it seems (using 2016.2) ostree admin instutils grub2-generate, called on 15_ostree, on grub2-mkconfig, expects /boot to be in a separated partition, as it generates the kernel and initrd paths like /ostree/..., when in my single partitioning setup, it should be /boot/ostree/....

Please let me know if you think I should report this issue as a bug. It's a trivial fix for me right now to just change grub.cfg after it's generated, but I'd be glad on having it behaving correctly during generation :-)

BTW, I also think grub2 sucks, and as I am using intel hardware, I was thinking on migrating to extlinux, which is way simpler and less complicated. How well supported is it on ostree?

On 29 March 2016 at 16:09, Colin Walters <walters verbum org> wrote:
 
On Tue, Mar 29, 2016, at 04:44 AM, Leandro Santiago wrote:
I apologize for resurrecting this thread, but has anyone had success on this process? I was previously using anaconda to deploy an ostree based system, but due some anaconda's bugs and limitations,
 
Hm, what were those?  Did you file any bugs/issues?
 
 
I am also open to use syslinux, as my use case is not that complex to require grub.
My best regards,
 
GNOME Continuous currently uses syslinux with a separate /boot partition.  See
this code:
 
Basically it boots qemu with a special systemd target.
 
Though honestly I'm forgetting now why we stopped using the
`guestfs_extlinux` command http://libguestfs.org/guestfs.3.html
 
But for my use of OSTree in Project Atomic, supporting bare metal deployments
(things like EFI etc.) and an array of storage formats is important, so integrating
with Anaconda made sense  (as opposed to having custom VM-specific code).
That said I'm open to improving things for cases outside of it.
 



--
Sent from my mind
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]