paul75 Posted July 24, 2016 Posted July 24, 2016 Hello I want to do a special sdcard to my use of multiple card without reconfigure all the time. If I install into a 4gb sdcard after can I write a iso and copy to another sdcard and write to 128gb and when can I resize it into the new card? Thanks
shahidali55 Posted July 25, 2016 Posted July 25, 2016 Please try the instructions in below post: http://forum.armbian.com/index.php/topic/146-moving-to-a-larger-sd-card/#entry750
tkaiser Posted July 25, 2016 Posted July 25, 2016 I want to do a special sdcard to my use of multiple card without reconfigure all the time. If I install into a 4gb sdcard after can I write a iso and copy to another sdcard and write to 128gb and when can I resize it into the new card? The best way is to learn how to use our build system and the customize image functionality. Then you touch /root/.no_rootfs_resize at image creation time to prevent automatic partition resize on first boot, can then customize the image like you want (preferred method as outlined in our docs, manually fiddling around in an already created image seems to be more easy but is not!) and deploy it later: http://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script Then you only need a trick in your image to detect when the image runs on another host (since you provide zero information about the hardware you want to use no way to help you) and then executes the do_expand_rootfs function from our /etc/init.d/firstrun script (see link below). sudo resize2fs /dev/mmcblk0p1 Won't work since you need partitions to be resized too: https://github.com/igorpecovnik/lib/blob/master/scripts/firstrun#L129-L236 (a little bit more than just calling resize2fs )
shahidali55 Posted July 25, 2016 Posted July 25, 2016 Wow, "do_expand_rootfs()" is a lot of work . . . Won't work since you need partitions to be resized too: https://github.com/igorpecovnik/lib/blob/master/scripts/firstrun#L129-L236 (a little bit more than just calling resize2fs )
Tido Posted July 31, 2016 Posted July 31, 2016 http://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script expand it to the card’s maximum capacity at boot time I fully understand the resizing at first boot /reboot time and it makes sense to almost all users, but .. at every boot time this leaves out people like me who accept above, call afterwards the partition manager, resize it to 2,5GB (because backup process time, and space used is less). In the begin resizing was at first boot time - great. No repeating resizing on every boot. This text is from the docs: You can prevent the partition expansion from within customize-image.sh by a touch /root/.no_rootfs_resize or configure the resize operation by either a percentage or a sector count So I understand, with the current coding there is only one way to prevent this resizing by making your own image. last -x shutdown lists all shutdowns, if there is more than three, no more resizing would be nice to have in the standard image. I don't understand the sense of checking and resizing every time at boot. And if someone wants to move its system from one to another SDcard - there are ways to do this adjustment manually.
zador.blood.stained Posted July 31, 2016 Posted July 31, 2016 I fully understand the resizing at first boot /reboot time and it makes sense to almost all users, but .. at every boot time this leaves out people like me who accept above, call afterwards the partition manager, resize it to 2,5GB (because backup process time, and space used is less). In the begin resizing was at first boot time - great. No repeating resizing on every boot. Resize attempt is made only at first boot assuming there are no errors such as read-only root file system.
Tido Posted July 31, 2016 Posted July 31, 2016 I resized the SDcard with my PCs KDE Linux's partition mgr.Put it back in and bootet:The SSH is no more valid - I have re-accept the SSH-Key.root@lamobo-r1:~# df -hFilesystem Size Used Avail Use% Mounted on/dev/mmcblk0p1 2.2G 1.1G 1.1G 51% /root@lamobo-r1:~# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABELNAME FSTYPE SIZE MOUNTPOINT LABELsda 698.7G|-sda1 ext4 21G linuxfs|-sda2 ext4 21G /media/second_boot bana`-sda3 ext4 258G /media/daten_c Datenmmcblk0 14.9G`-mmcblk0p1 ext4 2.2G /root@lamobo-r1:/# ls -la total 80drwxr-xr-x 22 root root 4096 Jul 30 21:06 .drwxr-xr-x 22 root root 4096 Jul 30 21:06 ..drwxr-xr-x 2 root root 4096 Apr 18 22:19 bindrwxr-xr-x 3 root root 4096 Jul 30 21:06 bootdrwxr-xr-x 14 root root 3920 Jul 30 21:06 devdrwxr-xr-x 86 root root 4096 Jul 30 21:06 etcdrwxr-xr-x 3 root root 4096 May 10 20:27 homedrwxr-xr-x 18 root root 4096 Apr 29 04:55 libdrwx------ 2 root root 16384 Apr 29 04:58 lost+founddrwxr-xr-x 5 root root 4096 May 30 21:52 mediadrwxr-xr-x 2 root root 4096 Apr 18 22:13 mntdrwxr-xr-x 2 root root 4096 Apr 18 22:13 optdr-xr-xr-x 97 root root 0 Jan 1 1970 procdrwx------ 3 root root 4096 Jun 18 00:19 rootdrwxr-xr-x 17 root root 600 Jul 31 13:04 rundrwxr-xr-x 2 root root 4096 Jun 21 20:26 sbindrwxr-xr-x 2 root root 4096 Apr 29 04:53 selinuxdrwxr-xr-x 2 root root 4096 Apr 18 22:13 srvdr-xr-xr-x 12 root root 0 Jan 1 1970 sysdrwxrwxrwt 7 root root 180 Jul 30 21:06 tmpdrwxr-xr-x 10 root root 4096 Apr 18 22:13 usrdrwxr-xr-x 11 root root 4096 May 10 19:49 var now I do an init 6The SSH is no more valid - I have re-accept the key.And boom it is big again 15 GBroot@lamobo-r1:~# df -hFilesystem Size Used Avail Use% Mounted on/dev/mmcblk0p1 15G 1.1G 14G 8% /root@lamobo-r1:/# ls -la total 80drwxr-xr-x 22 root root 4096 Jul 31 13:07 .drwxr-xr-x 22 root root 4096 Jul 31 13:07 ..drwxr-xr-x 2 root root 4096 Apr 18 22:19 bindrwxr-xr-x 3 root root 4096 Jul 31 13:07 bootdrwxr-xr-x 14 root root 3920 Jul 31 13:07 devdrwxr-xr-x 86 root root 4096 Jul 31 13:07 etcdrwxr-xr-x 3 root root 4096 May 10 20:27 homedrwxr-xr-x 18 root root 4096 Apr 29 04:55 libdrwx------ 2 root root 16384 Apr 29 04:58 lost+founddrwxr-xr-x 5 root root 4096 May 30 21:52 mediadrwxr-xr-x 2 root root 4096 Apr 18 22:13 mntdrwxr-xr-x 2 root root 4096 Apr 18 22:13 optdr-xr-xr-x 97 root root 0 Jan 1 1970 procdrwx------ 3 root root 4096 Jun 18 00:19 rootdrwxr-xr-x 17 root root 580 Jul 31 13:09 rundrwxr-xr-x 2 root root 4096 Jun 21 20:26 sbindrwxr-xr-x 2 root root 4096 Apr 29 04:53 selinuxdrwxr-xr-x 2 root root 4096 Apr 18 22:13 srvdr-xr-xr-x 12 root root 0 Jan 1 1970 sysdrwxrwxrwt 7 root root 180 Jul 31 13:07 tmpdrwxr-xr-x 10 root root 4096 Apr 18 22:13 usrdrwxr-xr-x 11 root root 4096 May 10 19:49 var no errors such as read-only root file system. Is there an easy method to prevent this error. Will I have to run an fsck before rebooting ? Edit: Armbian_5.10_Lamobo-r1_Debian_jessie_3.4.112.raw
zador.blood.stained Posted July 31, 2016 Posted July 31, 2016 First you'll have to find what caused this error. /etc/init.d/firstrun should run only at first boot and then disable itself, so "disable itself" part is obviously failing for some reason. In case your distribution is Jessie or Xenial, you may try to get some logs: systemctl status -l firstrun > log.txt journalctl -b -u firstrun >> log.txt journalctl -b >> log.txt mount >> log.txt dmesg >> log.txt and upload this log somewhere
Tido Posted July 31, 2016 Posted July 31, 2016 systemctl status -l firstrun > log.txt journalctl -b -u firstrun >> log.txt journalctl -b >> log.txt mount >> log.txt dmesg >> log.txt I hope I didn't mix it up, should be exactly in the order like above http://pastebin.com/0abvhuKm http://pastebin.com/dTf9u1QU http://pastebin.com/PiFCbyiU http://pastebin.com/TLVFJGhq http://pastebin.com/CbiDnuqV
zador.blood.stained Posted July 31, 2016 Posted July 31, 2016 This looks like an old Armbian version Edit: Armbian_5.10_Lamobo-r1_Debian_jessie_3.4.112.raw Exactly. This issue with firstrun script was fixed a long time ago. Please try more recent version (5.14 is available and it can be upgraded to 5.16) 1
Tido Posted August 1, 2016 Posted August 1, 2016 It looks like that wit BPi R1 and armbian 5.10 I got the worst case :-) What I am still curious - if you found it to be faulty, why was it not fixed in 5.10 ? Is this like freezed and problems fixed in the next version and if so, I do understand this behavior for programs, but not really for an OS. What I mean, if Ubuntu 14.04 has a bug in the screensaver, it will be fixed for 14.04 and not with 16.04. I have now installed armbian 5.14 and dist-upgrade and will now test if my problems with hostapd and resizing of SDcard are solved.
tkaiser Posted August 1, 2016 Posted August 1, 2016 What I am still curious - if you found it to be faulty, why was it not fixed in 5.10 ? OMG. Do you know what version numbers are for? Do you know what updates are for? Did you ever had a look at the output of dpkg -l | egrep "armbian| linux-" cat /etc/armbian-release Please do me a favor and the next time you don't understand something please ask instead of flooding the forums with silly assumptions others might stumble across and draw wrong conclusions. Next time this whole useless thread could look like: Q: "Why does my SD card gets resized on every boot?" A: "Most probably you forgot to update your installation, do an apt-get upgrade and you're done" We had a bug in 5.10, we fixed it pretty fast and you get the fix by updating your Armbian installation. It's still the usual 'apt-get upgrade' and then the specific package containing the fix is not on 5.10 any more -- see the two commands above. Armbian's version number is not a release like Ubuntu's 14.04/16.04 but an internal version number all Armbian packages use (otherwise 'apt-get upgrade' wouldn't work since Debian's package manager only updates packages with increased version numbers!). So with your Lamobo it will look like root@lamobor1:~# dpkg -l | egrep "armbian| linux-" ii armbian-firmware 5.14 all Linux firmware ii armbian-hostapd-xenial 5.14 armhf Patched hostapd for xenial ii armbian-tools-xenial 5.14 armhf Armbian tools, sunxi, temper ii linux-base 4.0ubuntu1 all Linux image base package ii linux-dtb-next-sunxi 5.16 armhf Linux DTB, version 4.6.3-sunxi ii linux-headers-next-sunxi 5.16 armhf Linux kernel headers for 4.6.3-sunxi on armhf ii linux-image-next-sunxi 5.16 armhf Linux kernel, version 4.6.3-sunxi ii linux-libc-dev:armhf 4.4.0-31.50 armhf Linux Kernel Headers for development ii linux-u-boot-lamobor1-next 5.16 armhf Uboot loader 2016.05 ii linux-xenial-root-next-lamobor1 5.16 armhf Armbian tweaks for xenial on lamobor1 (next branch) Most packages already at 5.16 and a few remaining on the last version when Igor let all packages be updated.
Tido Posted August 5, 2016 Posted August 5, 2016 One more time, you don't understand why I am looking into this - you just do your assumption. The reason, that people love Debian so much on the server is stability - not features. If I allow updates through # deb http://apt.armbian.comjessie main it can by updating, remove certain function by accident. i.e. the hostapd for R1 does not work in 5.10 and 5.14 - it does work in 5.17 and in 4.2 I wanted to build my latest manual on 5.10, but hostapd wouldn't work. Uncomment apt.armbian.com would probably update components that reliably work and might no longer work after the update = not option. Debian updates do not evolve, just fix. This is indeed a huge difference. /usr/share/doc/linux-headers-3.13.0-24/debian.README.gz for details /usr/share/doc/linux-headers-3.13.0-27/debian.README.gz for details /usr/share/doc/linux-headers-3.13.0-29/debian.README.gz for details So you can stay with the same 'version' and only fix a bug like 5.14.01 the next generation is something like 5.16
zador.blood.stained Posted August 5, 2016 Posted August 5, 2016 One more time, you don't understand why I am looking into this - you just do your assumption. The reason, that people love Debian so much on the server is stability - not features. If I allow updates through # deb http://apt.armbian.comjessie main it can by updating, remove certain function by accident. i.e. the hostapd for R1 does not work in 5.10 and 5.14 - it does work in 5.17 and in 4.2 Comparing Debian and Armbian is not a good idea: Each Debian package has maintainer(s) assigned to them There are different releases - stable, testing and unstable (currently it's Jessie, Stretch and sid). Moreover, stable release has different repository components branches for updates (i.e jessie-updates), and for security updates, both of which can be disabled. Updates go from sid to testing and from testing to stable after testing and verification that they work good enough. Armbian is a much smaller scale project, we can't afford almost all of this. I wanted to build my latest manual on 5.10, but hostapd wouldn't work. Uncomment apt.armbian.com would probably update components that reliably work and might no longer work after the update = not option. Debian updates do not evolve, just fix. "Probably" is a good word. Are you happy with installed version of armbian-hostapd (I don't mean current version, I mean any version that you manually installed and that works OK for you)? Or maybe standard Debian hostapd works better? apt-mark hold armbian-hostapd and this package will not be updated or removed unless you remove the mark.
Tido Posted August 6, 2016 Posted August 6, 2016 Armbian is a much smaller scale project, we can't afford almost all of this. This was no critics, I just tried to explain why I asked all those question and why it makes sense to me but maybe not to others. Are you happy with installed version of armbian-hostapd (I don't mean current version, I mean any version that you manually installed and that works OK for you)? Or maybe standard Debian hostapd works better? apt-mark hold armbian-hostapd and this package will not be updated or removed unless you remove the mark. As I wrote above, I was happy with the hostapd from Armbian_4.2_Lamobo-r1_Debian_wheezy_3.4.108.img. Since July 2015 there was no need for manually work as your hostapd worked better than anything before. Your suggestion with apt-mark will be an option when you distribute hostapd 5.17, but currently it doesn't work with R1. In conclusion - I do now understand the principle. I still ask myself - if there are developers or any other Project who would like to have a 'stable' release (only bug fixes) if this is feasable with your manpower ? is there a need ? is a company willing to pay for this ? i.e. digital signage - the Beelink X2 is a bargain - in compare the NEC Display computer cost € 900.- / the Intel NUC € 400.- but both run with a stable (Windows, CentOS) system and in a company environment this is what you want. There are many many digital signage provider - and they also fight with pricing and all-in-one systems. Just some thoughts how to offer a business model around your work.
zador.blood.stained Posted August 6, 2016 Posted August 6, 2016 As I wrote above, I was happy with the hostapd from Armbian_4.2_Lamobo-r1_Debian_wheezy_3.4.108.img. Since July 2015 there was no need for manually work as your hostapd worked better than anything before. Your suggestion with apt-mark will be an option when you distribute hostapd 5.17, but currently it doesn't work with R1. This is kind of offtopic here - but are you sure you have problem with hostapd and not, for example, with kernel drivers for your wireless device? You can try removing armbian-hostapd (with its config file) and install "official" Debian hostapd, there aren't that many differences in armbian-hostapd apart from newer version and regulatory/40MHz related patch (if we are talking about non-Realtek specific hostapd version). If there are issues/errors, having some logs and details would be nice.
Tido Posted August 7, 2016 Posted August 7, 2016 Good guess as this WLAN-Module RTL8192CU (driver rtl871xdrv) has everything else than a good reputation. I just read here: https://wireless.wiki.kernel.org/en/users/drivers/rtl819x rtl8192cu is a USB driver for RTL8192CU/RTL8188CU devices. It's going to be replaced by rtl8xxxu. Lamobo R1 v5.10 Problem with SDcard as mentioned above (is fixed) armbian-hostapd wouldn't run - Igor has sent me an armbian-hostapd-jessie_5.17_armhf.deb this solves the problem Lamobo R1 v5.14 armbian-hostapd wouldn't run - I haven't tested the .deb on this version yet, but I guess Igor has.
DrTune Posted August 11, 2016 Posted August 11, 2016 FYI for anyone else wanting to avoid having Armbian use all your SD card when it first boots... a) download armbian and write image to SD. Don't boot with it yet! plug SD card into a running linux system as external drive (e.g. via a USB-SD adapter) - I just used a previous Armbian image on my Banana Pi - and mount it, c) cd to the card's root directory d) echo 50% >root/.rootfs_resize <<Where 50% is the amount of the actual SD card you want to utilize e) sync and remove card. f) Boot it e.g. I used a 4GB card and set it to resize to 65% and now my Armbian is using 2.4G of the 4G card. I want this because I keep my images compact so I can zip up the SD image and send it to my factory in China (who I have set up with a production programmer/tester device using BananaPi + Armbian) Thanks Armbian guys, I can barely express how much I love your work. My fave distro for embedded systems EVER! 2
Recommended Posts