Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pinebook | New image required to fix firstrun update issue #2864

Open
MichaIng opened this issue May 27, 2019 · 8 comments

Comments

Projects
None yet
2 participants
@MichaIng
Copy link
Owner

commented May 27, 2019

Ref: https://dietpi.com/phpbb/viewtopic.php?p=18226#p18226

The fix was patched with v6.20 but the image we offer for download is older and does not yet contain it. Since error appears during APT upgrade, patch cannot be applied.

We can move the fix to pre-patches (we should do this anyway), but a new image would not hurt as well.

@MichaIng MichaIng added this to the v6.25 milestone May 27, 2019

@MichaIng MichaIng added the Via Forum label May 27, 2019

@Fourdee Fourdee self-assigned this May 28, 2019

@Fourdee

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

@MichaIng

Leave the image update with me, will try and do it today.

@MichaIng

This comment has been minimized.

Copy link
Owner Author

commented May 28, 2019

@Fourdee
Many thanks!

Try out https://github.com/MichaIng/DietPi/blob/dietpi-image/.meta/dietpi-image to speed things up. Should be safe, only GPT I am not sure about.

@Fourdee

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

Notes:

  • Unable to change brightness of LCD panel | /sys/class/backlight/backlight/brightness now has no effect.
  • bl_power 0 turns off display, no other value turns it back on
root@DietPi:~# echo 0 > /sys/class/backlight/backlight/bl_power 
root@DietPi:~# echo 1 > /sys/class/backlight/backlight/bl_power

root@DietPi:~# /sys/class/backlight/backlight/
actual_brightness  device/            subsystem/
bl_power           max_brightness     type
brightness         power/             uevent

  • dietpi-boot.service taking 2minutes?

  • Any ARMbian image we read, then resize. Reopening the image under loopback causes a "Cant have a partition outside of the disk" error. Partition is visible in gparted, however not mountable. Regardless the image works.
  • Issue is why are ARMbian images only doing this? Something they have added to prevent users re-imaging, or, their resize script on their 1st run setup is causing this issue?
    Requires testing.
  • Images are MBR, no GPT resize issue?
  • If we run a truncate on the original ARMbian image, this causes the issue:
    image
@Fourdee

This comment has been minimized.

Copy link
Collaborator

commented May 29, 2019

@MichaIng

This comment has been minimized.

Copy link
Owner Author

commented May 29, 2019

@Fourdee
You mean parted resizepart, right? https://github.com/MichaIng/DietPi/pull/2693/files#diff-38702c6380ec8afa2acb3aff1616a6ccR114

Hmm we anyway can't resize the partition to a lower value then the size of the file system with resize2fs. Also gparted simply denies to do so. And since resize2fs does not rearrange content of course, parted resizepart to the size of the file system (resize2fs) should include possible gaps. AFAIK gparted as well does not rearrange content, in terms of closing gaps. It moves partitions around if you choose to do so but does not allow to shrink them any further than what resize2fs had as minimum before. This is why some month ago I had trouble with creating the x86 PC image, since whatever I did, the fs/partition gaps were not closed. Only solution was to move out the whole content, shrink the empty partition to what should be enough and move the content inside again.

Did you run into the issue when running the above script?

@Fourdee

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2019

PB image is currently being redone due to a previous update issue. We aim to have this image available again ASAP.


@MichaIng

dietpi-imager appears to be working now, nice work on the resize loop btw. Script will be a timer saver.

Redone the PB image, however, wont boot back up a second time after FS resize. more debugging to do.

@Fourdee

This comment has been minimized.

Copy link
Collaborator

commented Jun 9, 2019

User reports truncated .7z, fails to extract. Will look into this once we fix the initial image.

For now, updated the URL for PB DL to this ticket.

@MichaIng

This comment has been minimized.

Copy link
Owner Author

commented Jun 9, 2019

@Fourdee

truncated .7z

Since the 7z archive is not truncated of course, does the extraction indeed fail or flashing/booting the interned img file (which is truncated)?

EDIT: Just tested it, indeed it fails to extract or even open in 7zip on Windows. But has nothing to do with the interned file, but the 7z archive itself.

Not sure if compression method could be an issue (LZMA2 ultra), but with current Windows and Debian Stretch available versions it works. Also RAM usage on extraction is not high, just for the compression it is.


About the bootup issue:

  • Does the "partition outside the disk" error still appear on parted? Perhaps this needs to be fixed first?
  • Otherwise what is the issue/error on second boot? If it simply hangs at some stage, the following might be the reason: #2806
    • I am afraid we might need to pre-install haveged on all images, since the long random init causes issues on several edges, sometimes visible to user, sometimes not. I am still investigating/testing this, e.g. depending on attached hardware or not.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.