Jump to content











Photo
- - - - -

Load Linux Mint installed on second disk first partition from grub4dos.

grub4dos linux-mint ubuntu

  • Please log in to reply
12 replies to this topic

#1 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 13 September 2019 - 04:16 PM

Load Linux Mint install located on second disk first partition from grub4dos.

 

In order to better test this distro I disconected the MBR HD (where 7, 10 and several VHDs and *wim(s) are located) and added an old small second disk where Linux Mint was instaled, full disk selected during install, it created a single (about 300 MB) MBR partition formated as ext4, AFAIK this distro uses Grub2 v2.2 as MBR (BootIce detects it as Grub2 and unknown PBR).

 

All was working very fine and I decided to connect again the previous disk and select by means of Bios wich disk to boot,  On mainboard Windows disk is pluged to Sata 1 and Linux disk is pluged to Sata 2, this has been working fine so far.

 

I usually load grub4dos from an entry on BCD to boot grldr.mbr wich in turn loads grldr and menu.lst to load a bunch of Isos from Isos folder on (hd0,6).

 

I would like to also have an option on my menu.lst to boot  to (hd1,0) where Linux Mint is located, to avoid changing HD boot order on the Bios every time I want to boot from the other disk.

 

 

I have tried:

title Boot from second HD\nboot Linux Mint Cinnamon x64
chainloader (hd1,0)+1
boot

Grub4dos-0.4.6a( 2019-08-09) said can't load that, then I tried:

title linuxmint-19-cinnamon-64bit-v2\nBoot linuxmint-19-cinnamon-64bit-v2 from second HD 
root (hd1,0)
kernel /vmlinuz
initrd /initrd.img

It starts booting fine (text mode) but then it just freezes.

 

Any ideas or suggestions will be highly appreciated.

 

 

Best Regards

 

alacran



#2 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 14 September 2019 - 01:10 AM

After an exhaustive Google search and a few more tests found I need to use vmlinuz and initrd.img located into boot folder.

 

This also give me the option to edit respective title (or make several) on menu.lst to boot from any available vmlinuz and initrd.img (wich contain diferent kernel versions).

 

 

title linuxmint-19-cinnamon-64bit-v2\nBoot linuxmint-19-cinnamon-64bit-v2 from second HD
root (hd1,0)
kernel /boot/vmlinuz-4.15.0-62-generic root=/dev/sdb1 ro
initrd /boot/initrd.img-4.15.0-62-generic

 

NOTE: Since Linux Mint is based on Ubuntu, with little modifications this can be adapted to Ubuntu and derivatives.

 

alacran



#3 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 September 2019 - 07:25 AM

@alacran

 

JFYI:

"generic" adaptation translation from grub4dos to linux devices:

http://reboot.pro/to...ts-in-grub4dos/

 

Usually, but not always, Ubuntu derivatives can be booted using UUID:

http://reboot.pro/to...this-partition/

 

i.e. having a menu.lst entry that can boot a given kernel+initrd from *any* partition, calculating automatically the needed parameters.

 

:duff:

Wonko



#4 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 16 September 2019 - 09:26 PM

I found this info about reset/change forgoten password on Linux Mint, and wanted to share it:

 

https://www.orcus.de...nt_reset_pw.htm

 

@ Wonko

 

Thanks, good info as always. But for my needs the menu/title on my previous post seems easier to understand/remember.

 

alacran



#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 September 2019 - 11:40 AM

Thanks, good info as always. But for my needs the menu/title on my previous post seems easier to understand/remember.


Sure, but you will need to change it every time you move/switch disk order or move the distro, the idea was not to suggest you that your menu.lst entry is "wrong" (as it works just fine).

Still it is hardcoded (twice) so not very "portable".

Compare with (hypothetical/to be tested):
title linuxmint-19-cinnamon-64bit-v2\nBoot linuxmint-19-cinnamon-64bit-v2 from *any* HD
set kername=/boot/vmlinuz-4.15.0-62-generic
set irdname=/boot/initrd.img-4.15.0-62-generic
find --set-root %kername%
calc *0x82a0-31 | call Fn.2 | set LXVOLID=sd &; calc *0x829e&255+1 > nul &; set LXVOLID=%LXVOLID%%@retval%
kernel %kername% root=/dev/%LXVOLID% ro
initrd %irdname%

or:

title linuxmint-19-cinnamon-64bit-v2\nBoot linuxmint-19-cinnamon-64bit-v2 from *any* HD
set kername=/boot/vmlinuz-4.15.0-62-generic
set irdname=/boot/initrd.img-4.15.0-62-generic
find --set-root %kername%
uuid ()
set UUID=%?%
kernel %kername% root=/dev/disk/by-uuid/%UUID% ro
initrd %irdname%



:duff:
Wonko

#6 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 4 weeks ago

@ Wonko

 

From both of your suggested titles I liked better the second, it looks less complicated than the first one and easier to remember, anyway just to say I tested it and as expected it is working fine on actual install location but I have no dubt it will work from any HD and partition.

 

Only thing I have some dubts for use it, because if there are more than one /boot/vmlinuz-4.15.0-62-generic on other disks/partitions (maybe from other Linux Mint flavors or other distros, since I'm testing several Linux options not only Mint) it will boot always from the first /boot/vmlinuz-4.15.0-62-generic it finds.

 

When we specify exactly disk and partition (as in my title) we will be always sure we are getting what we want.

 

I think setting root by locating a different tag file (user created for each different distro) on your suggested title could also solve this issue.

 

Something like this (this is now Linux Mint 19.2 Cinnamon x64 [last updated version], less updates to download after install):

title Linux Mint 19.2 Cinnamon x64\nBoot Linux Mint 19.2 Cinnamon x64 from *any* HD
set kername=/boot/vmlinuz-4.15.0-62-generic
set irdname=/boot/initrd.img-4.15.0-62-generic
#Tag file to be created by user is Cinnamon19_2-x64 in this case
find --set-root /boot/Cinnamon19_2-x64
uuid ()
set UUID=%?%
kernel %kername% root=/dev/disk/by-uuid/%UUID% ro
initrd %irdname%

Now I will check how easy or difficult is to create this tag file on /boot/ or find other easier location and modify the title as required.

 

EDIT: Create or copy to /boot folder the Cinnamon19_2-x64 empty text file is not allowed from booted OS, maybe from command line can be done but so far I'm not very familiar with linux command line.

 

I have the following options:

 

1) Find a good program to read/write to ext4 from Windos in order to do it easier without OS restrictions.

 

2) Do it from the live Linux Mint used for install that I have on my USB AIO Multiboot.

 

3) So far I have been looking from Windows the files/folders located on etx4 using PartitionGuru, I can try to create or copy the file with this program.

 

 

alacran



#7 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 4 weeks ago

Just to confirm PartitionGuru let us drag and drop files from (Windows) NTFS to (Linux) ext4 and vice versa.

 

Then since I had file Cinnamon19_2-x64 empty text file already made, just ran PartitionGuru from Windows 7x64, selected second disk first partition, opened  /boot folder and only dragged and dropped the mentioned file there.

 

Later using the menu title from my previous post Linux Mint booted as expected.

 

alacran



#8 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 4 weeks ago

Good info for beginers on Linux Command Line:

 

https://tutorials.ub...for-beginners#0

https://www.cybercit...linux-commands/

https://www.ubuntupi...n-the-terminal/

 

After reading a little about Linux Command liine I found:

 

In order to create an empty text file on /boot folder we need special privileges that standard user do not have so we need to open a command terminal:

 

Control+Alt+t , to open a terminal, then on terminal type:

(If you want to verify your actual directory type pwd + enter key, and actual location will be shown)

cd /boot + enter key, to Change to /boot directory, once there type:

sudo touch Cinnamon19_2-x64 + enter key

 

Then user password is requested, and after typing the password (+ Enter key) the command is executed creating the empty text file (witout extension) named Cinnamon19_2-x64 that I used in previous posts as an example for my tag file.

 

alacran



#9 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Yep a tag file is a good idea, but you can also use the actual volume UUID without needing to write any file on the volume/partition.


:duff:
Wonko

#10 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 4 weeks ago

I think the tag file would be even more versatile, since if I make an image (with Clonezilla Live) of the OS partition and latter I apply it to another HD it will be there and will remain valid to set root to the OS on the new HD.

 

From Clonezilla Page on Features:

 

One image restoring to multiple local devices is supported.

 

The UUID is unique and I assume it will be different when OS is applied to another HD.

 

alacran



#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

I think the tag file would be even more versatile, since if I make an image (with Clonezilla Live) of the OS partition and latter I apply it to another HD it will be there and will remain valid to set root to the OS on the new HD.

From Clonezilla Page on Features:

The UUID is unique and I assume it will be different when OS is applied to another HD.

alacran


Sure it is Unique ( and Universally Unique as a matter of fact, otherwise it would be a ID ;)).
But is it Unique if you actually clone/image and apply a filesystem?
Or - more loosely - can the UUID be duplicated?
https://unix.stackex...uid-2-same-uuid

By the way,
I also think UUID (Universally Unique IDentifier) is a weird name. It should be called PGUID (Possibly Globally Unique IDentifier), or even better, just ARLN (A Reasonably Large Number).

One could use tune2fs -U <UUID> <device> under Linux.

But more generally, let's say that you have the "generic" find menu entry,

Until you have one (and one only) "/boot/vmlinuz-4.15.0-62-generic" on *any* connected disks, it will work just fine.

The moment you add another "/boot/vmlinuz-4.15.0-62-generic" there are three cases:
1) the "find --set-root" command will find the SAME (earlier version) that works just fine and you can use BOTH your grub4dos environment or the Linux to correct the issue
2) the "find --set-root" command will find the NEW (version) that works just fine and you can use BOTH your grub4dos environment or the Linux to correct the issue
3) the "find --set-root" command will find EITHER the SAME (earlier version) or the NEW one BUT - for whatever reasons the found one fails to boot Linux, so you have only grub4dos to correct the issue

To correct the issue you can (from within grub4dos), using the iniline editor:
1) calculate find the UUID of the volume where the instance you want to boot is and replace the line:
find --set-root %kername%
with
find --set-root uuid () <UUID you found>
2) or replace the line:
find --set-root %kername%
with
root (hdm,n)

then, as soon as you are in the booted Linux you can re-do the same changes in menu.lst to make them "sticky".

One could also make a small grub4dos batch "scanning" a (reasonable) number of disks/volumes for the wanted file and present results (if more than one) to the user to choose which one to boot from or proceed to the "only" one found.

 

Please note how this (hypothetical) menu entry:

title linuxmint-19-cinnamon-64bit-v2\nBoot linuxmint-19-cinnamon-64bit-v2 <some more id details>

set kername=/boot/vmlinuz-4.15.0-62-generic
set irdname=/boot/initrd.img-4.15.0-62-generic

# change the following to any other (hdm,n)
root (hd1,0)

uuid ()
set UUID=%?%
kernel %kername% root=/dev/disk/by-uuid/%UUID% ro
initrd %irdname%

 

is still "hard coded", but it is hardcoded in one place only, so it is easier to edit in case of need.

:duff:
Wonko



#12 alacran

alacran

    Gold Member

  • .script developer
  • 1106 posts
  •  
    Mexico

Posted 4 weeks ago

@ Wonko

 

Thanks, your comments are always wellcome my friend.

 

Well, now I know UUID is unique only on first install, later when we make an image and re-apply it is not unique anymore.

 

About the menu alternatives: There is usually many ways to do something, and the way to do it depends of knowledge/skills of the person doing it.

 

I know you (and also steve6375, tinybit, yaya, karionix and other members) have better knowledge/skills than me on this (grub4dos) subject and it is always good to learn something, that was the reason I became a member on this forum 10 years ago.

 

alacran



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Well, now I know UUID is unique only on first install, later when we make an image and re-apply it is not unique anymore.

 

 

Yep :) , hence the quote of the alternate definition as ARLN, but the identifier remains (virtually) unique (as the generation is usually "random enough" and the possibilities of a collision are rather low).

 

It is the procedure used to clone/image/apply that may make a duplicate (or a collision) that needs to be used with care.

 

If you prefer is when you "apply" or "restore" the SAME image TWICE on the same device (or you have two cloned devices) that the possible collision issue arises, each of the two copies has its own "unique" ID that happens to be non-unique only because the other copy is actually a copy).

 

 

For "MS" filesystem where there is not a "real" UUID (but rather the volume serial) see:

http://reboot.pro/to...ed-drive-image/

 

The possibility - at least for FAT filesystems - of a collision is not-so-trivial, given the right (fictional) scenario, JFYI:

https://msfn.org/boa...&comment=987748

 

:duff:

Wonko







Also tagged with one or more of these keywords: grub4dos, linux-mint, ubuntu

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users