linux-kernel - Re: Request For Help - Embedded x86, Kernel 2.6.33 boots, Mounts ?JFFS2 rootfs, Stops at init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a0rna7-rem.ln1@chipmunk.wormnet.eu>
Date:	Thu, 29 Apr 2010 09:01:46 +0100
From:	Alexander Clouter <alex@...riz.org.uk>
To:	linux-kernel@...r.kernel.org
Subject: Re: Request For Help - Embedded x86, Kernel 2.6.33 boots, Mounts ?JFFS2 rootfs, Stops at init

Graeme Russ <graeme.russ@...il.com> wrote:
>
> On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <alex@...riz.org.uk> wrote:
>
>> What does you /dev directory look like?  You need to have at least the
>> following:
>> ----
>> mknod console c 5 1
>> mknod null c 1 3
>> mknod ttyS0 c 4 64
>> ----
> 
> tick, tick, tick
> 
> A little further background (should have included this last night but it
> was late and I thought the problem must be trivial)...
> 
> I had originally mounted this root fs using NFS with (very) limited
> success. After mounting and performing a few NFS requests (observed using
> wireshark) the NFS activity would simply stop with 'server not responding'
> messages. I turned on debugging in the 8139too and NFS drivers. With
> debugging output enabled I was still getting 'server not responding'
> messages, but (eventually) the boot sequence would continue. This even
> resulted in logs in /var/log of the NFS share for the device (filled with
> raw network packet data).
>
I got this behaviour when setting up a PXE booting workstation network 
registration system.  My issue was that the IP changed and was running
running TCP based NFS; I think the kernel continues to try to use the 
old IP, same socket, but as it is no longer there...Game Over.   
Depending on how your boot up worked, at the PXE booting phase (or 
just where the kernel uses DHCP to get a lease) things work, however 
then you get to the network configuring part of the boot up, dhclient 
uses a different identifier so you get a different IP.
 
Well...that's what happened to us and the simpliest fix was to move to 
UDP for NFS.

> But no console...
>
...instead of LFS, have you looked at buildroot[1]?

> What if I init with the following:
> 
> #!/bin/bash
> echo hello > /hello.txt
> 
....put a 'while (true); do sleep 1; done' on the end of that.  Although 
you should see a 'attempted to kill init' without it there.

> and then rebooted and checked the root fs in U-Boot? How long will it
> take for hello.txt to be flushed? Can I force the flush?
> 
Have a look at:

http://www.spinics.net/lists/mips/msg37361.html

Especially my 'readelf' bit, I'm guessing you might have forgotten a 
library or two in your keenness to trim your root mountpoint.

Cheers

[1] http://buildroot.uclibc.org/

-- 
Alexander Clouter
.sigmonster says: Time to be aggressive.  Go after a tattooed Virgo.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/