Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19903 - [mkinitcpio] Something seems to be wrong in 0.6.6.

Attached to Project: Arch Linux
Opened by James (JRMoore) - Tuesday, 22 June 2010, 16:41 GMT
Last edited by Thomas Bächler (brain0) - Thursday, 01 July 2010, 16:13 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I'm using a custom kernel with tuxonice, uvesafb (integrated), fbcondecor and devtmpfs enabled and rebuilding the current initramfs with the new version of mkinitcpio generates a somewhat broken one:

uvesafb errors:
uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22

fbsplash also complains about not being able to find the speficied theme and trying to hibernate doesn't show the userui either. Are the files and binaries specified in the config file for mkinitcpio included in the newer version? Generating the image using version 0.6.4 works as expected.

Here you may find the current mkinitcpio I'm using for that kernel: http://pastebin.ca/1888592
This task depends upon

Closed by  Thomas Bächler (brain0)
Thursday, 01 July 2010, 16:13 GMT
Reason for closing:  Fixed
Comment by Thomas Bächler (brain0) - Tuesday, 22 June 2010, 20:03 GMT
Some time ago I knew that error -22 means. As for the other problems, I have no explanation right now. You can check mkinitcpio.git for details.
Comment by James (JRMoore) - Saturday, 26 June 2010, 11:04 GMT
I have played a bit with the git code and the commit which produces the breakage is the one between 0.6.5 and 0.6.6, "Create /dev/{null,zero,mem,console} devices when devtmpfs is missing".

The strange thing about that is that I have devtmpfs enabled in my kernel, and the default Arch kernel v2.6.34 has the same options selected:

CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set

Do you have any idea on what could be the problem?

From this commit the initrd image will produce the described errors: http://projects.archlinux.org/mkinitcpio.git/commit/?id=96a4abdbbf8f490e97e72435627938a2577c613e
Comment by James (JRMoore) - Saturday, 26 June 2010, 11:22 GMT
In my case, adding [1] back to base everything works as expected, but I don't know why nor if it's safe to change this as I don't have a deep knowledge in the matter.

[1]:

add_device "/dev/zero" c 1 5
add_device "/dev/mem" c 1 1
Comment by Thomas Bächler (brain0) - Saturday, 26 June 2010, 11:31 GMT
Now I know what's going on: I overlooked that you have uvesafb built-in (as in: not as a module). In that case, uvesafb will start v86d the moment initramfs has been extracted and does not wait for us to mount (dev)tmpfs and create /dev/mem. However, v86d needs /dev/mem access to function properly.

I guess we should add back the device to base - they don't hurt anyone: http://projects.archlinux.org/mkinitcpio.git/commit/?id=6d2ef0afddb8ab62ac5019e203fa85bb4a9f5165
Comment by James (JRMoore) - Thursday, 01 July 2010, 14:25 GMT
I'm sorry for the late posting, thank you for your time and answer.

Anyway, if you don't like those devices to be there (this case is rare, I guess not many people have uvesafb enabled and integrated in the kernel) knowing that it's safe to have them there I can recompile mkinitcpio for my needs every time it's updated without problems.

This bug report can be closed, having those devices in base fixed the issue.
Comment by Thomas Bächler (brain0) - Thursday, 01 July 2010, 16:13 GMT
Well, I added them back, so they will be back in the next version.

Loading...