Arch Linux

We should really write a notice to all affected pages in the wiki, because this causes a bunch of different problems.
Maybe the tip from 25659 could be added

/*
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 23 August 2011, 20:07 GMT-4
Or trivially but not dynamic: "ln -s /dev/your-partition /lib/udev/devices/root". Just keep in mind this if you change your root-partition on migration ;)
*/

https://wiki.archlinux.org/index.php/Kernel_Compilation_without_ABS
https://wiki.archlinux.org/index.php/Kernel_Compilation_without_ABS_for_New_Users#16.29_Configure_Bootloader
https://wiki.archlinux.org/index.php/GRUB2

Loading a the initrd is unwanted by many custom-kernel users, it is unnecessary. So including the initrd is a ugly workaround. Also it should (?) be necessary to remove one or more hooks from the mkinitcpip.conf (filesystem, sata or pata). With the initrd (and the regular hooks) it get always a message that the "modprobe.dep" couldn't be loaded, it think this is caused by one of this hooks. But editing the mkinitcpio.conf will, of course, break the kernels offered by Archlinux itself!

Have you tried configuring your kernel with CONFIG_DEVTMPFS_MOUNT=y ? Fixed it for me

Can this be closed now that https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ is required?

I run a custom 3.2 kernel compiled with CONFIG_DEVTMPFS_MOUNT=y w/o initrd and I still experience the described problem.

Here are the current mount points:
% mount
/dev/root on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1024896k,nr_inodes=256224,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
/sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=262144k)
%

Also /dev/root actually does not exist:
% file /dev/root
/dev/root: ERROR: cannot open `/dev/root' (No such file or directory)
%

How about I modify the install message to say something similar to
'Trying to automatically create a config. This may fail on some systems running a custom kernel. Please refer to the wiki on how to create a config manually'

Or do we know what exactly makes it fail so we can condition on that?

@pressh: Why are you trying to run grub-mkconfig in post_install when you don't (similarly) run grub-install? If the users want, they can run it manually. There is no need to generate a grub.cfg when the package is installed. I, for one, don't use grub-mkconfig at all. I maintain my grub.cfg manually. Running mkconfig becomes a stumbling block for remaining/other package upgrades. Just install the package, don't run anything.

@Keshav: There is a difference here. We only run grub-mkconfig once, on first install. It doesn't create the grub.cfg config file but an example config file which you still need to check and copy yourself. So all it does is create a reasonable example config file for your system (if it works that is). You still can and need to manage it yourself. IMO it is still better to provide a reasonable config 80% of the time than providing a random config all the time.

So no, it is not the same as running grub-install, which actually has effect on your systems behavior. IMO that should not be done (I'm not sure what would happen if you would run this in a chroot or something....)

Either way, we can set a conditional on when to or not to run grub-mkconfig (if we know that is), or simply try to run it and have a message stating that is may fail on some custom kernels. We could even copy a generic example file and try to overwrite it with grub-mkconfig so if it fails there is still something there that the user can build upon. Though I don't think I prefer this last one.

Btw this is the grub2 bug I'd like to close before pushing the updated packages, the rest is already in trunk (mostly).