| View previous topic :: View next topic |
| Author |
Message |
666threesixes666
Veteran
Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w
|
 Posted: Fri May 31, 2013 6:30 pm Post subject: uvesafb failed to mount root block |
 |
|
as soon as i insert initramfs the kernel has an exception. unable to mount root device.
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_UVESA=y
CONFIG_FB_VESA=y
CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_INITRAMFS_COMPRESSION_NONE=y
both 3.4.47 & 3.9.4 are acting like this.....
fb vesa + fb boot vesa = no same behavior.... |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54232
Location: 56N 3W
|
| Posted: Fri May 31, 2013 8:23 pm Post subject: |
|
|
666threesixes666,
What about | Code: | | CONFIG_BLK_DEV_INITRD=y |
I roll my own initramfs, since it saves rebuilding the kernel to change the initramfs.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
666threesixes666
Veteran
Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w
|
| Posted: Fri May 31, 2013 9:30 pm Post subject: |
|
|
yeah...
kernel...
http://bpaste.net/show/OuVpxPjtu7iwTWZXh3cn/
initramfs kernel points to....
http://bpaste.net/show/1547ZWabzkaFogPpPaAH/
prime suspect > dev-libs/klibc-1.5.20, though klibc-2.0.2 did the same thing.
it could have something to do with edid support not being compiled into the kernel the original klibc was compiled against. though i know i re-merged it upon finding edid unselected.
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_FIRMWARE_EDID=y
i also tried enabling vesafb, stabbing every option like a tinfoil psycho.
"Kernel Panic: VFS: Unable to mount root fs on unknown-block(0,0)"
before it did not mind my JFS/xfs drives and did not throw errors of this sort because an initramfs was linked in the kernel configuration.
>> latest update...
moved initramfs location out of kernel to let grub boot the initramfs, and its throwing the errors of kernel panics above. i have my file system compiled into the kernel, but i did not compile them into the initramfs.... this should not be this difficult. |
|
| Back to top |
|
|
666threesixes666
Veteran
Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w
|
| Posted: Sat Jun 08, 2013 4:49 am Post subject: |
|
|
do you have any reason why its going on with this? as soon as i insert
| Code: |
/boot/initramfs-3.9.5.img
|
to grub2, it kernel panics saying it cant find v86d & then wont boot cant find root drive.....
and it contains these lines.
| Code: |
mkultra@mksrv ~ $ cat /boot/initramfs-3.9.5.img.backup
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
nod /dev/tty1 0600 0 0 c 4 1
nod /dev/zero 0600 0 0 c 1 5
nod /dev/mem 0600 0 0 c 1 1
dir /root 0700 0 0
dir /sbin 0755 0 0
file /sbin/v86d /sbin/v86d 0755 0 0
|
&&
| Code: |
mkultra@mksrv ~ $ stat /sbin/v86d
File: '/sbin/v86d'
Size: 115440 Blocks: 232 IO Block: 4096 regular file
Device: 813h/2067d Inode: 21360 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-06-08 00:44:54.886529027 -0400
Modify: 2013-06-08 00:44:54.887529016 -0400
Change: 2013-06-08 00:44:56.305513825 -0400
Birth: -
|
Initramfs unpacking failed: junk in compressed archive |
|
| Back to top |
|
|
666threesixes666
Veteran
Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w
|
| Posted: Tue Jul 30, 2013 5:20 pm Post subject: |
|
|
again, bump... followed wiki to a T... rebooted between every kernel configuration stage. as soon as CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" it fails to mount root on unknown-block 0,0
kernel 3.9.11
its been a while since ive seen uvesafb, vesafb works well for me, but id like to be able to tell it 1024x768-32 instead of some coded garbage.
the uvesa penguins load up, it looks like v86d is loaded then the initramfs takes a poo. |
|
| Back to top |
|
|
ddavidson72
n00b
Joined: 29 Dec 2013
Posts: 8
|
| Posted: Sun Dec 29, 2013 7:47 pm Post subject: |
|
|
Hi. I am writing to confirm that I also have this exact same problem with the most recent kernel 3.10.17.
Everything works great until I configured the v86d framebuffer option:
Changing this:
| Code: |
CONFIG_INITRAMFS_SOURCE=""
|
to this:
| Code: |
CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs"
|
...build the kernel with the new option and the system fails to boot.
I noticed exactly what is happening. I believe that the kernel is dynamically assigning the disk drive device identifiers for the disks on this system. The kernel should be loading the root from /dev/sda2. I have:
in my grub.conf [menu.lst] file.
If I use the CONFIG_INITRAMFS_SOURCE option mentioned above, the kernel panics on boot and complains that it could not find /dev/sda2. It then mentions that it found /dev/sdi2. So then if I change the GRUB command line to use sdi2 instead, it boots:
This isn't a very good fix though, because if I insert an SD card into device, it again renames the device description to /dev/sdj2 [!!!] So here again, on the next boot, I get a kernel panic because it couldn't mount the root file system. It's almost like the USB card reader or other block devices on the system are being assigned a higher priority and moving the hard disk that should be assigned to /dev/sda further down on the list.
This is with legacy grub; I had a difficult time using UUID or /dev/disk/by-id identifiers on the GRUB command line, which would have solved this problem for me. I know that perhaps moving to grub2 would definitely permit me to use UUID or bus identifiers, but even still, I really think that changing the silly v86d framebuffer option should NOT have anything to do with the naming convention for the drive IDs and somebody should take a better look at this and determine the rhyme or reason why this would happen.
Said differently, /dev/sda should always be /dev/sda, framebuffer option or not.
Also, I should mention that I am not using any initramfs image for this system, and I don't believe that I should have to use one.
Does anyone think that there might be a bug open for this, or should there be one?
Thank you for your thoughts. |
|
| Back to top |
|
|
666threesixes666
Veteran
Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w
|
| Posted: Mon Dec 30, 2013 6:37 am Post subject: |
|
|
my guess.... regression in kernel... im all the way up to 3.12.4 now ill get 3.12.6 going one of these days. 3.12.6 boots, but i get white screen, i suspect its conflicting with my nouveau frame buffer. at least the disk mounts and i can blindly pass commands to terminals. i followed wiki to a T only except adding a reboot and loading of kernel instead of just symlinking @ that part of the wiki.
http://nouveau.freedesktop.org/wiki/KernelModeSetting/
makes sense, this page says nouveau and uveasafb conflict..... ill have to do this to the desktop since that runs the evil empires drivers. |
|
| Back to top |
|
|
|
Installing Gentoo
