Hi,
I need some instructions on how to expand the CentOS 7 ARM image for
Raspberry PI 2. I followed several instructions including here:
https://raspberrypi.stackexchange.com/questions/499/how-can-i-resize-my-root
-partition
They don't help. I reboot my PI and it goes into a Kernel Panic right after
formatting with fdisk. The /root-partion command also doesn't work with my
64Gb card.
Thanks,
I've heard some say that crosscompiling is a big win
Sent from Nine
________________________________
From: Gordan Bobic <gordan(a)redsleeve.org>
Sent: Dec 23, 2016 10:38 AM
To: Conversations around CentOS on ARM hardware
Subject: Re: [Arm-dev] How to chroot from x86 to arm?
Userspace emulation won't be meaningfully faster. There is no real alternative to getting a faster ARM machine.
On the cheaper end, an decently specced 8 core (4+4) can be had for under $200. Samsung Chromebook 2 is …
[View More]more expensive but I find it more convenient.
On the higher end, a Gigabyte MP30-AR0/AR1 is a monster and it takes standard DDR3 DIMMs, but it is quite expensive. I got one specifically for compiling packages. If you decide to go down that route, if you rebuild the kernel with the more reasonable 4KB page size, you can run a 32-bit chroot or docker container on an aarch64 host (that is the setup I use). I filled mine up with 128GB of RAM, so even bloadware like LibreOffice and web browsers can compile entirely on tmpfs, which helps significantly.
On Fri, Dec 23, 2016 at 6:18 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
>
> On 23 December 2016 at 02:35, mo.ucina <mo.ucina(a)gmail.com> wrote:
> > Hello Guys,
> >
> > I have been doing centos package compiling on arm hardware for a while now ,
> > and it has been going OK . One drawback is that some bigger packages would
> > run for 10hrs to compile . I would like to speed up that process , and
> > compile on a much more powerful machine . I tried cross-compiling but ended
> > up with issues when the arm package got contaminated with i386 libraries no
> > matter what I tired .
> >
> > I also tried qemu VM running on my core2duo 4 core desktop machine . This
> > worked OK as packages were perfect , but it was slower to compile than using
> > arm hardware . Same package that took 10 hrs on arm hw , compiled for 3 and
> > a half days on the desktop .
> >
> > My question is if I used a chroot approach to run the emulation will this be
> > quicker than a qemu VM . If so can anyone please share their instructions on
> > how to configure a chroot to run a centos 7 arm image on a x86 desktop.
>
> I am probably misunderstanding what you are wanting.. but my initial
> thought is that you can't.
>
> The ARM uses a completely different computer architecture to x86_64.
> This means that you can't just chroot into an arm environment because
> the underlying processor (x86_64) isn't changing. It is still going to
> try and interpret machine code 32 to be one thing even if on an ARM
> that meant something completely different. [Also the fact that even if
> machine code 32 was the same the ARM has different number of registers
> and other internals than an x86]
>
> You are running into the same problems we have had with ARM
> development over the last N years. The only solutions are
>
> a) Patience with the slow hardware you have.
> b) Get more hardware but still have patience
> c) Get large scale server hardware and have patience.
>
> The emulation problem you are running into is pretty much standard
> because of the translation of a RISC architecture on a CISC
> architecture. The most off the shelf ARM systems are equivalent to a
> P400 MHZ from the early 2000's in some ways but also faster in others.
> [Trying to use a P400 to compile say texlive is a multi day event
> while on an arm system it might be only 10-20 hours.] You have a
> slightly better emulation result if you have an 64 bit arm 'emulate' a
> 32 bit arm but that is hardware dependent and still requires patience.
>
>
>
> >
> > Best Regards
> >
> > Milorad
> >
> > _______________________________________________
> > Arm-dev mailing list
> > Arm-dev(a)centos.org
> > https://lists.centos.org/mailman/listinfo/arm-dev
>
>
>
> --
> Stephen J Smoogen.
> _______________________________________________
> Arm-dev mailing list
> Arm-dev(a)centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev
[View Less]
So far I have only done this with a Cubieboard2, using the CubieTruck
image. It should work on the CT itself, and other A20 boards that have
a sata connector.
First there is some problem with the 2016.09.01 uboot for booting from
sata. Don't know what it is, but after a brief conversation on the
Fedora-arm list and the uboot list, I tried the uboot in F26 which is
2016.11 and that works. It is really quite simple:
dd your Cubie image onto your HD. Connect the HD to the sata port on
…
[View More]the Cubie.
dd the uboot bin pulled from a Fedora26 image (or some other source for
2016.11) onto a smallish mSD card (I use a 4GB one that costs 1/2 that
of a 16GB card). This card MUST have NO partitions. Just the uboot.
Insert the mSD into the Cubie.
Boot.
You are on your way.
This, of course is very important. To run a production OS on a sata HD,
and not a mSD card, and perhaps even a USB HD. You can use a SSD drive
if you want to spend the money.
Bob
P.S. Next step is to turn this into a simple web server to replace the
current medon.htt-consult.com server that keeps crashing with disk I/O
problems (so much for better reliability with HDs!).
P.P.S. Feel free to add this to the Wiki. :)
[View Less]
I am trying to put the CubieTruck image on a hard drive.
With the Cubies, you put only the uboot on the SD card, and all your
partitions on the sata HD. The system boots up nicely to the HD. No
special fstab needed.
So I picked up a 2.5" HD on ebay and connected it via a USB/sata
adapter. I used the regular dd command:
xzcat CentOS-Userland-7-armv7hl-Minimal-1611-CubieTruck.img.xz | sudo dd
of=/dev/sdb bs=4M; sync
But after quite some time, it is still going. So I checked
/var/log/…
[View More]messages on my notebook where I am doing the copy and see:
Dec 19 12:53:13 lx120e kernel: Buffer I/O error on dev sdb, logical
block 568827, lost async page write
Dec 19 12:58:20 lx120e kernel: buffer_io_error: 15967 callbacks suppressed
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585255, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585256, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585257, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585258, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585259, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585260, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585261, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585262, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585263, lost async page write
Dec 19 12:58:20 lx120e kernel: Buffer I/O error on dev sdb, logical
block 585264, lost async page write
Dec 19 12:59:23 lx120e dnsmasq-dhcp[969]: DHCPREQUEST(virbr0)
192.168.122.138 52:54:00:90:58:e7
Dec 19 12:59:23 lx120e dnsmasq-dhcp[969]: DHCPACK(virbr0)
192.168.122.138 52:54:00:90:58:e7
Is this I/O error a problem with the HD? Or does this HD require some
other blocksize?
thank you
Bob
[View Less]
I am pleased to announce the general availability of CentOS Linux 7
(1611) for armhfp compatible machines.
This is the current release for CentOS Linux
7 and is tagged as 1611, derived from Red Hat Enterprise Linux 7.3
== Download
You can download new images for armhfp boards on
http://mirror.centos.org/altarch/7/isos/armhfp/
Images and sha256sums :
067b147ebdbaf7df04e8338e51de72dea87343992f1c29a03950ecf65a598869
CentOS-Userland-7-armv7hl-Minimal-1611-BananaPi.img.xz
…
[View More]81472c2b8497081b18d53a5cc07815df015eb9efd4303c228713c7b497ed637b
CentOS-Userland-7-armv7hl-Minimal-1611-Cubieboard.img.xz
2ff7fad419a629f96fd9400e0cbaf96632d981de8e7d6f29b4b48999d0c7cfe4
CentOS-Userland-7-armv7hl-Minimal-1611-CubieTruck.img.xz
2237b41107707428c442e40fcea1ee594ab534644df3760d491fdbbfa7535603
CentOS-Userland-7-armv7hl-Minimal-1611-RaspberryPi2.img.xz
deb8ec2e74d4cd084a566434652a95bf33c8e4edcb5d4a1e04435a0b6fce9dfb
CentOS-Userland-7-armv7hl-Minimal-1611-RaspberryPi3.img.xz
== What's new (specific to armhfp)
As before, CentOS 7 userland for armhfp is still built from the CentOS 7
distribution, with some modified, added (or removed) packages.
Here are some highlights for the 7.3.1611 release :
- Kernel (for both rpi2/2 and generic boards) was bumped to 4.4.x (LTS
version) to also follow the i386 AltArch kernel.
- uboot images were updated to version 2016.09
- rootfs-resize (unmaintained) had issue when resizing FS bigger than
32Gb, and has been replaced by cloud-utils-growpart
- default image[s] for rpi2/rpi3 now also support selinux directly
More informations/details on the dedicated wiki page :
https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32
== Getting help
If you are searching for help, or would like to help the CentOS
altarch/armhfp ecosystem, feel free to subscribe to the CentOS arm-dev
list (https://lists.centos.org/mailman/listinfo/arm-dev) or chat with us
in #centos-arm on irc.freenode.net
--
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
[View Less]
First comment is on setting up crony.
Add:
timedatectl set-timezone .....
I use:
timedatectl set-timezone America/Detroit
Otherwise your system time is UTC.
Which 64 bit consumer-size board is the easiest to work with now?
I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate?
https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64
I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed.
I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time …
[View More]on the bootloader and kernel compilation and less time at the application level.
AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market.
Any suggestions?
Many thanks, Nick
[View Less]
> While I can't promise anything yet, we should also have a patchset
> coming that would enable 64bit support for the rpi3 for everything
> except graphics. The upstream graphics driver isn't as stable as I'd
> like so I'm looking at restricting that to console only for now.
+1.
The RIP3 has been a total disappointment for me. Its runs as slowly as
a BeagleBoard, BananaPi or CubieTruck. I continuously run benchmarks
against a HiKey, Pine64, ODROID-C2, RaspberryPi-3, BeagleBoard,
…
[View More]BananaPi and CubieTruck
It also suffers obscure runtime crashes when attempting to compile
with ARMv8 features, like CRC and Crypto.
An Aarch64 image would be very welcomed.
Jeff
[View Less]
hi All,
I'm curious to know what are the best activities for me to pursue if I want to contribute to the next CentOS release?
I.e.: Is there a nightly ISO I can play around with?
best regards,Richard