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=1&chap=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
