View previous topic :: View next topic |
Author |
Message |
fosco n00b
Joined: 06 Jan 2017 Posts: 3
|
Posted: Sun Jan 08, 2017 7:24 pm Post subject: |
|
|
Hi all!
Just wondering...
what do you figure would happen adopting Quote: | ACCEPT_KEYWORDS="amd64" | in /etc/portage/make.conf.
Having CHOST and CFLAGS set for aarch64 and cortex, that could simply involve portage selection pattern, isn't it? |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Sun Jan 08, 2017 7:44 pm Post subject: |
|
|
I think I will settle for much simpler version of package.accept_keywords:
Code: | */* *
# required by media-video/ffmpeg-2.8.6::gentoo[fdk]
# required by ffmpeg (argument)
=media-libs/fdk-aac-0.1.4-r1 **
dev-php/pecl-redis **
dev-php/pecl-imagick **
=sys-devel/gcc-6.3.0 **
=sys-devel/binutils-2.27 **
|
*/* * will select the highest stable ebuild from any arch (i.e. the stable from amd64), the result is basically amd64 stable, since it's probably themost uptodate.
apparently I needed to autounmask just a few ebuild ... (gentoo improved a lot apparently)
emerge -e world
Considering it will downgrade a considerable number of stuff I think there will be problems ....
not: I will never be convinced there's an added value in waiting for someone to add a keyword to an ebuild without touching anthing else, if something breaks I will mask it. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54584 Location: 56N 3W
|
Posted: Sun Jan 08, 2017 7:48 pm Post subject: |
|
|
fosco,
Welcome to Gentoo.
You are correct.
The ACCEPT_KEYWORDS setting only affects the 'visibility' of packages considered by portage for use in dependency calculations.
In your example, all the stable packages on amd64 would be considered. That does not mean they would build or work if they did build.
You just would not know that they were not tested.
You could also (try to) emerge packages that are known to not work. This is especially true of binary packages.
nvida-drivers, icedtea-bin, firefox-bin, libreoffice-bin, virtualbox ... You would get amd64 code.
We might well hear the crash when you try to run that :)
icedtea, firefox and libreoffice all build and work on arm64. It the case of firefox, the version you get with ACCEPT_KEYWORDS=amd64 will build but not run.
I would suggest that the short term gains are outweighed by the more subtle issues you are going to have.
It will also cause confusion when you get asked to post your
~arm64 keywords are developing. Join in the fun. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Sun Jan 08, 2017 11:00 pm Post subject: |
|
|
erm67 wrote: |
emerge -e world
Considering it will downgrade a considerable number of stuff I think there will be problems ....
|
I rather choose for upgrading considerable number of stuff which may also have problems ....
Code: | ACCEPT_KEYWORDS="* ~*"
| but so far no major issues. |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Mon Jan 09, 2017 1:25 am Post subject: |
|
|
NeddySeagoon wrote: | [...]
~arm64 keywords are developing. Join in the fun. |
Agreed
But : /usr/portage/profiles/arch/arm64/use.mask is also on the conservative side...
I have allowed or hard unmasked several use lines and ... no so far no major issues |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Mon Jan 09, 2017 2:32 am Post subject: |
|
|
By the way:
It seems even with -j3 make flag (I have 4 cores and want to keep one available), some gentoo builds keep 6 cores going, and, no need to tell: temp rising ...
OK say, upto around 60 degC, perhaps OK since another box lives on 80 degC.
But eventually box may give up and crash on high temp.
Ideally I guess I should buy a switch and a 7 or 15 or 31 boxes farm to compile distcc and cc-cached together
|
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Jan 09, 2017 8:25 am Post subject: |
|
|
mDup wrote: | erm67 wrote: |
emerge -e world
Considering it will downgrade a considerable number of stuff I think there will be problems ....
|
I rather choose for upgrading considerable number of stuff which may also have problems ....
Code: | ACCEPT_KEYWORDS="* ~*"
| but so far no major issues. |
Yeah, I understand now that ACCEPT_KEYWORDS="*" is what I was looking for, like NeddySeagoon said there isn't a lot of stuff in ~amd64 and it is developing, i.e. new ebuilds can be pushed also for minor changes, triggering tedious rebuilds. I prefer to go stable i.e. ACCEPT_KEYWORDS="*" and eventually unmask things I need, like 2 php modules. In theory this should be the way a distro works, masked = non-working being developed, ~* working ebuild being tested and further developed, * stable=the real distro. Unfortunately there was a time when the only choice was between severely outdated stable ebuilds and frequently updated ~ARCH.
Are we sure that ACCEPT_KEYWORDS="*" is the same as using '*/* *' in package.accept_keywords? I am still emergin' thank to the perl clusterfuck
I didn't remember the * keyword, but it should be default, you know aarch64 or arm64 is not really uncharted territory, there is Ubuntu 16/4, archlinux, fedora25, users will notice that recent versions of all packages are available in every distro apart gentoo and think gentoo developers are lazy fucks, smarter users will verify how packages are built on those distro, realize that they are (99.9%) just recompiled on the arch without changes and get even more convinced that gentoo has become a backward distro.
archlinuxarm just enabled the arm keyword on every PKGBUILD wih customizepkg, they didn't even bother to actually add the keyword to the packages in the git, too much useless work, and it is very likely the best arm distro. Probably because they did not waste most of the development time needlessly whitelisting perfectly good PKGBUILDS ...
IMHO there should be only a * (stable) ~* (developing) and special needs ebuild be masked or marked using arch names like arm64......
Code: | # Raúl Porcel <armin76@gentoo.org>
# I've been told xfs is broken on ARM
xfs
|
fedora arm uses xfs as the default fs for the root partition (without sppecial patches I bet), it is very hard to explain to a random user how the gentoo developers determined instead that xfs should be hard masked, someone did told him in a dream?
I bet most of the hard masked stuff should be unmasked ASAP and moved to testing in ~*... once upon a time devs of other distro looked for gentoo but now the opposite should be done, if x.y.z works on other arm distro it should be hard-unmasked without particular testing.
I checked also the neon thing, the cpu definitely supports advanced simd(NEON) but use neon instructions to do math instead of the fpu (-mfpu=neon) is slower with 64bit arm instructions so -mfpu=neon is not available for 64 bit arm, -ftree-vectorize should take advantage of the asimd instructions, but ... well tree-vectorize ..... _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net
Last edited by erm67 on Mon Jan 09, 2017 10:56 am; edited 1 time in total |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Jan 09, 2017 10:50 am Post subject: |
|
|
mDup wrote: | By the way:
It seems even with -j3 make flag (I have 4 cores and want to keep one available), some gentoo builds keep 6 cores going, and, no need to tell: temp rising ...
OK say, upto around 60 degC, perhaps OK since another box lives on 80 degC.
But eventually box may give up and crash on high temp.
Ideally I guess I should buy a switch and a 7 or 15 or 31 boxes farm to compile distcc and cc-cached together
|
Don't know what box are you using, but most chinese box use a piece of steel as dissipator, open the box, some guys in other forum just opened the box, replaced the "dissipator" with a real dissipator, and cut the plastic case leaving the dissipator outside, and solved any overheating problem.
I have no overheating problems, but many china-boxes do. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Mon Jan 09, 2017 2:21 pm Post subject: |
|
|
erm67 wrote: |
Don't know what box are you using, but most chinese box use a piece of steel as dissipator, open the box, some guys in other forum just opened the box, replaced the "dissipator" with a real dissipator, and cut the plastic case leaving the dissipator outside, and solved any overheating problem.
I have no overheating problems, but many china-boxes do. |
I am using a minimx-g. It does not overheat with -j3 since there is always one variable core free. Temperature then is between 45 and 50 degC. When I first started building, I used -j4 or -j5 and such would put all 4 cores on 100% cpu and would somewhat overstress the box.
The offending ebuild is qtwebengine which, for some reason, even with -j1, gets 6 cc1plus processes running simultaneously during 3rdparty/chromium build. That puts all 4 cores on 100% cpu and temperature rises to 60 degC.
@erm67 : what box are you using and what makeflag do you use and what temperature does your box have during emerge? |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Jan 09, 2017 9:17 pm Post subject: |
|
|
I also have a beelink but the mini-mxII, the only hw component non working in linux is the temp sensor so I have no idea about the temperature but even after heavy emerge the case is only lukewarm at touch ...
I bought an S905 because I had read some complaints about S905X not being stable with linux.
I was using this flags CFLAGS="-O2 -pipe -march=armv8-a+crc+fp+simd -mabi=lp64 -mcpu=cortex-a53+crc+fp+simd" (only crc is required since fp and simd are on by default) cat /proc/cpuinfo will tell you the extensions supported by the cpu, autodetection was broken on gcc <6 and extensions not automatically enabled.
GCC6 supports the native target and I use this now:
CFLAGS="-O2 -pipe -march=native -mabi=lp64 -mcpu=native" I tested several binaries and the two strings produce the same binaries on my arch.
LibreElec uses -ftree-vectorize for kodi and ffmpeg that should produce very fast code using the asimd extension, considering that I used a lot libreelec without problems I guess that tree-vectorize should be ok at least for some apps. tree-vectorize system-wide is usually not a great idea. graphite is masked on gentoo arm64 (probably the voices again since I read android uses it) it should give a bit more performance together with -flto and use ld.gold as a linker. Consider that some ebuild will strip out cflags 'for your safety'.
The next hurdle for me is to get java, which is again masked despite working perfectly in all other aarch64 distro. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Tue Jan 10, 2017 12:54 am Post subject: |
|
|
erm67 wrote: | I also have a beelink but the mini-mxII, the only hw component non working in linux is the temp sensor so I have no idea about the temperature but even after heavy emerge the case is only lukewarm at touch ... [...]
The next hurdle for me is to get java, which is again masked despite working perfectly in all other aarch64 distro. |
mini-mxII and minimx-g might be different (but very similar) here is my Android build fingerprint
Code: | # grep ro.build.fingerprint build.prop
ro.build.fingerprint=Android/p200_2G/p200_2G:5.1.1/LMY47V/20160420:user/test-keys |
The temperature I read from /sys :
Code: | # cat /sys/devices/virtual/thermal/thermal_zone0/temp
46000
|
I may want to try build icedtea java replacement. Some heavy ebuilds failed so far or took forever (thunderbird, firefox, libreofffice, qtwebkit, ...)
I did build some other apps such as : balsa, gnumeric, abiword, rhythmbox, imagemagick, gimp an others. I try webkit-gtk now.
Next I can try to do icedtea. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22705
|
Posted: Tue Jan 10, 2017 2:43 am Post subject: |
|
|
Portage will (usually) pass your preferred --jobs=N line to the underlying build system. Whether that build system respects it is an open question. I recall seeing one build system mentioned recently (ninja, I think) that ignored the user's choice and spawned however many jobs it thought the system ought to be able to handle. Personally, I would file a bug on packages that blow past user job settings like that.
On the other hand, I think that you ought to improve the cooling to the point that the box is stable with all cores spinning at 100%. For current personal sized systems (i.e. with cores <= 16), this should be an achievable goal.
You could also try using kernel settings to prohibit Portage jobs from using the system at full capacity, such as by restricting it to run the jobs only on a subset of available CPUs. This would reduce heat usage and work in the presence of ill-behaved build systems. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Tue Jan 10, 2017 7:55 am Post subject: |
|
|
His CPU is a Cortex-A57 it is a BIG/little architecture that has 4 fast power hungry core and 4 slower energy efficient cores, it uses heterogeneous SMP, in theory the slower cores are started first and when they reach 80% the faster cores are started by the scheduler. I am not sure that the 8 cores are really used all at the same time at the physical level even if it appears so, since according to the benchmarks it is not twice as fast as a 4 cores. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Tue Jan 10, 2017 10:12 am Post subject: |
|
|
mDup wrote: | erm67 wrote: | I also have a beelink but the mini-mxII, the only hw component non working in linux is the temp sensor so I have no idea about the temperature but even after heavy emerge the case is only lukewarm at touch ... [...]
The next hurdle for me is to get java, which is again masked despite working perfectly in all other aarch64 distro. |
mini-mxII and minimx-g might be different (but very similar) here is my Android build fingerprint
Code: | # grep ro.build.fingerprint build.prop
ro.build.fingerprint=Android/p200_2G/p200_2G:5.1.1/LMY47V/20160420:user/test-keys |
The temperature I read from /sys :
Code: | # cat /sys/devices/virtual/thermal/thermal_zone0/temp
46000
|
I may want to try build icedtea java replacement. Some heavy ebuilds failed so far or took forever (thunderbird, firefox, libreofffice, qtwebkit, ...)
I did build some other apps such as : balsa, gnumeric, abiword, rhythmbox, imagemagick, gimp an others. I try webkit-gtk now.
Next I can try to do icedtea. |
The biggest difference is that you have a A-57 core while I have an A-53 .......
I use it only as a headless server for the moment, but you'll need opengl and (probably) wayland drivers for mali, that are not available as ebuild for gentoo, plus libamcodec from codesnake https://github.com/codesnake for hw accelerated codecs.
This should also help:
https://source.tizen.org/mali-ddk-wayland?langredirect=1
I've read that opengl and hw decoding only work well fullscreen with the mali driver. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54584 Location: 56N 3W
|
Posted: Tue Jan 10, 2017 10:42 am Post subject: |
|
|
mDup,
Quote: | I may want to try build icedtea java replacement. Some heavy ebuilds failed so far or took forever (thunderbird, firefox, libreofffice, qtwebkit, ...)
I did build some other apps such as : balsa, gnumeric, abiword, rhythmbox, imagemagick, gimp an others. I try webkit-gtk now.
Next I can try to do icedtea. |
thunderbird, firefox, libreofffice, qtwebkit All build and work except thunderbird, which segfaults on launch.
You need to jump through a few hoops to get icedtea
libreofffice with USE=java looks good with iced tea too.
I can update my BINHOST if there is any interest. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Tue Jan 10, 2017 1:57 pm Post subject: |
|
|
NeddySeagoon wrote: | mDup,
Quote: | I may want to try build icedtea java replacement. Some heavy ebuilds failed so far or took forever (thunderbird, firefox, libreofffice, qtwebkit, ...)
I did build some other apps such as : balsa, gnumeric, abiword, rhythmbox, imagemagick, gimp an others. I try webkit-gtk now.
Next I can try to do icedtea. |
thunderbird, firefox, libreofffice, qtwebkit All build and work except thunderbird, which segfaults on launch.
You need to jump through a few hoops to get icedtea
libreofffice with USE=java looks good with iced tea too.
I can update my BINHOST if there is any interest. |
Just curious : on which HW do you build ? - native or cross build, or perhaps a combination?
When I built qtwebkit all my 2GB memory was used and already 2GB of my 4GB swapspace, it kept going ... but forever.
Last edited by mDup on Tue Jan 10, 2017 2:12 pm; edited 2 times in total |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Tue Jan 10, 2017 2:08 pm Post subject: |
|
|
erm67 wrote: | [...]
I use it only as a headless server for the moment, but you'll need opengl and (probably) wayland drivers for mali, that are not available as ebuild for gentoo, plus libamcodec from codesnake https://github.com/codesnake for hw accelerated codecs.
This should also help:
https://source.tizen.org/mali-ddk-wayland?langredirect=1
I've read that opengl and hw decoding only work well fullscreen with the mali driver. |
Thanks for pointers!
For now I use fbdev Xorg without acceleration. It is just fine for me as most applications I use and need for now are rather textual.
I will use the device as +/- portable workstation mainly to log into various (mostly also gentoo based) servers HTPCs PBXs routers switches modems etc...
One thing I do want to check now is if all hardware works (audio, bluetooth, wifi, ...) and adjust accordingly
The video performance aspects are not most important to me but if someone finds howto then sure will take advantage. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54584 Location: 56N 3W
|
Posted: Tue Jan 10, 2017 2:45 pm Post subject: |
|
|
mDup,
Its all native builds on Raspberry Pi 3 in 64 bit mode. I have found distcc to be more bother than its worth. Fixing that is on my todo list though.
The Pi 3 has 1G RAM and a 4G swap. Swap was 2G and I didn't have any build failures for running out of swap but I did see it go down to 10 Mb free, which is too close.
SD card write performance is really poor, so I build on a USB HDD.
Code: | # genlop -t qtwebkit
!!! Error: no merge found for 'qtwebkit' | so I don't have it yet. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Tue Jan 10, 2017 3:31 pm Post subject: |
|
|
mDup wrote: |
One thing I do want to check now is if all hardware works (audio, bluetooth, wifi, ...) and adjust accordingly
The video performance aspects are not most important to me but if someone finds howto then sure will take advantage. |
Is this your wifi BT chip?
Quote: | The AP6330 chip is made by AMPAK. It supports 802.11a/b/g/n (no 11ac), BT 4.0, and FM. It has a Broadcom BCM40183 BT module and a Broadcom BCM4330 Wifi module. The wifi maximum speed is 65 or 72 or 72.2Mbps according to different sources. |
For audio do you plan to use hdmi or the spdif (if present)? _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Tue Jan 10, 2017 3:53 pm Post subject: |
|
|
erm67 wrote: | mDup wrote: |
One thing I do want to check now is if all hardware works (audio, bluetooth, wifi, ...) and adjust accordingly
The video performance aspects are not most important to me but if someone finds howto then sure will take advantage. |
Is this your wifi BT chip?
Quote: | The AP6330 chip is made by AMPAK. It supports 802.11a/b/g/n (no 11ac), BT 4.0, and FM. It has a Broadcom BCM40183 BT module and a Broadcom BCM4330 Wifi module. The wifi maximum speed is 65 or 72 or 72.2Mbps according to different sources. |
For audio do you plan to use hdmi or the spdif (if present)? |
I don't know all the components well but all is working in kszaq LE so there must sure be ways to build kernel support, kszaq does use separate driver repository iirc. Perhaps balbes150 also already supports everything, my kernel build is a bit old. Yes, also spdif (optical). |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Tue Jan 10, 2017 4:10 pm Post subject: |
|
|
NeddySeagoon wrote: | [...]
SD card write performance is really poor, so I build on a USB HDD.
|
You mean a USB SSD or classical HD?
I would think SD card write performance is OK. I have Samsung cards 32GB 90/90 MBs r/w. But perhaps USB HDD is faster? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54584 Location: 56N 3W
|
Posted: Tue Jan 10, 2017 4:24 pm Post subject: |
|
|
mDup,
Its a 'rotating rust' USB HDD. On the Pi I get 30Mb/sec.
The PI microSD is only 25MB/sec read.
Write speeds vary wildly from card to card, as low as < 2Mb/sec for sustained writes on an XC-I card.
They start out well then drop off. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Tue Jan 10, 2017 6:15 pm Post subject: |
|
|
The internal eMMC of the box (with TRIM support, so speed wont drop with time) is small (16GB) but not bad:
Code: | localhost / # hdparm -t /dev/system
/dev/system:
Timing buffered disk reads: 336 MB in 3.01 seconds = 111.72 MB/sec
|
@mDup, are you using the internal SSD I hope .....
Some bluetooth-wifi chip also need userspace tools, you should find out what components are in your box since, very often, china-boxes with the same name have different components inside. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
mDup Apprentice
Joined: 14 Apr 2006 Posts: 212
|
Posted: Tue Jan 10, 2017 7:36 pm Post subject: |
|
|
erm67 wrote: | The internal eMMC of the box (with TRIM support, so speed wont drop with time) is small (16GB) but not bad:
Code: | localhost / # hdparm -t /dev/system
/dev/system:
Timing buffered disk reads: 336 MB in 3.01 seconds = 111.72 MB/sec
|
@mDup, are you using the internal SSD I hope .....
Some bluetooth-wifi chip also need userspace tools, you should find out what components are in your box since, very often, china-boxes with the same name have different components inside. |
thanks for help!
... no I boot and run various OS from various external SDs
Code: | minimx-g ~ # hdparm -t /dev/mmcblk0p2
/dev/mmcblk0p2:
Timing buffered disk reads: 84 MB in 3.08 seconds = 27.26 MB/sec
|
note 27.26 is much less than advertised 90
I do not feel very confident on how to put gentoo on the internal ssd. Afraid to brick.
The (14) original android partitions are still there. But I hardly use Android (on this machine).
Anyone can provide some recipe to transfer to internal? |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Tue Jan 10, 2017 8:41 pm Post subject: |
|
|
/dev/mmcblk0p2 s probably your sd card, it doesn't support TRIM and the write speed will very soon drop to ~0 ......
There are varius ways to use the internal memory, the less risky way that also preserves your android environment is to boot balbes (or kszaq) kernel from sd and use /dev/data as root partition you can use another android partition (like /dev/cache or /dev/system) for swap but don't forget to go to android recovery and format cache&user data&system again before using android.
The root device is probably set in your uboot environment, altering uboot variables probably involves a very slight risk of bricking, it is safer do it on a serial console; a quick and dirty way is decompress the init image, extract it and modify the init bash script to boot from the /dev/data partition, recreate and compress the init image put it on the sd card and boot. Move the gentoo system to /dev/data first, that should be easy for you. This way you'll be using the sd only for booting.
The extreme solution is convert the binary dtb to dts (decompile), edit it to create the partitions you want, and recompile it.
What sounds less complicated and risky to you?
There is another way of course boot from the sd and than switch root to /dev/data, it is good to prepare the gentoo system. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|