Intermittent Boot Issues

[lot378]

Were any error checks omitted in the excerpt above? The dd commands send stdout and stderr to null nothing to read.

Doing that without checking for errors or testing to verify may be a bad action.

[MrRoosevelt]

Were any error checks omitted in the excerpt above? The dd commands send stdout and stderr to null nothing to read.

Doing that without checking for errors or testing to verify may be a bad action.

The script I am looking at does a file check to make sure the image files exist. That is pretty much it...

Code:

echo "Updating U-Boot..."
SYSPART=$(findmnt -n -o SOURCE /)
if echo $SYSPART | grep -qE 'p[0-9]$' ; then
DEVID=$(echo $SYSPART | sed -e s+'p[0-9]$'+''+)
else
DEVID=$(echo $SYSPART | sed -e s+'[0-9]$'++)
fi
echo Identified $DEVID as device to flash uboot to...
if [ -f $DIR/idbloader.img ] ; then
echo "Upgrading idbloader.img..."
dd if=$DIR/idbloader.img of=$DEVID bs=32k seek=1 conv=fsync &>/dev/null
fi
if [ -f $DIR/uboot.img ] ; then
echo "Upgrading uboot.img..."
dd if=$DIR/uboot.img of=$DEVID bs=64k seek=128 conv=fsync &>/dev/null
fi
if [ -f $DIR/trust.img ] ; then
echo "Upgrading trust.img..."
dd if=$DIR/trust.img of=$DEVID bs=64k seek=192 conv=fsync &>/dev/null
fi

I wanted to sanity check before I ran it; so, echoed the dd commands instead.

The wiki identifies the eMMC as mmcblk1 (see: https://wiki.pine64.org/index.php/Pinebo...le_Storage). It enumerates as mmcblk2 on my PBP. All the partitions match up otherwise.

[charlespine]

I  get denied when cloning or downloading the mrfixit repo.

[EDIT]: Nevermind, that was user error...

I'm trying to make sure that I write the images to the correct device. It looks like the script wants to do this (omitting long file path):

Code:

dd if=...updates_repo/pinebook/filesystem/idbloader.img of=/dev/mmcblk2 bs=32k seek=1 conv=fsync &>/dev/null
dd if=...updates_repo/pinebook/filesystem/uboot.img of=/dev/mmcblk2 bs=64k seek=128 conv=fsync &>/dev/null
dd if=...updates_repo/pinebook/filesystem/trust.img of=/dev/mmcblk2 bs=64k seek=192 conv=fsync &>/dev/null

It looks sane to me; but, I'm still looking for documentation on the wiki to confirm (I don't want to overwrite the wrong device).

Use lsblk to confirm your devices and then use sudo in front of dd if you're not root.

[khanku]

I  get denied when cloning or downloading the mrfixit repo.

[EDIT]: Nevermind, that was user error...

I'm trying to make sure that I write the images to the correct device. It looks like the script wants to do this (omitting long file path):

Code:

dd if=...updates_repo/pinebook/filesystem/idbloader.img of=/dev/mmcblk2 bs=32k seek=1 conv=fsync &>/dev/null
dd if=...updates_repo/pinebook/filesystem/uboot.img of=/dev/mmcblk2 bs=64k seek=128 conv=fsync &>/dev/null
dd if=...updates_repo/pinebook/filesystem/trust.img of=/dev/mmcblk2 bs=64k seek=192 conv=fsync &>/dev/null

It looks sane to me; but, I'm still looking for documentation on the wiki to confirm (I don't want to overwrite the wrong device).

Use lsblk to confirm your devices and then use sudo in front of dd if you're not root.

You'll want to remove "&> /dev/null" at the end too in order to see any potential error. I.e.:

Code:

lsblk # look for mount point or size to make sure mmcblk2 is the eMMC

sudo dd if=idbloader.img of=/dev/mmcblk2 bs=32k seek=1 conv=fsync
sudo dd if=uboot.img of=/dev/mmcblk2 bs=64k seek=128 conv=fsync
sudo dd if=trust.img  of=/dev/mmcblk2 bs=64k seek=192 conv=fsync

[yurievitch]

I too have had serious Manjaro boot problems. Miy PBP was from an earlier batch, so I had loaded Manjaro myself. Seemed to work a bit. Then it would not. Initially I could do the Control-Alt-Delete and then it would boot.

But in the end, I think I have to try something different. Since it appears to be a U-Boot issue, I'll give @khanku fix a try.

After a few days it seems to be settling down, but as I bought this for my granddaughter for school and play, Manjaro doesn't support for some of what she needs.
I've tried a Bionic live USB, but it doesn't supersede booting from the internal drive. Is there a key combination that lets me change the boot order?

[MrRoosevelt]

I  get denied when cloning or downloading the mrfixit repo.

[EDIT]: Nevermind, that was user error...

I'm trying to make sure that I write the images to the correct device. It looks like the script wants to do this (omitting long file path):

Code:

dd if=...updates_repo/pinebook/filesystem/idbloader.img of=/dev/mmcblk2 bs=32k seek=1 conv=fsync &>/dev/null
dd if=...updates_repo/pinebook/filesystem/uboot.img of=/dev/mmcblk2 bs=64k seek=128 conv=fsync &>/dev/null
dd if=...updates_repo/pinebook/filesystem/trust.img of=/dev/mmcblk2 bs=64k seek=192 conv=fsync &>/dev/null

It looks sane to me; but, I'm still looking for documentation on the wiki to confirm (I don't want to overwrite the wrong device).

Use lsblk to confirm your devices and then use sudo in front of dd if you're not root.

You'll want to remove "&> /dev/null" at the end too in order to see any potential error. I.e.:

Code:

lsblk # look for mount point or size to make sure mmcblk2 is the eMMC

sudo dd if=idbloader.img of=/dev/mmcblk2 bs=32k seek=1 conv=fsync
[size=small][font=Monaco, Consolas, Courier, monospace]sudo dd if=uboot.img of=/dev/mmcblk2 bs=64k seek=128 conv=fsync[/font][/size]
sudo dd if=trust.img  of=/dev/mmcblk2 bs=64k seek=192 conv=fsync

I too have had serious Manjaro boot problems. Miy PBP was from an earlier batch, so I had loaded Manjaro myself. Seemed to work a bit. Then it would not. Initially I could do the Control-Alt-Delete and then it would boot.

But in the end, I think I have to try something different. Since it appears to be a U-Boot issue, I'll give @khanku fix a try.

After a few days it seems to be settling down, but as I bought this for my granddaughter for school and play, Manjaro doesn't support for some of what she needs.
I've tried a Bionic live USB, but it doesn't supersede booting from the internal drive. Is there a key combination that lets me change the boot order?

Sorry to appear apprehensive; this is my first trip outside of x86 land in a very long time. I usually can get away from using dd as it is not a tool I take lightly.

But, I successfully flashed uboot and I was able to boot 4 or 5 times in a row with no issues. I noticed that the power LED behaves differently now. Its not a bug, I mention it because I find it interesting.

Thanks for everyone's input. I'm excited to play around with this for a bit.

[boggle]

Is the mrfixit uboot still working? There's a lot of edits throughout this thread, could you re-explain what the final solution was? I have the exact same problem and it's driving me nuts. About to throw this thing in the trash.

[Arwen]

@boggle
Since installing the default Debian's U-Boot, my Pinebook Pro has been pretty stable. Out of 30 or so boots, only time it had issues was when I tried to get hibernation to work.

How I did it, won't help anyone else. I had good backups, including the individual U-Boot files.

Can someone else help @boggle out?

[KiteX3]

I haven't had the opportunity to install the new U-boot, since (as I understand) I'll need an external keyboard for that and I haven't one on-hand at the moment. However, I have found that the device usually boots up just fine if I hold the power button for longer, usually a second or three after the power indicator actually lights up.

It makes me wonder if the issue isn't the boot-up so much as how the Pinebook Pro's default U-boot handles the machine's indicator lights. I encountered similar problems with the indicator lights while attempting to disengage the Wifi privacy switch, and the solution to that problem (holding the keyboard combo for a full three seconds rather than just until the indicator lights up) was what prompted me to try holding the power button for longer while booting it up.

If anyone else is still dealing with the default U-boot, I'd be interested to see if this works around the problem for you too.

[khanku]

I haven't had the opportunity to install the new U-boot, since (as I understand) I'll need an external keyboard for that and I haven't one on-hand at the moment. However, I have found that the device usually boots up just fine if I hold the power button for longer, usually  a second or three after the power indicator actually lights up.

I think you might be confusing keyboard/track firmware and u-boot. There is no need for an external keyboard to dd a different u-boot to a SD or eMMC.


Having now gotten a serial cable I can now see how Manjaro's u-boot often leads to the initramfs failing to find the root device and thus getting stuck. While no obvious error is shown the manjaro build does not show debug messages like mrfixit2001's does so I can only guess some race condition leads to the eMMC not being available when the kernel boots.