[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to Boot with LVM

On Thursday, September 10, 2015 at 10:00:06 AM UTC-5, Pascal Hambourg wrote:
> ray a écrit :
> > I have only been able to boot the HDD instance.  When I navigate to
> > the SSD instance, nothing is there.
> Sorry, I should have mentionned that I never used rEFInd (fortunately
> never needed it) and don't know how it works and what it looks like.
> Could you describe what it displays step by step ?
> >> /dev/sdf is one of the SSD used for RAID 0 and LVM, right ?
> >
> > /dev/sdf is a HDD, no md or LVM.
> I was confused because you wrote in a previous post :
> > sda, sdb 32GB + 32GB, RAID0 - md0, LVM, GParted shows 1MB reserved, 1 GB (EFI)
> > sdc, sdd 64GB + 64GB, RAID0- md1, md127, LVM, GParted shows 1MB reserved, 1 GB (EFI)
> > sde, sdf 120GB + 120GB, RAID0- md0, md126 LVM, GParted shows 1MB reserved, 1 GB (EFI)
> > sdg, sdh are 2 and 4 GB HD, sdg currently hosts debian8.+q++q
> So it looks like some device names changed.
> >>> root@mc:/boot/efi/EFI# grub-install /dev/sdf
> >>> Installing for x86_64-efi platform.
> >>> Installation finished. No error reported.
> >>
> >> The device name is not used by grub-install with an EFI target.
> >> You could have tried to use the option --boot-loader-id I mentioned in
> >> a previous post.
> >
> > Which device name is not used by grub-install?
> Whatever you type as the device name in the command line, /dev/sdf  here.
> > I did not find a way to use --boot-loader-id.  I googled this exact
> phrase and did not find anything but this posting.  How do I use it?
> > I did not find a way to use --boot-loader-id.  I googled this exact
> > phrase and did not find anything but this posting.  How do I use it?
> It is describonned in grub-install manpage. Just type "man grub-install"
> in the command line to read it.
This is one place I fell down, my instance of grub-install did not have that commend.

> >>> root@mc:/boot/efi/EFI# file /boot/efi/EFI/debian/grubx64.efi
> >>> /boot/efi/EFI/debian/grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
> >>> root@mc:/boot/efi/EFI# efibootmgr --verbose | grep debian
> >>> Boot0000* debian    HD(1,GPT,87471e98-b814-4aa9-b2bc-ea4669c75565,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
> >> Looks as expected. You can check with blkid which partition has
> >> PARTUUID=87471e98-b814-4aa9-b2bc-ea4669c75565. If you wonder about the
> >> formard / in the boot entry pathname, that's because the UEFI uses
> >> MS-style path.
> > blkid shows PARTUUID=87471e98-b814-4aa9-b2bc-ea4669c75565 to be /dev/sdf1.
> This is consistent with /dev/sdf1 being mounted on /boot/efi.
> >>> A baffling point:  In rEFInd the path is /boot/efi/EFI/debian/grubx64.efi
> >> How is it baffling ? The EFI system partition is mounted on /boot/efi
> >> and the path relative to the partition filesystem root is
> >> /EFI/debian/grubx64.efi. The EFI firmware does not care about where you
> >> mount the EFI system partition.
> >
> > Baffling:  Viewing with rEFInd, I see /boot/efi/EFI/debian/grubx64.efi
> What do you mean by "viewing with rEFInd" ? AFAIK, rEFInd is just a boot
> loader, and pathnames such as /boot/efi/EFI/debian/grubx64.efi are used
> only in a running system after the kernel takes over.
> >>> After booting up into the HDD instance, I get:
> >> Booting how ? On its own or from rEFInd ?
> > This is after booting on its own.
> Whether you boot the HDD Debian instance from rEFInd, the GRUB EFI
> installed on HDD or any other boot loader should not make any difference
> in the mounted filesystems...
> >> What's mounted on /boot/efi ?
> > I am not sure what it means 'what's mounted on ...'.
> If "mount" or "df" show a line with /dev/sdf1 and /boot/efi, it means
> that /dev/sdf1 is mounted on /boot/efi.
It took me many times rereading this for it to sink in.

> > #mount | grep boot returns empty
> > #mount | grep efi returns efivarfs on /sys/firmware/efi/efivars (...)
> Looks like nothing is mounted on /boot/efi, explaining why it looks
> empty. But we have yet to explain why nothing is mounted.
> Can you check the contents of /etc/fstab ?
> > root@md:/home/rayj# df -h /boot/
> > Filesystem      Size  Used Avail Use% Mounted on
> > /dev/sdf2       1.4T  4.2G  1.3T   1% /
> Irrelevant. We are interested in /boot/efi, not /boot.
> > OK, a little more reading tells me /dev/sdf2 is mounted on /boot
> No, it is the root filesystem, mounted on /. There is no separate /boot.

It looks like I lost my previous response to this conversation in my excitement.
After rereading your messages and Davids', I found I needed to mount /dev/sdf1 on /boot/efi since I didn't find it there.  

The first fault was:
# grub-install /dev/sdf --target=x86_64-efi  --bootloader-id=test --recheck
Unrecognized option `--target=x86_64-efi'

I found from grub-install --help, there was no --bootloader-id=  or --recheck.
After some checking, I
#apt-get install grub2

Now, grub-install had all the functions.

None of the boot directories were updated.  Research showed that I needed to:

I was able to use PCManFM to see the new files.

I rebooted.  Now there are two choices Debian and test.

I booted into Debian, but I could not go into the boot directories with PCManFM, I had to sudo into them in a shell.

I rebooted and chose test.  It booted up.  But it is not the same instance of Debian, there is a different boot (in fact two boots -  /boot and /boot/efi). Both on SSDs not the HDD.  The / and home are on a different SSD.  And the desk top was not the same.  The /, /boot, and /home are on LVM.

Yes, this is a test case.  While I learned a lot, the result is not what I was looking for.

I was looking for a way to rename the instance I have so I could build a new instance using Debian with a specific distribution of partitions.  

I am not sure how to recover.  I don't really care about the new partitions across the drives, I can fix that.  But I did not rename my current instance so I don't know how to install a new, controlled placement since Debian will crash into itself again - this is where I started.

Now I have two, but one is overlayed ontop of some of the locations I was planning on using for my target system.  I am reluctant to just remove the current 'debian' instance and attempt a fresh install; if/when I screw up the first (few) attempts, I won't have an intact instance from which to work.

Any suggestions?

Reply to: