Cfxtrjtrk

I went into Live CD and activated Terminal. Then, I typed gksu nautilus to gain temporary access to my root directory. Once the Manager window opened, I clicked on File System and navigated to the /etc/default/grub directory. I then double clicked on the Grub file to make changes to the TIMEOUT and TIMEOUT_QUIET.

I saved the file after I made the changes. Then I went back to the terminal mode and typed:

gksu update-grub

The error message I got was:

Can not find a device for / (is /dev mounted?)

I'm not sure what to do at this point. How can I run update-grub to update the changes? Thanks in advance for your help. Please be very detailed and specific with your response as I am totally new to this environment.

Phase 1 - Note: don't use a Live CD.

• In your Ubuntu open a terminal (press Ctrl+Alt+T at the same time)


• Type gedit admin:///etc/default/grub
  This will run text-editor gedit, if you're using another one just type the name of it instead of gedit.
  


• Make the changes you would like to make and save them.


• Close gedit.
  Your terminal should still be open.
  


• In the terminal type sudo update-grub, wait for the update to finish.


• Reboot your computer.

Phase 2 - After you have logged into your system

• Open a terminal again (Ctrl+Alt+T).


• Type in the terminal gksu gedit /etc/default/grub
  


• To see the grub-menu at boot time,
  comment or remove the following line: GRUB_HIDDEN_TIMEOUT=0
  
  
  
  
  • To comment, add # at the beginning of this line, the result will be #GRUB_HIDDEN_TIMEOUT=0
    
  
  
  
  


• Save the file.


• Again in the terminal run sudo update-grub.

If seeing the grub menu at boot is the only thing you want you should undo earlier changes to the file.

You are getting that message because the Live CD doesn't mount a writeable filesystem. It's only meant to be used to try-out Ubuntu or to rescue a damaged system. Executing a sudo update-grub only works on an installed version of Ubuntu, where you have write access to the underlying GRUB files (and on a Live CD, you do not).

You can do update-grub from a live CD on an installed Ubuntu Distro (although I assume this works with any [debian-based?] linux distro. It is "required" (there may be other methods but knowing this one, I don't care about them at all) if you clone your drive and have already installed the new one in the computer. I mention cloning here extensively, because in a sense the update-grub step is a subset of it and the approaches have the same basis during a live session. Also this method was discovered through searching in the context of cloning. You can take what you need from it if you are not cloning, and your process will be simplified.

I should qualify this here; importantly for cloning, not importantly for just doing update-grub: I have done this on BIOS systems only. I have not attempted it on a UEFI system. The UEFI system requires a FAT partition for boot loading and I have not tested whether this partition should just come along for the ride during the cloning copy steps. I expect that it does affect the required [bind-]mounting that synthesizes the native grub environment during the live session...

This is detailed on this page: http://frugaltech.happystoic.com/ssdlinux. I have used this method many times, and you can swap hard drives around ad-infinitum using it. Swapping physical hard drives becomes so trivial this way, it is tempting to make it its own hobby and/or try to fix other people's messed-up computers.

The following may be a helpful paraphrase of what you will find there:

1. Ctrl+Alt+T for Bash terminal and enter a superuser shell (sudo -s) during a live session.



2. 
   

   mount the full install drive partition (that which is [or will become] your permanent Linux filesystem root directory).

   
   
   

   2a. If the full install already exists on your hard drive, skip to (2). IF you are CLONING: [based on the assumption that you are not doing a fresh install, since this is all entirely automatic in that case] if your full install does not already exist on this partition, now is the time to simply

   
   
   

   rsync -a /existing/linux/filesystem/live-mount-point/ /new/linux/filesystem/live-mount-point/ 
   
   

   
   
   

   [these mount points are purely with respect to the live session environment - in Ubuntu they are generally of the form "/media/ubuntu/???"] it onto the new drive [partition].

   
   
   

   2b. Other operating system full installs can be handled in the same way here. I have generally used a Windows-based resource to bulk-copy windows partitions to new drives in advance but I have also used rsync and it worked for Win XP (assuming you have support for the correct partition format, such as ntfs; I think the live session media do generally come inclusive of alternative format support). Just be careful about your spelling and use the trailing / in the source directory if you are fully naming the target.

   
   



3. bind-mount the live /dev, /proc, and /sys directories to their respective directories on your [mounted] permanent full install partition you are seeking to use. The script detailed in the link above accomplishes this very elegantly with a "for" statement. Also, the script given does not need to be executed as a script, per se. It can be entered from the bash prompt, line-by-line.




4. chroot to the permanent full install partition. After doing (3) and (4), the system now "virtually resides" in your "final filesystem" and GRUB will function homogeneously. Without these steps, grub will assume your system is simply a live session, and I don't know specifically what it does in that case but sufficiently it is not the desired outcome, as to which was alluded above in this thread.




5. run grub-install on the /dev/sdX (drive, not mount point) that corresponds with the permanent install (or whichever drive will host GRUB if a multi-drive [, multi-boot] system). Flexibility here may depend on your vintage and BIOS. As far as I know running "grub-install" does nothing harmful if it not necessary, so I always do it if I am using this live session method.




6. run update-grub and it will act as if the running system is nested in the future permanent partition, discovering all kernels and bootable OSes you may have available.



7. 
   

   If you have not physically changed hard drives, skip to (5). Otherwise edit or verify your /new/linux/filesystem/live-mount-point/etc/fstab file to ensure correct file system structure for your [new] environment. If you are at this level you surely already know about using blkid to harvest UUIDs for fstab.

   
   
   

   IMHO: you should always use UUIDs in fstab (not "dev/sdXY" form) since in its own scope it is immune to physical hard drive reconfiguration, other than the degree to which this requires literal updates of UUID values (such as if at some point in the future you install an additional HDD for your /home directory, etc.). It is simply the most fundamental, robust, and invariant approach.

   
   


8. 
   

   exit the chroot, exit supershell, exit bash, shut down, and start the system without the live media. You should now be where you intended.

   
   
   

   Importantly NOTE: Arguments for mount and chroot are directories (generally, MOUNT POINTS such as /mnt/?? or /media/??) corresponding to the live session. In most if not all cases a full install resides in its own partition, so the terms "directory" and "mount point" are essentially synonymous here. Argument for grub-install is a PHYSICAL DRIVE (generally /dev/sdX, where "X" is a letter corresponding to the drive in your system, sda, sdb, etc. and it should not depend on the session).

   
   

You should now be done. I have simultaneously cloned Windows (XP and 7) in various permutations alongside Ubuntu and Puppy using this method and it has not failed me. I think you can use a live medium of a different distro (I have only used different Ubuntu flavors and Mint for this however) as long as they provide the version of GRUB you intend to use. You can move partitions around, swap drives, combine other OS installs, and clone to or from SSD using this. I can only speak to it working in the same machine however. I assume drivers that might be required for a different machine might have been skipped during your previous full install. My rule of thumb is switching drives in a computer requires this method, but switching computers with a drive requires a full [re-]install.

Perhaps someone can debunk this..?