PINE64
Proper way to use mrfixit update - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: General Discussion on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=112)
+--- Thread: Proper way to use mrfixit update (/showthread.php?tid=11660)

Pages: 1 2


Proper way to use mrfixit update - bastafari - 09-28-2020

I'm not booting from sd card. Tried copying and pasting the updat_sh in terminal after downloading the files but still not working. Am I doing something wrong.
Apparently my uboot is fine. Used etcher on a windows pc to make an sd and worked fine. For some reason dd/of isn't working maybe? Progress in terminal shows like it's doing something, so I'm not sure what the issue is.


RE: Proper way to use mrfixit update - KC9UDX - 09-29-2020

What is the exact command syntax you used?


RE: Proper way to use mrfixit update - bastafari - 09-29-2020

(09-29-2020, 11:09 AM)KC9UDX Wrote: What is the exact command syntax you used?
Code:
xzcat <path to .img.xz file> | sudo dd of=<device path> bs=4M status=progress



RE: Proper way to use mrfixit update - KC9UDX - 09-29-2020

Right, but unless you had either of those parameters wrong, it shouldn't fail.

If this is on the Pinebook, 64k might be faster that 4m. At least that's what I found with the SD cards that I've used so far.


RE: Proper way to use mrfixit update - bastafari - 09-29-2020

(09-29-2020, 12:44 PM)KC9UDX Wrote: Right, but unless you had either of those parameters wrong, it shouldn't fail.

If this is on the Pinebook, 64k might be faster that 4m.  At least that's what I found with the SD cards that I've used so far
Not in front of the machine but I think I used /dev/mmcblk2 for sd card. And I just clicked and dropped the file path in. I can try 64k.


RE: Proper way to use mrfixit update - KC9UDX - 09-29-2020

I presume that would work. But something went wrong somewhere. `dd` is as down-to-Earth as it gets. All it does is blindly copy from one place to the other, block by block. So long as you feed it good parameters and the data stream is correct, it really can't go wrong.

bs=64k should be faster from what I've seen, but shouldn't affect the data success.

What will slow you down is doing the unxz in advance. But I would do that just to simplify it further.


RE: Proper way to use mrfixit update - bastafari - 09-29-2020

So just extract then in terminal I can just do dd? Still learning Linux and terminal so I thought I would be a hot shot and use terminal for everything.


RE: Proper way to use mrfixit update - wdt - 09-29-2020

xzcat should work OK, saves wear and tear on SD (writing extracted image),,
bs speed depends on a lot of things, I would say 64k is minimum for good performance,
somebody did a test and results were hardly determinate
Not surprising, there are about 4 variables
iozone gives a good clue
of= should be to ENTIRE block device, right?,, not to a partition
(and you do have to be root, or sudo both sides of pipe)

and what's the thing about mrfixit_update.sh,, you know that is ONLY for that distro?


RE: Proper way to use mrfixit update - bastafari - 09-29-2020

(09-29-2020, 02:59 PM)wdt Wrote: xzcat should work OK, saves wear and tear on SD (writing extracted image),,
bs speed depends on a lot of things, I would say 64k is minimum for good performance,
somebody did a test and results were hardly determinate
Not surprising, there are about 4 variables
iozone gives a good clue
of= should be to ENTIRE block device, right?,, not to a partition
(and you do have to be root, or sudo both sides of pipe)

and what's the thing about mrfixit_update.sh,, you know that is ONLY for that distro?
No! I guess I missed that somehow.

Oh sudo on both sides. Ok. I'll try again tonight.


RE: Proper way to use mrfixit update - wdt - 09-29-2020

So it doesn't interrupt pipeline to ask password, sudo for xzcat is not neccessary,
but then won't ask password for sudo dd
mrfixit_update.sh not only updates uboot and kernel, also changes extlinux.conf to point to new kernel
For any other distro, this would not work out well