Page 1 of 1

BIBM boot partition confusion

Posted: Thu Jan 21, 2016 3:34 pm
by eldiener
I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint 17.1 and Ubuntu 15.0.4. Each one has its own separate boot, root, and home partitions. The boot partitions for both are next to each other in a logical drive on my first hard drive, with the Ubuntu boot partition coming first. The root and home partitions are next to each other in a logical drive on my second hard drive, with the Ubuntu partitions coming first. The boot partitions of both use grub2, with menus in grub2 for other OSs also besides their own on top, but I ignore the other OSs since I use BIBM for multi-booting. I have BIBM pointing to their boot partitions and it has been working fine. I also use BIBM to multi-bbot lost of other OSs beside Ubunto and Mint on my first hard drive and it has been working fine.

I backup all my partitions to external disk drives using gparted live. I had problems in the past using BIBM to do this, as it was not seeing my external hard drives, and gparted live works fine for me.

Recently, after backing up my partitions, I attempted to upgrade Ubuntu from 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started the process, walked away from my computer, and when I came back my computer was completely shutdown. I rebooted into BIBM, booted into Ubuntu, but something had gone wrong with the update since booting back into Ubuntu produced a broken implementation. So I booted gparted live, deleted my Ubuntu boot, root, and home partitions, and restored my backup partitions to their original places on my hard disks.

I then went to boot back into Ubuntu from my BIBM boot menu to see if my Ubuntu 15.0.4 would boot again. I did this before attempting to regenerate grub2 just to see if it would still work. What happened then in BIBM was very strange:

1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for Mint 17.1
2) Likewise when I booted into Mint 17.1, whose boot partition I never touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.

Huh ? Does anybody know what is going on ? No other partitions in my BIBM multi-boot were affected.

I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 ) successfully in BIBM by simply changing the boot partition for each one in BIBM maintenance. But I am still wondering what has happened.

It seems as if BIBM is somehow "pointing" to the wrong boot partitions for each now. I am aware that when I restored the Ubuntu boot partition with gparted live that while I am restoring the partition to the same place on my hard disk where it previously existed, the sda(n) order of partitions has changed. Is this confusing BIBM somehow ?

Re: BIBM boot partition confusion

Posted: Thu Jan 21, 2016 3:47 pm
by TeraByte Support
if you're dealing with volumes in extended partitions and using something
else, it's possible that something else wiped out the id for the volumes.
likewise if you don't have an embr and something changes the mbr order it
would change the id used for it.


"eldiener" wrote in message news:10923@public.bootitbm...

I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint 17.1 and
Ubuntu 15.0.4. Each one has its own separate boot, root, and home
partitions. The boot partitions for both are next to each other in a logical
drive on my first hard drive, with the Ubuntu boot partition coming first.
The root and home partitions are next to each other in a logical drive on my
second hard drive, with the Ubuntu partitions coming first. The boot
partitions of both use grub2, with menus in grub2 for other OSs also besides
their own on top, but I ignore the other OSs since I use BIBM for
multi-booting. I have BIBM pointing to their boot partitions and it has been
working fine. I also use BIBM to multi-bbot lost of other OSs beside Ubunto
and Mint on my first hard drive and it has been working fine.

I backup all my partitions to external disk drives using gparted live. I had
problems in the past using BIBM to do this, as it was not seeing my external
hard drives, and gparted live works fine for me.

Recently, after backing up my partitions, I attempted to upgrade Ubuntu from
15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started the
process, walked away from my computer, and when I came back my computer was
completely shutdown. I rebooted into BIBM, booted into Ubuntu, but something
had gone wrong with the update since booting back into Ubuntu produced a
broken implementation. So I booted gparted live, deleted my Ubuntu boot,
root, and home partitions, and restored my backup partitions to their
original places on my hard disks.

I then went to boot back into Ubuntu from my BIBM boot menu to see if my
Ubuntu 15.0.4 would boot again. I did this before attempting to regenerate
grub2 just to see if it would still work. What happened then in BIBM was
very strange:

1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for Mint 17.1
2) Likewise when I booted into Mint 17.1, whose boot partition I never
touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.

Huh ? Does anybody know what is going on ? No other partitions in my BIBM
multi-boot were affected.

I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 ) successfully in
BIBM by simply changing the boot partition for each one in BIBM maintenance.
But I am still wondering what has happened.

It seems as if BIBM is somehow "pointing" to the wrong boot partitions for
each now. I am aware that when I restored the Ubuntu boot partition with
gparted live that while I am restoring the partition to the same place on my
hard disk where it previously existed, the sda(n) order of partitions has
changed. Is this confusing BIBM somehow ?


Re: BIBM boot partition confusion

Posted: Thu Jan 21, 2016 4:40 pm
by eldiener
TeraByte Support wrote:
> if you're dealing with volumes in extended partitions and using something
> else, it's possible that something else wiped out the id for the volumes.
>
> likewise if you don't have an embr and something changes the mbr order it
> would change the id used for it.

I am not using embr and the mbr order definitely changed. I am assuming when you say "id" you are talking about BIBM's internal id for the volume rather than the actual disk label. How do I change BIBM's internal id to match the disk label again ?
>
>
> "eldiener" wrote in message news:10923@public.bootitbm...
>
> I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint 17.1
> and
> Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> partitions. The boot partitions for both are next to each other in a
> logical
> drive on my first hard drive, with the Ubuntu boot partition coming first.
>
> The root and home partitions are next to each other in a logical drive on
> my
> second hard drive, with the Ubuntu partitions coming first. The boot
> partitions of both use grub2, with menus in grub2 for other OSs also
> besides
> their own on top, but I ignore the other OSs since I use BIBM for
> multi-booting. I have BIBM pointing to their boot partitions and it has
> been
> working fine. I also use BIBM to multi-bbot lost of other OSs beside Ubunto
>
> and Mint on my first hard drive and it has been working fine.
>
> I backup all my partitions to external disk drives using gparted live. I
> had
> problems in the past using BIBM to do this, as it was not seeing my
> external
> hard drives, and gparted live works fine for me.
>
> Recently, after backing up my partitions, I attempted to upgrade Ubuntu
> from
> 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started the
>
> process, walked away from my computer, and when I came back my computer was
>
> completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> something
> had gone wrong with the update since booting back into Ubuntu produced a
> broken implementation. So I booted gparted live, deleted my Ubuntu boot,
> root, and home partitions, and restored my backup partitions to their
> original places on my hard disks.
>
> I then went to boot back into Ubuntu from my BIBM boot menu to see if my
> Ubuntu 15.0.4 would boot again. I did this before attempting to regenerate
>
> grub2 just to see if it would still work. What happened then in BIBM was
> very strange:
>
> 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for Mint
> 17.1
> 2) Likewise when I booted into Mint 17.1, whose boot partition I never
> touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
>
> Huh ? Does anybody know what is going on ? No other partitions in my BIBM
> multi-boot were affected.
>
> I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 ) successfully
> in
> BIBM by simply changing the boot partition for each one in BIBM
> maintenance.
> But I am still wondering what has happened.
>
> It seems as if BIBM is somehow "pointing" to the wrong boot partitions for
>
> each now. I am aware that when I restored the Ubuntu boot partition with
> gparted live that while I am restoring the partition to the same place on
> my
> hard disk where it previously existed, the sda(n) order of partitions has
> changed. Is this confusing BIBM somehow ?

Re: BIBM boot partition confusion

Posted: Thu Jan 21, 2016 7:41 pm
by TeraByte Support
just setup the boot item for the changes.


"eldiener" wrote in message news:10926@public.bootitbm...

TeraByte Support wrote:
> if you're dealing with volumes in extended partitions and using something
> else, it's possible that something else wiped out the id for the volumes.
>
> likewise if you don't have an embr and something changes the mbr order it
> would change the id used for it.

I am not using embr and the mbr order definitely changed. I am assuming when
you say "id" you are talking about BIBM's internal id for the volume rather
than the actual disk label. How do I change BIBM's internal id to match the
disk label again ?
>
>
> "eldiener" wrote in message news:10923@public.bootitbm...
>
> I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint 17.1
> and
> Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> partitions. The boot partitions for both are next to each other in a
> logical
> drive on my first hard drive, with the Ubuntu boot partition coming first.
>
> The root and home partitions are next to each other in a logical drive on
> my
> second hard drive, with the Ubuntu partitions coming first. The boot
> partitions of both use grub2, with menus in grub2 for other OSs also
> besides
> their own on top, but I ignore the other OSs since I use BIBM for
> multi-booting. I have BIBM pointing to their boot partitions and it has
> been
> working fine. I also use BIBM to multi-bbot lost of other OSs beside
> Ubunto
>
> and Mint on my first hard drive and it has been working fine.
>
> I backup all my partitions to external disk drives using gparted live. I
> had
> problems in the past using BIBM to do this, as it was not seeing my
> external
> hard drives, and gparted live works fine for me.
>
> Recently, after backing up my partitions, I attempted to upgrade Ubuntu
> from
> 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started the
>
> process, walked away from my computer, and when I came back my computer
> was
>
> completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> something
> had gone wrong with the update since booting back into Ubuntu produced a
> broken implementation. So I booted gparted live, deleted my Ubuntu boot,
> root, and home partitions, and restored my backup partitions to their
> original places on my hard disks.
>
> I then went to boot back into Ubuntu from my BIBM boot menu to see if my
> Ubuntu 15.0.4 would boot again. I did this before attempting to regenerate
>
> grub2 just to see if it would still work. What happened then in BIBM was
> very strange:
>
> 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for Mint
> 17.1
> 2) Likewise when I booted into Mint 17.1, whose boot partition I never
> touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
>
> Huh ? Does anybody know what is going on ? No other partitions in my BIBM
> multi-boot were affected.
>
> I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 ) successfully
> in
> BIBM by simply changing the boot partition for each one in BIBM
> maintenance.
> But I am still wondering what has happened.
>
> It seems as if BIBM is somehow "pointing" to the wrong boot partitions for
>
> each now. I am aware that when I restored the Ubuntu boot partition with
> gparted live that while I am restoring the partition to the same place on
> my
> hard disk where it previously existed, the sda(n) order of partitions has
> changed. Is this confusing BIBM somehow ?


Re: BIBM boot partition confusion

Posted: Fri Jan 22, 2016 2:46 am
by eldiener
TeraByte Support wrote:
> just setup the boot item for the changes.

I do not understand your last remark.

Currently BIBM identifies as the boot volume for Ubuntu a logical partition whose disk label is MINTBOOT and it identifies as the boot volume for Mint a logical partition whose disk label is UBUNTUBOOT. While this actually works correctly, due to the fact that I manually changed the boot partitions for Ubuntu and Mint to match BIBM's confusion, clearly BIBM's internals IDs for these boot volumes were messed up when I restored the backup Ubuntu boot partition and changed the order ( but not the position ) of the partitions on the hard drive.

How do I straighten out BIBM's internal ids for these logical volumes ?
Are you telling me that each time the logical order of partitions on a hard drive changes that BIBM cannot handle it properly ?

I would really like to understand this because whenever a partition restore is done in gparted, the old partition area gets deleted before a copy is done of the backup to the old partition's space on a hard drive. While this does not change the physical order of partitions on the hard drive it will almost always change the logical order. And there must be some way to sunsequently tell BIBM about this change so that it re-syncs up its own internal IDs to the correct physical partitions on the drive.

>
>
> "eldiener" wrote in message news:10926@public.bootitbm...
>
> TeraByte Support wrote:
> > if you're dealing with volumes in extended partitions and using
> something
> > else, it's possible that something else wiped out the id for the
> volumes.
> >
> > likewise if you don't have an embr and something changes the mbr order
> it
> > would change the id used for it.
>
> I am not using embr and the mbr order definitely changed. I am assuming
> when
> you say "id" you are talking about BIBM's internal id for the volume rather
>
> than the actual disk label. How do I change BIBM's internal id to match the
>
> disk label again ?
> >
> >
> > "eldiener" wrote in message news:10923@public.bootitbm...
> >
> > I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint 17.1
> > and
> > Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> > partitions. The boot partitions for both are next to each other in a
> > logical
> > drive on my first hard drive, with the Ubuntu boot partition coming
> first.
> >
> > The root and home partitions are next to each other in a logical drive
> on
> > my
> > second hard drive, with the Ubuntu partitions coming first. The boot
> > partitions of both use grub2, with menus in grub2 for other OSs also
> > besides
> > their own on top, but I ignore the other OSs since I use BIBM for
> > multi-booting. I have BIBM pointing to their boot partitions and it has
> > been
> > working fine. I also use BIBM to multi-bbot lost of other OSs beside
> > Ubunto
> >
> > and Mint on my first hard drive and it has been working fine.
> >
> > I backup all my partitions to external disk drives using gparted live. I
> > had
> > problems in the past using BIBM to do this, as it was not seeing my
> > external
> > hard drives, and gparted live works fine for me.
> >
> > Recently, after backing up my partitions, I attempted to upgrade Ubuntu
> > from
> > 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started
> the
> >
> > process, walked away from my computer, and when I came back my computer
> > was
> >
> > completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> > something
> > had gone wrong with the update since booting back into Ubuntu produced a
> > broken implementation. So I booted gparted live, deleted my Ubuntu boot,
> > root, and home partitions, and restored my backup partitions to their
> > original places on my hard disks.
> >
> > I then went to boot back into Ubuntu from my BIBM boot menu to see if my
> > Ubuntu 15.0.4 would boot again. I did this before attempting to
> regenerate
> >
> > grub2 just to see if it would still work. What happened then in BIBM was
> > very strange:
> >
> > 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for Mint
> > 17.1
> > 2) Likewise when I booted into Mint 17.1, whose boot partition I never
> > touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
> >
> > Huh ? Does anybody know what is going on ? No other partitions in my
> BIBM
> > multi-boot were affected.
> >
> > I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 )
> successfully
> > in
> > BIBM by simply changing the boot partition for each one in BIBM
> > maintenance.
> > But I am still wondering what has happened.
> >
> > It seems as if BIBM is somehow "pointing" to the wrong boot partitions
> for
> >
> > each now. I am aware that when I restored the Ubuntu boot partition with
> > gparted live that while I am restoring the partition to the same place
> on
> > my
> > hard disk where it previously existed, the sda(n) order of partitions
> has
> > changed. Is this confusing BIBM somehow ?

Re: BIBM boot partition confusion

Posted: Fri Jan 22, 2016 8:02 am
by TeraByte Support
the names are associated with the volumes not id, so you just go to
properties (in partition work) and change the name. You can use the use
volume labels options in settings to pull in the volume name for certain
file systems. The boot item would reference an id. Other tools may not
copy the volume name (os2 name compatible) or the id.


"eldiener" wrote in message news:10936@public.bootitbm...

TeraByte Support wrote:
> just setup the boot item for the changes.

I do not understand your last remark.

Currently BIBM identifies as the boot volume for Ubuntu a logical partition
whose disk label is MINTBOOT and it identifies as the boot volume for Mint a
logical partition whose disk label is UBUNTUBOOT. While this actually works
correctly, due to the fact that I manually changed the boot partitions for
Ubuntu and Mint to match BIBM's confusion, clearly BIBM's internals IDs for
these boot volumes were messed up when I restored the backup Ubuntu boot
partition and changed the order ( but not the position ) of the partitions
on the hard drive.

How do I straighten out BIBM's internal ids for these logical volumes ?
Are you telling me that each time the logical order of partitions on a hard
drive changes that BIBM cannot handle it properly ?

I would really like to understand this because whenever a partition restore
is done in gparted, the old partition area gets deleted before a copy is
done of the backup to the old partition's space on a hard drive. While this
does not change the physical order of partitions on the hard drive it will
almost always change the logical order. And there must be some way to
sunsequently tell BIBM about this change so that it re-syncs up its own
internal IDs to the correct physical partitions on the drive.

>
>
> "eldiener" wrote in message news:10926@public.bootitbm...
>
> TeraByte Support wrote:
> > if you're dealing with volumes in extended partitions and using
> something
> > else, it's possible that something else wiped out the id for the
> volumes.
> >
> > likewise if you don't have an embr and something changes the mbr order
> it
> > would change the id used for it.
>
> I am not using embr and the mbr order definitely changed. I am assuming
> when
> you say "id" you are talking about BIBM's internal id for the volume
> rather
>
> than the actual disk label. How do I change BIBM's internal id to match
> the
>
> disk label again ?
> >
> >
> > "eldiener" wrote in message news:10923@public.bootitbm...
> >
> > I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint 17.1
> > and
> > Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> > partitions. The boot partitions for both are next to each other in a
> > logical
> > drive on my first hard drive, with the Ubuntu boot partition coming
> first.
> >
> > The root and home partitions are next to each other in a logical drive
> on
> > my
> > second hard drive, with the Ubuntu partitions coming first. The boot
> > partitions of both use grub2, with menus in grub2 for other OSs also
> > besides
> > their own on top, but I ignore the other OSs since I use BIBM for
> > multi-booting. I have BIBM pointing to their boot partitions and it has
> > been
> > working fine. I also use BIBM to multi-bbot lost of other OSs beside
> > Ubunto
> >
> > and Mint on my first hard drive and it has been working fine.
> >
> > I backup all my partitions to external disk drives using gparted live. I
> > had
> > problems in the past using BIBM to do this, as it was not seeing my
> > external
> > hard drives, and gparted live works fine for me.
> >
> > Recently, after backing up my partitions, I attempted to upgrade Ubuntu
> > from
> > 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started
> the
> >
> > process, walked away from my computer, and when I came back my computer
> > was
> >
> > completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> > something
> > had gone wrong with the update since booting back into Ubuntu produced a
> > broken implementation. So I booted gparted live, deleted my Ubuntu boot,
> > root, and home partitions, and restored my backup partitions to their
> > original places on my hard disks.
> >
> > I then went to boot back into Ubuntu from my BIBM boot menu to see if my
> > Ubuntu 15.0.4 would boot again. I did this before attempting to
> regenerate
> >
> > grub2 just to see if it would still work. What happened then in BIBM was
> > very strange:
> >
> > 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for Mint
> > 17.1
> > 2) Likewise when I booted into Mint 17.1, whose boot partition I never
> > touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
> >
> > Huh ? Does anybody know what is going on ? No other partitions in my
> BIBM
> > multi-boot were affected.
> >
> > I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 )
> successfully
> > in
> > BIBM by simply changing the boot partition for each one in BIBM
> > maintenance.
> > But I am still wondering what has happened.
> >
> > It seems as if BIBM is somehow "pointing" to the wrong boot partitions
> for
> >
> > each now. I am aware that when I restored the Ubuntu boot partition with
> > gparted live that while I am restoring the partition to the same place
> on
> > my
> > hard disk where it previously existed, the sda(n) order of partitions
> has
> > changed. Is this confusing BIBM somehow ?


Re: BIBM boot partition confusion

Posted: Sat Jan 23, 2016 8:30 pm
by eldiener
TeraByte Support wrote:
> the names are associated with the volumes not id, so you just go to
> properties (in partition work) and change the name. You can use the use
> volume labels options in settings to pull in the volume name for certain
> file systems. The boot item would reference an id. Other tools may not
> copy the volume name (os2 name compatible) or the id.

I have done more investigation of the problem I found and here I give the results. I am using the names UBUNTUBOOT and MINTBOOT to refer to the actual partition labels on the hard disk:

1) When looking at the partitions UBUNTUBOOT and MINTBOOT in Partition Work of BIBM, the correct partitions and their contents are given.
2) When booting from UBUNTUBOOT and MINTBOOT as boot items in the Boot Menu BIBM is booting from the "wrong" partitions. Booting from UBUNTUBOOT is actually booting from the MINTBOOT partition and booting form MINTBOOT is actually booting from the UBUNTUBOOT partition.

I think what has caused this problem in BIBM is that the boot items when editing a boot menu choice is based on what BIBM has tagged as an internal logical partition identifier, and not as the actual physical position of the partition on the hard drive. For my two partitions whose disk labels are UBUNTUBOOT and MINTBOOT, the original logical partitions are:

sda10=UBUNTUBOOT
sda11=MINTBOOT

When I subsequently had to restore a backup of UBUNTUBOOT using gparted live, the process had to be to first delete the current UBUNTUBOOT partition, leaving free space in its place, and only then to restore my backup of UBUNTUBOOT into that free space area. After this was done the logical partitions were then:

sda11=UBUNTUBOOT
sda10=MINTBOOT

Note that the physical order of the partitions on the hard drive did not change.

But BIBM evidently does not know about this change when I boot from the boot item UBUNTUBOOT or MINTBOOT. Instead BIBM seems to consider the boot item UBUNTUBOOT as sda10 and the boot item MINTBOOT as sda11. So now in BIBM when I boot from UBUNTUBOOT I am booting from the MINTBOOT partition and when I am booting from MINTBOOT I am booting from the UBUNTUBOOT partition. This is the only surmise that makes sense to explain the problem as I see it in BIBM.

Is this a known problem with BIBM ? Is there any way to straighten out BIBM so that when the actual logical order of partitions change the BIBM boot item will pick up the change and correct its view of the booting partition ?

It does seem as if this problem manifests itself only with the booting partition. When I hide or unhide partitions when booting Ubuntu or Mint the correct partitions appear to be in effect even though my restore of Ubuntu root and Ubuntu home partitions also changed the logical order of those partitions on my second hard drive.

>
>
> "eldiener" wrote in message news:10936@public.bootitbm...
>
> TeraByte Support wrote:
> > just setup the boot item for the changes.
>
> I do not understand your last remark.
>
> Currently BIBM identifies as the boot volume for Ubuntu a logical partition
>
> whose disk label is MINTBOOT and it identifies as the boot volume for Mint
> a
> logical partition whose disk label is UBUNTUBOOT. While this actually works
>
> correctly, due to the fact that I manually changed the boot partitions for
>
> Ubuntu and Mint to match BIBM's confusion, clearly BIBM's internals IDs for
>
> these boot volumes were messed up when I restored the backup Ubuntu boot
> partition and changed the order ( but not the position ) of the partitions
>
> on the hard drive.
>
> How do I straighten out BIBM's internal ids for these logical volumes ?
> Are you telling me that each time the logical order of partitions on a hard
>
> drive changes that BIBM cannot handle it properly ?
>
> I would really like to understand this because whenever a partition restore
>
> is done in gparted, the old partition area gets deleted before a copy is
> done of the backup to the old partition's space on a hard drive. While this
>
> does not change the physical order of partitions on the hard drive it will
>
> almost always change the logical order. And there must be some way to
> sunsequently tell BIBM about this change so that it re-syncs up its own
> internal IDs to the correct physical partitions on the drive.
>
> >
> >
> > "eldiener" wrote in message news:10926@public.bootitbm...
> >
> > TeraByte Support wrote:
> > > if you're dealing with volumes in extended partitions and using
> > something
> > > else, it's possible that something else wiped out the id for the
> > volumes.
> > >
> > > likewise if you don't have an embr and something changes the mbr order
> > it
> > > would change the id used for it.
> >
> > I am not using embr and the mbr order definitely changed. I am assuming
> > when
> > you say "id" you are talking about BIBM's internal id for the volume
> > rather
> >
> > than the actual disk label. How do I change BIBM's internal id to match
> > the
> >
> > disk label again ?
> > >
> > >
> > > "eldiener" wrote in message news:10923@public.bootitbm...
> > >
> > > I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint
> 17.1
> > > and
> > > Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> > > partitions. The boot partitions for both are next to each other in a
> > > logical
> > > drive on my first hard drive, with the Ubuntu boot partition coming
> > first.
> > >
> > > The root and home partitions are next to each other in a logical drive
> > on
> > > my
> > > second hard drive, with the Ubuntu partitions coming first. The boot
> > > partitions of both use grub2, with menus in grub2 for other OSs also
> > > besides
> > > their own on top, but I ignore the other OSs since I use BIBM for
> > > multi-booting. I have BIBM pointing to their boot partitions and it
> has
> > > been
> > > working fine. I also use BIBM to multi-bbot lost of other OSs beside
> > > Ubunto
> > >
> > > and Mint on my first hard drive and it has been working fine.
> > >
> > > I backup all my partitions to external disk drives using gparted live.
> I
> > > had
> > > problems in the past using BIBM to do this, as it was not seeing my
> > > external
> > > hard drives, and gparted live works fine for me.
> > >
> > > Recently, after backing up my partitions, I attempted to upgrade
> Ubuntu
> > > from
> > > 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started
> > the
> > >
> > > process, walked away from my computer, and when I came back my
> computer
> > > was
> > >
> > > completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> > > something
> > > had gone wrong with the update since booting back into Ubuntu produced
> a
> > > broken implementation. So I booted gparted live, deleted my Ubuntu
> boot,
> > > root, and home partitions, and restored my backup partitions to their
> > > original places on my hard disks.
> > >
> > > I then went to boot back into Ubuntu from my BIBM boot menu to see if
> my
> > > Ubuntu 15.0.4 would boot again. I did this before attempting to
> > regenerate
> > >
> > > grub2 just to see if it would still work. What happened then in BIBM
> was
> > > very strange:
> > >
> > > 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for
> Mint
> > > 17.1
> > > 2) Likewise when I booted into Mint 17.1, whose boot partition I never
> > > touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
> > >
> > > Huh ? Does anybody know what is going on ? No other partitions in my
> > BIBM
> > > multi-boot were affected.
> > >
> > > I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 )
> > successfully
> > > in
> > > BIBM by simply changing the boot partition for each one in BIBM
> > > maintenance.
> > > But I am still wondering what has happened.
> > >
> > > It seems as if BIBM is somehow "pointing" to the wrong boot partitions
> > for
> > >
> > > each now. I am aware that when I restored the Ubuntu boot partition
> with
> > > gparted live that while I am restoring the partition to the same place
> > on
> > > my
> > > hard disk where it previously existed, the sda(n) order of partitions
> > has
> > > changed. Is this confusing BIBM somehow ?

Re: BIBM boot partition confusion

Posted: Sat Jan 23, 2016 11:34 pm
by TeraByte Support
whatever you're seeing in the "boot" field is the partition/volume being
booted matching the name given in partition work. It's possible the grub
(kernel loader) entries are reversed.


"eldiener" wrote in message news:10948@public.bootitbm...

TeraByte Support wrote:
> the names are associated with the volumes not id, so you just go to
> properties (in partition work) and change the name. You can use the use
> volume labels options in settings to pull in the volume name for certain
> file systems. The boot item would reference an id. Other tools may not
> copy the volume name (os2 name compatible) or the id.

I have done more investigation of the problem I found and here I give the
results. I am using the names UBUNTUBOOT and MINTBOOT to refer to the actual
partition labels on the hard disk:

1) When looking at the partitions UBUNTUBOOT and MINTBOOT in Partition Work
of BIBM, the correct partitions and their contents are given.
2) When booting from UBUNTUBOOT and MINTBOOT as boot items in the Boot Menu
BIBM is booting from the "wrong" partitions. Booting from UBUNTUBOOT is
actually booting from the MINTBOOT partition and booting form MINTBOOT is
actually booting from the UBUNTUBOOT partition.

I think what has caused this problem in BIBM is that the boot items when
editing a boot menu choice is based on what BIBM has tagged as an internal
logical partition identifier, and not as the actual physical position of the
partition on the hard drive. For my two partitions whose disk labels are
UBUNTUBOOT and MINTBOOT, the original logical partitions are:

sda10=UBUNTUBOOT
sda11=MINTBOOT

When I subsequently had to restore a backup of UBUNTUBOOT using gparted
live, the process had to be to first delete the current UBUNTUBOOT
partition, leaving free space in its place, and only then to restore my
backup of UBUNTUBOOT into that free space area. After this was done the
logical partitions were then:

sda11=UBUNTUBOOT
sda10=MINTBOOT

Note that the physical order of the partitions on the hard drive did not
change.

But BIBM evidently does not know about this change when I boot from the boot
item UBUNTUBOOT or MINTBOOT. Instead BIBM seems to consider the boot item
UBUNTUBOOT as sda10 and the boot item MINTBOOT as sda11. So now in BIBM when
I boot from UBUNTUBOOT I am booting from the MINTBOOT partition and when I
am booting from MINTBOOT I am booting from the UBUNTUBOOT partition. This is
the only surmise that makes sense to explain the problem as I see it in
BIBM.

Is this a known problem with BIBM ? Is there any way to straighten out BIBM
so that when the actual logical order of partitions change the BIBM boot
item will pick up the change and correct its view of the booting partition ?

It does seem as if this problem manifests itself only with the booting
partition. When I hide or unhide partitions when booting Ubuntu or Mint the
correct partitions appear to be in effect even though my restore of Ubuntu
root and Ubuntu home partitions also changed the logical order of those
partitions on my second hard drive.

>
>
> "eldiener" wrote in message news:10936@public.bootitbm...
>
> TeraByte Support wrote:
> > just setup the boot item for the changes.
>
> I do not understand your last remark.
>
> Currently BIBM identifies as the boot volume for Ubuntu a logical
> partition
>
> whose disk label is MINTBOOT and it identifies as the boot volume for Mint
> a
> logical partition whose disk label is UBUNTUBOOT. While this actually
> works
>
> correctly, due to the fact that I manually changed the boot partitions for
>
> Ubuntu and Mint to match BIBM's confusion, clearly BIBM's internals IDs
> for
>
> these boot volumes were messed up when I restored the backup Ubuntu boot
> partition and changed the order ( but not the position ) of the partitions
>
> on the hard drive.
>
> How do I straighten out BIBM's internal ids for these logical volumes ?
> Are you telling me that each time the logical order of partitions on a
> hard
>
> drive changes that BIBM cannot handle it properly ?
>
> I would really like to understand this because whenever a partition
> restore
>
> is done in gparted, the old partition area gets deleted before a copy is
> done of the backup to the old partition's space on a hard drive. While
> this
>
> does not change the physical order of partitions on the hard drive it will
>
> almost always change the logical order. And there must be some way to
> sunsequently tell BIBM about this change so that it re-syncs up its own
> internal IDs to the correct physical partitions on the drive.
>
> >
> >
> > "eldiener" wrote in message news:10926@public.bootitbm...
> >
> > TeraByte Support wrote:
> > > if you're dealing with volumes in extended partitions and using
> > something
> > > else, it's possible that something else wiped out the id for the
> > volumes.
> > >
> > > likewise if you don't have an embr and something changes the mbr order
> > it
> > > would change the id used for it.
> >
> > I am not using embr and the mbr order definitely changed. I am assuming
> > when
> > you say "id" you are talking about BIBM's internal id for the volume
> > rather
> >
> > than the actual disk label. How do I change BIBM's internal id to match
> > the
> >
> > disk label again ?
> > >
> > >
> > > "eldiener" wrote in message news:10923@public.bootitbm...
> > >
> > > I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint
> 17.1
> > > and
> > > Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> > > partitions. The boot partitions for both are next to each other in a
> > > logical
> > > drive on my first hard drive, with the Ubuntu boot partition coming
> > first.
> > >
> > > The root and home partitions are next to each other in a logical drive
> > on
> > > my
> > > second hard drive, with the Ubuntu partitions coming first. The boot
> > > partitions of both use grub2, with menus in grub2 for other OSs also
> > > besides
> > > their own on top, but I ignore the other OSs since I use BIBM for
> > > multi-booting. I have BIBM pointing to their boot partitions and it
> has
> > > been
> > > working fine. I also use BIBM to multi-bbot lost of other OSs beside
> > > Ubunto
> > >
> > > and Mint on my first hard drive and it has been working fine.
> > >
> > > I backup all my partitions to external disk drives using gparted live.
> I
> > > had
> > > problems in the past using BIBM to do this, as it was not seeing my
> > > external
> > > hard drives, and gparted live works fine for me.
> > >
> > > Recently, after backing up my partitions, I attempted to upgrade
> Ubuntu
> > > from
> > > 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I started
> > the
> > >
> > > process, walked away from my computer, and when I came back my
> computer
> > > was
> > >
> > > completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> > > something
> > > had gone wrong with the update since booting back into Ubuntu produced
> a
> > > broken implementation. So I booted gparted live, deleted my Ubuntu
> boot,
> > > root, and home partitions, and restored my backup partitions to their
> > > original places on my hard disks.
> > >
> > > I then went to boot back into Ubuntu from my BIBM boot menu to see if
> my
> > > Ubuntu 15.0.4 would boot again. I did this before attempting to
> > regenerate
> > >
> > > grub2 just to see if it would still work. What happened then in BIBM
> was
> > > very strange:
> > >
> > > 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for
> Mint
> > > 17.1
> > > 2) Likewise when I booted into Mint 17.1, whose boot partition I never
> > > touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
> > >
> > > Huh ? Does anybody know what is going on ? No other partitions in my
> > BIBM
> > > multi-boot were affected.
> > >
> > > I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 )
> > successfully
> > > in
> > > BIBM by simply changing the boot partition for each one in BIBM
> > > maintenance.
> > > But I am still wondering what has happened.
> > >
> > > It seems as if BIBM is somehow "pointing" to the wrong boot partitions
> > for
> > >
> > > each now. I am aware that when I restored the Ubuntu boot partition
> with
> > > gparted live that while I am restoring the partition to the same place
> > on
> > > my
> > > hard disk where it previously existed, the sda(n) order of partitions
> > has
> > > changed. Is this confusing BIBM somehow ?


Re: BIBM boot partition confusion

Posted: Sun Jan 24, 2016 2:42 am
by eldiener
TeraByte Support wrote:
> whatever you're seeing in the "boot" field is the partition/volume being
> booted matching the name given in partition work. It's possible the grub
> (kernel loader) entries are reversed.

It is actually grub2 for both Ubuntu and Mint.

Your surmise is the only other possibility but that would mean that the grub2 entries were reversed between the Ubuntu and Mint boot partitions while the actual content of these partitions remained the same. Of course it is possible that when Ubuntu failed to update from 15.0.4 to 15.0.10 it actually reversed the grub2 menu entries and left everything else alone as part of its buggy attempt at update. But how strange that would be.

Is there anything I can physically look at in the boot partitions for Ubuntu and Mint that will tell me what the grub2 entries are for each partition ?

>
>
> "eldiener" wrote in message news:10948@public.bootitbm...
>
> TeraByte Support wrote:
> > the names are associated with the volumes not id, so you just go to
> > properties (in partition work) and change the name. You can use the use
> > volume labels options in settings to pull in the volume name for certain
> > file systems. The boot item would reference an id. Other tools may not
> > copy the volume name (os2 name compatible) or the id.
>
> I have done more investigation of the problem I found and here I give the
> results. I am using the names UBUNTUBOOT and MINTBOOT to refer to the
> actual
> partition labels on the hard disk:
>
> 1) When looking at the partitions UBUNTUBOOT and MINTBOOT in Partition Work
>
> of BIBM, the correct partitions and their contents are given.
> 2) When booting from UBUNTUBOOT and MINTBOOT as boot items in the Boot Menu
>
> BIBM is booting from the "wrong" partitions. Booting from UBUNTUBOOT is
> actually booting from the MINTBOOT partition and booting form MINTBOOT is
> actually booting from the UBUNTUBOOT partition.
>
> I think what has caused this problem in BIBM is that the boot items when
> editing a boot menu choice is based on what BIBM has tagged as an internal
>
> logical partition identifier, and not as the actual physical position of
> the
> partition on the hard drive. For my two partitions whose disk labels are
> UBUNTUBOOT and MINTBOOT, the original logical partitions are:
>
> sda10=UBUNTUBOOT
> sda11=MINTBOOT
>
> When I subsequently had to restore a backup of UBUNTUBOOT using gparted
> live, the process had to be to first delete the current UBUNTUBOOT
> partition, leaving free space in its place, and only then to restore my
> backup of UBUNTUBOOT into that free space area. After this was done the
> logical partitions were then:
>
> sda11=UBUNTUBOOT
> sda10=MINTBOOT
>
> Note that the physical order of the partitions on the hard drive did not
> change.
>
> But BIBM evidently does not know about this change when I boot from the
> boot
> item UBUNTUBOOT or MINTBOOT. Instead BIBM seems to consider the boot item
> UBUNTUBOOT as sda10 and the boot item MINTBOOT as sda11. So now in BIBM
> when
> I boot from UBUNTUBOOT I am booting from the MINTBOOT partition and when I
>
> am booting from MINTBOOT I am booting from the UBUNTUBOOT partition. This
> is
> the only surmise that makes sense to explain the problem as I see it in
> BIBM.
>
> Is this a known problem with BIBM ? Is there any way to straighten out BIBM
>
> so that when the actual logical order of partitions change the BIBM boot
> item will pick up the change and correct its view of the booting partition
> ?
>
> It does seem as if this problem manifests itself only with the booting
> partition. When I hide or unhide partitions when booting Ubuntu or Mint the
>
> correct partitions appear to be in effect even though my restore of Ubuntu
>
> root and Ubuntu home partitions also changed the logical order of those
> partitions on my second hard drive.
>
> >
> >
> > "eldiener" wrote in message news:10936@public.bootitbm...
> >
> > TeraByte Support wrote:
> > > just setup the boot item for the changes.
> >
> > I do not understand your last remark.
> >
> > Currently BIBM identifies as the boot volume for Ubuntu a logical
> > partition
> >
> > whose disk label is MINTBOOT and it identifies as the boot volume for
> Mint
> > a
> > logical partition whose disk label is UBUNTUBOOT. While this actually
> > works
> >
> > correctly, due to the fact that I manually changed the boot partitions
> for
> >
> > Ubuntu and Mint to match BIBM's confusion, clearly BIBM's internals IDs
> > for
> >
> > these boot volumes were messed up when I restored the backup Ubuntu boot
> > partition and changed the order ( but not the position ) of the
> partitions
> >
> > on the hard drive.
> >
> > How do I straighten out BIBM's internal ids for these logical volumes ?
> > Are you telling me that each time the logical order of partitions on a
> > hard
> >
> > drive changes that BIBM cannot handle it properly ?
> >
> > I would really like to understand this because whenever a partition
> > restore
> >
> > is done in gparted, the old partition area gets deleted before a copy is
> > done of the backup to the old partition's space on a hard drive. While
> > this
> >
> > does not change the physical order of partitions on the hard drive it
> will
> >
> > almost always change the logical order. And there must be some way to
> > sunsequently tell BIBM about this change so that it re-syncs up its own
> > internal IDs to the correct physical partitions on the drive.
> >
> > >
> > >
> > > "eldiener" wrote in message news:10926@public.bootitbm...
> > >
> > > TeraByte Support wrote:
> > > > if you're dealing with volumes in extended partitions and using
> > > something
> > > > else, it's possible that something else wiped out the id for the
> > > volumes.
> > > >
> > > > likewise if you don't have an embr and something changes the mbr
> order
> > > it
> > > > would change the id used for it.
> > >
> > > I am not using embr and the mbr order definitely changed. I am
> assuming
> > > when
> > > you say "id" you are talking about BIBM's internal id for the volume
> > > rather
> > >
> > > than the actual disk label. How do I change BIBM's internal id to
> match
> > > the
> > >
> > > disk label again ?
> > > >
> > > >
> > > > "eldiener" wrote in message news:10923@public.bootitbm...
> > > >
> > > > I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint
> > 17.1
> > > > and
> > > > Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> > > > partitions. The boot partitions for both are next to each other in a
> > > > logical
> > > > drive on my first hard drive, with the Ubuntu boot partition coming
> > > first.
> > > >
> > > > The root and home partitions are next to each other in a logical
> drive
> > > on
> > > > my
> > > > second hard drive, with the Ubuntu partitions coming first. The boot
> > > > partitions of both use grub2, with menus in grub2 for other OSs also
> > > > besides
> > > > their own on top, but I ignore the other OSs since I use BIBM for
> > > > multi-booting. I have BIBM pointing to their boot partitions and it
> > has
> > > > been
> > > > working fine. I also use BIBM to multi-bbot lost of other OSs beside
> > > > Ubunto
> > > >
> > > > and Mint on my first hard drive and it has been working fine.
> > > >
> > > > I backup all my partitions to external disk drives using gparted
> live.
> > I
> > > > had
> > > > problems in the past using BIBM to do this, as it was not seeing my
> > > > external
> > > > hard drives, and gparted live works fine for me.
> > > >
> > > > Recently, after backing up my partitions, I attempted to upgrade
> > Ubuntu
> > > > from
> > > > 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I
> started
> > > the
> > > >
> > > > process, walked away from my computer, and when I came back my
> > computer
> > > > was
> > > >
> > > > completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> > > > something
> > > > had gone wrong with the update since booting back into Ubuntu
> produced
> > a
> > > > broken implementation. So I booted gparted live, deleted my Ubuntu
> > boot,
> > > > root, and home partitions, and restored my backup partitions to
> their
> > > > original places on my hard disks.
> > > >
> > > > I then went to boot back into Ubuntu from my BIBM boot menu to see
> if
> > my
> > > > Ubuntu 15.0.4 would boot again. I did this before attempting to
> > > regenerate
> > > >
> > > > grub2 just to see if it would still work. What happened then in BIBM
> > was
> > > > very strange:
> > > >
> > > > 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for
> > Mint
> > > > 17.1
> > > > 2) Likewise when I booted into Mint 17.1, whose boot partition I
> never
> > > > touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
> > > >
> > > > Huh ? Does anybody know what is going on ? No other partitions in my
> > > BIBM
> > > > multi-boot were affected.
> > > >
> > > > I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 )
> > > successfully
> > > > in
> > > > BIBM by simply changing the boot partition for each one in BIBM
> > > > maintenance.
> > > > But I am still wondering what has happened.
> > > >
> > > > It seems as if BIBM is somehow "pointing" to the wrong boot
> partitions
> > > for
> > > >
> > > > each now. I am aware that when I restored the Ubuntu boot partition
> > with
> > > > gparted live that while I am restoring the partition to the same
> place
> > > on
> > > > my
> > > > hard disk where it previously existed, the sda(n) order of
> partitions
> > > has
> > > > changed. Is this confusing BIBM somehow ?

Re: BIBM boot partition confusion

Posted: Tue Jan 26, 2016 7:39 am
by eldiener
TeraByte Support wrote:
> whatever you're seeing in the "boot" field is the partition/volume being
> booted matching the name given in partition work. It's possible the grub
> (kernel loader) entries are reversed.

I solved this problem. Actually nothing had changed other than I needed to do a grub-install for both Mint and Ubuntu once the logical order of the two partitions had changed ( been reversed ). Evidently the boot code at the beginning of each partition is keyed to the logical drive where the rest of the grub2 processing would occur. Once I reversed the logical drive the boot code at the beginning of each partition pointed to the other partition as the proper grub2 processing to use. That was why when I booted to the UBUNTUBOOT partition it showed me the Mint grub2 choices and when I booted to the MINTBOOT partition it showed me the Ubuntu grub2 choices. I was able to boot into one of them, and then grub-install on its boot partition to straighten out its boot code. Subsequently I used the latest Terabyte GRUB2 iso to boot into the other, and then grub-install and straighten out its boot code. Now both partitions work properly.

Thanks for your help and patience. The problem was not BIBM but the way that grub2 works.

>
>
> "eldiener" wrote in message news:10948@public.bootitbm...
>
> TeraByte Support wrote:
> > the names are associated with the volumes not id, so you just go to
> > properties (in partition work) and change the name. You can use the use
> > volume labels options in settings to pull in the volume name for certain
> > file systems. The boot item would reference an id. Other tools may not
> > copy the volume name (os2 name compatible) or the id.
>
> I have done more investigation of the problem I found and here I give the
> results. I am using the names UBUNTUBOOT and MINTBOOT to refer to the
> actual
> partition labels on the hard disk:
>
> 1) When looking at the partitions UBUNTUBOOT and MINTBOOT in Partition Work
>
> of BIBM, the correct partitions and their contents are given.
> 2) When booting from UBUNTUBOOT and MINTBOOT as boot items in the Boot Menu
>
> BIBM is booting from the "wrong" partitions. Booting from UBUNTUBOOT is
> actually booting from the MINTBOOT partition and booting form MINTBOOT is
> actually booting from the UBUNTUBOOT partition.
>
> I think what has caused this problem in BIBM is that the boot items when
> editing a boot menu choice is based on what BIBM has tagged as an internal
>
> logical partition identifier, and not as the actual physical position of
> the
> partition on the hard drive. For my two partitions whose disk labels are
> UBUNTUBOOT and MINTBOOT, the original logical partitions are:
>
> sda10=UBUNTUBOOT
> sda11=MINTBOOT
>
> When I subsequently had to restore a backup of UBUNTUBOOT using gparted
> live, the process had to be to first delete the current UBUNTUBOOT
> partition, leaving free space in its place, and only then to restore my
> backup of UBUNTUBOOT into that free space area. After this was done the
> logical partitions were then:
>
> sda11=UBUNTUBOOT
> sda10=MINTBOOT
>
> Note that the physical order of the partitions on the hard drive did not
> change.
>
> But BIBM evidently does not know about this change when I boot from the
> boot
> item UBUNTUBOOT or MINTBOOT. Instead BIBM seems to consider the boot item
> UBUNTUBOOT as sda10 and the boot item MINTBOOT as sda11. So now in BIBM
> when
> I boot from UBUNTUBOOT I am booting from the MINTBOOT partition and when I
>
> am booting from MINTBOOT I am booting from the UBUNTUBOOT partition. This
> is
> the only surmise that makes sense to explain the problem as I see it in
> BIBM.
>
> Is this a known problem with BIBM ? Is there any way to straighten out BIBM
>
> so that when the actual logical order of partitions change the BIBM boot
> item will pick up the change and correct its view of the booting partition
> ?
>
> It does seem as if this problem manifests itself only with the booting
> partition. When I hide or unhide partitions when booting Ubuntu or Mint the
>
> correct partitions appear to be in effect even though my restore of Ubuntu
>
> root and Ubuntu home partitions also changed the logical order of those
> partitions on my second hard drive.
>
> >
> >
> > "eldiener" wrote in message news:10936@public.bootitbm...
> >
> > TeraByte Support wrote:
> > > just setup the boot item for the changes.
> >
> > I do not understand your last remark.
> >
> > Currently BIBM identifies as the boot volume for Ubuntu a logical
> > partition
> >
> > whose disk label is MINTBOOT and it identifies as the boot volume for
> Mint
> > a
> > logical partition whose disk label is UBUNTUBOOT. While this actually
> > works
> >
> > correctly, due to the fact that I manually changed the boot partitions
> for
> >
> > Ubuntu and Mint to match BIBM's confusion, clearly BIBM's internals IDs
> > for
> >
> > these boot volumes were messed up when I restored the backup Ubuntu boot
> > partition and changed the order ( but not the position ) of the
> partitions
> >
> > on the hard drive.
> >
> > How do I straighten out BIBM's internal ids for these logical volumes ?
> > Are you telling me that each time the logical order of partitions on a
> > hard
> >
> > drive changes that BIBM cannot handle it properly ?
> >
> > I would really like to understand this because whenever a partition
> > restore
> >
> > is done in gparted, the old partition area gets deleted before a copy is
> > done of the backup to the old partition's space on a hard drive. While
> > this
> >
> > does not change the physical order of partitions on the hard drive it
> will
> >
> > almost always change the logical order. And there must be some way to
> > sunsequently tell BIBM about this change so that it re-syncs up its own
> > internal IDs to the correct physical partitions on the drive.
> >
> > >
> > >
> > > "eldiener" wrote in message news:10926@public.bootitbm...
> > >
> > > TeraByte Support wrote:
> > > > if you're dealing with volumes in extended partitions and using
> > > something
> > > > else, it's possible that something else wiped out the id for the
> > > volumes.
> > > >
> > > > likewise if you don't have an embr and something changes the mbr
> order
> > > it
> > > > would change the id used for it.
> > >
> > > I am not using embr and the mbr order definitely changed. I am
> assuming
> > > when
> > > you say "id" you are talking about BIBM's internal id for the volume
> > > rather
> > >
> > > than the actual disk label. How do I change BIBM's internal id to
> match
> > > the
> > >
> > > disk label again ?
> > > >
> > > >
> > > > "eldiener" wrote in message news:10923@public.bootitbm...
> > > >
> > > > I multi-boot with BIBM 1.31e. I multi-boot, among others, both Mint
> > 17.1
> > > > and
> > > > Ubuntu 15.0.4. Each one has its own separate boot, root, and home
> > > > partitions. The boot partitions for both are next to each other in a
> > > > logical
> > > > drive on my first hard drive, with the Ubuntu boot partition coming
> > > first.
> > > >
> > > > The root and home partitions are next to each other in a logical
> drive
> > > on
> > > > my
> > > > second hard drive, with the Ubuntu partitions coming first. The boot
> > > > partitions of both use grub2, with menus in grub2 for other OSs also
> > > > besides
> > > > their own on top, but I ignore the other OSs since I use BIBM for
> > > > multi-booting. I have BIBM pointing to their boot partitions and it
> > has
> > > > been
> > > > working fine. I also use BIBM to multi-bbot lost of other OSs beside
> > > > Ubunto
> > > >
> > > > and Mint on my first hard drive and it has been working fine.
> > > >
> > > > I backup all my partitions to external disk drives using gparted
> live.
> > I
> > > > had
> > > > problems in the past using BIBM to do this, as it was not seeing my
> > > > external
> > > > hard drives, and gparted live works fine for me.
> > > >
> > > > Recently, after backing up my partitions, I attempted to upgrade
> > Ubuntu
> > > > from
> > > > 15.0.4 to 15.0.10 using an online method supplied by Ubuntu. I
> started
> > > the
> > > >
> > > > process, walked away from my computer, and when I came back my
> > computer
> > > > was
> > > >
> > > > completely shutdown. I rebooted into BIBM, booted into Ubuntu, but
> > > > something
> > > > had gone wrong with the update since booting back into Ubuntu
> produced
> > a
> > > > broken implementation. So I booted gparted live, deleted my Ubuntu
> > boot,
> > > > root, and home partitions, and restored my backup partitions to
> their
> > > > original places on my hard disks.
> > > >
> > > > I then went to boot back into Ubuntu from my BIBM boot menu to see
> if
> > my
> > > > Ubuntu 15.0.4 would boot again. I did this before attempting to
> > > regenerate
> > > >
> > > > grub2 just to see if it would still work. What happened then in BIBM
> > was
> > > > very strange:
> > > >
> > > > 1) When I booted into Ubuntu 15.0.4 the grub2 menu was the one for
> > Mint
> > > > 17.1
> > > > 2) Likewise when I booted into Mint 17.1, whose boot partition I
> never
> > > > touched or restored, the grub2 menu was the one for Ubuntu 15.0.4.
> > > >
> > > > Huh ? Does anybody know what is going on ? No other partitions in my
> > > BIBM
> > > > multi-boot were affected.
> > > >
> > > > I was able to boot back into Ubuntu 15.0.4 ( and Mint 17.1 )
> > > successfully
> > > > in
> > > > BIBM by simply changing the boot partition for each one in BIBM
> > > > maintenance.
> > > > But I am still wondering what has happened.
> > > >
> > > > It seems as if BIBM is somehow "pointing" to the wrong boot
> partitions
> > > for
> > > >
> > > > each now. I am aware that when I restored the Ubuntu boot partition
> > with
> > > > gparted live that while I am restoring the partition to the same
> place
> > > on
> > > > my
> > > > hard disk where it previously existed, the sda(n) order of
> partitions
> > > has
> > > > changed. Is this confusing BIBM somehow ?