> http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec [I see no designated mechanism for feedback, so I'll try this one.] After reading that spec (last edited 2013-02-14 21:36:10), I have these comments: 1. Indirection by one level should be supported, such as a file: $BOOT/loader/entries/my-purple-project.indir having the contents: directory //b098c68b69f54d21848176c25b44da36/purple/boot where b098c...da36 is the blkid of a filesystem, which the boot loader locates by exhaustive search. All .conf files in that directory are processed as if they appeared in $BOOT/loader/entries/ , except that any pathname contained in such a .conf file is interpreted in the context of the filesystem that has the named blkid. Rationale: Updating the boot configuration for the running system never should require searching for the location which contains the .conf files. The answer always is some path which has the prefix "/boot/", whether that is a local directory or a mount point. Part of the reason for the current mess involving boot loaders is the insistence that everything must be in one place that the boot loader controls. Instead, multiboot by chain loading is a useful option of GRUB1 (especially: chaining to another GRUB1 which is installed in the bootblock of a partition and manages only that partition), and the 'configfile' indirection feature of GRUB2 is very nice. 2. Filesystem type for $BOOT: Explicitly allow FAT12, FAT16, FAT32. Explicitly disallow FAT32X and NTFS because of complexity. ext4 is a headache because it requires more code. On disk, ext3 is the same as ext2 (assuming a clean unmount.) Obviously the boot loader should warn about dirty unmount (which for ext3 means that the journal will not be processed.) 3. It can be handy if .conf files are syntax-compatible with shell, so that they can be parsed and interpreted by ". file1.conf" or "source file1.conf", instead of having to write a loop: while read line; do set -- "$line"; case "$1" in title) ... ;; ... ;; esac done Problem areas often are: escaping, quoting, meta characters, continuation lines. Regarding shell compatibility, it looks like the Boot Loader Spec might be aiming for having shell procedures title(), version(), etc. However, "machine-id" is not a shell identifier. Also, shell characters such as "\\'\"([{*?<>&$;" (backslash singlequote doublequote open leftsquare leftbrace star ask less greater amper dollar semi) should be quoted or escaped. Sharp '#' should begin a comment anywhere, not only first on a line. 4. Explicitly suggest a mechanism for inter-operating with the 'loader' of Microsoft Windows for non-EFI systems. There are many such systems, and they will persist for many years. If there is no explicit suggestion, then there will be different incompatible extensions, which will cause pain later. -- _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
