Written Armbian image correctly on 64 GB micro SD but it's not using full available space

[Slavi]

hi guys,

 

I have reported this on to etcher folks at https://github.com/resin-io/etcher/issues/1466

Not sure if it's a feature or a bug.

 

Cubie truck 3

 

Any ideas?

 

 

• Etcher version:
  Etcher-1.0.0-win32-x64.exe

• Operating system and architecture:
  windows 8

• Image flashed:
  https://dl.armbian.com/cubietruck/archive/Armbian_5.25_Cubietruck_Ubuntu_xenial_default_3.4.113_desktop.7z

• Do you see any meaningful error information in the DevTools?

Filesystem      Size  Used Avail Use% Mounted on
udev            941M     0  941M   0% /dev
tmpfs           189M  5.5M  184M   3% /run
/dev/mmcblk0p1  2.7G  2.2G  490M  82% /
tmpfs           944M   92K  944M   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           944M     0  944M   0% /sys/fs/cgroup
tmpfs           944M  104K  944M   1% /tmp
log2ram          50M  1.4M   49M   3% /var/log
tmpfs           189M     0  189M   0% /run/user/0
tmpfs           189M  8.0K  189M   1% /run/user/1000

[Igor]

Reboot.

[pfeerick]

This NOT an etcher bug. A small image is written to a big (micro)SD card, and it is then resized on the first reboot. Sometimes there is a automatic reboot, other times it is left up to you. I believe it is something to do with whether resize2fs can do an online resize or not on different kernels?? (you can see the test here in the resize2fs script). 

 

When you logged into the CT for the first time, it probably have had the red text shown on this screenshot (which obviously for a OrangePi Zero, but never mind...). As the text indicates, and as Igor said... reboot!   If you manually reboot and the file system hasn't been expanded... then there is a problem!  

 

[tkaiser]

From a usability point of view the behaviour we implemented in Armbian is just an insane fail. There's a 80x25 screen completely filled with absolutely useless data at this point (where those two jelling lines in red somewhere in the middle are lost) and even the informative message trying to guide through the task the user should cope with now is f*cked up (it's line 1 at the top talking about required password change and lines 24-25 continuing with this).

 

I never liked this motd stuff (display of fancy data delaying login) but it should be obvious that displaying this stuff here is counterproductive. But we're simply too blind to realize. If there's a need to reboot why not adding this to the end of user creation: Checking whether reboot is needed or not, telling the user that a reboot is necessary with one option 'reboot' requiring [enter]. No more hassles. And all the irrelevant motd stuff becoming active only on 2nd boot.

[Igor]

1 hour ago, tkaiser said:

Checking whether reboot is needed or not, telling the user that a reboot is necessary with one option 'reboot' requiring [enter]. No more hassles. And all the irrelevant motd stuff becoming active only on 2nd boot.

We changed automated rebooting with this note because some other users complained on this feature. It's impossible to please everybody at once. If we remove this, believe me, we won't do much good. People will start asking ... where is this and that
 

1 hour ago, tkaiser said:

I never liked this motd stuff

You are not the only one but at least this is now quick and trivial to disable withing armbian-config.

[tkaiser]

25 minutes ago, Igor said:

We changed automated rebooting with this note because some other users complained on this feature.

Yes, we did it wrong, do it wrong and still don't want to do it right

 

Automatic reboot for rootfs resize was there for historical reasons. It started to interfere with user creation (users logging in too early and then being surprised when the board restarts without notice) but the 'solution' to display a notice somewhere in between a wall of text many users can't cope with is obviously none. We use /var/run/resize2fs-reboot today in update-motd.d/98-autoreboot-warn to display information most users will miss in this wall of text but instead we could move this check to  check_first_login.sh and simply tell the user after finishing account creation to reboot asap (either forced asking him to press enter or in red letters as information only as it's done in 98-autoreboot-warn now).

 

That's my whole point: guiding users, providing them with the information they need at a certain point and preventing them being flooded with useless data as it's the case now. I talked to a teacher recently about different kind of people and what challenges she meets from her education point of view (and she mentioned that a huge amount of people can't extract relevant information from such a colourful wall of text that is our 'welcome screen' today. It's like fireworks exploding in front of them)

[Igor]

3 minutes ago, tkaiser said:

providing them with the information they need at a certain point

Absolutely agree that we have room for optimisation here. Perhaps removing the whole welcome part and having just this at first login?

 

 

[tkaiser]

31 minutes ago, Igor said:

Perhaps removing the whole welcome part and having just this at first login?

 

This would be great since users then are only confronted with what's necessary at this stage (and the reboot message will still only displayed if necessary). Two more thoughts:

• Displaying the device name the image is made for could be useful for those users that downloaded the wrong one (OPi Plus vs. PC Plus as the most prominent example) but I doubt people will take notice now (they'll realize it later since Ethernet isn't working which is something we could check for since in both cases missing Ethernet PHY is available via dmesg output -- but let's postpone that until we followed @zador.blood.stained's suggestion to implement a sane template framework for all of this stuff)
• What about exchanging '(root enforced)' with something guiding users through this process: »You are required to change the root password immediately. Enter current password '1234' once and then two times a new and strong password as requested«?

 

[zador.blood.stained]

14 minutes ago, tkaiser said:

What about exchanging '(root enforced)' with something guiding users through this process: »You are required to change the root password immediately. Enter current password '1234' once and then two times a new and strong password as requested«?

I don't think this can be customized without recompiling the PAM libraries or using a custom localization, and I would prefer to not touch any of those options.

 

Example from ru.po localization file:

#: modules/pam_unix/pam_unix_acct.c:255
msgid "You are required to change your password immediately (root enforced)"
msgstr ""
"Вам необходимо немедленно сменить пароль (в принудительном режиме root)"

 

 

[tkaiser]

2 minutes ago, zador.blood.stained said:

I don't think this can be customized without recompiling the PAM libraries or using a custom localization, and I would prefer to not touch any of those options.

 

No problem, then we don't exchange strings but add information (as it's done now, today between the first line of this process and the next about 20 lines of motd stuff are inserted -- we could just add 2 lines explaining that's 1234 first and then two times the same new password later).

[zador.blood.stained]

1 minute ago, tkaiser said:

No problem, then we don't exchange strings but add information (as it's done now, today between the first line of this process and the next about 20 lines of motd stuff are inserted -- we could just add 2 lines explaining that's 1234 first and then two times the same new password later).

As far as I remember MOTD is not displayed before forced password change when you log in from a serial console or from tty1/display. Are these screenshots from SSH?

[Slavi]

Thank you all for the replies. Now I see them.

I wrote the image again and can't remember maybe I've rebooted and the actual disk space showed up.

The little server is up and running. Co cool