[bug #36132] Requires write access outside of /boot

View: New views
6 Messages — Rating Filter:   Alert me  

[bug #36132] Requires write access outside of /boot

by Aljosha Papsch-3 :: Rate this Message:

| View Threaded | Show Only this Message

URL:
  <http://savannah.gnu.org/bugs/?36132>

                 Summary: Requires write access outside of /boot
                 Project: GNU GRUB
            Submitted by: tamusjroyce
            Submitted on: Mon 09 Apr 2012 02:03:08 AM GMT
                Category: Installation
                Severity: Major
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: TamusJRoyce
        Originator Email: TamusJRoyce@...
             Open/Closed: Open
         Discussion Lock: Any
                 Release:
                 Release: Bazaar - trunk
         Reproducibility: Every Time
         Planned Release: None

    _______________________________________________________

Details:

Originally, Grub (now Grub-Legacy) did not require configuration files to
reside outside of /boot.

1.  The default installation location of configuration files should be in
/boot/grub2 (like Grub-Legacy using /boot/grub).

2.  It should use the current /etc/grub2 if /boot/grub2 is not found for
backwards compatibility.

3.  On installation, /etc/grub2/... should be copied over to /boot/grub2 if it
exists (or until /etc/grub2 is depricated, if that happens).

This makes distributions which use read-only file systems, such as TinyCore,
possible to use grub2.

NOTE:  This issue is only trying to introduce compatibility where Grub-Legacy
works and Grub2 is incompatible.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36132>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-grub mailing list
Bug-grub@...
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #36132] Requires write access outside of /boot

by Aljosha Papsch-3 :: Rate this Message:

| View Threaded | Show Only this Message

Follow-up Comment #1, bug #36132 (project grub):

/etc isn't used at boot time. It's used only by grub-mkconfig and I don't see
how grub-mkconfig using /etc is more of a problem that any other program.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36132>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-grub mailing list
Bug-grub@...
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #36132] Requires write access outside of /boot

by Aljosha Papsch-3 :: Rate this Message:

| View Threaded | Show Only this Message

Follow-up Comment #2, bug #36132 (project grub):

Another issue I am having:

When using multiple linux distributions on the same hard drive, it is
difficult to syncrhonize /etc/grub2 between different root / partitions.

Grub's scope is dependent on a single boot partiton.  So all configuration
information should be shared inside of that single boot partition.

1.  Have partition 1 as the boot partition.
    a.  linux (hd0,gpt1)/kernel-gentoo root=/dev/sda2    #server
    b.  linux (hd0,gpt1)/kernel-sabayon root=/dev/sda3   #desktop
    c.  linux (hd0,gpt1)/kernel-tiny-core root=/dev/sda4 #family

2.  Have partition 2 as Gentoo root partition.
3.  Have partition 3 as Sabayon root partition.
4.  Have partition 4 as TinyCore root partition.
5.  Have partition 5 as swap space.

Modifying customization on Gentoo and applying it wipes out Sabayons
customization.

I guess this is a future feature, because work-arounds are possible in this
scenario.

The except to this is TinyCore, which has Read-Only issues and stores
configuration directories in a non-standard location.  It may be a
distributition specific issue.

Unless other live-dvd Linux distros suffer from this issue (which are used to
modify systems, but not allow modifications to themselves...e.g. Linux
LiveCD/DVD recovery disks).

I also like the idea of the configuration persisting after the loss of the
root partition which it was installed to.

NOTE:  I would not work on this until after other more important issues are
resolved!

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36132>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-grub mailing list
Bug-grub@...
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #36132] Requires write access outside of /boot

by Aljosha Papsch-3 :: Rate this Message:

| View Threaded | Show Only this Message

Follow-up Comment #3, bug #36132 (project grub):

Looks like you don't understand the difference between grub-mkconfig and GRUB
runtime, the role of grub-mkconfig and how to use source. For multiple distros
I recommend following config:
- Designated GRUB either from one of OS or independent which sources all other
grub.cfg
- one grub-mkconfig per distro so it creates grub.cfg just for this distro.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36132>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-grub mailing list
Bug-grub@...
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #36132] Requires write access outside of /boot

by Aljosha Papsch-3 :: Rate this Message:

| View Threaded | Show Only this Message

Follow-up Comment #4, bug #36132 (project grub):

I do understand.  You might not be seeing the tight-coupling that is
happening.

Grub-Legacy had files stored in this manner (the internal code may have been
tightly-coupled, but the program functionality was not).

1.  grub-mkconfig (userspace program)
2.  configuration files (boot partition)
3.  grub runtime (mbr table)

What is happening now is the configuration files are being tightly coupled
with grub-mkconfig (from a usability perspective, not coding), by being on the
same partition as grub-mkconfig.

Applying grub configuration effects all partitions.  Why would the
configuration be located outside of the boot partition?

--------------------------------------------------------------

If a root partition was being booted from (/boot directory located in /), the
same per-root-partition configuration would be available.

--------------------------------------------------------------

I don't like to ask questions within issues...But can you re-generate the
configuration files (including customization) from grub runtime if the
configuration files are lost?

This is a feature request (which understandably, not all features make it into
applications).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36132>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-grub mailing list
Bug-grub@...
https://lists.gnu.org/mailman/listinfo/bug-grub

[bug #36132] Requires write access outside of /boot

by Aljosha Papsch-3 :: Rate this Message:

| View Threaded | Show Only this Message

Follow-up Comment #5, bug #36132 (project grub):

I think I forgot how flexible linux can be.

In my situation I solved it by moving the configuration files to /boot/grub2.
Then I simply linked /etc/grub2 to /boot/grub2.  I have to remember to do this
for each system, but it works!

mkdir /boot/grub2
cp -p /etc/grub.d/* /boot/grub2
mv /etc/grub.d /etc/grub.d.bak/
ln -s /boot/grub2 /etc/grub.d

Vladimir, thank you for your help.  There was something I wasn't
understanding.

I would still like this as a feature.  But I guess it would be part of the
installer, because symlinking solves the issue without changing any code.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36132>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/


_______________________________________________
Bug-grub mailing list
Bug-grub@...
https://lists.gnu.org/mailman/listinfo/bug-grub