linux - Ubuntu 12.04.3 LTS live boot from grub2 from hard drive

16
2014-04
  • user172277

    I have very strange issue:

    1. I download the ubuntu 12.04.3 LTS
    2. I configured gurub, /etc/grub.d/40_custom:

      menuentry "Live CD" {  
      loopback loop /ub.iso
      linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/ub.iso noeject noprompt -- 
      initrd (loop)/casper/initrd.lz
      }
      
    3. I make sudo update-grub and after reboot I can use Ubuntu 12.04.3 in live mode.

    4. Next I install this ubutntu on other partition. On this installation I install remastersys tool.
    5. I backup my system by creating new ISO using remastersys.
    6. I reconfigure grub, because in that new ISO has initrd.gz instead of initrd.lz, like that:

      menuentry "Live CD" {
      loopback loop /ub.iso
      linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/ub.iso noeject noprompt --
      initrd (loop)/casper/initrd.gz
      }
      
    7. Of course update grub.
    8. After reboot I have error:

      stdin: error 0
      /init: line3: can't open /dev/sr0: No medium found`
      

      and I think it is OK, because I don't have any floppy.

    9. At the end I have another error:

      (initframs) Unable to finde a medium containing a live file system`
      

    I know it is possible to do it, because my friend do this year ago with ubuntu 12.10. And he remember that there was some "issue", but unfortunately don't remember what kind ;/ Should I install some additional packets or sth?

    Best Regards, Bartosz

  • Answers
    Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

    Related Question

    Having problems with Grub2 booting Ubuntu from my External Hard Drive
  • cesar

    I installed Ubuntu on my external hard drive but it won't boot on my laptop. What do I do?

    I did some reading and traced the source of the problem to Grub2. Apparently, Grub2 doesn't use the device's UUID, and uses the linux directory instead (/dev/sdf2). This means that whenever I plug my E-HDD into a system that has a different number of drives connected to it, I won't be able to boot without editing the boot command. I don't understand it too well but that's what I got from what I read.

    Is there any way to fix this?

    Here's my grub config (trimmed to show example kernel entry). I have no idea why it's not using UUID. I didn't tweak it once...

    ### BEGIN /etc/grub.d/10_linux ###
    menuentry "Ubuntu, Linux 2.6.31-20-generic" {
            recordfail=1
            if [ -n ${have_grubenv} ]; then save_env recordfail; fi
        set quiet=1
        linux   /boot/vmlinuz-2.6.31-20-generic root=/dev/sdc2 ro   quiet splash
        initrd  /boot/initrd.img-2.6.31-20-generic
    }
    menuentry "Ubuntu, Linux 2.6.31-20-generic (recovery mode)" {
            recordfail=1
            if [ -n ${have_grubenv} ]; then save_env recordfail; fi
        linux   /boot/vmlinuz-2.6.31-20-generic root=/dev/sdc2 ro single 
        initrd  /boot/initrd.img-2.6.31-20-generic
    }
    

  • Related Answers
  • cesar

    The problem was that my device.map was not configured properly which led to grub using the ubuntu names, e.g. sdf2, rather than the UUIDs of the hard drive. the fix was to update device.map and then update grub2. It is done by running 'drivemap', i think, then update-grub. I'm not too sure on the command to update device.map because i did this about a week ago, but yeah. This is just in case anyone runs into my problem.

  • quack quixote

    OK, you're right that that's not grabbing UUIDs, which strikes me as odd.

    Here's how a kernel entry should look (this is from my Ubuntu 9.10 VM, slightly tweaked but this should be fairly stock):

    menuentry "Ubuntu, Linux 2.6.31-20-generic" {
        recordfail=1
        if [ -n ${have_grubenv} ]; then save_env recordfail; fi
        set quiet=1
        insmod ext2
        set root=(hd0,1)
        search --no-floppy --fs-uuid --set b22c7fe9-4354-40bf-b9bf-87a469289f6e
        linux /boot/vmlinuz-2.6.31-20-generic root=UUID=b22c7fe9-4354-40bf-b9bf-87a469289f6e ro
        initrd        /boot/initrd.img-2.6.31-20-generic
    }
    

    The /boot/grub/grub.cfg file is generated when something runs update-grub from the scripts in /etc/grub.d and variables in file /etc/default/grub.


    • Now, there is a variable in the default file, GRUB_DISABLE_LINUX_UUID, that if set to true will give a root=/dev/sdXY value to the linux kernel line (instead of a root=UUID=... value). I don't think that's your problem, but check your /etc/default/grub file to make sure. You should see these lines (the # at the beginning of the line means it's commented out):

      # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
      #GRUB_DISABLE_LINUX_UUID=true
      

      If you see GRUB_DISABLE_LINUX_UUID without the # at the beginning, insert it, save the file, and run sudo update-grub to regenerate grub.cfg. Then check grub.cfg again to see if it looks right.


    • If the defaults file looks OK, next check your drive's UUIDs themselves. It's possible that the drive UUIDs aren't set correctly, or aren't getting detected correctly. uDev has the job of creating symlinks in the device tree for disk UUIDs; check them:

      $ ls -l /dev/disk/by-uuid
      total 0
      lrwxrwxrwx 1 root root 10 2010-04-18 04:15 b22c7fe9-4354-40bf-b9bf-87a469289f6e -> ../../sda1
      lrwxrwxrwx 1 root root 10 2010-04-18 04:15 e1c64ac1-186d-4c15-8833-6072ac6421df -> ../../sda5
      

      If this doesn't show you a partition you're expecting to see, you might need to check the filesystem directly with tune2fs (manpage) (replace /dev/sda1 with the right device name):

      $ sudo tune2fs -l /dev/sda1 | grep UUID
      Filesystem UUID:          b22c7fe9-4354-40bf-b9bf-87a469289f6e
      

      If this is missing, you can recreate it with:

      $ sudo tune2fs -U random /dev/sda1
      

      Now re-check the tune2fs -l output, and then check /dev/disks/by-uuid again. You may need to reboot before uDev picks up the changes. The update-grub scripts should now pick up the UUID, so re-run it and check the new grub.cfg to see if it looks right.


    • If none of these are panning out, you may need to dig a little deeper. Let's check our assumptions:
      • How is your boot drive partitioned? (fdisk -l)
      • How is your boot drive formatted? (ext2/3/4? FAT32? NTFS?)
      • Did you install via Wubi?