Announcement

Collapse
No announcement yet.

Jaunty Updates and Grub: a warning

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Jaunty Updates and Grub: a warning

    Greetings all:

    I'm one of those anal retentives who likes to have full control of everything on my system. One of the things I'm particularly strict about is Grub. I have a small partition on the laptop hard disk that holds nothing but grub and it's current boot files. When I install or modify a Linux version on this system, I manually modify my grub setup to load what I want, in the order I want. (I have three Linux partitions currently, two of them I use for testing stuff).

    This takes a little more effort at times, but for me it's worth it to keep things the way I want them.

    Because of this, when I install a new distro on a partition, I always de-select the option to install Grub. On the Ubuntus, you have to look for this option on the very last installation screen, using that "advanced options" button on that last install page.

    So, I installed Jaunty last week to try it out. I hadn't used it in a few days and when I booted it this morning, there were about 300 updates available. I browsed through the list of updates and noticed it wanted to install a few things as well (like sane, which is odd since I have no scanner attached to the laptop).

    I also discovered grub on that list. This leads me to believe that Jaunty sees that grub isn't installed initially, and chooses to add it when you do updates. This, of course, could potentially screw up my boot sector and cause me to have to reconfigure things back to the way I had them in the first place.

    I'm not sure if this needs to be reported as a bug or not, but I wanted to make everyone aware of this. My guess is that there are a few other "early adopters" here who might have a similar configuration.
    Joe<br />in Florida

    #2
    Re: Jaunty Updates and Grub: a warning

    When you installed *buntu, did you install its Grub into the partition root? How are you linking your booted Grub to the *buntu kernel and root filesystem? I have a dual boot setup, and find the "configfile" technique really simple to link the booted Grub menu to the "other" Linux OS -- this way each Linux system can install new kernels and run update-grub if it needs to, with no consequences on the boot menu or Grub.

    Comment


      #3
      Re: Jaunty Updates and Grub: a warning

      Originally posted by dibl
      When you installed *buntu, did you install its Grub into the partition root? How are you linking your booted Grub to the *buntu kernel and root filesystem? I have a dual boot setup, and find the "configfile" technique really simple to link the booted Grub menu to the "other" Linux OS -- this way each Linux system can install new kernels and run update-grub if it needs to, with no consequences on the boot menu or Grub.
      My problem with letting the system manage the grub setup is that, if I let each new install manage grub, things would be reinstalled/updated every time I added or updated a new version. One other issue was non-Ubuntu and non-grub-using distros (like Slackware, for example). Slack wants to install LILO, which means I have to change a whole lot of things around.

      Here's how I do this:

      I have two primary partitions for Linux installs and a small, 100MB primary partition for Grub, plus an extended partition broken up for /home, general storage and one more Linux install.

      The grub version in the grub partition was installed manually (I believed I used a bootable CD, IIRC). This wasn't particularly difficult, since manual grub installs are pretty easy: you basically just tell it where to install the boot files, then copy the config and stage files to /boot/grub in that partition. Essentially, you're doing by hand what Grub does automatically when you do a system installation. There are other ways to do this: booting to a floppy disk with grub, or right from an existing installed system.

      I always have one system partition ready to boot and run. My primary work partition is currently my Kubuntu Hardy partition that I've been running forever. I usually leave that alone and test on the other two install partitions. All my home directories are in /home. I also share the "storage" partition with all versions.

      When I do an installation, I skip the boot loader install (no matter how it's done). When I'm ready to reboot, I boot to my working Kubuntu partition. The grub partition is mounted on startup by default, so I can always access the grub files. I also make sure I mount the other two Linux system partitions on each install. This gives me access to everything, no matter which version I boot.

      After I reboot, I go to the mounted grub folder and sudo edit the menu.lst file. I know which partition is which, so all I need to add is the appropriate information for that installation. In the case of the Ubuntu loads, I need the UUID of the root partition (which can be pulled from the fstab file in each installation's /etc directory), and the kernel and initrd file names. In the case of a distro like Slackware, all I need is the kernel file name/location and the standard device indicator for the drive (i.e, /dev/sda2), since it doesn't use UUIDs.

      That's basically it.

      What you're saying is correct and the way to do it for most people. I'm an old schooler, I suppose, and have been diddling with Linux since it was just a kernel and a terminal. the way I boot here is not particularly unusual (I discovered the setup idea somewhere on line), and I'm pretty certain others here do something similar. Since installing grub capriciously can mess up custom installs, I wanted to make sure other knew of this little "feature."
      Joe<br />in Florida

      Comment


        #4
        Re: Jaunty Updates and Grub: a warning

        Originally posted by joe.attaboy

        After I reboot, I go to the mounted grub folder and sudo edit the menu.lst file. I know which partition is which, so all I need to add is the appropriate information for that installation. In the case of the Ubuntu loads, I need the UUID of the root partition (which can be pulled from the fstab file in each installation's /etc directory), and the kernel and initrd file names. In the case of a distro like Slackware, all I need is the kernel file name/location and the standard device indicator for the drive (i.e, /dev/sda2), since it doesn't use UUIDs.
        I did it that same way until I discovered "configfile" last year -- now I view your method as "needless work and time".

        Here's the menu part of my Kubuntu menu.lst file, which is the "master" boot menu on my system:

        ## ## End Default Options ##

        title Ubuntu 8.10, kernel 2.6.27-11-generic
        root (hd1,0)
        kernel /boot/vmlinuz-2.6.27-11-generic root=UUID=4ee99d57-a4e3-4381-a900-7a57cfa9eea2 ro vga=837 quiet splash
        initrd /boot/initrd.img-2.6.27-11-generic
        quiet

        title Ubuntu 8.10, kernel 2.6.27-11-generic (recovery mode)
        root (hd1,0)
        kernel /boot/vmlinuz-2.6.27-11-generic root=UUID=4ee99d57-a4e3-4381-a900-7a57cfa9eea2 ro vga=837 single
        initrd /boot/initrd.img-2.6.27-11-generic

        title Ubuntu 8.10, kernel 2.6.27-9-generic
        root (hd1,0)
        kernel /boot/vmlinuz-2.6.27-9-generic root=UUID=4ee99d57-a4e3-4381-a900-7a57cfa9eea2 ro vga=837 quiet splash
        initrd /boot/initrd.img-2.6.27-9-generic
        quiet

        title Ubuntu 8.10, kernel 2.6.27-9-generic (recovery mode)
        root (hd1,0)
        kernel /boot/vmlinuz-2.6.27-9-generic root=UUID=4ee99d57-a4e3-4381-a900-7a57cfa9eea2 ro vga=837 single
        initrd /boot/initrd.img-2.6.27-9-generic

        title Ubuntu 8.10, memtest86+
        root (hd1,0)
        kernel /boot/memtest86+.bin
        quiet

        ### END DEBIAN AUTOMAGIC KERNELS LIST

        title .
        root

        title Other operating systems:
        root

        title .
        root

        title Debian sidux GNU/Linux on hd4,0
        configfile (hd4,0)/boot/grub/menu.lst
        So on either Kubuntu or sidux, I can run dist-upgrade, let it install new kernels and run update-grub, and never again fiddle with the menu.lst file.

        Comment


          #5
          Re: Jaunty Updates and Grub: a warning

          Looks interesting. Maybe after the Jaunty dust settles (I'm still not sold on KDE 4.2 yet), I'll give this a try. I guess we get set in our ways sometimes. ;-)
          Joe<br />in Florida

          Comment


            #6
            Re: Jaunty Updates and Grub: a warning

            I use a small dedicated GRUB partition sdb1 at the start of the 2nd HDD.
            Here's the entire menu.lst:

            # sdb1 GRUB partition menu.lst
            default 0
            timeout 10
            # Pretty colours
            color cyan/blue white/blue

            title Kubuntu 8.04 sdb2 = (hd1,1)
            configfile (hd1,1)/boot/grub/menu.lst

            title Windows XP Home Edition sda1
            root (hd0,0)
            chainloader +1

            title Kubuntu 8.10 Intrepid sdb3 = (hd1,2)
            configfile (hd1,2)/boot/grub/menu.lst

            (Embarrassed to be temporarily down to just 3 OSs while I re-do that disk), but here's the point--same as dibl is making:

            I can make changes to the OS on (hd1,1) and (hd1,2) and not have to edit ANY menu.lst. In fact, I can install ANY Linux dirsto on those two partitions and not change the main menu.lst as long as they use a menu.lst as the config file. (If, instead, they use a grub.cfg or some-such, I simply change it to read configfile (hdx,y)/boot/grub/grub.cfg.)
            If I make a new partition and put a Linux distro on (hd1,4) that boots by a menu.lst, for example, simply add this boot stanza to the main menu.lst in sdb1 = (hd1,0):

            title whatever OS on (hd1,4)
            configfile (hd1,4)/boot/grub/menu.lst

            Nothing could be easier.


            How To GRUB Methods - Toolkit
            http://kubuntuforums.net/forums/inde...opic=3081671.0
            SECTION 9: Making and using a separate GRUB partition
            --> tips about setting the default & timeout in the target menu.lst, etc.
            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

            Comment


              #7
              Re: Jaunty Updates and Grub: a warning

              Thanks for the tips. Next time I update, I'll take a look at this and all the other advice.
              Joe<br />in Florida

              Comment


                #8
                Re: Jaunty Updates and Grub: a warning

                I don't recall seeing it in synaptic or adept, but there is a forbid/purge/don't-even-think-of-touching it option for dselect. I haven't needed it for an uninstalled package since before "debian derived distributions" was a mere pipe-dream, but I believe that you can get it with the _ option in aptitude and dselect. There should be a dpkg or dpkg-deb command line to do this, too.

                If memory serves, you need to get it to purge rather than not-installed when the package is part of the base system, as debian tries to install "missing" base packages

                hawk
                Noone else may have these opinions without paying my retainer

                Comment


                  #9
                  Re: Jaunty Updates and Grub: a warning

                  You got most of it Hawk. Aptitude helps a little in this regard also.
                  sudo aptitude hold grub
                  will set the system to never install grub again until you remove the hold. You can run full-upgrade (dist-upgrade) or just upgrade and it will still be held.

                  Comment


                    #10
                    Re: Jaunty Updates and Grub: a warning

                    Originally posted by mando_hacker
                    You got most of it Hawk. Aptitude helps a little in this regard also.
                    sudo aptitude hold grub
                    Well, aptitude *is* a bit after my time

                    When I switched from debian to FreeBSD for my own use, dselect was still the most advanced tool, and all of the debian lists were still getting spammed sensless by the all-caps "PROJECT DEITY" topics . . . that left me with a bad taste for what would become apt . . .

                    Now, I'm a mere dilettante on the linux side of things. I need it for the menus for the kids, for the times when the java-based features of openoffice are less buggy/crashy on the linux side than FreeBSD side (a see-saw, for sure!), and for the more recent versions of flash. But those now mean most of the time . . .

                    hawk

                    Noone else may have these opinions without paying my retainer

                    Comment

                    Working...
                    X