Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: GRUB 2.02 Has Many Features, Might Hit Ubuntu 14.04

  1. #11

    Default

    I always knew GRUB was the "everything including the kitchen sink" bootloader, but even with that in mind, I boggled at this entry in the changelog:

    Code:
    * Morse code output using system speaker
    I imagine it's so it can communicate if video fails to come up, but I still don't know whether to be impressed or horrified!

  2. #12
    Join Date
    Dec 2009
    Location
    Greece
    Posts
    351

    Default

    When will Ubuntu fork GRUB2?Before or after forking the kernel?

  3. #13
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

    Quote Originally Posted by schmidtbag View Post
    hmm the uboot functionality intrigues me, but I'm not entirely sure how that works. Does that mean you need a uEnv to boot to grub, or, are you able to completely place grub over uboot? Because I would love to get rid of uboot - it is so poorly documented and inconsistent.

    ARM in general needs a serious overhaul in the booting department. It's an inconvenient mess.
    It chainloads grub from u-boot, doesn't replace it. This means you can pretend like u-boot isn't there at the cost of some boot delay, and gain the flexibility of grub.

  4. #14
    Join Date
    Aug 2007
    Posts
    6,641

    Default

    @Grogan

    If you manually need to edit your grub.cfg then you do something completely wrong. When you come from grub 1 then you would have noticed that it was a custom script in Debian based systems called update-grub that modified the menu.lst file in a post install trigger. This is now STANDARD, the script name is there on Debian but it just calls:
    Code:
    grub-mkconfig -o /boot/grub/grub.cfg
    This triggers the execution of all scripts you find in /etc/grub.d, if you want manual entries you have got 2 simple positions, the old way was adding a file in /etc/grub.d (must be +x) or append to /etc/grub.d/40_custom, this required the execution of the command mentioned before. A bit later a file called /etc/grub.d/41_custom was added, that simply souces custom.cfg in the same dir as you find the grub.cfg. As this is dynamically done you can just modifiy the custom.cfg and it will be used. Another project that was first used on Debian is called os-prober, it is used to find other OS installs. Right now grub 2 ships already the os-prober hooks in /etc/grub.d and as soon as you install the tool you see other OSs in the list as well. In the case you dislike that uninstall os-prober or -x the /etc/grub.d/30_os-prober and you are done. If you want that your custom commands are shown first rename the files, 09-xxxx would be in front of default Linux entries. I don't get what your problem is... Btw. if you manually compile kernels on Debian (or RPM) systems there are nice targets to use like:
    Code:
    make INSTALL_MOD_STRIP=1 deb-pkg

  5. #15
    Join Date
    May 2011
    Posts
    1,558

    Default

    Quote Originally Posted by TemplarGR View Post
    When will Ubuntu fork GRUB2?Before or after forking the kernel?
    When the GNOME people take it over and decide that it's too "cluttered" and begin ripping out features.

  6. #16
    Join Date
    Jul 2013
    Posts
    17

    Default

    Correct me if I'm wrong but could it be that the ones hating Grub for being too bloated are the same ones that hate systemd?

  7. #17
    Join Date
    Jul 2009
    Location
    Germany
    Posts
    512

    Default

    Quote Originally Posted by Vistaus View Post
    Correct me if I'm wrong but could it be that the ones hating Grub for being too bloated are the same ones that hate systemd?
    Nope. I'm still using grub1 and I'm not going to change this, but like systemd

  8. #18
    Join Date
    Jun 2011
    Posts
    57

    Default

    I like all the features Grub2 is getting. Not for use on my own machine, but for what you can take advantage of in an IT environment. Netbooting in particular. It would be really nice to have a dhcpd.conf that looks like this:

    Code:
    #For PowerPC Mac's
    class "AppleNBI-ppc" {
    	match if substring (option vendor-class-identifier, 0, 13) = "AAPLBSDPC/ppc";
    	option dhcp-parameter-request-list 1,3,6,12,15,17,43,53,54,60;
    	option vendor-class-identifier "AAPLBSDPC";
    	if (option dhcp-message-type = 1) {
    		option vendor-encapsulated-options 08:04:81:00:00:09;
    	} elsif (option dhcp-message-type = 8) {
    		option vendor-encapsulated-options 01:01:02:08:04:81:00:00:09;
    	} else {
    		option vendor-encapsulated-options 00:01:02:03:04:05:06:07;
    	}
    }
    
    #For Intel Mac's
    class "AppleNBI-i386" {
    	match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
    	if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; }
    	if (option dhcp-message-type = 1) { option vendor-encapsulated-options 08:04:81:00:00:67; }
    	option dhcp-parameter-request-list 1,3,17,43,60;
    }
    
    subnet 192.168.1.0 netmask 255.255.255.0 {
    	pool {
    		range 192.168.1.41 192.168.1.60;
    		filename "/grub-ppc/grub.0";
    		allow members of "AppleNBI-ppc";
    	}
    	pool {
    		range 192.168.1.21 192.168.1.40;
    		filename "/grub-efi/grub.0";
    		allow members of "AppleNBI-i386";
    	}
    	pool {
    		allow unknown-clients;
    		filename "/grub-i386/grub.0";
    		range 192.168.1.1 192.168.1.20;
    	}
    }
    This dhcpd.conf is just an example and I have no idea if it'll work.

    This way you can supply x86 and PPC Macintosh's the proper bootloader (I know, PPC has long since been obsolete, but the point is...) and supply everything else the i386 bootloader. Say what you want about Grub2's complicated-ness, but this setup ends up making everything much cleaner because you can configure and compile Grub2 to load its configuration from TFTP the same way for all architectures. So you can have a setup like this:

    Code:
    /srv/
    	tftp/
    		grub-efi/
    		grub-pc/
    		grub-ppc/
    		grub.cfg
    		images/
    			i386/
    				kernel
    				initrd.gz
    			ppc/
    				kernel
    				initrd.gz
    The various grub directories are just for platform-dependent modules and nothing else, and the grub.cfg will be used for the boot menu for every platform. And then you can do something like this:

    grub.cfg
    Code:
    menuentry "Rescue Mode" {
    	#grub_platform is a built-in variable that is set when Grub loads.  It represents the architecture.
    	if [ "$grub_platform" = "ppc" ]; then
    		set bootparameters="root=nfs://path/to/ppc/share"
    	else
    		set bootparameters="root=nfs://path/to/i386/share"
    	fi
    
    	kernel (tftp)/images/$grub_platform/kernel $bootparameters
    	initrd (tftp)/images/$grub_platform/initrd.gz
    }
    I probably screwed something up in these examples, but I have been able to get an old PowerPC G4 to netboot, load grub2, and boot a linux kernel this way, in conjuction with i386 machines. I imagine other architectures can do the same.

    I've been searching for ways to exploit Grub2 for all its worth and I would love to build software that uses Grub2 for platform-independent ways of managing clusters of thin clients or offline backups/reimaging.

    The point I'm trying to make here is, don't just think of Grub2 as a piece of software for bootstrapping your operating system. It can be used for so much more than just booting your one PC.

  9. #19
    Join Date
    Sep 2012
    Posts
    287

    Default

    Quote Originally Posted by johnc View Post
    When the GNOME people take it over and decide that it's too "cluttered" and begin ripping out features.
    Would like to see that.
    GRUB 3 no support for keyboard (or mouse) because that doesn't work on tablets.
    If you don't have a touch screen your out of luck :P

    But seriously a feature I would like from GRUB is that it were possible to make it look a bit more modern, think BURG or chameleon.

  10. #20
    Join Date
    Jan 2013
    Location
    Ontario, Canada
    Posts
    92

    Default

    Quote Originally Posted by Ferdinand View Post
    How is steam on linux? Good experience?
    Steam itself is great. They use some pretty kludgy methods... wrapper scripts and a bunch of symlinks to find its various data directories but in a way that makes it somewhat self-repairing. Also, there doesn't seem to be a legit way to change the location of the Steam directory. You can add a new library location, but not all things can go there for example games implemented as Source Engine mods will always go to the main Steam directory. You either have to move the data directories and then let the wrapper script fix it (it will prompt for paths if broken) or just manually move the symlinks in ~/.steam. Other than that and seeming to use a lot of memory (e.g. a few hundred megs... doesn't really matter much to me), the Linux Steam client is good.

    What we need are more games ported though, of course. Pretty much anything I want that's available on Linux, I already have. The only game I wanted to buy was Amnesia: A Machine for Pigs. I'm watching though, as soon as I see another game for Linux that I'm even a little bit interested in I'll do it. (I really want this to work out for them)

    My best games are Metro Last Light and the Half Life 2 games. Those run very well, at least as good as on Windows. Left 4 Dead 2 and Serious Sam 3 run relatively poorly though, by contrast, at least on AMD Catalyst (fglrx). The best driver for me so far seems to be 3.11 BetaV9.4, the latest BetaV9.95 harms performance for me.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •