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 ?