Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Mon, Jul 29, 2013 at 7:56 PM,  <gottlieb@×××.edu> wrote:
> I am a gnome-3 user, who wants to continue with gnome-3.  I understand
> now that to move to 3.8 requires I move from openRC to systemd and am
> trying to accomplish that now.  I have so far only done the easy first
> steps.
>
> 0.  I always back up my user files and /etc daily
>
> 1.  I confirmed that my system still boots off my installation CD
>     (just in case).
>
> 2.  I added enough entries to /etc/portage/package.mask to prevent
>     systemd being required (list at the end if others are interested).
>
> 3.  Performed the kernel prerequisites from the wiki (most of which
>     were already enabled).
>
> 4.  My /run directory was already present and populated.

Sounds reasonable.

> Now I hit my first question
>
> The wiki says that "upstream suggests that the /etc/mtab file should
> be a simlink to /proc/self/mounts."  It then points out problems with
> and without the symlink.
>
> My current system has both files but with slightly different contents,
> specifically the entries for my filesystems, root (includes /usr) and several
> lvm2 lvs, say "commit=0 0 2" in /etc/mtab but say "data=ordered 0 0"
> in /proc/self/mounts
>
> Do you advising leaving it alone or executing
>    ln -sf /proc/self/mounts /etc/mtab

AFAIU, systemd will print the following warning if /etc/mtab is not a
symlink to /proc/self/mounts:

"/etc/mtab is not a symlink or not pointing to /proc/self/mounts. This
is not supported anymore. Please make sure to replace this file by a
symlink to avoid incorrect or misleading mount(8) output."

Also, upstream will reject flatly any support for systems where this
happens. Lastly, if I understand correctly, /proc/self/mounts is how
the mounts are really mounted, so if they differ, /proc/self/mounts
contains the correct information.

If you switch to systemd, you will need to make /etc/mtab a symlink to
/proc/self/mounts.

> After that comes the big one
>
> emerge systemd
> USE="... systemd ..."
> emerge --change-use
> /etc/init.d/udev restart
>
> Can the system be rebooted at this point (I realize init will still not
> use systemd) or must the entire conversion (including changing init) be
> completed before the system is bootable?  I am hoping it is the former.

If you install systemd, sys-fs/udev will be uninstalled first (they
block each other). At this point, /etc/init.d/udev doesn't exists
anymore in your system. If you reboot, I don't believe there is any
chance your system will boot up correctly.

/etc/init.d/udev is installed by sys-fs/udev; sys-apps/systemd doesn't
provide anything similar. I recommend installing everything necessary
(and uninstalling everything that is not) before trying the reboot.

Also, instead of emerge --changed-use (not --change-use, BTW), try:

emerge --update --deep --newuse --verbose

Or its shorter equivalent, emerge -uDNv world. --deep will force a
check on the entire dependency tree, --newuse will trigger
reinstallation for flags you didn't set. I think, in this case at
least, it's better to cover as many possible packages affected by the
switch. Although I update my systems always with --deep and --newuse.

Also, I would do the whole shebang in a one step, removing all the
masked packages you did. You can try to boot to multi-user.target
instead of graphical.target, if you want to test that systemd works
correctly independently of GNOME.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México