[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HP ZX6000 & Debian "testing"



Hi,

Don't bother with it anymore, I've identified the root cause (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068#42 for
details). The root cause is that this initrd.img contains a broken
/bin/sh binary (being a copy of system /usr/lib/klic/bin/sh binary
rather than /bin/busybox binary).

Now, the workaround for current initramfs-tools 0.99:

1°/ Create a temporary directory that will host initrd.img contents.
Let initrd be that directory
2°/ Copy your current /boot/initrd.img into it
3°/ Extract your current initrd.img by issueing:

     zcat initrd.img | cpio -i

4°/ Overwrite initrd.img's bin/sh with /bin/busybox
5°/ Recreate the cpio archive: to this end, issue the following
command from within the temporary initrd directory:

     find . | cpio --create --format='newc' > ../initrd.img

6°/ Compress the initrd.img:

     gzip initrd.img

7°/ Overwrite your current /boot/initrd.img with the recreated initrd.img.gz one
8°/ Don't forget to rerun elilo -v and check that everything is OK
9°/ Reboot.

Keep in mind when daily updating your system that some post-install
scripts might invoke mkinitramfs or update-initramfs. Don't forget to
redo the above steps or you'll end up once again with an unbootable
system!

Hope this helps,

     Emeric


Le 15 janvier 2012 19:04, Patrick Baggett <baggett.patrick@gmail.com> a écrit :
> Yes, I am. I'll look into that, good thought!
>
> Patrick
>
>
> On Fri, Jan 13, 2012 at 4:13 PM, Émeric Maschino <emeric.maschino@gmail.com>
> wrote:
>>
>> Patrick, are you also running Debian Testing on your SPARC?
>>
>> Would it then be possible for you to check whether /bin/sh in your
>> SPARC initrd.img is a copy of your SPARC filesystem
>> /usr/lib/klibc/bin/sh or /bin/busybox (or something else)?
>>
>>     Émeric
>>
>>
>> Le 13 janvier 2012 22:31, Patrick Baggett <baggett.patrick@gmail.com> a
>> écrit :
>> > It looks like a lot of shell scripty stuff. Not outside of my domain,
>> > but
>> > not my specialty. I can check it out...
>> >
>> >
>> > On Fri, Jan 13, 2012 at 3:30 PM, Émeric Maschino
>> > <emeric.maschino@gmail.com>
>> > wrote:
>> >>
>> >> Well, I've bisected and reported the offending commit.
>> >>
>> >> I've downloaded the source package and recompiled various versions,
>> >> with and without the offending commit but don't understand what's
>> >> going wrong (everything is reported in the bug report if you're
>> >> interested): basically, this commit should simply replace symbolic
>> >> links to files by copies of files in the generated initrd.img, but
>> >> something is broken somewhere. It eventually ends up with an incorrect
>> >> /bin/sh script in initrd.img that is a copy of /usr/lib/klibc/bin/sh
>> >> whereas in working initrd.img, /bin/sh is a copy of /bin/busybox. It's
>> >> all I can say and I didn't get recent advice from the initramfs-tools
>> >> team that would help further debugging.
>> >>
>> >>     Émeric
>> >>
>> >>
>> >> Le 13 janvier 2012 21:19, Patrick Baggett <baggett.patrick@gmail.com> a
>> >> écrit :
>> >> > Indeed it is. It's good to know my hardware works OK.
>> >> >
>> >> > This bug was reported August 2011 and now it's Jan 2012 and still no
>> >> > work
>> >> > around. Is there anything I can do to help? Compile a kernel from
>> >> > git?
>> >> > Test
>> >> > a patch? I'm a fairly competent programmer -- is there any
>> >> > explanation
>> >> > of
>> >> > the issue that just needs some programmer love? I don't have any
>> >> > experience
>> >> > with IA64 assembly, unfortunately, but I can do quite a bit in C.
>> >> >
>> >> > Patrick
>> >> >
>> >> >
>> >> > On Fri, Jan 13, 2012 at 2:12 PM, Émeric Maschino
>> >> > <emeric.maschino@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Patrick,
>> >> >>
>> >> >> And welcome aboard :-)
>> >> >>
>> >> >> Aren't you hitting this issue?
>> >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068
>> >> >>
>> >> >> In this case, the only solution at this time is to downgrade
>> >> >> initramfs-tools from 0.99 to 0.98.8. But you'll have to downgrade
>> >> >> kernel too, as Debian kernels > 2.6.39 require initramfs-tools 0.99.
>> >> >>
>> >> >> Hope this helps,
>> >> >>
>> >> >>     Émeric
>> >> >>
>> >> >>
>> >> >> Le 13 janvier 2012 16:16, Patrick Baggett
>> >> >> <baggett.patrick@gmail.com> a
>> >> >> écrit :
>> >> >> > All,
>> >> >> >
>> >> >> > I just got an HP ZX6000, and I'm very pleased with how quickly
>> >> >> > Debian
>> >> >> > "squeeze" installed on it. I have Debian "testing" running on
>> >> >> > SPARC
>> >> >> > as
>> >> >> > well,
>> >> >> > and I figured I'd go ahead and move the ia64 system to testing.
>> >> >> > When
>> >> >> > I
>> >> >> > did
>> >> >> > however, the system became unbootable. It uncompressed the kernel
>> >> >> > and
>> >> >> > initrd, and then just stopped. I figured I must have done
>> >> >> > something
>> >> >> > dumb, so
>> >> >> > I wiped the disk, redid the installation and made sure I had the
>> >> >> > firmware
>> >> >> > (required for radeon and tigon3 drivers apparently). It still
>> >> >> > failed
>> >> >> > to
>> >> >> > boot
>> >> >> > in the same way. It seems there may be a problem with the
>> >> >> > linux-kernel-3.1.0-mckinley package, because the kernel itself
>> >> >> > doesn't
>> >> >> > even
>> >> >> > output a single message before it dies. Anyone run into a similar
>> >> >> > issue?
>> >> >> > I
>> >> >> > wouldn't mind filing a bug, but I don't know how to get a
>> >> >> > backtrace
>> >> >> > this
>> >> >> > early in the boot process.
>> >> >> >
>> >> >> > Patrick
>> >> >
>> >> >
>> >
>> >
>
>


Reply to: