F10 post installation kernel issue?

Daniel B. Thurman dant at cdkkt.com
Wed Feb 4 00:28:30 UTC 2009


Rick Stevens wrote:
> Daniel B. Thurman wrote:
>> Rick Stevens wrote:
>>> Daniel B. Thurman wrote:
>>>> Rick Stevens wrote:
>>>>> Daniel B. Thurman wrote:
>>>>>> Daniel B. Thurman wrote:
>>>>>>>
>>>>>>> First time F10 install went well.  One thing I did
>>>>>>> differently in installing F10 was to:
>>>>>>>
>>>>>>> 1) Use the Volume based filesystems
>>>>>>> 2) Enabled disk encryption
>>>>>>>
>>>>>>> I noticed that on every reboot, one must enter the password
>>>>>>> long before seeing a grub display.  Hmm...  maybe for a server
>>>>>>> this is not the way to go, but for a workstation, it's probably ok.
>>>>>>>
>>>>>>> Anyway, the initial kernel I started with is:
>>>>>>> (1) kernel-2.6.27.5-117.fc10.i686
>>>>>>>
>>>>>>> I proceeded to get the latest updates and this was approx. 1 
>>>>>>> week ago.
>>>>>>>
>>>>>>> I later added programs I wanted installed, configured the 
>>>>>>> services I wanted,
>>>>>>> etc., etc., and everything went well.  I was able to reboot, no 
>>>>>>> problems.
>>>>>>>
>>>>>>> But then a few days later, more updates came through, but 
>>>>>>> specifically
>>>>>>> a new kernel was added:
>>>>>>> (2) kernel-2.6.27.9-159.fc10.i686
>>>>>>>
>>>>>>> Rebooting, I got the messages:
>>>>>>> ======================
>>>>>>> ata1: ACPI get timing mode failed (AE 0x300d)
>>>>>>> Loading /lib/kdb/Keymaps/i386/qwerty/us.map
>>>>>
>>>>> Eh?  Sure that's not "/lib/kbd/keymaps/i386/qwerty/us.map" 
>>>>> (/lib/kbd NOT
>>>>> /lib/kdb and no capital K)?
>>>>>
>>>>> If what you posted is what's really being displayed, then we have
>>>>> serious problems.  The correct directory is provided by kbd RPM.
>>>>>
>>>>>
>>>>>
>>>>>>> [hang]
>>>>>>>
>>>>>>> So, I never got to the point where I needed to enter
>>>>>>> the encrypted disk password for continuance.
>>>>>>>
>>>>>>> To be sure, I rebooted back to the original kernel (1),
>>>>>>> and it booted just fine.  Leaving it there, I continued using
>>>>>>> the system, but got yet another kernel update:
>>>>>>> (3) kernel-2.6.27.12-170.2.5.fc10.i686
>>>>>>>
>>>>>>> Same problem reported in (2) above.  So I am still
>>>>>>> stuck at using my initial kernel at (1).
>>>>>>>
>>>>>>> Is there anything I can do or to check to understand why
>>>>>>> I am not able to use the latest kernels?
>>>>>
>>>>> If the system is looking for the keymap you've shown, it won't 
>>>>> find it,
>>>>> the console won't be set up and things will come to a screeching 
>>>>> halt.
>>>>> I run 64-bit kernels so I can't test it and I don't know where it's
>>>>> getting that path from.  I have run all the kernels you show and they
>>>>> run fine here.  None ask for that funky keymap path.
>>>> I double-checked and got that path wrong initially.
>>>> The correct path shown on boot up (but appears ONLY
>>>> with the later newer kernels) are:
>>>>
>>>> /lib/kbd/keymaps/i386/qwerty/us.map
>>>>
>>>> It still hangs.  The interesting thing is, as I said, I can
>>>> boot with the first kernel (1) installed but not the ones
>>>> following.  Still scratching my head...
>>>
>>> Ok, hmmm.  It looks like the initrd images didn't get built right.  
>>> Boot
>>> up under the kernel that works, then as root:
>>>
>>>     # cd /boot
>>>     # mkinitrd -f -v initrd-2.6.27.12-170.2.5.fc10.i686.img
>>>         2.6.27.12-170.2.5.fc10.i686
>>>
>>> (the second and third lines should be ONE line...my mailer is wrapping
>>> them)
>>>
>>> Then try rebooting using that -170 kernel again.  The keymaps and 
>>> things
>>> actually are in the initrd image as well as the main system.  See if
>>> that does the job.
>> Did what you suggested and it does not change anything.  Still hangs.
>> I tried autorelabel for SeLinux just in case, no change.  It is 
>> subjective,
>> but could having the filesystem encrypted be a problem?
>
> I've heard of issues regarding encrypted filesystems.  I'm pretty sure
> there's a thread on it in this forum somewhere.  It may be that the
> initrd didn't get built with the cryptographic stuff.  I don't think
> mkinitrd is smart enough to realize it needs the crypto stuff from the
> /etc/modprobe.conf or /etc/fstab and you have to force feed it that
> stuff with "--with=module" on the command line.
>
> >                                                            Did you try
>> to see if you can run all the kernel version under an encrypted 
>> filesystem?
>
> I don't use encrypted filesystems myself, so I'm going to have to bow
> out on any of that stuff.  However, when you built the initrd, I 
> recommended you use the "-v" flag.  You should have seen it include the
> crypto modules along with the "dm-" stuff.  If not...well, that may be
> your problem.
>
>> I am now testing to see if removing any packages (one by one) has any 
>> effect,
>> a shot in the dark, but I do not know what else to do.
>
> Don't think that's it.  It's quitting long before any other stuff is
> loaded up...it's definitely having issues with the root filesystem,
> and I'm willing to bet it is this crypto stuff.  Check the archives of
> this list to find the thread(s) regarding it.
I think I discovered what it was.

I was looking over the grub stuff, specifically to those newly
added kernels and at the grub kernel line, I found this added to
the end of that line:

init=/sbin/bootchartd

What the heck is that!?!?

I edited this out in grub, and booted, a LO AND BEHOLD!  It worked!

Geez, what is going on?

Thanks for bearing with me!
Dan




More information about the fedora-list mailing list