Errors in Boot Log for Dell M300

@daviddyer,


With your spinning rust HDD, do you see this behavior? i.e. can you boot with and without USB plugged in?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I have installed 2 packages, ntfs-3g before I reported the problem yesterday, installed perhaps 10:00AM, then later in the day I installed file.

Yesterday, I did an update before installing ntfs-3g and another update before installing file as it could not find the package. Then an update/upgrade last evening that resulted in regenerating the uInitrd.

root@m300-2:~# cat /etc/debian_version
10.3

root@m300-2:~# dpkg -l | grep ssl
ii  libssl0.9.8                        0.9.8o-4squeeze7              armel        SSL shared libraries
rc  libssl1.0.0:armel                  1.0.1k-3+deb8u2               armel        Secure Sockets Layer toolkit - shared libraries
rc  libssl1.0.2:armel                  1.0.2l-2                      armel        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:armel                    1.1.1d-0+deb10u2              armel        Secure Sockets Layer toolkit - shared libraries
ii  libzstd1:armel                     1.3.8+dfsg-3                  armel        fast lossless compression algorithm
root@m300-2:~#

Here's a timeline:

Quote

2/15 - A fresh install of the 5.2.9 file system and 5.5.1 kernel. After 2 or 3 clean boots, ran into this on the serial connection: posted 2/16

This was on a second M300 stock 16GB SSD, reformatted with 2 partitions, 4GB labeled sata-rootfs and remainder labeled data.

2/18 - created 1GB swap file on the data partition of the SSD

A few successful boots without serial connected

2/20 - failed boot with serial connected

2/22 - updated initramfs using using update-initramfs -u, and regenerated uInitrd. 

First boot OK but second reported udevadm relocation error

2/26 - booted from SSD OK with USB installed

11:00 AM - installed ntfs-3g and regenerated united, continued boot problems when USB not installed

1:00PM - Installed file after apt-get update

6:00 PM - Did apt-get update, apt-get upgrade and regenerated uInitrd

Edited 2 time(s). Last edit at 02/27/2020 04:09PM by mikeh49.

bodhi Wrote:
-------------------------------------------------------
> JT,
>
> Ah. I understood your problem now. Don't have any
> idea why yet, but I can see that was a strange
> behavior that happens with a new SSD.
>
> Did you install crytodev or anything like that?

I assume you mean cryptodev? No, haven't installed anything like that. Right now it's hung up on trying to install java-headless (unfortunately I need java for something). It's because of problems like this that I haven't done much with the two M300s I have. Meanwhile my Dockstar just keeps humming along! :-)

-JT



Edited 1 time(s). Last edit at 02/27/2020 03:36PM by renojim.

Mike & JT,

Please get this output:

ll /lib/arm-linux-gnueabi/*crypt*
ll /usr/lib/arm-linux-gnueabi/*crypt*

I have a feeling the SSD is a red herring. The problem might be entirely related to the "move to /usr" during Debian upgrade.

Mike's error is saying udevadm was looking for libcrypto.so in /lib

udevadm: symbol lookup error: /lib/arm-linux-gnueabi/libcrypto.so.1.1: undefined symbol: ASN1_UNIVERSALSTRINC_it, version OPENSSL_1_1_0

But my rootfs shows libcrypto.so is in /usr

root@M300:~# ll /usr/lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root 1443064 Feb 29  2016 /usr/lib/arm-linux-gnueabi/libcrypto.so.1.0.0
-rw-r--r-- 1 root root 1530152 Mar 29  2018 /usr/lib/arm-linux-gnueabi/libcrypto.so.1.0.2
-rw-r--r-- 1 root root 2097564 May 30  2019 /usr/lib/arm-linux-gnueabi/libcrypto.so.1.1
lrwxrwxrwx 1 root root      19 May 21  2019 /usr/lib/arm-linux-gnueabi/libhcrypto.so.4 -> libhcrypto.so.4.1.0
-rw-r--r-- 1 root root  183024 May 21  2019 /usr/lib/arm-linux-gnueabi/libhcrypto.so.4.1.0
lrwxrwxrwx 1 root root      18 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3 -> libk5crypto.so.3.1
-rw-r--r-- 1 root root  190320 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3.1

root@M300:~# ll /lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root  34344 May  1  2019 /lib/arm-linux-gnueabi/libcrypt-2.28.so
lrwxrwxrwx 1 root root     23 Aug 26  2019 /lib/arm-linux-gnueabi/libcryptsetup.so.12 -> libcryptsetup.so.12.4.0
-rw-r--r-- 1 root root 316568 Aug 26  2019 /lib/arm-linux-gnueabi/libcryptsetup.so.12.4.0
lrwxrwxrwx 1 root root     22 May  9  2017 /lib/arm-linux-gnueabi/libcryptsetup.so.4 -> libcryptsetup.so.4.7.0
-rw-r--r-- 1 root root 147740 May  9  2017 /lib/arm-linux-gnueabi/libcryptsetup.so.4.7.0
lrwxrwxrwx 1 root root     16 May  1  2019 /lib/arm-linux-gnueabi/libcrypt.so.1 -> libcrypt-2.28.so
lrwxrwxrwx 1 root root     19 Nov 14  2014 /lib/arm-linux-gnueabi/libgcrypt.so.11 -> libgcrypt.so.11.7.0
-rw-r--r-- 1 root root 499084 Nov 14  2014 /lib/arm-linux-gnueabi/libgcrypt.so.11.7.0
lrwxrwxrwx 1 root root     19 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20 -> libgcrypt.so.20.2.4
-rw-r--r-- 1 root root 754232 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20.2.4

Try reinstall OpenSSL to see if it will correct this problem. You might also need to reinstall linux-headers-5.5.1-kirkwood-tld-1_1.0_armel.deb

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/27/2020 06:14PM by bodhi.

As requested:

root@m300-2:~# ll /lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root  34344 May  1  2019 /lib/arm-linux-gnueabi/libcrypt-2.28.so
lrwxrwxrwx 1 root root     16 May  1  2019 /lib/arm-linux-gnueabi/libcrypt.so.1 -> libcrypt-2.28.so
lrwxrwxrwx 1 root root     19 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20 -> libgcrypt.so.20.2.4
-rw-r--r-- 1 root root 754232 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20.2.4
root@m300-2:~# ll /usr/lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root 2097564 Oct 12 12:56 /usr/lib/arm-linux-gnueabi/libcrypto.so.1.1
lrwxrwxrwx 1 root root      18 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3 -> libk5crypto.so.3.1
-rw-r--r-- 1 root root  190320 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3.1
root@m300-2:~#

To reinstall OpenSSL use apt-get install?

I believe I installed the headers on this box as part of the 5.5.1 kernel upgrade:

root@m300-2:~# dpkg -l | grep linux-header
ii  linux-headers-5.5.1-kirkwood-tld-1 1.0                           armel        Linux kernel headers for 5.5.1-kirkwood-tld-1 on armel
root@m300-2:~#

Any significance to this?



Edited 2 time(s). Last edit at 02/27/2020 07:06PM by mikeh49.

MIke,

Strange, yours listing looks OK. So I don't know why udevadm looked for the cypto so in /lib! that is the wrong place in wheezy too.

Now I don't know if reinstall OpenSSL will help. But I think you should do it anyway.

I'm going to boot my M300 back to the internal SSD only to see if it has any info.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Re-installed Open SSL, here's the two directories:

root@m300-2:~# ll /lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root  34344 May  1  2019 /lib/arm-linux-gnueabi/libcrypt-2.28.so
lrwxrwxrwx 1 root root     16 May  1  2019 /lib/arm-linux-gnueabi/libcrypt.so.1 -> libcrypt-2.28.so
lrwxrwxrwx 1 root root     19 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20 -> libgcrypt.so.20.2.4
-rw-r--r-- 1 root root 754232 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20.2.4
root@m300-2:~# ll /usr/lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root 2097564 Oct 12 12:56 /usr/lib/arm-linux-gnueabi/libcrypto.so.1.1
lrwxrwxrwx 1 root root      18 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3 -> libk5crypto.so.3.1
-rw-r--r-- 1 root root  190320 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3.1

No change evident, but maybe the install made some changes or links somewhere.

You have a lot more files in these directories than I do.



Edited 2 time(s). Last edit at 02/28/2020 08:38AM by mikeh49.

> You have a lot more files in these directories
> than I de.

That because I reused my Kirkwood rootfs that I had for a long time. But that should not matter.

I think the big hint is "why udevadm looks in /lib/arm-linux-gnueabi/ for libcrypto.so.1.1 ?".

I've just boot my M300 to the internal SDD rootfs and did not see any thing strange.

I guess I need to find the Debian discussion about "moving to /usr" to see if any thing was related to this.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Mike,

Please install OpenSSL.

apt-get install openssl --install-recommends

Reboot.

And then

dpkg -l | grep ssl

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/27/2020 09:05PM by bodhi.

As requested:

root@m300-2:~# apt-get install openssl --install-recommends
Reading package lists... Done
Building dependency tree       
Reading state information... Done
openssl is already the newest version (1.1.1d-0+deb10u2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@m300-2:~# dpkg -l | grep ssl
ii  libssl0.9.8                        0.9.8o-4squeeze7              armel        SSL shared libraries
rc  libssl1.0.0:armel                  1.0.1k-3+deb8u2               armel        Secure Sockets Layer toolkit - shared libraries
rc  libssl1.0.2:armel                  1.0.2l-2                      armel        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:armel                    1.1.1d-0+deb10u2              armel        Secure Sockets Layer toolkit - shared libraries
ii  libzstd1:armel                     1.3.8+dfsg-3                  armel        fast lossless compression algorithm
ii  openssl                            1.1.1d-0+deb10u2              armel        Secure Sockets Layer toolkit - cryptographic utility

FWIW, I unpacked uInitrd and found the libcrypto.so.1.1 file in both the /lib and /usr/lib paths.

When in the boot process is control transferred from the initramfs (uInitrd) to root fs on the USB or HDD?

ii  libssl0.9.8                        0.9.8o-4squeeze7              armel        SSL shared libraries

That does not look right. In case it got confuse and use this old squeeze library, we should remove it. Not sure how it got into your rootfs?

Backup your rootfs, just in case. And boot back into Debian,

dpkg --purge libssl0.9.8
sync

Remake the uInitrd, sync, and reboot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/28/2020 05:51PM by bodhi.

Before I do anything drastic, I checked my other M300 and a Pogo E02 both running the 5.2.9 filesystem and they both have the 0.9.8 Squeeze package. Mean anything?

Mike,

> Before I do anything drastic, I checked my other
> M300 and a Pogo E02 both running the 5.2.9
> filesystem and they both have the 0.9.8 Squeeze
> package. Mean anything?

Wow. Then that must be from the time I created this rootfs with debootstrap! Removing it is actually not drastic at all. The libraries can be installed but only the latest version is being used. I am only cautious to not mess up your rootfs, I've removed mine.


Note, if the shared library is in the rootfs, it should be the latest (not a squeeze version).

ii  libssl0.9.8                           0.9.8o-7                         armel        SSL shared libraries

Let me take a look at the release rootfs to see if it was still there.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks Mike,

It has been in the rootfs since day one :) I need to add instruction to remove it.

I can see why. Squeeze distribution is no longer exist, so currently apt-get upgrade wont do anything to this old package.

(chroot into the Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2)

root@tldDebian:/# dpkg -l | grep ssl

ii  libssl0.9.8                      0.9.8o-4squeeze7              armel        SSL shared libraries
rc  libssl1.0.0:armel                1.0.1k-3+deb8u2               armel        Secure Sockets Layer toolkit - shared libraries
rc  libssl1.0.2:armel                1.0.2l-2                      armel        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:armel                  1.1.1c-1                      armel        Secure Sockets Layer toolkit - shared libraries
ii  libzstd1:armel                   1.3.8+dfsg-3                  armel        fast lossless compression algorithm

Let's see if your removal and reboot will make any difference.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

OK, no joy. Removed the 0.9.8 ssl library with dpkg --purge, checked with dpkg -l and it was gone. Rebuilt uInitrd, synced, halted, removed USB, and booted:

Loading, please wait...
Starting version 241
Begin: Loading essential drivers ... done.
Comment: long pause here, perhaps 10-15 seconds
Begin: Running /scripts/init-pre
[   19.797399][    T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[   19.806345][    T1] CPU: 0 PID: 1 Comm: init Not tainted 5.5.1-kirkwood-tld-1 #1.0
[   19.813943][    T1] Hardware name: Marvell Kirkwood (Flattened Device Tree)
[   19.820953][    T1] [<8010f668>] (unwind_backtrace) from [<8010b9f4>] (show_stack+0x10/0x14)
[   19.829429][    T1] [<8010b9f4>] (show_stack) from [<80119e8c>] (panic+0xfc/0x328)
[   19.837032][    T1] [<80119e8c>] (panic) from [<8011bc4c>] (do_exit+0x1b4/0xa24)
[   19.844461][    T1] [<8011bc4c>] (do_exit) from [<8011d280>] (do_group_exit+0x54/0xe0)
[   19.852415][    T1] [<8011d280>] (do_group_exit) from [<80128c68>] (get_signal+0x27c/0x7e8)
[   19.860802][    T1] [<80128c68>] (get_signal) from [<8010b23c>] (do_work_pending+0xf0/0x418)
[   19.869278][    T1] [<8010b23c>] (do_work_pending) from [<80101068>] (slow_work_pending+0xc/0x20)
[   19.878186][    T1] Exception stack(0xeecb5fb0 to 0xeecb5ff8)
[   19.883950][    T1] 5fa0:                                     00763180 00763180 0000006c 00000000
[   19.892855][    T1] 5fc0: 0075a330 00000000 007593d4 76fda968 00000000 00000000 00000000 0075938c
[   19.901766][    T1] 5fe0: 005c7f24 7ec9f7c8 0046b530 00429714 00000010 ffffffff
[   19.909115][    T1] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
mount ... done.
Begin: Mounting root file system ...

I tried a boot earlier today and got the same messages.



Edited 1 time(s). Last edit at 03/03/2020 06:36PM by mikeh49.

This is discouraging :)

It is a different error, has nothing to do with the so library loading.

Please boot back with non-rootfs USB drive plug in. Hopefully, that seems to be working for you before?

I think I have to plug in a new SSD to see and troubleshoot it on my box. I have a 1TB Samsung SSD waiting to be used on a different computer.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I don't know if it's still needed but here's my output:

root@kaceM300-1:~# ll /lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root  34344 May  1  2019 /lib/arm-linux-gnueabi/libcrypt-2.28.so
lrwxrwxrwx 1 root root     16 Sep 17 23:52 /lib/arm-linux-gnueabi/libcrypt.so.1 -> libcrypt-2.28.so
lrwxrwxrwx 1 root root     19 Sep 17 23:52 /lib/arm-linux-gnueabi/libgcrypt.so.20 -> libgcrypt.so.20.2.4
-rw-r--r-- 1 root root 754232 Jan 20  2019 /lib/arm-linux-gnueabi/libgcrypt.so.20.2.4
root@kaceM300-1:~# ll /usr/lib/arm-linux-gnueabi/*crypt*
-rw-r--r-- 1 root root 2097564 Oct 12 12:56 /usr/lib/arm-linux-gnueabi/libcrypto.so.1.1
lrwxrwxrwx 1 root root      18 Sep 17 23:49 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3 -> libk5crypto.so.3.1
-rw-r--r-- 1 root root  190320 Jun 18  2019 /usr/lib/arm-linux-gnueabi/libk5crypto.so.3.1
lrwxrwxrwx 1 root root      22 May 23  2019 /usr/lib/arm-linux-gnueabi/libssh-gcrypt.so.4 -> libssh-gcrypt.so.4.7.4
-rw-r--r-- 1 root root  455156 May 23  2019 /usr/lib/arm-linux-gnueabi/libssh-gcrypt.so.4.7.4

Looks very similar to Mike's.

I'm thinking there is a timing issue with the scripts in the initramfs. The USB inserts a delay while it is "processed" that perhaps allows the SSD to "catch up". I wonder if there is a "feature" of this 16GB stock SSD that is a factor. Perhaps they did something in the stock initramfs scripts to accommodate this. My other M300 with a modern 120GB SSD has been reliable.

I unpacked the uInitrd and poked around in the /scripts directory and found /scripts/local had a number of time related aspects associated with local filesystem mounting. I don't fully understand how these scripts actually work as I could not find /scripts/init-premount where the problem seems to occur. I don't know if it is worth investigating this as having a USB plugged in is a good enough work-around. If someone has the stock system (I don't) perhaps the scripts could be compared.

@Mike,

> My other M300 with a
> modern 120GB SSD has been reliable.

That's good to hear! that means a lot. If the problem is only with this SSD (if you are booting the same rootfs on both), and not with a newer SSD, then it is not systemic.

> I unpacked the uInitrd and poked around in the
> /scripts directory and found /scripts/local had a
> number of time related aspects associated with
> local filesystem mounting. I don't fully
> understand how these scripts actually work as I
> could not find /scripts/init-premount where the
> problem seems to occur. I don't know if it is
> worth investigating this as having a USB plugged
> in is a good enough work-around. If someone has
> the stock system (I don't) perhaps the scripts
> could be compared.

Unfortunately, I don't think they are comparable. Stock is old and have different sets of Debian init scripts populated. We might find some customed quirks in there that confirm your theory about timing, though.

@JT,

So I think, when you have time, should try booting with a non-rootfs USB and SSD rootfs to see if you can run it that way, like Mike does. If you can repeat that, then we might be on to something here.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

I wonder if there is a "feature" of this 16GB stock SSD that is a factor. Perhaps they did something in the stock initramfs scripts to accommodate this.

I don't think so. I'm booting with stock internal SSD,

root@M300sata:~# myinfo 
M300sata
192.168.0.249  
Dell KACE M300
Linux version 5.5.1-kirkwood-tld-1 (root@tldDebian) (gcc version 8.3.0 (Debian 8.3.0-6)) #1.0 PREEMPT Sat Feb 1 22:28:36 PST 2020
Debian 10.3
console=ttyS0,115200 root=LABEL=sata_rootfs rootdelay=10 mtdparts=spi0.0:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) earlyprintk=serial
uboot_version=U-Boot 1.1.4 (Jun 20 2011 - 13:16:26) Marvell version: 3.4.27 -stock
--- System Stats:
/dev/sda: TS16GSSD25H-M:  no sensor
SMART check: PASSED
Fri 28 Feb 2020 09:59:48 PM PST up 2 hours, 42 minutes

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/29/2020 12:01AM by bodhi.

Thanks for the help, maybe a miracle will happen and it will just work sometime in the future, ATM, I plan to use this a quick and dirty linux box, so using a USB to assist booting is not a problem.

I have 2 16GB SSDs from 2 M300s. Both of them have trouble booting on this second box, M300-2. I think the first one also had problems booting on the first M300.

BTW, what's the best way to get the u-boot version?

With traditional HD, I did see similar behavior, but not very often.
With the 16GB SSD, it happens often on one M300, but NOT on the other M300. I posted the ENVs of these two boxes in the other thread, but I did not do further research

Since the system is still usable, I did not bother with it.

> BTW, what's the best way to get the u-boot
> version?

You can grep /dev/mtd0 for "U-Boot". But I just set the env u-boot and print it out as part of the alias myinfo.

fw_setenv uboot_version 'U-Boot 1.1.4 (Jun 20 2011 - 13:16:26) Marvell version: 3.4.27 -stock'

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

daviddyer,

> With traditional HD, I did see similar behavior,
> but not very often.
> With the 16GB SSD, it happens often on one M300,

And this 16GB SSD has the Debian rootfs installed on it? or is it running stock?

> but NOT on the other M300. I posted the ENVs of
> these two boxes in the other thread, but I did not
> do further research
>
> Since the system is still usable, I did not bother
> with it.

Thanks for the info. So that's another datapoint. I think it is a systemic problem after all if you've seen this error with the HDD!

The behavior does not seem like SATA power related either! OTOH, it is very suspicious that a plugged in USB drive helping the issue (it is 5V).

In any case, I've removed my USB rootfs and run this box with the 16GB internal SSD rootfs permanently, hope I will see this problem at some point.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

This will make it happen easier:
1 reboot
2 heavy disk I/O

I've rebooted 10 times and ls -R / each time. Still not seeing any error.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Please post your /etc/fstab content.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Mine:

root@m300-2:~# myinfo
m300-2
192.168.1.135
Dell KACE M300
Linux version 5.5.1-kirkwood-tld-1 (root@tldDebian) (gcc version 8.3.0 (Debian 8.3.0-6)) #1.0 PREEMPT Sat Feb 1 22:28:36 PST 2020
root@m300-2:~#

root@m300-2:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
LABEL=sata_rootfs    /               ext3    noatime,errors=remount-ro 0 1
LABEL=data	/mnt/data		ext3	defaults,noatime  0	2
/mnt/data/swapfile1     swap            swap    defaults          0       0
tmpfs          /tmp            tmpfs   defaults          0       0

@Mike,

Thanks!

@David & JT,

If you could, run your system (one with errors) with a non-rootfs USB plugged in at boot, to see if you see the same behavior (i.e. no error) that Mike's box has.

=======

I'm trying different configurations to see if I can find some hints.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)