Jump to content

Help To do sdcard question


Recommended Posts

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

Link to comment
Share on other sites

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 ;) )

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 2.2G 1.1G 1.1G 51% /


root@lamobo-r1:~# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME FSTYPE SIZE MOUNTPOINT LABEL
sda 698.7G
|-sda1 ext4 21G linuxfs
|-sda2 ext4 21G /media/second_boot bana
`-sda3 ext4 258G /media/daten_c Daten
mmcblk0 14.9G
`-mmcblk0p1 ext4 2.2G /



root@lamobo-r1:/# ls -la

total 80
drwxr-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 bin
drwxr-xr-x 3 root root 4096 Jul 30 21:06 boot
drwxr-xr-x 14 root root 3920 Jul 30 21:06 dev
drwxr-xr-x 86 root root 4096 Jul 30 21:06 etc
drwxr-xr-x 3 root root 4096 May 10 20:27 home
drwxr-xr-x 18 root root 4096 Apr 29 04:55 lib
drwx------ 2 root root 16384 Apr 29 04:58 lost+found
drwxr-xr-x 5 root root 4096 May 30 21:52 media
drwxr-xr-x 2 root root 4096 Apr 18 22:13 mnt
drwxr-xr-x 2 root root 4096 Apr 18 22:13 opt
dr-xr-xr-x 97 root root 0 Jan 1 1970 proc
drwx------ 3 root root 4096 Jun 18 00:19 root
drwxr-xr-x 17 root root 600 Jul 31 13:04 run
drwxr-xr-x 2 root root 4096 Jun 21 20:26 sbin
drwxr-xr-x 2 root root 4096 Apr 29 04:53 selinux
drwxr-xr-x 2 root root 4096 Apr 18 22:13 srv
dr-xr-xr-x 12 root root 0 Jan 1 1970 sys
drwxrwxrwt 7 root root 180 Jul 30 21:06 tmp
drwxr-xr-x 10 root root 4096 Apr 18 22:13 usr
drwxr-xr-x 11 root root 4096 May 10 19:49 var



now I do an init 6

The SSH is no more valid - I have re-accept the key.

And boom it is big again 15 GB

root@lamobo-r1:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 15G 1.1G 14G 8% /



root@lamobo-r1:/# ls -la

total 80
drwxr-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 bin
drwxr-xr-x 3 root root 4096 Jul 31 13:07 boot
drwxr-xr-x 14 root root 3920 Jul 31 13:07 dev
drwxr-xr-x 86 root root 4096 Jul 31 13:07 etc
drwxr-xr-x 3 root root 4096 May 10 20:27 home
drwxr-xr-x 18 root root 4096 Apr 29 04:55 lib
drwx------ 2 root root 16384 Apr 29 04:58 lost+found
drwxr-xr-x 5 root root 4096 May 30 21:52 media
drwxr-xr-x 2 root root 4096 Apr 18 22:13 mnt
drwxr-xr-x 2 root root 4096 Apr 18 22:13 opt
dr-xr-xr-x 97 root root 0 Jan 1 1970 proc
drwx------ 3 root root 4096 Jun 18 00:19 root
drwxr-xr-x 17 root root 580 Jul 31 13:09 run
drwxr-xr-x 2 root root 4096 Jun 21 20:26 sbin
drwxr-xr-x 2 root root 4096 Apr 29 04:53 selinux
drwxr-xr-x 2 root root 4096 Apr 18 22:13 srv
dr-xr-xr-x 12 root root 0 Jan 1 1970 sys
drwxrwxrwt 7 root root 180 Jul 31 13:07 tmp
drwxr-xr-x 10 root root 4096 Apr 18 22:13 usr
drwxr-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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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!

B) 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!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines