:: [DNG] Stupid LVM conflict resolved
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Hendrik Boom
Fecha:  
A: Daniel Reurich, dng
Asunto: [DNG] Stupid LVM conflict resolved
On Sat, Aug 15, 2015 at 05:15:44PM +1200, Daniel Reurich wrote:
> On 15/08/15 16:54, Hendrik Boom wrote:
> >On Sat, Aug 15, 2015 at 03:21:47PM +1200, Daniel Reurich wrote:
> >>On 15/08/15 14:47, Hendrik Boom wrote:
> >>
> >>>>
> >>>>Don't forget to do `update-initramfs -u -k all` and `update-grub` to
> >>>>rebuild the
> >>>
> >>>Ouch. update-initramfs crapped out:
> >>>
> >>>oot@notlookedfor:~# update-initramfs -u -k all
> >>>update-initramfs: Generating /boot/initrd.img-3.16.0-4-686-pae
> >>>mkinitramfs: failed to determine device for /usr
> >>>mkinitramfs: workaround is MODULES=most, check:
> >>>grep -r MODULES /etc/initramfs-tools/
> >>
> >>so it failed to determine the path for /usr.
> >>
> >>Double check your fstab uses either the new path and that the new
> >>path exists (if it's using UUID= for /usr it shouldn't need to be
> >>changed.
> >>
> >>You may need to do a `mount -o remount /usr` so that your cat
> >>/proc/mounts matches /etc/fstab
> >
> >mount -o remount /usr
> >
> >doesn't help. It seems to have figured out all by itself that / is now
> >on
> >/dev/mapper/jessie-devuan--root
> >but it still thinks /usr is on
> >/dev/mapper/VG1-devuan--usr which no longer exists, even after the
> >remount.
>
> that's a bit weird...
> >
> >It's late at night here, and I'm tired. (I suppose it's daytime in New
> >Zealand) If no ideas show up overnight I'm going to try rebooting
> >on the off chance that the message is merely precautionary, and if that
> >doesn't work, I can simply reinstall. It will be easier this time
> >because now that I've already done it.
> >
> >Still wondering why initramfs needs to know where /usr is.
>
> For tools that it might need - could also be a hangover from systemd
> which can't cope with a separate /usr volume.


Rebooted with no problems. I suspecct the need for /usr it was a
precautionary check left over from systemd.

-- hendrik

> >
> >>
> >>>Another anomaly:
> >>>
> >>>I grepped for my new volume group in /boot/grub/grub.cfg, and the third
> >>>"linux" line it produced was:
> >>>
> >>>linux    /vmlinuz-3.16.0-4-686-pae root=/dev/mapper/jessie-devuan--root
> >>>ro  quiet init=/lib/systemd/systemd

> >>>
> >>>The others did not mention systemd.
> >>>
> >>>THen I noticed that /lib/systemd/ is a fully populated directory, with
> >>>lots of systemd stuff in it. Surprise! To be investigated another day.
> >>
> >>That looks like you've got systemd-sysv installed - what do you have
> >>for PID1?
> >
> >4 S     0     1     0  0  80   0 -   810 poll_s ?        00:00:01 init

> >
> >Some program called init. There is an /sbin/init, but I have no proof
> >that it is indeed that one.
>
> Ok that's fine then.
> >
> >There's also a process running systemd-logind but the name may have been
> >trunctated. Could it have come in with xfce? or whatever display
> >manager Devuan uses?
>
> It's pulled in by libpamsystemd which some packages still depend on
> in particular cups.
> >
> >I thought, in my innocence, that devuan might have avoided systemd. I
> >guess we're not all the way there yet.
> >
> We're working on it. You should be able to have an entirely systemd
> free server and XFCE desktop, and possibly mate. Not sure whether
> Gnome3 will ever be able to be fully free'd from systemd tho.
>
> Daniel
>
> --
> Daniel Reurich
> Centurion Computer Technology (2005) Ltd.
> 021 797 722