bug#37471: Cannot make a disk image for the BeagleBone Black

[Timothy Sample]

Hi,

Ludovic Courtès <address@hidden> writes:

> Hi Timothy,
>
> Timothy Sample <address@hidden> skribis:
>
>> [   34.338311] SCSI subsystem initialized
>> [   34.478195] Unhandled fault: page domain fault (0x01b) at 0x00000000
>> [   34.483251] pgd = (ptrval)
>> [   34.485473] [00000000] *pgd=4e48c835, *pte=00000000, *ppte=00000000
>> [   34.493074] Internal error: : 1b [#1] SMP ARM
>
> Is this error the actual problem?
>
>> [   34.497643] Modules linked in: libata(+) scsi_mod
>> [   34.506434] CPU: 1 PID: 1 Comm: init Not tainted 5.2.15-gnu #1
>> [   34.511049] Hardware name: Generic DT based system
>> [   34.523922] PC is at ata_attach_transport+0xd4/0x1fc [libata]
>> [   34.530415] LR is at 0xce4430bc
>> [   34.533789] pc : [<bf05a00c>]    lr : [<ce4430bc>]    psr: 60000013
>> [   34.537248] sp : ce105cd0  ip : bf061dac  fp : ce105cf4
>> [   34.539050] r10: 00000000  r9 : bf061ddc  r8 : bf061dbc
>> [   34.540417] r7 : bf061dcc  r6 : ce4430cc  r5 : ce4430dc  r4 : ce443000
>> [   34.544194] r3 : 00000000  r2 : bf0596a8  r1 : 00000124  r0 : bf0661d4
>> [ 34.547445] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
>> none
>> [   34.549935] Control: 10c5387d  Table: 4e00406a  DAC: 00000051
>> [   34.552425] Process init (pid: 1, stack limit = 0x(ptrval))
>> [   34.555936] Stack: (0xce105cd0 to 0xce106000)
>> [ 34.559887] 5cc0: 00000000 00000000 bf06c100 bf06bf00
>> [ 34.564103] 5ce0: bf076000 ffffffff ce105d84 ce105cf8 bf074c3c
>> bf059f44 d0821000 ce104000
>> [ 34.568192] 5d00: bf063734 bf063700 bf06c100 bf063780 c0f05dcc
>> 60000013 ffffffff bf075000
>
> … or is it that shepherd could not be spawned for some reason?

I assumed so.  Is this the output you would expect if the unhandled
fault stuff was just a warning which was followed by Shepherd failing?

Is it the “init Not tainted” part that makes it look like Shepherd is
having problems?

> Could it be that our kernel config for ARMv7 is wrong somehow?

I was guessing that it was a problem with the modules (either that we
are missing something in the kernel config or we are not including
something in the initrd).  However, I guess it could also be a change in
how we invoke QEMU.  I haven’t had a chance to dive into it yet, I was
hoping that someone “out there” might know something!  :)


-- Tim