I noticed late Sunday night that I was booting after the usrmove procedure from a pre-usrmove kernel. When I tried to boot from a kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), I got:
"/bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!"
So I rebuilt another Rawhide VM and went through the same procedure but I'm having the same problem.
I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail at the same point.
Has anyone been able to boot from a kernel installed from the f17-usrmove repository?
On Tue, Jan 31, 2012 at 3:47 AM, Tom H tomh0665@gmail.com wrote:
I noticed late Sunday night that I was booting after the usrmove procedure from a pre-usrmove kernel. When I tried to boot from a kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), I got:
"/bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!"
So I rebuilt another Rawhide VM and went through the same procedure but I'm having the same problem.
I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail at the same point.
Has anyone been able to boot from a kernel installed from the f17-usrmove repository?
Those kernels are just inherited from rawhide. There isn't a specially built kernel in the f17-usrmove repo that I'm aware of.
Also, the problem is in your initramfs, not the kernel itself.
Harald?
josh
On Tue, Jan 31, 2012 at 7:42 AM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jan 31, 2012 at 3:47 AM, Tom H tomh0665@gmail.com wrote:
I noticed late Sunday night that I was booting after the usrmove procedure from a pre-usrmove kernel. When I tried to boot from a kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), I got:
"/bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!"
So I rebuilt another Rawhide VM and went through the same procedure but I'm having the same problem.
I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail at the same point.
Has anyone been able to boot from a kernel installed from the f17-usrmove repository?
Those kernels are just inherited from rawhide. There isn't a specially built kernel in the f17-usrmove repo that I'm aware of.
Thanks (although I thought that I'd seen an email here about a patch to the usrmove kernels).
Also, the problem is in your initramfs, not the kernel itself.
Harald?
I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs.
I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work...
On Tue, Jan 31, 2012 at 8:30 AM, Tom H tomh0665@gmail.com wrote:
On Tue, Jan 31, 2012 at 7:42 AM, Josh Boyer jwboyer@gmail.com wrote:
On Tue, Jan 31, 2012 at 3:47 AM, Tom H tomh0665@gmail.com wrote:
I noticed late Sunday night that I was booting after the usrmove procedure from a pre-usrmove kernel. When I tried to boot from a kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17), I got:
"/bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Kernel panic - not syncing: Attempted to kill init!"
So I rebuilt another Rawhide VM and went through the same procedure but I'm having the same problem.
I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail at the same point.
Has anyone been able to boot from a kernel installed from the f17-usrmove repository?
Those kernels are just inherited from rawhide. There isn't a specially built kernel in the f17-usrmove repo that I'm aware of.
Thanks (although I thought that I'd seen an email here about a patch to the usrmove kernels).
Also, the problem is in your initramfs, not the kernel itself.
Harald?
I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs.
I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work...
Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6":
[root@localhost ~]# find . -name 'libc.so.6' ./rc4/run/initramfs/lib/libc.so.6 [root@localhost ~]#
On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote:
Also, the problem is in your initramfs, not the kernel itself.
Harald?
I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs.
I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work...
Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6":
[root@localhost ~]# find . -name 'libc.so.6' ./rc4/run/initramfs/lib/libc.so.6 [root@localhost ~]#
The initramfs is generated on-the-fly when the kernel is installed. So I suspect the bug here is correctly described as 'When installing any kernel package after doing the /usr move updates, the generated initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel package in question doesn't matter, it's rather that any attempt to generate an initramfs after doing the /usr move will fail. This is obviously a significant problem, if I'm correct.
On Tue, 2012-01-31 at 09:26 -0800, Adam Williamson wrote:
On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote:
Also, the problem is in your initramfs, not the kernel itself.
Harald?
I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs.
I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work...
Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6":
[root@localhost ~]# find . -name 'libc.so.6' ./rc4/run/initramfs/lib/libc.so.6 [root@localhost ~]#
The initramfs is generated on-the-fly when the kernel is installed. So I suspect the bug here is correctly described as 'When installing any kernel package after doing the /usr move updates, the generated initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel package in question doesn't matter, it's rather that any attempt to generate an initramfs after doing the /usr move will fail. This is obviously a significant problem, if I'm correct.
Has anyone else who's done the /usr move tried to install a kernel after the move? If so, does it work, or do you hit the same problem Tom hit?
On Tue, Jan 31, 2012 at 3:25 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2012-01-31 at 09:26 -0800, Adam Williamson wrote:
On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote:
Also, the problem is in your initramfs, not the kernel itself.
Harald?
I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs.
I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work...
Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6":
[root@localhost ~]# find . -name 'libc.so.6' ./rc4/run/initramfs/lib/libc.so.6 [root@localhost ~]#
The initramfs is generated on-the-fly when the kernel is installed. So I suspect the bug here is correctly described as 'When installing any kernel package after doing the /usr move updates, the generated initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel package in question doesn't matter, it's rather that any attempt to generate an initramfs after doing the /usr move will fail. This is obviously a significant problem, if I'm correct.
Has anyone else who's done the /usr move tried to install a kernel after the move? If so, does it work, or do you hit the same problem Tom hit?
I hope that no one else hits it and that it's just some bad juju on my side but it's happened with two different installs. I've also just duped my VM and run dracut for the bootable kernel - and it's now unbootable.
[root@localhost ~]# rpm -q dracut dracut-014-77.git20120126.fc17.1.noarch
On 31/01/12 20:25, Adam Williamson wrote:
Has anyone else who's done the /usr move tried to install a kernel after the move? If so, does it work, or do you hit the same problem Tom hit?
I ran into the same problem, but after seeing Tom's post held off reporting.
Will check more guests in the morning.
On Tue, Jan 31, 2012 at 12:26 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2012-01-31 at 10:44 -0500, Tom H wrote:
Also, the problem is in your initramfs, not the kernel itself.
Harald?
I was about to follow up. I tried rebuilding the rc6 kernel's initramfs but there was no joy. I then managed to boot with the rc6 kernel using the rc4 initramfs.
I've unpacked my the rc4 and rc6 initramfs's to take a look but have had to go back to real work...
Unpacked initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img to "~/rc4" and initramfs-3.3.0-0.rc1.git6.1.fc17.i686.img to "~/rc6":
[root@localhost ~]# find . -name 'libc.so.6' ./rc4/run/initramfs/lib/libc.so.6 [root@localhost ~]#
The initramfs is generated on-the-fly when the kernel is installed. So I suspect the bug here is correctly described as 'When installing any kernel package after doing the /usr move updates, the generated initramfs will not contain /lib/libc.so.6' - i.e. the actual kernel package in question doesn't matter, it's rather that any attempt to generate an initramfs after doing the /usr move will fail. This is obviously a significant problem, if I'm correct.
Bug submitted:
On 31/01/12 17:26, Adam Williamson wrote:
The initramfs is generated on-the-fly when the kernel is installed.
I presume initramfs gets the libc.so.6 from /usr/lib ?
On my post /usr box. /usr/lib/libc.so.6 is a symlink itself to /usr/lib/libcc-2.15.so
Is it the double softlink that's breaking things. /usr/bin/ > /usr/lib/libc.so.6 > /usr/lib/libcc-2.15.so
-
Adam Williamson -
Frank Murphy -
Josh Boyer -
Tom H