[Problem] Can't find a SQUASHFS superblock und No init found

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
F

fweite

Neuer User
Mitglied seit
30 Mrz 2022
Beiträge
9
Punkte für Reaktionen
1
Punkte
3
Ich habe ein komisches Problem mit meiner 7490. Da die Telekom nur fast 50 Megabit schafft reicht mir die. Zuerst habe ich eine Freetz-ng Firmware gebaut und danch mit push_firmware aufgespielt. Das hat funktioniert und Freetz-ng ist auf Port 81 erreichbar. Nun kommt es aber: Wenn ich reboote hängt die Fritte im Bootloop! Einmal habe ich es mit replaced kernel versucht und dann ohne, jedes mal das gleiche! Aber wenn mit der frisch gepushte Firmware die gleiche Firmware nochmal über Freetz-ng installiert wird geht auch der Reboot danach!

Ich habe eine Console angestöpselt um zu sehen was da los ist
Code: 
[    6.630000] [    3.000000] [ppe_eth_init] init_hw()
[    6.630000] [    3.000000] [init_hw] ppe_hw_init=0xff successful
[    6.630000] [    3.010000] [ppe_eth_init] ifx_proc_file_create()
[    6.630000] [    3.010000] [ppe_eth_init] dma_setup_init()
[    6.630000] [    3.020000] [avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown unicast frames 0x48
[    6.630000] [    3.030000] [avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown multicast frames 0x48
[    6.630000] [    6.420000] [set_pce_critical_mac] setting critical mac_addr rule for ba:db:ad:c0:ff:ee, sw-m-port=5
[    6.630000] [    6.420000] [set_pce_set_bc_mc_class] setting mac_addr (01:00:00:00:00:00) class 1
[    6.630000] [    6.430000] [set_pce_set_bc_mc_class] setting mac_addr (03:00:00:00:00:00) class 1
[    6.630000] [    6.440000] [set_pce_set_bc_mc_class] setting mac_addr (0f:00:00:00:00:00) class 1
[    6.630000] [    6.450000] [avmnet_set_macaddr] Setup Mac Addr for Device(eth0): 08:96:d7:12:34:56
[    6.630000] [    6.460000] [avmnet_set_macaddr] Setup Mac Addr for Device(eth1): 08:96:d7:12:34:56
[    6.630000] [    6.470000] [avmnet_set_macaddr] Setup Mac Addr for Device(eth2): 08:96:d7:12:34:56
[    6.630000] [    6.470000] [avmnet_set_macaddr] Setup Mac Addr for Device(eth3): 08:96:d7:12:34:56
[    6.630000] [    6.480000] [avmnet_set_macaddr] Setup Mac Addr for Device(wasp): 00:de:ad:12:34:78
[    6.630000] [    6.490000] [avmnet_create_netdevice] setup offload_cpu_link on device wasp
[    6.630000] [    6.550000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock1
[    6.630000] [    6.560000] yaffs: dev is 32505857 name is "mtdblock1" ro
[    6.630000] [    6.560000] yaffs: passed flags ""
[    6.630000] [    6.570000] yaffs: yaffs: Attempting MTD mount of 31.1,"mtdblock1"
[    6.630000] [    6.570000] yaffs: auto selecting yaffs2
[    6.630000] [    6.590000] yaffs: yaffs_read_super: is_checkpointed 1
[    6.630000] [    6.590000] VFS: Mounted root (yaffs filesystem) readonly on device 31:1.
[    6.630000] [    6.590000] devtmpfs: mounted
[    6.630000] [    6.600000] Freeing unused kernel memory: 308K (80913000 - 80960000)
[    6.630000] [    6.630000] Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
[    6.630000] [    6.630000] set_reboot_status: Soft-Reboot(PANIC)  - SHORTPOWERCUT(1) PANIC(95)SUM(96)UP(6)UTC(6)FW(07.61)HW(185)HWS(1)BV(1.1777)BN(124973)FS(07.61)BT(0)BD(0)
[    6.630000] Rebooting in 5 seconds..
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000


Was ist das Problem? Ich überlege ob es "SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock1" oder "No init found. Try passing init= option to kernel" sein könnte? Oder hat die Fritte Altersschwäche?
 
Schon mal mit anderen seriellen Logs einer 7490 (es gibt einige hier im Board) oder gar dem einer originalen AVM-Firmware verglichen? Tatsächlich ist die wrapper-Partition in einer VR9-Box kein SquashFS, sondern eine YAFFS2-Partition, in der das eigentliche SquashFS-Image als Datei abgelegt ist und über ein loop-Device gemountet wird, bevor mittels pivot-root auf ebendieses umgeschaltet wird.

Offenbar fehlt da irgendetwas in dem aktuellen (YAFFS2-)Image (was eigentlich kein "Image" ist, sondern wo lediglich eine leere, frisch initialisierte ("flash erased" und danach als YAFFS2 gemountete) Partition durch simples Kopieren mit den notwendigen Inhalt versehen wird) bzw. vermutlich machst Du die (jeweils zweite) "Installation" falsch, wenn ich lese, daß es nach richtiger Installation (egal ob über EVA oder Freetz-NG) auch "dauerhaft" funktioniert.
 
Zuletzt bearbeitet:
wenn ich lese, daß es nach richtiger Installation (egal ob über EVA oder Freetz-NG) auch "dauerhaft" funktioniert.
Zum Vergrößern anklicken....
Nein, nicht über EVA! Sondern aus nur dem gestarteten Freetz-ng image heraus.
Jeder installation mit push_firmware ist nicht dauerhaft und führt zum Bootloop


"Konnte Wrapper-Verzeichnis nicht kopieren."

Ich hab noch etwas weiter geforscht, wenn man auf der Console zum richtigen Zeitpunkt "Enter" drückt erscheinen mehr Logs!

Code: 
[    6.610000] VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
[    6.610000] devtmpfs: mounted
[    6.620000] Freeing unused kernel memory: 308K (80913000 - 80960000)
[VR9-flash] -- Test --
[    8.590000] led_module: module license '
[    8.590000] (C) Copyright 2012 by AVM
[    8.590000] ' taints kernel.
[    8.600000] Disabling lock debugging due to kernel taint
[    8.610000] [module-alloc-by-name] give 0x39000 bytes at 0x811ac000 to module 'led_module' (0x850000 total bytes left)
[    8.640000] [LED] use GPIO 45 for 'gpio_avm_led_power'
[    8.640000] [LED] use GPIO 47 for 'gpio_avm_led_internet'
[    8.640000] [LED] use GPIO 36 for 'gpio_avm_led_festnetz'
[    8.650000] [LED] use GPIO 35 for 'gpio_avm_led_wlan'
[    8.650000] [LED] use GPIO 33 for 'gpio_avm_led_info'
[    8.660000] [LED] use GPIO 46 for 'gpio_avm_led_info_red'
[    8.670000] [BUTTON] use GPIO 29 for 'gpio_avm_button_wlan'
[    8.670000] [BUTTON] use GPIO 1 for 'gpio_avm_button_dect'
[    8.680000] [avm_connect][state_machine_init] starting event worker thread
[    8.680000] led_module: Waiting for event system to be ready...
[VR9-flash] ============================================================================
[VR9-flash] Image flashing RAM -> NAND (v0.0.1)
[VR9-flash] ===================================
[VR9-flash] MTD-NR Kernel-RAM: 1 - (mtd1: 00280900 00000100 "kernel_ram")
[VR9-flash] MTD-NR Rootfs-RAM: 0 - (mtd0: 02d0d000 00000100 "rootfs_ram")
[VR9-flash] MTD-NR Kernel-NAND: 3 - (mtd3: 00400000 00020000 "kernel")
[VR9-flash] MTD-NR Rootfs_NAND: 4 - (mtd4: 03000000 00020000 "filesystem")
[VR9-flash]
[VR9-flash] ..delete MTD-Kernel-NAND + cpy kernel.image
[    9.420000] [0]system-load  50% loadavg 0.32 0.7 0.2 - pgstat: sum=47906 free=41502 slab=1515 alloc=1235/s fault=550/s (sleep 3)
[    9.650000] [1]system-load  41% loadavg 0.32 0.7 0.2 - task runtime:32% max:update_kernel 30%  pgstat: sum=47915 free=41502 slab=1515 alloc=1235/s fault=550/s (sleep 1)
[VR9-flash] ..delete MTD-Rootfs-NAND + cpy wrapper-fs
[   10.050000] yaffs: dev is 32505860 name is "mtdblock4" rw
[   10.050000] yaffs: passed flags ""
[   19.430000] [0]system-load  69% loadavg 0.42 0.10 0.3 - task runtime:33% max:cp 29%  pgstat: sum=47900 free=23893 slab=1758 alloc=2329/s fault=92/s (sleep 3)
[VR9-flash] [Fehler] Konnte Wrapper-Verzeichnis nicht kopieren.
[VR9-flash] [Fehler]
[VR9-flash] [Fehler]
[VR9-flash] [Fehler] Image wurde nicht geflasht. Bitte beachten Sie die Fehlerausgaben..
[VR9-flash] [Fehler]
[VR9-flash] [Fehler]====================================================================
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] append 128768 Bytes
[main] written 0x20000 Bytes
[main] eof reached
[main] exit error 0
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x3000000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
starting pid 1033, tty '': '/etc/boot.d/1'
mount: mounting proc on /proc failed: Device or resource busy
mount: mounting sysfs on /sys failed: Device or resource busy
mount: mounting pstore on /sys/fs/pstore failed: No such file or directory
mknod: /dev/led: File exists
[   27.330000] TFFS Name Table N

Diese Fehlermeldung kommt vermutlich aus /sbin/flash_update.
Code: 
# fs-mtd im nand loeschen + kopieren
print_message "..delete MTD-Rootfs-NAND + cpy wrapper-fs"
if [ -e "/dev/mtd${rootfs_nand_mtdnr}" ] ; then
    /sbin/update_kernel -o /dev/mtd${rootfs_nand_mtdnr} >> ${tmp_log_file}

    mount -t yaffs2 /dev/mtdblock${rootfs_nand_mtdnr} ${tmp_dir_mntfs} >> ${tmp_log_file}
    # Check if mount was ok
    var_mount_mtd=`mount | grep /dev/mtdblock${rootfs_nand_mtdnr}`
    if [ -n "${var_mount_mtd}" ] ; then
        cp -R /wrapper/* ${tmp_dir_mntfs}
        if [ $? -ne 0 ] ; then
            print_message "[Fehler] Konnte Wrapper-Verzeichnis nicht kopieren."
            print_error_logfile
            exit 3
        fi
    else
        print_message "[Fehler] Konnte Filesystem-Partition ${rootfs_nand_mtdnr} nicht mounten."
        print_error_logfile
        exit 4
    fi
fi

Hier fehlt mir die Vorstellungskraft weshalb das kopieren nicht geht
 
Ich rate einfach mal (wenn auch als "educated guess" und nicht nur ins Blaue), daß Dein Image einfach zu groß ist für den verbleibenden Platz in der YAFFS2-Partition - die gesamte Partition ist 0x3000000 = 48 MB groß, dein eigenes Image als SquashFS-Image ist 0x2D0D000 Bytes (47.239.168 Bytes = etwas über 45 MB) groß.

Das ist aber selbst noch einmal komprimiert und daher stimmt die Berechnung in Freetz-NG auch nicht mehr, seitdem AVM wieder auf das SquashFS-Format für den Inhalt der Wrapper-Partition gewechselt ist (vorher bei ext2 für den Wrapper spielte Kompression keine Rolle), solange da nicht der unkomprimierte Inhalt (außer natürlich das Core-Image, was aber selbst noch einmal komprimiert ist) als Grundlage herangezogen wird (EDIT: ob das geändert wurde in Freetz-NG, habe ich nicht mehr verfolgt).

Da aber auch YAFFS2 noch ein paar (wenige) eigene Verwaltungsinformation braucht, dürfte das Kopieren einfach fehlschlagen, weil eben der Platz am Ziel nicht ausreicht. Man sollte einfach mal den tatsächlich belegten Speicherplatz in der (äußeren) SquashFS-Datei zusammenzählen (lassen, iirc gibt das unsquashfs umfassende Infos aus, wenn man es richtig aufruft).
 
Zuletzt bearbeitet:
Wow!

Code: 
ls -al build/modified/firmware/var/tmp/
insgesamt 48712
-rw-r--r--. 1 freetz freetz 47247368 18. Okt 13:25 filesystem.image
-rw-r--r--. 1 freetz freetz 2624008 18. Okt 13:25 kernel.image

Ich hab es noch nicht überprüft aber es sieht heiss aus. Das würde auch erklären weshalb das image aus dem Ram starten kann
 
Noch einmal - die Image-Größe sieht man auch in Deinem (partiellen) Protokoll … entscheidend ist hier nicht, wie groß die filesystem.image selbst ist, sondern worauf sich ihr Inhalt nach dem Auspacken (oder meinetwegen auch nach dem Mounten auf einem loop-Device) summiert.
 
Hilft das? Aus /sbin/flash_update
Code: 
tmp_dir="/var"
tmp_dir_mntfs="${tmp_dir}/mnt_fs"
mkdir -p ${tmp_dir_mntfs}

rootfs_nand_mtdnr=$(sed -nr 's/^mtd([[:digit:]]+)[:].*\"filesystem\"$/\1/p' "/proc/mtd")
mount -t yaffs2 /dev/mtdblock${rootfs_nand_mtdnr} ${tmp_dir_mntfs}


root@fritz:~# du -s ${tmp_dir_mntfs}
47878   /var/mnt_fs

root@fritz:~# df ${tmp_dir_mntfs}
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mtdblock6           49152     49152         0 100% /var/mnt_fs

Freetz-ng hatte behauptet
Code: 
copying filesystem image
  filesystem image size: 45.1 MB, max 48.0 MB, free 2.9 MB (3088384 bytes)

-------------------------------------------------------------------------------------------------------------

Ich habe das 2mb grosse ImageMagick entfernt, und jetzt geht es

"SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock3" bleibt und muss wohl so ein

Code: 
[    6.640000] [avmnet_create_netdevice] setup offload_cpu_link on device wasp
[    6.680000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock3
[    6.680000] yaffs: dev is 32505859 name is "mtdblock3" ro
[    6.690000] yaffs: passed flags ""
[    6.740000] VFS: Mounted root (yaffs filesystem) readonly on device 31:3.
[    6.750000] devtmpfs: mounted
[    6.750000] Freeing unused kernel memory: 308K (80913000 - 80960000)
[    7.040000] [ifx_hsnand_command] read block is critical (column: 0x0 page: 0xca28)
[    8.670000] led_module: module license '
[    8.670000] (C) Copyright 2012 by AVM
[    8.670000] ' taints kernel.
[    8.680000] Disabling lock debugging due to kernel taint

nur "block is critical" ist nicht so schön.

Das schreiben selbst ist auch ohne Fehler:
Code: 
[VR9-flash] -- Test --
[    8.610000] led_module: module license '
[    8.610000] (C) Copyright 2012 by AVM
[    8.610000] ' taints kernel.
[    8.620000] Disabling lock debugging due to kernel taint
[    8.630000] [module-alloc-by-name] give 0x39000 bytes at 0x811ac000 to module 'led_module' (0x850000 total bytes left)
[    8.660000] [LED] use GPIO 45 for 'gpio_avm_led_power'
[    8.660000] [LED] use GPIO 47 for 'gpio_avm_led_internet'
[    8.670000] [LED] use GPIO 36 for 'gpio_avm_led_festnetz'
[    8.670000] [LED] use GPIO 35 for 'gpio_avm_led_wlan'
[    8.680000] [LED] use GPIO 33 for 'gpio_avm_led_info'
[    8.680000] [LED] use GPIO 46 for 'gpio_avm_led_info_red'
[    8.690000] [BUTTON] use GPIO 29 for 'gpio_avm_button_wlan'
[    8.690000] [BUTTON] use GPIO 1 for 'gpio_avm_button_dect'
[    8.700000] [avm_connect][state_machine_init] starting event worker thread
[    8.710000] led_module: Waiting for event system to be ready...
[VR9-flash] ============================================================================
[VR9-flash] Image flashing RAM -> NAND (v0.0.1)
[VR9-flash] ===================================
[VR9-flash] MTD-NR Kernel-RAM: 1 - (mtd1: 00280a00 00000200 "kernel_ram")
[VR9-flash] MTD-NR Rootfs-RAM: 0 - (mtd0: 02b36000 00000200 "rootfs_ram")
[VR9-flash] MTD-NR Kernel-NAND: 5 - (mtd5: 00400000 00020000 "kernel")
[VR9-flash] MTD-NR Rootfs_NAND: 6 - (mtd6: 03000000 00020000 "filesystem")
[VR9-flash]
[VR9-flash] ..delete MTD-Kernel-NAND + cpy kernel.image
[    9.470000] [0]system-load  50% loadavg 0.32 0.7 0.2 - pgstat: sum=48398 free=42144 slab=1509 alloc=1216/s fault=550/s (sleep 2)
[    9.660000] [1]system-load  41% loadavg 0.32 0.7 0.2 - task runtime:50% max:update_kernel 47%  pgstat: sum=48389 free=42144 slab=1509 alloc=1216/s fault=550/s (sleep 2)
[VR9-flash] ..delete MTD-Rootfs-NAND + cpy wrapper-fs
[   10.070000] yaffs: dev is 32505862 name is "mtdblock6" rw
[   10.080000] yaffs: passed flags ""
[   19.480000] [0]system-load  70% loadavg 0.42 0.10 0.3 - task runtime:32% max:cp 29%  pgstat: sum=48339 free=24528 slab=1734 alloc=2324/s fault=92/s (sleep 1)
[VR9-flash] ..cleanup
[   26.660000] TFFS Name Table N
[VR9-flash] FINISHED -> Reboot now..
[VR9-flash] ============================================================================
[   26.730000] set_reboot_status: Soft-Reboot  - UP(26)UTC(26)FW(07.61)HW(185)HWS(1)BV(1.1777)BN(124973)FS(07.61)BT(0)BD(0)
[   26.740000] Res
ROM VER: 1.1.4
CFG 05
** START
RVEC bf200000

Nur Freetz-ng hat nicht gewarnt

Code: 
du -sb build/modified/filesystem.outer/
48737901        build/modified/filesystem.outer/

du -s build/modified/filesystem.outer/
47660   build/modified/filesystem.outer/

cat build/modified/filesystem.log
Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 46128.52 Kbytes (45.05 Mbytes)
        96.90% of uncompressed filesystem size (47602.80 Kbytes)
Inode table size 842 bytes (0.82 Kbytes)
        13.04% of uncompressed inode table size (6456 bytes)
Directory table size 1062 bytes (1.04 Kbytes)
        66.88% of uncompressed directory table size (1588 bytes)

ls -al build/modified/firmware/var/tmp/kernel.image
-rw-r--r--. 1 freetz freetz 2623496 18. Okt 15:52 build/modified/firmware/var/tmp/kernel.image

Also darf die firmware 48*1024*1024=50331648 nicht überschreiten?
Bestehend aus kernel 2623496 und filesystem 1024*47660=47660 +2,8?
Das wären 51427336 und 50331648 zuviel, also mehr als 1mb drüber!
 
Noch mal - der unkomprimierte(!) Inhalt der filesystem.outer darf (geteilt durch die Blockgröße der YAFFS2-Partition) die Anzahl der verfügbaren(!) Blöcke in der YAFFS2-Partition nicht übersteigen.

Da nun mal in einem NAND-Flash auch defekte Blöcke vollkommen normal sind, ist es auch schwer, eine feste Größe für den max. Umfang der Daten festzulegen, erst recht dann, wenn das sogar (inzwischen eben wieder, nachdem es lange ein ext2-Image war) noch einmal als SquashFS-Image gepackt ist.

Wenn man hier eine Obergrenze für Warnungen festlegen wollte, sollte man (meine Meinung) prophylaktisch schon mal 5% von der maximalen Kapazität der Partition abziehen, denn neben der reinen Summe der Dateigrößen braucht es eben auch noch Platz für Verwaltung (Inodes, etc.) und es können defekte Blöcke existieren, die nicht genutzt werden können.

Eine "echte" Berechnung braucht also deutlich mehr Aufwand, als nur den Vergleich mit den 48 MB, die die Partition selbst im NAND-Flash belegt - bis hin zur Angabe, wieviele defekte Blöcke in der Zielpartition vorhanden sind und das kann auch noch je nach Slot (linux_fs_start) unterschiedlich sein, so daß man für eine exakte(!) Prüfung sogar wissen müßte, in welchem Partition-Set das am Ende landen soll.

Der Kernel interessiert dabei gar nicht, der hat ja seine eigene Partition.

Man knallt einfach nicht seine eigenen Images für eine VR9-Box (und eigentlich für alle Modelle mit NAND-Flash und ohne eigenes "bad block management" - dazu zählt eMMC also ausdrücklich nicht) bis zur max. denkbaren, theoretischen Größe zu und versucht, da jedes freie Byte (bzw. jeden freien Block) herauszuquetschen … eine ganz alte Weisheit bei der Verwendung von Freetz und Nachfolgern.

Auch AVM läßt i.d.R. genug Platz, damit auch Boxen mit mehreren defekten NAND-Blöcken (in den Adressen für die Dateisystem-Partitionen) noch funktionieren (oder die neue Firmware läßt sich dann eben gar nicht flashen, wie das bei Dir ja auch der Fall war und auch dann bleibt das Gerät zumindest funktionsfähig).

EDIT: Ein fehlendes "nicht" hat meine eigentliche Aussage total verdreht - ich habe es ergänzt und fett markiert.
 
Zuletzt bearbeitet:
Das ohne Kernel ist mir nun klar. Der Rest glaube und hoffe ich auch :D

Ich hatte die unkomprimierte Grösse genutzt
Code: 
du -s build/modified/filesystem.outer/
47660   build/modified/filesystem.outer/

und im Log
Code: 
uncompressed filesystem size (47602.80 Kbytes)

Theoretisch sind also noch fast 1,5mb frei (abzüglich der Dinge die du noch aufgezählt hast) in den 48mb - aber praktisch konnten meine 46,5mb nicht geschrieben werden.

5% hört sich viel and, aber von 48mb sind 95% 45,6mb was schon wieder sehr nahe an meiner filesystem-Grenze ist.
Diese 5% hatte ich auch schon in den Kommentaren im Quellcode gesehen und mich gewundert. Ich muss mal suchen.
Vielleicht sollte man pro Lebensjahr 1% abziehen, das wären schon 10% bei meiner 7490

Eine "[ifx_hsnand_command] read block is critical" Zeile hatte ich auch, siehe oben

----------

Im Kernel-Quellcode in sources/kernel/kgw/scripts/add-file-helper/link_and_print_symbols.sh steht
Code: 
    base_offset=$((0x60000))
    kernel_len=$(( (kernel_len / 256 + 1 ) * 256 ))
    est_fs_size="$(tar -cJf - "${GU_FILESYSTEM}" | wc --bytes)"

    ## We reserve 120% estimated size + 256K for the FS
    est_fs_size=$((est_fs_size / 3 +  est_fs_size))
    est_fs_size=$((est_fs_size + 0x40000))
    ram_start=$((kernel_len + est_fs_size + base_offset))
    ram_start=$(( (ram_start / 4096 + 1 ) * 4096 ))

    # TODO: Use Produkt.init Variable to adjust ram size
    ram_size=$((128 * 1024 * 1024))

Auch sieht man das Padding auf 256 bzw 4096 bytes
So kam ich auf den Trichter dass Kernel und Filesystem in einer Partition sind
 
Zuletzt bearbeitet:
Und ich hatte da tatsächlich ein "nicht" zuwenig im Text - vermutlich hatte ich das "nicht" in Bezug zum eMMC noch im Kopf und habe daher ein weiteres "nicht" einfach unterschlagen, das ich nun - aber weiter vorne im Satz - oben ergänzt habe.

Also: NICHT den Platz bis zum letzten Block ausreizen - es gibt andere Mechanismen, zu große Pakete auszulagern, wenn man sie unbedingt haben will.
 
Und ich hatte die "5" verdreht. AVM macht nicht 5% dazu sondern 1/5
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Zurzeit aktive Besucher

Gesamt: 501 (Mitglieder: 22, Gäste: 479)

Statistik des Forums

Themen
247,842
Beiträge
2,274,785
Mitglieder
376,858
Neuestes Mitglied
Hilbth

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten