Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
Canek Peláez Valdés can...@gmail.com writes: The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. It is pulled in by sys-fs/udev-init-scripts which is a dependency of systemd[openrc]. So the Wiki is correct.
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31 2013, Graham Murray wrote: Canek Peláez Valdés can...@gmail.com writes: The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. It is pulled in by sys-fs/udev-init-scripts which is a dependency of systemd[openrc]. So the Wiki is correct. But the wiki doesn't specify emerging system with the openrc flag. Should I suggest that the wiki be modified. To be sure I understand. At this point I would have already 1. merged systemd (perhaps with USE=openrc ... 2. set USE=systemd ... 3. updated with emerge --newuse --deep --verbose--ask @world * The wiki doesn't say --update; is that correct? I would *not* have 1. added init=/usr/lib/systemd/systemd to the kernel line in grub 2. rebooted. A related question. Am I correct in believing that once I do the emerge ... @world above I can *not* reboot until I have added the init=... phrase to the kernel line in grub (and thus committed to systemd not OpenRC) Thanks to all allan
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31, 2013 at 5:09 AM, Graham Murray gra...@gmurray.org.uk wrote: Canek Peláez Valdés can...@gmail.com writes: The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. It is pulled in by sys-fs/udev-init-scripts which is a dependency of systemd[openrc]. So the Wiki is correct. Yeah, sorry: my bad. I completely forgot about the openrc USE flag. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31, 2013 at 9:28 AM, gottl...@nyu.edu wrote: On Wed, Jul 31 2013, Graham Murray wrote: Canek Peláez Valdés can...@gmail.com writes: The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. It is pulled in by sys-fs/udev-init-scripts which is a dependency of systemd[openrc]. So the Wiki is correct. But the wiki doesn't specify emerging system with the openrc flag. Should I suggest that the wiki be modified. To be sure I understand. At this point I would have already 1. merged systemd (perhaps with USE=openrc ... 2. set USE=systemd ... 3. updated with emerge --newuse --deep --verbose--ask @world * The wiki doesn't say --update; is that correct? I would *not* have 1. added init=/usr/lib/systemd/systemd to the kernel line in grub 2. rebooted. I think (now that Graham correctly pointed that you can preserve /etc/init.d/udev with the openrc USE flag), that then you should restart udev. A related question. Am I correct in believing that once I do the emerge ... @world above I can *not* reboot until I have added the init=... phrase to the kernel line in grub (and thus committed to systemd not OpenRC) That, I believe, is correct. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
Thank you Canek and Graham. I apologize for all the questions, but one still remains. The wiki says to emerge --ask --changed-use --deep @world One could make small additions/changes, but there is a large one that is not clear. Should you have --update ? allan
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31, 2013 at 12:43 PM, gottl...@nyu.edu wrote: Thank you Canek and Graham. I apologize for all the questions, but one still remains. The wiki says to emerge --ask --changed-use --deep @world One could make small additions/changes, but there is a large one that is not clear. Should you have --update ? I would do it, just in case. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, 31 Jul 2013 13:43:55 -0400, gottl...@nyu.edu wrote: The wiki says to emerge --ask --changed-use --deep @world One could make small additions/changes, but there is a large one that is not clear. Should you have --update ? --changed-use will re-emerge any packages affected by the changed flags, and update any of those for which new versions exist. --update will also update any other packages on your system, unaffected by the switch to systemd, for which updates are available. I think the Wiki advice is wise, leave the other updates until you have gone through the systemd conversion and made everything is working. Adding extra changes increases the chance of things going wrong, and the number of paces you have to look if they do. -- Neil Bothwick Sir! Romulan warbird decloaki»®õ÷üÁ NO CARRIER signature.asc Description: PGP signature
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31 2013, gottl...@nyu.edu wrote: I apologize for all the questions, but one still remains. The wiki says to emerge --ask --changed-use --deep @world One could make small additions/changes, but there is a large one that is not clear. Should you have --update ? Thank you canek and neil. allan
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
First and foremost, thank you Canek. On Tue, Jul 30 2013, Canek Peláez Valdés wrote: On Mon, Jul 29, 2013 at 7:56 PM, gottl...@nyu.edu wrote: I am a gnome-3 user, who wants to continue with gnome-3. [ I described my current state--beginning of wiki ] Sounds reasonable. [ I asked about /etc/mtab and /proc/self/mounts If you switch to systemd, you will need to make /etc/mtab a symlink to /proc/self/mounts. Done. After that comes the big one emerge systemd USE=... systemd ... emerge --newuse ... [ a change from previous msg ] /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 reboot [now], I don't believe there is any chance your system will boot up correctly. I see. /etc/init.d/udev is installed by sys-fs/udev; sys-apps/systemd doesn't provide anything similar. I don't understand. *After* installing systemd (and setting the USE and executing the emerge --newuse ...), the wiki tells you to /etc/init.d/udev restart Emerging systemd unmerges udev so how can I do the restart? I recommend installing everything necessary (and uninstalling everything that is not) before trying the reboot. How far do I have to get in the wiki? I am hoping to do smaller chunks so that if I have to back out a step (using a bootable CD) to restore bootability to the system, it won't take too long. In particular do I have to switch init to /usr/lib/systemd/systemd before I can boot. I know you have had systemd installed for a long time. Did you always have the init= line or were you for a while running openrc with systemd installed? 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. I am not so worried about gnome coming up. If the system boots and I can get the 6 text terminals, I can survive for quite a while with emacs and gnus. Again thanks for the help. allan
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Tue, Jul 30, 2013 at 8:31 PM, gottl...@nyu.edu wrote: First and foremost, thank you Canek. On Tue, Jul 30 2013, Canek Peláez Valdés wrote: On Mon, Jul 29, 2013 at 7:56 PM, gottl...@nyu.edu wrote: I am a gnome-3 user, who wants to continue with gnome-3. [ I described my current state--beginning of wiki ] Sounds reasonable. [ I asked about /etc/mtab and /proc/self/mounts If you switch to systemd, you will need to make /etc/mtab a symlink to /proc/self/mounts. Done. After that comes the big one emerge systemd USE=... systemd ... emerge --newuse ... [ a change from previous msg ] /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 reboot [now], I don't believe there is any chance your system will boot up correctly. I see. /etc/init.d/udev is installed by sys-fs/udev; sys-apps/systemd doesn't provide anything similar. I don't understand. *After* installing systemd (and setting the USE and executing the emerge --newuse ...), the wiki tells you to /etc/init.d/udev restart Emerging systemd unmerges udev so how can I do the restart? The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. I recommend installing everything necessary (and uninstalling everything that is not) before trying the reboot. How far do I have to get in the wiki? I am hoping to do smaller chunks so that if I have to back out a step (using a bootable CD) to restore bootability to the system, it won't take too long. I thing you should do it all in one big step. sys-fs/udev and sys-apps/systemd conflict each other pretty badly, and the latter changes the init program; also, several programs can work with OpenRC, or systemd, but not both. Doing it in smaller chunks seems to me a great recipe to making your system unbootable. In particular do I have to switch init to /usr/lib/systemd/systemd before I can boot. Yeah, I believe you have to. I know you have had systemd installed for a long time. Did you always have the init= line or were you for a while running openrc with systemd installed? No, I did the switch and almost immediately started to work in the gentoo-systemd-only overlay[1], which I just deprecated. At the very beggining having OpenRC could wreck the whole boot, since some stuff (barely documented at the time) called scripts in /etc/init.d seemingly at random, and at the time OpenRC scripts didn't even consider that the machine was not being booted with OpenRC. I do have an old server *running* with systemd and with OpenRC still installed; it's my last machine waiting to switch to the new service-manager virtual. 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. I am not so worried about gnome coming up. If the system boots and I can get the 6 text terminals, I can survive for quite a while with emacs and gnus. GNUS? Damn, that brings back some memories. I stopped using it for reading email in 2002 or 2003, when Evolution become mature enough. If you are comfortable with only a console, do the switch from a VT. A lot of stuff will stopping working *during* the transition, and will not become functional again until you reboot. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
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. 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 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. thanks in advance for any help. allan My file /etc/portage/package.mask/gnome-3.8 =gnome-base/gnome-3.8 =gnome-base/gnome-core-apps-3.8 =gnome-base/gnome-control-center-3.8 =gnome-base/gnome-shell-3.8 =x11-terms/gnome-terminal-3.8 =gnome-extra/gnome-power-manager-3.8 =media-gfx/eog-3.8 =media-video/totem-3.8 =app-crypt/seahorse-3.8 =net-im/empathy-3.8 =app-editors/gedit-3.8.3 =gnome-extra/gnome-shell-extensions-3.8 =gnome-base/gnome-extra-apps-3.8.0-r1:3.0 =gnome-extra/evolution-data-server-3.8 =dev-libs/folks-0.9 =gnome-extra/gnome-calculator-3.8 =gnome-extra/gnome-tweak-tool-3.8 =gnome-base/gdm-3.8 =gnome-extra/gnome-documents-3.8 =gnome-extra/nautilus-tracker-tags-0.16 =app-misc/tracker-0.16 =dev-libs/totem-pl-parser-3.4.5 =dev-libs/libpeas-1.8 =gnome-extra/yelp-3.8 =gnome-extra/gnome-contacts-3.8 =app-cdr/brasero-3.8 =net-misc/vinagre-3.8 =app-dicts/gnome-dictionary-3.8 =app-arch/file-roller-3.8 =net-analyzer/gnome-nettool-3.8 =gnome-extra/gnome-system-monitor-3.8 =gnome-extra/gucharmap-3.8 =media-gfx/gnome-font-viewer-3.8 =net-misc/vino-3.8 =media-gfx/gnome-screenshot-3.8 =sys-apps/baobab-3.8 =www-client/epiphany-3.8 =dev-cpp/gtkmm-3.8 =app-admin/gnome-system-log-3.8 =media-video/cheese-3.8 =net-libs/libzapojit-0.0.3 =gnome-extra/sushi-3.8 =mail-client/evolution-3.8 =gnome-base/gnome-core-libs-3.8 =gnome-base/gvfs-1.16 =net-wireless/gnome-bluetooth-3.8 =app-text/evince-3.8 =net-libs/gnome-online-accounts-3.8 =gnome-extra/gnome-color-manager-3.8 =x11-wm/mutter-3.8 =gnome-base/libgnome-keyring-3.8 =net-libs/webkit-gtk-2.0.4:3/25 =gnome-extra/zenity-3.8 =gnome-base/gnome-session-3.8 =x11-libs/gtksourceview-3.8 =media-libs/clutter-gtk-1.4.4:1.0 =x11-themes/gnome-themes-standard-3.8 =media-video/cheese-3.8 =gnome-extra/yelp-xsl-3.8 =x11-themes/gnome-icon-theme-3.8 =x11-themes/gnome-icon-theme-symbolic-3.8 =gnome-base/gsettings-desktop-schemas-3.8 =gnome-base/gsettings-desktop-3.8 =gnome-base/gnome-desktop-3.8 =x11-themes/gnome-backgrounds-3.8 =gnome-extra/gnome-user-docs-3.8 =gnome-base/gnome-common-3.7 =x11-libs/gtk+-3.8 =gnome-base/gnome-keyring-3.8 =gnome-base/nautilus-3.8 =app-crypt/gcr-3.8 =net-libs/libsoup-2.42 =gnome-base/gnome-settings-daemon-3.8 =net-libs/webkit-gtk-2.0.3 =media-libs/clutter-1.14 =dev-libs/libgweather-3.8 =media-libs/cogl-1.14
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Mon, Jul 29 2013, gottl...@nyu.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. OK. Walt proved this wrong by managing, with some effort and doubtless considerable skill, to get 3.8 on an openrc machine but he does note that moving to systemd is the procedure supported by the gentoo devs. I am still trying to move to systemd and would appreciate help as mentioned in my previous msg. thanks again, allan
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Mon, Jul 29, 2013 at 7:56 PM, gottl...@nyu.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
[gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
First hint: it's a mess -- don't do it on a critical machine. (My main machine is ~amd64 and that's why I'm doing it on virtual ~amd64 machines first.) The new gnome-shell demands that systemd be installed, even if you don't intend to use it. The latest systemd conflicts with udev because the udev project has been rolled into systemd, which now provides all of the files previously installed by udev. Therefore your machine will still boot without udev because systemd installs all the udev files. You don't need to start or use systemd if you don't want to, but the systemd package must be installed *before* you reboot and after removing udev. Removal of udev has caused a few (temporary) problems with useflags, because a few packages still depend directly on udev instead of the newer (!systemd ? udev) which means accept either one but not both. That will get fixed soon, I'm sure. The right way to upgrade gnome is probably to remove every gnome package on the machine, which will avoid many of the conflicts I've had to fight for the last two days -- but of course I did it the hard way instead :) You can try emerge -au gnome-light early in the update, which is simpler than emerging gnome in all its immensity, but that's no guarantee of success -- I'm sure you'll still run into conflicts between packages and useflags, but it might be a bit easier. When you see conflicting packages that won't install, I suggest deleting both packages immediately -- let portage sort out the conflicts. Just keep removing packages until portage finally stops complaining. Beware of pambase, however. I finally took Canek's advice and removed consolekit from the machine and unset the useflag for all packages, including pambase and polkit. I'd suggest you get pambase and polkit re-installed with the proper useflags before you try to reboot. Dunno if that's mandatory, but I did it that way and had no problems (yet). I've finished updating my virtual gentoo systemd machine now, but I'm still fighting with the virtual openrc machine and I'm not sure how it will turn out. More tomorrow :)
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Jul 27, 2013 4:44 PM, walt w41...@gmail.com wrote: First hint: it's a mess -- don't do it on a critical machine. (My main machine is ~amd64 and that's why I'm doing it on virtual ~amd64 machines first.) The new gnome-shell demands that systemd be installed, even if you don't intend to use it. The latest systemd conflicts with udev because the udev project has been rolled into systemd, which now provides all of the files previously installed by udev. Therefore your machine will still boot without udev because systemd installs all the udev files. You don't need to start or use systemd if you don't want to, but the systemd package must be installed *before* you reboot and after removing udev. Removal of udev has caused a few (temporary) problems with useflags, because a few packages still depend directly on udev instead of the newer (!systemd ? udev) which means accept either one but not both. That will get fixed soon, I'm sure. The right way to upgrade gnome is probably to remove every gnome package on the machine, which will avoid many of the conflicts I've had to fight for the last two days -- but of course I did it the hard way instead :) You can try emerge -au gnome-light early in the update, which is simpler than emerging gnome in all its immensity, but that's no guarantee of success -- I'm sure you'll still run into conflicts between packages and useflags, but it might be a bit easier. When you see conflicting packages that won't install, I suggest deleting both packages immediately -- let portage sort out the conflicts. Just keep removing packages until portage finally stops complaining. Beware of pambase, however. I finally took Canek's advice and removed consolekit from the machine and unset the useflag for all packages, including pambase and polkit. I'd suggest you get pambase and polkit re-installed with the proper useflags before you try to reboot. Dunno if that's mandatory, but I did it that way and had no problems (yet). I've finished updating my virtual gentoo systemd machine now, but I'm still fighting with the virtual openrc machine and I'm not sure how it will turn out. More tomorrow :) I haven't upgraded yet to the last update (although I've been using GNOME 3+systemd for years), but I do know this: the primary reason of GNOME's dependency on systemd is logind, and logind *CANNOT* run correctly if systemd is not the running init. So you not only need to install systemd: you need to use it as init. I don't even think logind can start if systemd is not running. And actually, the long term plan is for systemd --user to basically replace gnome-session-manager, so just installing systemd is not going to work at all in the future, even if it *may* seems to work now (which I'm pretty sure it doesn't). systemd provides some pretty complex functionality for logind (and therefore GNOME) while running; it's not just some libraries. Regards.
