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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Apr 2010 09:14:26 +1000
From:	Graeme Russ <graeme.russ@...il.com>
To:	Alexander Clouter <alex@...riz.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Request For Help - Embedded x86, Kernel 2.6.33 boots, Mounts 
	JFFS2 rootfs, Stops at init

On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <alex@...riz.org.uk> wrote:
> Graeme Russ <graeme.russ@...il.com> wrote:
>>
>> I've been working for a while now getting the x86 U-Boot port up to speed
>> to boot a linux kernel
>>
> ...ewww x86.

Yeah, nothing like a challange ;)

>
>> [snipped]
>>
>> [    1.911896] Write protecting the kernel read-only data: 596k
>> [    1.915842] kernel_execve(/sbin/init)
>>
>> (I've added a printk in kernel_execve() which gives me the last line)
>>
>> I  initially had hot-plug support compiled into the kernel and was getting
>> a lot of kernel_execve(/sbin/hotplug) messages as well (plus a udev:
>> starting version 151 message which appear 100+ seconds and the above
>> messages), but I have since removed that and used mknod to create
>> /dev/ttyS0 directly
>>
>> I have also tried the following test script:
>>
>> #!/bin/bash
>> stty -F /dev/ttyS0 115200
>> cat hello > /dev/ttyS0
>>
>> but still no luck
>>
>> Does anyone have any advise on how I can debug this problem?
>>
> 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).

But no console...

What if I init with the following:

#!/bin/bash
echo hello > /hello.txt

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?

Regards,

Graeme
--
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/