Jump to content











Photo
- - - - -

Dual boot install - Ubuntu and Debian - won't boot


  • Please log in to reply
15 replies to this topic

#1 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 11 August 2019 - 09:41 AM

I have a second hard disk on my laptop on the cd rom slot. This hard disk has one encrypted with VeraCrypt partition and it had one system partition with Windows 7 also encrypted with VeraCrypt. I deleted the system partition and separate it on three logical partition - one for Ubuntu, one for Debian, and one swap partition. I installed first Ubuntu and then Debian. In the end of the Debian installation it asked me where to install grub and i selected the second hard disk. After that i tried to boot from the second hard disk but it won't boot. I think grub for some reason is not installed and the VeraCrypt bootloader is still installed. How to fix this?



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 August 2019 - 11:36 AM

I am not sure to understand (actually I am quite sure I don't understand).

 

You don't need anymore  the Veracrypt bootloader, right?

 

But what happens when you boot?

 

I mean "nothing", an error message, a blinking cursor, a J or G in the top left of the screen, etc.?

 

Have you tried re-installing grub (and is it grub2, right)?

 

Is it EFI/GPT or BIOS/MBR?

 

https://www.debian.w.../reinstall-grub

https://superuser.co...stall-grub2-efi

 

:duff:

Wonko



#3 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 11 August 2019 - 12:39 PM

No, i don't need the Veracrypt bootloader. When i boot i see a black screen with blinking cursor which is how the veracrpypt bootloader screen looked before, when i had Windows 7 installed.

I think it is MBR. It's an old model laptop - Thinkpad T420.

I tried installing grub from live usb with the command grub-install /dev/sdb but it didn't worked. Here is a screenshot. sdb is my second hard disk.

Screenshot.png



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 August 2019 - 01:14 PM

Good. :)

 

Maybe it is partedmagic part of the issue you have two errors in the screenshot, one is about "etc/slackware-version" (that is likely to be due to partedmagic, but you have also a "/boot/grub" error, which sounds more like the (stupid) grub2 installer wants to write to the MBR (and hidden sectors) BUT ALSO copy the needed files /boot/grub.

This usually happens on the /boot directory, but from the screenshot it seems like you haven't mounted any volume, see also:

https://www.gnu.org/...02dinstall.html

 

Anyway, you lied :w00t: from the screenshot you have 5 (five) partitions:

sdb1

sdb2

sdb5

sdb6

sdb7

the sdb1 size, 1 KB, makes no sense, it is probably a leftover of some kind.

 

Try running a:

fdisk -l

and post the resulting screenshot, I would advice to make sure that the voiumes/partitions on that hard disk are OK before re-attempting installing grub2.

 

:duff:

Wonko



#5 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 11 August 2019 - 01:34 PM

Yes, i have noticed this sdb1 partition, but i don't know how did appeared. I didn't create it.

This is a screenshot from 'fdisk -l':

Screenshot at 2019-08-11 16-27-25.png  



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 August 2019 - 02:16 PM

It's a "queer" setup.

 

The sdb1 is actually the "whole" extended partition (as seen by fdisk).

 

Usually (but there is no actual "strict rule" about it that I know of) a disk has first the primary partition and the extended partition is the last one (followed by the logical volumes inside extended, that are numbered starting from 5).

 

I wouldn't be surprised that the grub-install script got confused by this setup.

 

You could try:
1) to mount the /sdb5 (presuming it is the partition where the linux you want to boot is, otherwise the sdb6) to (say)  /mnt

2) to use the --boot-directory= parameter

as in the already given link:

https://www.gnu.org/...02dinstall.html

or better here:

https://www.gnu.org/...rub_002dinstall

 

I.e.:

mount  /dev/sdb5 /mnt

grub-install --boot-directory=/mnt/boot /dev/sdb

 

It shoudn't -even if it doesn't work - create any particular issue. :unsure:

 

:duff:

Wonko



#7 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 11 August 2019 - 03:08 PM

These commands worked. Thanks! Now i can boot to grub screen.

Any idea why this strange partition table setup have happened? 



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 August 2019 - 04:16 PM

These commands worked. Thanks! Now i can boot to grub screen.

Any idea why this strange partition table setup have happened?

Well, the "usual" (but as said I don't really think that is carved in stone anywhere) when partitioning a disk is:
1) create one (or more, up to three) primary partition
2) create one (and only one is possible) Extended partition covering the remaining unpartitioned space.
3) create as many volumes as you like inside the Extended partition
 
On MBR the entries for #1 and #2 would be written to the corresponding entry in the partition table and fdisk (and lblk) would read them as follows (let's say on sdb), in the case of three primaries and an extended:
Slot #1 -> sdb1 Primary
Slot #2 -> sdb2 Primary
slot #3 -> sdb3 Primary
slot #4 -> sdb4 Extended
then they would run the chain of logical volumes and assign them numbers in the order they are found, i.e.
sdb5 first volume inside extended
sdb6 second volume inside extended
etc.
 
In your case of only one primary, it would be:
Slot #1 ->sdb1 Primary
Slot #2 -> sdb2 Extended
then
 
sdb5 first volume inside extended
sdb6 second volume inside extended
etc.
 
What has been done on your disk is simply:
1) create an Extended partition
2) create a Primary partition
3) create three volumes inside extended
OR (it won't change the result:
 
1) create an Extended partition
2) create three volumes inside extended
3) create a Primary partition
 
Then - usually - the grub2 is installed partly (the boot code) to the MBR and hidden sectors  and partly (the stage 1.5 or second stage or whatever it is called + all the installable modules + all the madness that is auto-rebuild/update stuff + the actual grub.cfg) to a volume.
 
The stupid (did I say stupid?) grub4dos-install script EITHER:
a. tries to copy the files to sdb1 (which is not possible as an Extended partition is just a "container" and contains no filesystem, nor space to store the files)
OR:
b. tries to copy the files to the first primary partition it finds (sdb2) which won't as well work in your case because it is NTFS
AND (on the second attempt):
c. cannot detect that there is no volume mounted and just errors out
 
As said since it is actually a non-common partitioning scheme I find nothing particularly "wrong" in the fact that the script fails to deal with the situation, I am calling it stupid because it is provided as if it was a failproof/foolproof tool (it isn't) and there is NOTHING explicit about what to do when it fails, nor the error produced are actually explicative.
 
Imagine that you had printed on screen (say):
writing GRUB2 boot code to the MBR of sdb
OK ... done.
writing  GRUB2 second stage to sdb1/boot/grub
Oh-Oh I cannot copy to sdb1/boot/grub path sdb1 is an Extended partition type 0x0F
writing  GRUB2 second stage to sdb2/boot/grub
Oh-Oh I cannot read sdb2/boot/grub path it is a Primary partition 0x07 with NTFS format
Oh-Oh there is no volume mounted ...
... aborting ...
please re-run grub-install specifying in the --boot-directory= parameter the mounted volume path you want to install second stage to
 
It would have made the situation clearer at a glance.
 
What I really-really hate :ranting2:  is when I find something like this (mind you the SuperGrubDisk in itself is a very, very good project :)) tutorial (calling it "wizard" already irks me):
https://www.supergru...per-grub2-disk/
 

The most probable output for the command is:
Installation finished. No error reported.
That means that the installation was successful. When you reboot Grub menu should be alive again.

 
:duff:
Wonko

#9 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 11 August 2019 - 07:29 PM

Thanks, for the explanation.  



#10 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 12 August 2019 - 09:41 AM

Today i had another problem. I login to Ubuntu and run 'apt upgrade' and after the updates were installed i rebooted and i get grub screen with this message:

error symbol 'grub_term_highlight_color' not found
grub rescue>

My guess is that during the ubuntu updates installation grub was broken somehow. Do i need to run the previous two commands again to fix this and will this happen every time Ubuntu install updates?



#11 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 741 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 12 August 2019 - 10:27 AM

@Peter80: Probably you just need to run the grub-install command manually. Will it happen again after updating? Maybe, so be prepared to fix this when it happens. If you are installing updates that affect the kernel, normally the OS is smart enough to auto-update GRUB2 as well.

 

To my knowledge Ubuntu is based on Debian, so reading up on Debian-focused guides will help with managing Ubuntu. I do not use Ubuntu myself, but I do use Debian.



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 August 2019 - 11:29 AM

@Peter80
No, you are getting to the grub> prompt, so grub in itself should be fine (i.e. it actually boots to grub :)), but most probably the update broke something in the configuration file or in the modules or in the stupid (did I say stupid) auto-magical rebuilding of the configuration file that usually happens when you update.

You will find the issue "error symbol 'grub_term_highlight_color' not found" reported all over the internet, with the usual advice to re-install GRUB2 (i.e. re-running grub-install).
Of course it works, but it will probably break again at next update until you re-configure grub from within the Ubuntu (and/or Debian):
https://bugs.launchp...b2/ bug/1289977

So you need to run the "sudo dpkg-reconfigure grub-pc", but of course you need to run it from the booted system, and in order to do so it would be easier to re-install the GRUB2 as you did yesterday, still you should IMHO try to boot manually (as learning how to do so will save your butt in the future when you happen to have similar GRUB mis-configuration issues), then run the above command and then a: "sudo update-grub" to run the automagic script that will reset again your grub.cfg file.

If you post the EXACT version of the Ubuntu you are running we may be able to suggest the exact sequence of comnands to be typed at the grub rescue> command line, loosely it should be:
set prefix=(hd1,5)/boot/grub
insmod (hd1,5)/boot/grub/linux.mod
set root=(hd1,5)
linux /vmlinuz root=/dev/sdb5 ro
initrd /initrd.img
boot


You may want to run:
ls (hd1,5)
ls (hd1,5)/boot
ls (hd1,5)/boot/grub

in order to make sure that the paths are correct.

:duff:
Wonko

#13 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 12 August 2019 - 01:30 PM

I just run the previous two commands and it fixed the issue. It looked more simple solution than typing the commands in grub rescue terminal.
I am using Ubuntu 18.04 LTS, but i could install grub on Debian partition. Maybe Debian deal differently with installing updates and will not break grub.



#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 August 2019 - 02:07 PM

I just run the previous two commands and it fixed the issue. It looked more simple solution than typing the commands in grub rescue terminal.
I am using Ubuntu 18.04 LTS, but i could install grub on Debian partition. Maybe Debian deal differently with installing updates and will not break grub.

Yep :) , as said that is easier, the manual approach was given as a recommended (but entirely optional) exercise, useful if the same or similar issue happen when you don't have with you a live distro on CD/DVD or on USB stick.

Anyway point is that you need to "properly" set the install of GRUB2 by running:
"sudo dpkg-reconfigure grub-pc"
or whatever other command is needed in order to (hopefully) avoid the same issue at next upgrade/update.

Personally, as a preventive measure, I would add *somewhere* a grldr.exe (from grub4dos), which you should be able to run from GRUB2 rescue mode with a simple
linux (hdx,y)/grldr.exe
(needs to be tested, maybe you need to insmod the linux module, it depends o the specific GRUB 2 build)
optionally with a menu.lst with entries for the systems you are booting.

Actually (personally-personally) I would rather use grub4dos INSTEAD of GRUB2 on a BIOS machine.

:duff:
Wonko

#15 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 741 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 12 August 2019 - 03:19 PM

@Peter80: In addition to learning how to use the GRUB rescue prompt, I also recommend that you grab a copy of Super GRUB2 Disk. You can boot it from a flash drive or as an ISO. It should detect any Windows/Linux distro you have installed (and probably most other PC OSes as well). I've used it quite a bit to get Linux out of a pinch when it wouldn't boot after updating. Once in the OS, you can run whatever commands are necessary to fix issues.

Another tool I recommend is System Rescue CD. It is based on Gentoo, but it should allow you to chroot/manually mount any Linux so you can do repairs. This tool is useful when other tools fail to boot Linux.

#16 Peter80

Peter80

    Frequent Member

  • Advanced user
  • 115 posts

Posted 12 August 2019 - 07:56 PM

I have System Rescue CD on my multiboot usb drive. Will try to install Super GRUB2 Disk on it too. Thanks.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users