Upgraded F17 kernel to 3.8.8-100. Now it goes boots though udevd, i.e. "Welcome" seems to find the devices, though it's hard to tell since everything goes so fast.
/var/log/messages has no messages from these boot loops.
3.7.9-104 works.
3.8.4-102, but now dies with an fb message that nouveaufb conflicts with vesa vga, so it's removing the generic driver. But it just hangs there.
Any help appreciated.
sean
Am 30.04.2013 18:44, schrieb sean darcy:
Upgraded F17 kernel to 3.8.8-100. Now it goes boots though udevd, i.e. "Welcome" seems to find the devices, though it's hard to tell since everything goes so fast.
/var/log/messages has no messages from these boot loops.
3.7.9-104 works.
3.8.4-102, but now dies with an fb message that nouveaufb conflicts with vesa vga, so it's removing the generic driver. But it just hangs there.
Any help appreciated
* make sure "installonly_limit" in "/etc/yum.conf" is high enough to not remove the 3.7.x
* http://koji.fedoraproject.org/koji/packageinfo?packageID=8
there are a lot of newer builds 3.8.8.100 is the first 3.8
3.8.8.102 has a lot of security fixes and works here in production http://koji.fedoraproject.org/koji/buildinfo?buildID=414142
3.8.10-100.fc17 is the most recent F17 kernel the F18 build from it works fine on HP machines as also VMware guests http://koji.fedoraproject.org/koji/buildinfo?buildID=415092
On 04/30/2013 10:14 AM, Reindl Harald wrote:
- make sure "installonly_limit" in "/etc/yum.conf" is high enough to not remove the 3.7.x
If you really want to be safe:
yum remove kernel
will remove all installed kernels *except* for the one you're currently using. (That is, yum won't allow you to leave yourself without a kernel for the next time you boot.) You probably don't need to be this heavy-handed, but you never know when something like this might come in handy.
On 04/30/2013 02:05 PM, Joe Zeff wrote:
On 04/30/2013 10:14 AM, Reindl Harald wrote:
- make sure "installonly_limit" in "/etc/yum.conf" is high enough to not remove the 3.7.x
If you really want to be safe:
yum remove kernel
will remove all installed kernels *except* for the one you're currently using. (That is, yum won't allow you to leave yourself without a kernel for the next time you boot.) You probably don't need to be this heavy-handed, but you never know when something like this might come in handy.
I did that. Ran yum update. Same problem.
But I figured it out. I've been planning to upgrade to F18 when I have the courage. I've run fedup. But then when I upgrade to a new F17, grub2, in it's infinite wisdom, places all the upgrade stuff from a fedup boot to the command line of the new F17 kernel.
Only way to fix is to go edit grub.cfg itself. And you need to keep doing it with every kernel upgrade. Sigh.
sean
On Thu, 2013-05-02 at 13:17 -0400, sean darcy wrote:
On 04/30/2013 02:05 PM, Joe Zeff wrote:
On 04/30/2013 10:14 AM, Reindl Harald wrote:
- make sure "installonly_limit" in "/etc/yum.conf" is high enough to not remove the 3.7.x
If you really want to be safe:
yum remove kernel
will remove all installed kernels *except* for the one you're currently using. (That is, yum won't allow you to leave yourself without a kernel for the next time you boot.) You probably don't need to be this heavy-handed, but you never know when something like this might come in handy.
I did that. Ran yum update. Same problem.
But I figured it out. I've been planning to upgrade to F18 when I have the courage. I've run fedup. But then when I upgrade to a new F17, grub2, in it's infinite wisdom, places all the upgrade stuff from a fedup boot to the command line of the new F17 kernel.
Only way to fix is to go edit grub.cfg itself. And you need to keep doing it with every kernel upgrade. Sigh.
GRUB2 works more like LILO than like old GRUB, in that there is a configuration file to edit and an installation procedure to get the boot process to use the updated configuration.
The file to edit is /etc/default/grub. The installation command is
grub2-mkconfig -o /boot/grub2/grub.cfg
That command runs some scripts that create /boot/grub2/grub.cfg, which--as you've discovered--you should never edit.
/etc/default/grub is a set of shell variable definitions. The one you want to edit is GRUB_CMDLINE_LINUX, which contains a template for the kernel command line arguments. Once this is fixed, the kernel update process should work correctly.
If have trouble figuring out what to fix, post the contents of your /etc/default/grub here.
If you are annoyed by the "missing font file" error message when grub2 starts, add the line
LANG=C
to the top of that file.
sean
On 05/02/2013 03:07 PM, Matthew Saltzman wrote:
On Thu, 2013-05-02 at 13:17 -0400, sean darcy wrote:
On 04/30/2013 02:05 PM, Joe Zeff wrote:
On 04/30/2013 10:14 AM, Reindl Harald wrote:
- make sure "installonly_limit" in "/etc/yum.conf" is high enough to not remove the 3.7.x
If you really want to be safe:
yum remove kernel
will remove all installed kernels *except* for the one you're currently using. (That is, yum won't allow you to leave yourself without a kernel for the next time you boot.) You probably don't need to be this heavy-handed, but you never know when something like this might come in handy.
I did that. Ran yum update. Same problem.
But I figured it out. I've been planning to upgrade to F18 when I have the courage. I've run fedup. But then when I upgrade to a new F17, grub2, in it's infinite wisdom, places all the upgrade stuff from a fedup boot to the command line of the new F17 kernel.
Only way to fix is to go edit grub.cfg itself. And you need to keep doing it with every kernel upgrade. Sigh.
GRUB2 works more like LILO than like old GRUB, in that there is a configuration file to edit and an installation procedure to get the boot process to use the updated configuration.
The file to edit is /etc/default/grub. The installation command is
grub2-mkconfig -o /boot/grub2/grub.cfgThat command runs some scripts that create /boot/grub2/grub.cfg, which--as you've discovered--you should never edit.
/etc/default/grub is a set of shell variable definitions. The one you want to edit is GRUB_CMDLINE_LINUX, which contains a template for the kernel command line arguments. Once this is fixed, the kernel update process should work correctly.
If have trouble figuring out what to fix, post the contents of your /etc/default/grub here.
If you are annoyed by the "missing font file" error message when grub2 starts, add the line
LANG=Cto the top of that file.
sean
You miss the point. /etc/default/grub was never changed, and CMDLINE is the same as always: GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8"
Nonetheless, grub2 is putting all the upgrade stuff in the command line. That's the error.
sean
On Thu, 2013-05-02 at 22:31 -0400, sean darcy wrote:
On 05/02/2013 03:07 PM, Matthew Saltzman wrote:
On Thu, 2013-05-02 at 13:17 -0400, sean darcy wrote:
On 04/30/2013 02:05 PM, Joe Zeff wrote:
On 04/30/2013 10:14 AM, Reindl Harald wrote:
- make sure "installonly_limit" in "/etc/yum.conf" is high enough to not remove the 3.7.x
If you really want to be safe:
yum remove kernel
will remove all installed kernels *except* for the one you're currently using. (That is, yum won't allow you to leave yourself without a kernel for the next time you boot.) You probably don't need to be this heavy-handed, but you never know when something like this might come in handy.
I did that. Ran yum update. Same problem.
But I figured it out. I've been planning to upgrade to F18 when I have the courage. I've run fedup. But then when I upgrade to a new F17, grub2, in it's infinite wisdom, places all the upgrade stuff from a fedup boot to the command line of the new F17 kernel.
Only way to fix is to go edit grub.cfg itself. And you need to keep doing it with every kernel upgrade. Sigh.
GRUB2 works more like LILO than like old GRUB, in that there is a configuration file to edit and an installation procedure to get the boot process to use the updated configuration.
The file to edit is /etc/default/grub. The installation command is
grub2-mkconfig -o /boot/grub2/grub.cfgThat command runs some scripts that create /boot/grub2/grub.cfg, which--as you've discovered--you should never edit.
/etc/default/grub is a set of shell variable definitions. The one you want to edit is GRUB_CMDLINE_LINUX, which contains a template for the kernel command line arguments. Once this is fixed, the kernel update process should work correctly.
If have trouble figuring out what to fix, post the contents of your /etc/default/grub here.
If you are annoyed by the "missing font file" error message when grub2 starts, add the line
LANG=Cto the top of that file.
sean
You miss the point. /etc/default/grub was never changed, and CMDLINE is the same as always: GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8"
Sorry, the point wasn't clear, as you only referenced editing grub.cfg.
Nonetheless, grub2 is putting all the upgrade stuff in the command line. That's the error.
The scripts that are run by grub2-mkconfig reside in /etc/grub.d. Is there anything in that directory related to running the update?
Fedup apparently involves some systemd services. Are some enabled that should be turned off?
sean
-
Joe Zeff -
Matthew Saltzman -
Reindl Harald -
sean darcy