On Tue, Aug 29, 2017 at 07:40:06AM -0400, Hendrik Boom wrote:
> On Mon, Aug 28, 2017 at 10:15:03PM -0400, fsmithred wrote:
> > On 08/28/2017 07:59 PM, Hendrik Boom wrote:
> >
> > > Anyway, as I mentined in another post a few minutes ago, it does seem
> > > to be recognising it after all, but as a unknown Linux distro,
> > > failing tto notice it's Devun.
> >
> > This is correct. Grub does not recognize devuan. Add a stanza for devuan
> > to /usr/lib/os-probes/mounted/90linux-distro if you want it to be
> > recognized. Or make an /etc/lsb-release file with the right information.
> >
> >
> > >And I don't get a bootmenu stanza.
> > >
> >
> > That's not right. Not sure why it wouldn't work. You copied the contents
> > of one partition to another? Or did you dd one partition to another? The
> > partitions have different uuids? (Taking wild stabs in the dark here.)
>
> I used rsync. And had the wrong combination of slashes in the command
> so it copied the old /boot to the new /boot/boot. As a result, it
> found no kernel to boot.
>
> Fixing that, and realy going over the old and new etc/fstab I now have
> a situation where at boot time I have the choice of a Devunn system and
> an unidentified Liux system. Both in plin and advanced flavours.
>
> However, when booting the unidentified Linux system, it mounts exactly
> the same partitions as the old Linux system. It appears to
> completely ignore the new /etc/fstab in the new system.
>
> It's as if grub-update found the new system, but for perverse reasons
> still used the /etc/fstab in the old system instead of the one in the
> new system. And yes, I exclude /etc/fstab from the rsyc operation.
> The new one is definitely still different from the old one.
>
> Next I'll check whether /boot/grub/grub.cfg refers to the proper
> partitions. That should narrow down the possibilities.

/boot/grub/grub.cfg does not appear to refer to the correct partitions,
A few lines from the /boot/grub/grub.cfg:

submenu 'Advanced options for unknown Linux distribution (on /dev/mapper/jessie-ascii--root)' $menuentry_id_option 'osprober-gnulinux-advanced-c6f30bc1-91d8-4d44-a5ff-ecd38a92b076' {
        menuentry 'Devuan GNU/Linux (on /dev/mapper/jessie-ascii--root)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz-3.16.0-4-686-pae--c6f30bc1-91d8-4d44-a5ff-ecd38a92b076' {
                insmod part_msdos
                insmod ext2
                set root='hd0,msdos7'
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  a0f7f7ef-d766-48fe-93fd-c1e1a4da1c85
                else
                  search --no-floppy --fs-uuid --set=root 
a0f7f7ef-d766-48fe-93fd-c1e1a4da1c85
                fi
                linux /vmlinuz-3.16.0-4-686-pae root=/dev/mapper/jessie-devuan--root ro quiet
                initrd /initrd.img-3.16.0-4-686-pae
        }

The search command has the proper UUID for the new /boot partition.

The linux command specifies root=/dev/mapper/jessie-devuan--root, which
is the old root partition. So it will boot from the new system's /boot
using the old system's root partition which of course contains the old
/etc/fstab with all the old partitions.

So it looks as if grub-update is not doing the right thing.
Still need to figure out why.

-- hendrik