2:47 a.m.
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?
6:42 a.m.
On Tue, Jan 31, 2012 at 3:47 AM, Tom H <tomh0665(a)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
7:30 a.m.
On Tue, Jan 31, 2012 at 7:42 AM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Tue, Jan 31, 2012 at 3:47 AM, Tom H <tomh0665(a)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...
9:44 a.m.
On Tue, Jan 31, 2012 at 8:30 AM, Tom H <tomh0665(a)gmail.com> wrote:
On Tue, Jan 31, 2012 at 7:42 AM, Josh Boyer <jwboyer(a)gmail.com>
wrote:
> On Tue, Jan 31, 2012 at 3:47 AM, Tom H <tomh0665(a)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 ~]#
11:26 a.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:25 p.m.
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?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:08 p.m.
On Tue, Jan 31, 2012 at 3:25 PM, Adam Williamson <awilliam(a)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
4:04 p.m.
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.
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
3:03 p.m.
On Tue, Jan 31, 2012 at 12:26 PM, Adam Williamson <awilliam(a)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:
https://bugzilla.redhat.com/show_bug.cgi?id=786261
4:33 a.m.
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
--
Regards,
Frank Murphy, friend of fedoraproject
UTF_8 Encoded
4467
days inactive
4468
days old
10 comments
4 participants
participants (4)
-
Adam Williamson -
Frank Murphy -
Josh Boyer -
Tom H