Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
On 2013-03-18 7:15 AM, Tanstaafl tansta...@libertytrek.org wrote: The above reference to 'might need packages like sys-apps/kbd', which is now *required* by udev, suggests that now I again do need an initramsf? That was silly - I saw kbd and read it as kmod... ok, this one is no problem either... One new concern - I just confirmed that I do *not* have CONFIG_DEVTMPFS enabled in my current running kernel. I also am running an older kernel that is no longer in portage (I know, I know), so I want to recompile my existing kernel and get it booting with the new/updated u dev before upgrading it (will do that immediately once the udev update is done). I've never recompiled and replaced a running kernel before, so... I'm just going to recompile it with everything enabled, copy the new kernel over to /boot with a slightly different name, then reboot to the new kernel. But looking at: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=7 It says to enable the following: Device Drivers --- Generic Driver Options --- [*] Maintain a devtmpfs filesystem to mount at /dev [ ] Automount devtmpfs at /dev, after the kernel mounted the rootfs ... File systems --- (Select one or more of the following options as needed by your system) ... Pseudo Filesystems --- [*] /proc file system support [*] Virtual memory file system support (former shm fs) (In my current kernel the option is 'Tmpfs virtual memory file system support (former shm fs) ... (Enable GPT partition label support if you used that previously) -*- Enable the block layer --- ... Partition Types --- [*] Advanced partition selection ... [*] EFI GUID Partition support Now, when exiting menuconfig I get the following warnings: # make menuconfig scripts/kconfig/mconf Kconfig warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet direct dependencies (SMP MODULE_UNLOAD || HOTPLUG_CPU) warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet direct dependencies (SMP MODULE_UNLOAD || HOTPLUG_CPU) # # configuration written to .config Is this something I need to fix? Lastly, doing the actual updates once I have a supported kernel ready... Neil suggested just unmerging module-init-tools and then letting emerge world install kmod, but I like doing things in smaller steps. An emerge world wants to update a number of other non udev related things (like apache), so what I'd like to do is get udev updated first, reboot, then finish updating world, so what I'm thinking of doing (after fixing my kernel issue) is: emerge -C module-init-tools emerge -1 kmod then emerge -C sysvinit emerge -1 util-linux then emerge -vuDN udev reboot emerge -vuDN world My question is, is the above any 'safer' than just doing: emerge -C module-init-tools emerge -C sysvinit emerge -vuDN udev reboot ? Thanks
Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
Ok, spent a little time re-reading the old threads about this... Just to confirm, changes I should make in my /etc/fstab... snip normal fs lines # NOTE: The next line is critical for boot! none /proc procdefaults0 0 I can/should simply delete the above two lines? then # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) shm /dev/shmtmpfsnodev,nosuid,noexec 0 0 I should change the above line to: tmpfs /dev/shmtmpfsnodev,nosuid,noexec 0 0 Combined with the other recommended changes: - Remove udev-postmount from runlevels. - Enable CONFIG_DEVTMPFS=y in the kernel; I've also seen recommendation to enable: CONFIG_DEVTMPFS_MOUNT=y ? need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs) I have no /dev line, and only one network adapter, so nothing to do here - The case of separate /usr; if it worked for you with 171 it will continue to work for you with 197 (or newer). We still recommend initramfs with separate /usr mounting capabilities because you might need packages like sys-apps/kbd (keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot. Ok, this one is unclear... My system is currently indeed (and always has been) booting fine with a separate /usr (on lvm)... but... The above reference to 'might need packages like sys-apps/kbd', which is now *required* by udev, suggests that now I again do need an initramsf? Thanks for ya'lls patience. I have a feeling this is going to be another non-event, but I'd much prefer a little pre-update pain than a lot of post-update pain... ;)
Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
On Mon, 18 Mar 2013 07:15:39 -0400, Tanstaafl wrote: Thanks for ya'lls patience. I have a feeling this is going to be another non-event, but I'd much prefer a little pre-update pain than a lot of post-update pain... ;) quickpkg udev before the update. Then if it all goes TU, you can boot from a live disc and untar the package into your root directory. -- Neil Bothwick Remember that the Titanic was built by experts, and the Ark by a newbie signature.asc Description: PGP signature
[gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
Ok, I sync'd this morning, and now see the warning about udev 171-r10 being masked, so I guess it is time.. I know this was discussed quite a bit a few months ago, but just to refresh my memory... My question is, if I am currently running 171-r10 on my server, and I have a separate lvm managed /usr partition, is it now safe to comment out my udev masks and update udev, with a reasonable expectation that doing so won't break my boot ability? Also, should I manually fix the blockers: [blocks B ] sys-apps/module-init-tools (sys-apps/module-init-tools is blocking sys-apps/kmod-12-r1) [blocks B ] sys-apps/kmod (sys-apps/kmod is blocking sys-apps/module-init-tools-3.16-r2) by doing emerge -C module-init-tools emerge kmod *before* upgrading udev? Or does it matter? Thanks...
Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
On Sun, 17 Mar 2013 13:46:39 -0400, Tanstaafl wrote: Also, should I manually fix the blockers: [blocks B ] sys-apps/module-init-tools (sys-apps/module-init-tools is blocking sys-apps/kmod-12-r1) [blocks B ] sys-apps/kmod (sys-apps/kmod is blocking sys-apps/module-init-tools-3.16-r2) by doing emerge -C module-init-tools emerge kmod *before* upgrading udev? No, because that adds kmod to world. Just unmerge module-init-tools and then emerge world, letting portage install what it needs. -- Neil Bothwick I don't know what makes you tick but I wish it was a time bomb. signature.asc Description: PGP signature
Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
On 2013-03-17 2:17 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 17 Mar 2013 13:46:39 -0400, Tanstaafl wrote: Also, should I manually fix the blockers: [blocks B ] sys-apps/module-init-tools (sys-apps/module-init-tools is blocking sys-apps/kmod-12-r1) [blocks B ] sys-apps/kmod (sys-apps/kmod is blocking sys-apps/module-init-tools-3.16-r2) by doing emerge -C module-init-tools emerge kmod *before* upgrading udev? No, because that adds kmod to world. Just unmerge module-init-tools and then emerge world, letting portage install what it needs Ah, ok... but as for the rest... I should be able to safely upgrade udev, with a reasonable (I know there are no guarantees) expectation of everything 'just working' (ie, my lvm managed /usr partition shouldn't be an issue like it would have been earlier on in this process)? Thanks Neil
Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...
On Sun, 17 Mar 2013 14:33:50 -0400, Tanstaafl wrote: Ah, ok... but as for the rest... I should be able to safely upgrade udev, with a reasonable (I know there are no guarantees) expectation of everything 'just working' (ie, my lvm managed /usr partition shouldn't be an issue like it would have been earlier on in this process)? It worked for me on more than one machine, but that's no guarantee that it will even work for me again, let alone for you. It should work, and if it doesn't, at least you get to keep the pieces... -- Neil Bothwick New sig wanted good price paid. signature.asc Description: PGP signature
