On 03/16/2014 11:24 AM, Oliver Grawert wrote: > hi, Am Sonntag, den 16.03.2014, 11:03 -0400 schrieb David Marceau: >> On 03/16/2014 09:42 AM, David Marceau wrote: >>> On 03/16/2014 08:09 AM, Oliver Grawert wrote: > >> QUESTION: What's the best block size for ubuntu phone bs=1MiB, >> but that seems a bit high. > the same that is used by the system-image-upgrader script in > recovery mode ... I must say it was well hidden because I looked under the phablet-flash stuff and couldn't find it there. https://github.com/ycheng/miscscripts/blob/master/utouch_dev/bringup/system-image-upgrader#L145 https://github.com/ycheng/miscscripts/blob/master/utouch_dev/bringup/system-image-upgrader#L272 These indicate 4096 Byte block size. I understand that flashboot has some parameters to tell the sizes for each partition. Are we using flashboot anywhere in the process? Could we plug it in there?
> >> >> I tried: /sbin/dumpe2fs / | grep 'Block size' > >> But I got an error. dumpe2fs 1.42.9 (4-Feb-2014) /sbin/dumpe2fs: >> Attempt to read block from filesystem resulted in short read >> while trying to open / > > you *have* to do it in recovery mode, else there are plenty of > mountpoints on top of the loop device that you can not easily > unmount... (and without re-initializing the bigger loop device the > kernel wont notice the bigger partition size) > >>> sudo losetup -c /dev/loop0 sudo resize2fs /dev/loop0 > > none of these tools will be available in recovery mode (you would > have to port them to bionic first to even make them available) WARNING RANT: I feel like I don't have the control over this stuff. Why is it there are still dependencies on bionic(ANDROID stuff)? BACK TO REALITY: Understood. I won't continue on the resize loop0 path. > > seriously (on your PC): > > sudo apt-get install qemu-user-static sudo qemu-debootstrap --arch > armhf trusty my-devel-chroot sudo chroot my-devel-chroot (do > whatever you want to do wrt development) > > is the better approach ... > > ciao oli Ok, thanks for the qemu tips and your patience, I'll try it this afternoon and let you know. I tried these non-qemu cross-compile tricks, but it didn't work because of other complications: git clone git://github.com/davecheney/golang-crosscompile.git source golang-crosscompile/crosscompile.bash go-crosscompile-build linux/arm go-linux-arm get gopkg.in/v0/qml can't build package gopkg.in/v0/qml because it contains C++ files (all.cpp) but it's not using cgo nor SWIG CXX=/var/lib/schroot/chroots/click-ubuntu-sdk-13.10-armhf/usr/bin/arm-linux-gnueabihf-g++ go-linux-arm get gopkg.in/v0/qml can't build package gopkg.in/v0/qml because it contains C++ files (all.cpp) but it's not using cgo nor SWIG go-linux-arm build . can't build package gopkg.in/v0/qml because it contains C++ files (all.cpp) but it's not using cgo nor SWIG GOARM=5 go-linux-arm build . can't build package gopkg.in/v0/qml because it contains C++ files (all.cpp) but it's not using cgo nor SWIG -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
