Не получается увеличить размер rootfs на одном из контроллеров (WB 7)

vag · July 30, 2023, 5:51pm

Добрый день.
Прошу помощи в решении возникшей проблемы.
У меня на одном из контроллеров WB7 не получается расширить раздел rootfs.
При этом сами обновления (любые, как стабильные так и тестовые разных дат) устанавливаются без проблем. Обновления fit-ом успешно устанавливаю как через вэб интерфейс (с установленной галочкой “Расширить rootfs, если прошивка поддерживает эту возможность”), так и через SD карту (64Гб, индустр. приобреталась у вас) - процесс проходит корректно. Делал и просто обновления и со сбросом к заводским (сброс конфигурации наблюдаю).
Обновлял ПО как с установленной SD картой, так и без нее - результат идентичный.
Контроллер пока “голый” - периферия к нему не подключена. Подключено только питание (24 вольта) и РС (но не всегда, пробовал и “вслепую”) к USB порту “debuging console”
Контроллер свежий, покупался в составе заказа 196551 от 30.06.2023.

На этапе обновления в диагностической консоли имеется такой вывод (Repartition failed, continuing without it) :

>>> Checking SHA1 hash of rootfs
PROGRESS: 100%
>>> SHA1 hash of rootfs ok
>>> rootfs is valid, installing firmware update
>>> Enlarging first rootfs partition
>>> Checking and repairing filesystem on /dev/mmcblk0p2
>>> Temp toolpath: /tmp/tmp.qVeFW9
[   33.127466] vcc-gmac-phy: disabling
[   33.131309] dc5ldo: disabling
[   33.147469] dldo4: disabling
rootfs1: /lost+found not found.  CREATED.
rootfs1: 28624/65536 files (0.1% non-contiguous), 171181/262144 blocks
>>> Backing up old MBR (and partition table)
1+0 records in
1+0 records out
512 bytes copied, 0.00126704 s, 404 kB/s
>>> Creating a new parition table
>>> New disk dump will be saved in /tmp/tmp.nYO4Bu
Partition #2 contains a ext4 signature.
Partition #5 contains a swap signature.
Partition #6 contains a ext4 signature.
Re-reading the partition table failed.: Device or resource busy
>>> Unmounting /mnt/data and saving its mountpoint
[   40.007461]  mmcblk0: p1 p2 p3 p4 < p5 p6 >
>>> Restoring mount of /dev/mmcblk0p6 to /mnt/data
/dev/shm/tmp.cJe7zw: line 132: /mnt/data/.wb-update/state/update.log: No such file or directory
/dev/shm/tmp.cJe7zw: line 133: /mnt/data/.wb-update/state/update.status: No such file or directory
[   40.033654] EXT4-fs (mmcblk0p6): mounted filesystem with ordered data mode. Opts: (null)

>>> Expanding filesystem on this partition
resize2fs 1.46.2 (28-Feb-2021)
Overwriting existing filesystem; this can be undone using the command:
    e2undo /tmp/tmp.aV8dNT /dev/mmcblk0p2

Please run 'e2fsck -f /dev/mmcblk0p2' first.

/tmp/tmp.aV8dNT: while force-closing undo file
>>> Filesystem expantion failed, restoring everything
/tmp/tmp.aV8dNT: Corrupt undo file header.
1+0 records in
1+0 records out
512 bytes copied, 0.000559291 s, 915 kB/s
>>> Unmounting /mnt/data and saving its mountpoint
[   40.188038]  mmcblk0: p1 p2 p3 p4 < p5 p6 >
>>> Restoring mount of /dev/mmcblk0p6 to /mnt/data
/dev/shm/tmp.cJe7zw: line 132: /mnt/data/.wb-update/state/update.log: No such file or directory
/dev/shm/tmp.cJe7zw: line 133: /mnt/data/.wb-update/state/update.status: No such file or direct[   40.213793] EXT4-fs (mmcblk0p6):                                   mounted filesystem with ordered data mode. Opts: (null)
ory
>>> Repartition failed, continuing without it
>>> Getting mmcpart from U-Boot environment
>>> Will install to /dev/mmcblk0p3
>>> Temporarily mount actual rootfs /dev/mmcblk0p2 to check previous OS release
[   40.295198] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
>>> Debian: bullseye -> bullseye
[   40.400594] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
>>> Cleaning up /dev/mmcblk0p3
>>> Cleaning up using rsync
[   46.398381] random: crng init done
>>> Mounting /dev/mmcblk0p3 at /tmp/tmp.e8Dzew
[   46.753363] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
>>> Extracting files to new rootfs
/tmp/tmp.e8Dzew /
PROGRESS: 100%
/
>>> Recovering device certificates
[   78.222407] EXT4-fs (loop0): mounted filesystem without journal. Opts: (null)
>>> Mount /dev, /proc and /sys to rootfs
>>> Running post-install scripts
>>> > Processing /tmp/tmp.e8Dzew/usr/lib/wb-image-update/postinst/10update-u-boot
Skipping u-boot update (use factory reset to do it)
>>> Unmounting /dev, /proc and /sys from rootfs
>>> Switching to new rootfs
>>> Done!
>>> Removing FIT /mnt/data/.wb-update/webupd.fit
>>> Unmounting rootfs
>>> Reboot system
[   80.448394] reboot: Restarting system
[   80.462111] i2c i2c-0: No atomic I2C transfer handler

U-Boot SPL 2021.10-wb1.5.2-g1843380fc3 (Apr 27 2023 - 12:01:07 +0000)
DRAM: 2048 MiB
Trying to boot from MMC2


U-Boot 2021.10-wb1.5.2-g1843380fc3 (Apr 27 2023 - 12:01:07 +0000)

CPU:   Allwinner R40 (SUN8I 1701)
Model: Wiren Board rev. 7.2.0 (A40i)
I2C:   ready
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from MMC... OK
In:    serial@1c28000
Out:   serial@1c28000
Err:   serial@1c28000
Will only keep env vars: mmcpart bootcount upgrade_available uenvcmd wb_webupd otp_program otp_aes_program
## Info: input data size = 142 = 0x8E
bootcount=0
mmcpart=3
uenvcmd=true ; echo reset environment; env default -a; setenv mmcdev 0; saveenv; bmode emmc; reset
upgrade_available=1

Environment size: 142/131068 bytes
## Resetting to default environment
## Info: input data size = 142 = 0x8E
Net:   No ethernet found.
Hit <SPACE> key to stop autoboot in  1s
switch to partitions #0, OK
mmc1(part 0) is current device
eMMC found on device 1
Press FW button to enter firmware update mode
................................................
326 bytes read in 2 ms (159.2 KiB/s)
Importing environment from 0x42000000...
Checking if uenvcmd is set ...
test - minimal test like /bin/sh

Usage:
test [args..]
Running default loadzimage ...
6479952 bytes read in 171 ms (36.1 MiB/s)

MMC read: dev # 1, block # 2016, count 32 ... 32 blocks read: OK
Reading overlays list from eMMC
Reading factory fdt name from eMMC
Loading factory fdt sun8i-r40-wirenboard733
54742 bytes read in 4 ms (13.1 MiB/s)
254 bytes read in 2 ms (124 KiB/s)
Applying DT overlay temp-commercial
Applying extra overlay
Booting from mmc ...
Kernel image @ 0x42000000 [ 0x000000 - 0x62e050 ]
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Device Tree to 49fdd000, end 49ffffff ... OK

Starting kernel ...

Далее идет штатная загрузка.
При логине приветственная надпись:

В устройствах:

Результат выполнения e2fsck -f /dev/mmcblk0p2

Серийный номер ADP4HAE2 :

Диагностический архив (206 Мб) могу отправить вам по запросу (данный форум отказался принимать такой объем).

Другие контроллеры, обновил с расширением раздела под rootfs без проблем (тот же РС, тот же броузер Гугл хром, теми же fit файлами )…
Например:

P.S.
На всякий случай проверил на бэды и расширил отчет :
e2fsck -vfc /dev/mmcblk0p2

BrainRoot · July 31, 2023, 5:00pm

Непонятно… А Factory reset проходит удачно? Есть от него вывод?

vag · July 31, 2023, 7:57pm

Да, Factory Reset, как я и писал выше, проходит удачно. Все конфиги возвращаются к дефолту.
Вывод в консоль, к сожалению, перехватить нормально не удается (сбрасываю через SD карту = подача питания с зажатой кнопкой, а при подключенном кабеле в USB порт - питание происходит от него, т.е. кабель приходится отключать… В результате пока потом на компьютере определится СОМ порт, пока я к нему подключусь - половина загрузки уже пройдет.).
Судя по звуковым сигналам в процессе прошивки - все происходит как положено.
Конечный (итоговый) результат сброса - тоже корректный

На самом деле я уже решил проблему более “жестко”. - вручную переинициализировал (создал файловую систему = отформатировал) раздел и после этого процесс “расширения rootfs” прошел штатно. Возможно, действительно на данном разделе были проблемы, которые мешали его “ресайзить”, о чем скрипт честно извещал при своей работе.

Сейчас с разделами у меня вот так:

root@wirenboard-ADP4HAE2:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0      179:0    0 58.2G  0 disk
├─mmcblk0p1  179:1    0   16M  0 part
├─mmcblk0p2  179:2    0    2G  0 part /
├─mmcblk0p3  179:3    0    2K  0 part
├─mmcblk0p4  179:4    0    1K  0 part
├─mmcblk0p5  179:5    0  256M  0 part [SWAP]
└─mmcblk0p6  179:6    0   56G  0 part /mnt/data
mmcblk0boot0 179:8    0    4M  1 disk
mmcblk0boot1 179:16   0    4M  1 disk
mmcblk1      179:24   0 14.4G  0 disk
└─mmcblk1p1  179:25   0 14.4G  0 part /mnt/sdcard
root@wirenboard-ADP4HAE2:~#

Т.е. также как и у других моих контроллеров WB7.
Скорее всего данная проблема больше похожа на “случайный сбой в fs” , т.е. не имеет систематического характера и вряд ли может быть воспроизведена у вас для анализа.
Поэтому будем считать вопрос решенным.

PS просто к слову (информация) - в этом же (указанном выше) заказе была SD карточка на 64 ГБ. Я получил ее сломанной физически (сгибается поперек, не определяется системой, точнее дает ошибку “не поддерживаемое напряжение питания”). Похоже что она или неудачно “транспортировалась” СДЕКом или на момент отгрузки уже была такой. Сейчас это уже не выяснить.
Предыдущие карточки с другими контроллерами доходили целыми , хотя точно также отгружались вами в антистатическом пакетике внутри коробки с контроллером.
Рекомендую все же использовать для карточек что-то понадежнее, например, пластиковые контейнеры, ну или вставлять ее в контроллер (в моем заказе она шла “как бы в контроллере”).

BrainRoot · August 1, 2023, 7:24am

Да. До чего приятно когда общаешься с грамотным собеседником… Идеальная диагностика, все денные. Подумаем как избежать такого, принудительно запускать проверку /dev/mmcblk0p[2…3], наверно.

Нет, это так оставлять нельзя…
Давайте мы бесплатно поменяем вам оборудование. Курьер привезёт новое:

SD 64Гб

Для возврата напишите, пожалуйста, письмо на info@wirenboard.com.

В письме укажите:

ссылку на эту тему,
ваш действующий телефон, адрес доставки, ФИО получателя.

То есть недовставлена?

vag · August 1, 2023, 7:26pm

Нет, я имел ввиду, что для “безопасной транспортировки” карточку можно было бы вставить в контроллер, тем более, что при формировании заказа карточка “входила в состав (опции) контроллера”.

Карточка была упакована в антистатический пакетик и лежала под контроллером. Заказ был достаточно большой и тяжелый ( 27 наименований, 45 товарных единиц).
В итоге из коробки я достал ее в таком виде.

Предыдущие заказы включающие карты SD доходили до меня без проблем (карточки были упакованы также, но обычно лежали сбоку/поверх контроллера).

Как и писал выше, что и как именно произошло с данной картой сейчас уже не понять.
Да и по жизни они достаточно прочные - так просто их не сломать.
Поэтому просто предложил вам отправлять их в более безопасной (для карточки) упаковке или внутри слота в контроллере.

BrainRoot · August 2, 2023, 8:19am

Как бы то ни было - мы ее заменим (отправим вам новую).
Напишите пожалуйста письмо…

Да, так и должно быть (вставлена). Это мы у себя проверим, благодарю за сообщение.

Ghost · August 2, 2023, 10:04am

Не много не в тему проблемы, но приятно читать и осознавать, что компания добросовестная и заботится о своих клиентах.

vag · August 3, 2023, 9:01am

Сложно возразить.
Сам был приятно удивлен таким подходом, тем более, в столь спорной о очень неоднозначной ситуации.
Большое спасибо команде WirenBoard!
Вопрос с расширением fsroot решен, попутно возникший вопрос о SD карточке, так же решен (карточку на замену мне отправили).

BrainRoot · August 3, 2023, 3:16pm

Мы не подозреваем пользователей во лжи. Вот никогда.
В нежелении чиать документацию - да, бывает.
Ну, рад что разрешилось благополучно.

system · August 10, 2023, 3:17pm

Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.