Re: syslinux issues



On Mon, 2013-10-21 at 11:27 +0200, Daniel Narvaez wrote:

* /boot/syslinux is assumed to be a symlink. It's a real directory on
my system. Can we just g_file_query_exists?

In order to do atomic swaps, you'll need to arrange for /boot/syslinux
-> /boot/loader.  OSTree does kind of take over the handling of /boot
from the package manager.

I'm open to supporting other schemes; but the symlink should be pretty
easy to do.  What we really want eventually of course is for syslinux to
support the bootloader spec directly, then we won't need to synthesize
config files, and we wouldn't (necessarily) need to atomic swap the
syslinux config.

* The indenting is not necessarily a tab, it was four spaces on my
system. I guess we could just strip the string.
* I have LINUX instead of KERNEL. It seems like both are valid.

Hm, this is for reading existing configs?  So OSTree is designed to
read/write the bootloader spec.  It just *also* comes with legacy
support for generating syslinux and uBoot configs from the BLS.  But for
say GRUB+BLS patch, we don't need special GRUB support at all.

The problem with reading/writing existing syslinux.conf is that then
there'd be *two* sources of configuration.  The current OSTree-syslinux
code tries to avoid destroying configuration it doesn't know about, but
I'm not sure how "production" that can be - ultimately having a separate
copy of the syslinux config parsing code seems is doomed to be buggy.

* We are writing out the config to /boot/loader/syslinux.cfg, not
to /boot/syslinux/syslinux.cfg, despite what the message says. What is
the intention there?

Yes, because in order to implement atomic swaps of the syslinux config,
it needs to be under /boot/loader (which is really one
of /boot/loader.[01]).


So...executive summary here: OSTree as currently designed wants to take
over /boot - rather than package managers writing there directly, you
"ostree commit" builds into the OSTree repo, and use "ostree admin
deploy" to check them out and update the bootloader config.  I'm happy
to consider changes that might help other cases, but that's the way it's
designed now.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]