suchende

Members
  • Content Count

    9
  • Joined

About suchende

  • Rank
    Newbie

Recent Profile Visitors

370 profile views
  1. Thank you very much. I fixed it with a different approach in while. Take all necessary files in /boot and /lib/modules and copy them. Save the mbr and partition table with fdisk to a file, then copy straight with the dd if=/dev/mmcblk0 of=/dev/sdc bs=512 count=8192 and restore afterwards the saved fdisk dump. I forget to mentioned it here: the SoC is the odroid HC1.
  2. the dump from fdisk: p device Boot begin end sectors size Kn typ /dev/mmcblk0p1 8192 30396575 30388384 14,5G 83 Linux F beginn end sectors size 2048 8191 6144 3M 30398464 30703615 305152 149M the raw copy with `dd if=/dev/mmcblk0 of=/dev/sdc skip=2048 seek=2048 bs=512 count=6144 conv=notrunc` fails. Did you meant byte #8192 or sector? the kernel modules are still there.
  3. I made a kernel upgrade which was not successful The kernel does not boot up. Unfortunately armbian does not contain a fallback method to load the old kernel. Therefore I need a way to restore the old kernel. I copied a working boot folder from another sdcard which does not work. What did I miss?
  4. So far Kernel 4.14.20 worked for me. (I need however a way to restore it on to the sdcard)
  5. Usually I compile the kernel on my own because I need apparmor. The current 4.14.29 fails with this log. I tried it again with the Debian stretch next nightly. However this leads to the same: Blue and green LEDs get off and that's it. And a little bit offtopic: How do I fix a broken kernel...
  6. I remember this problem with the cubietruck an the armbian 4.9 kernel. With a self compiled 4.10 kernel it works. The same problem occurs with the odroid hc1. The self compiled 4.14 kernel works flawless.
  7. Try the other USB port. It sounds funny, but at my cubietruck it works at least for a 2.5" external drives.
  8. Hey, I compiled and installed the latest kernel (4.7.3 and uboot 2016-09) but something went wrong. The dtb file was missing. while a manually correct the missing dtb from another run a flashed uboot in the wrong way. Instead of using the drive /dev/sdc I used the partition /dev/sdc1. I read this: https://linux-sunxi.org/Bootable_SD_card#SD_Card_Layoutand with these two commands I should have erased the first 1Mb dd if=/dev/zero of=/dev/sdc1 bs=1k count=1023 seek=1 dd if=u-boot-sunxi-with-spl.bin of=/dev/sdc1 bs=1024 seek=8 (Luckily there is no backup at all ) gpart gives me this: gpart -vg /mnt/veracrypt1/Armbian_5.14_Cubietruck_Debian_jessie_4.6.2.raw dev(/mnt/veracrypt1/Armbian_5.14_Cubietruck_Debian_jessie_4.6.2.raw) mss(512) Primary partition(1) type: 131(0x83)(Linux ext2 filesystem) size: 1525mb #s(3123200) s(2048-3125247) chs: (16/0/1)-(1023/3/32)d (0/0/0)-(0/0/0)r hex: 00 00 01 10 83 03 E0 FF 00 08 00 00 00 A8 2F 00 ---------------------------------------------------------------------------------------- gpart -vg /mnt/veracrypt1/broken_cubietruck.img dev(/mnt/veracrypt1/broken_cubietruck.img) mss(512) Primary partition(1) type: 131(0x83)(Linux ext2 filesystem) size: 14991mb #s(30701568) s(2048-30703615) chs: (0/56/33)-(913/88/8)d (0/0/0)-(0/0/0)r hex: 00 38 21 00 83 58 C8 91 00 08 00 00 00 78 D4 01 I try to use the values from the raw image to recover at least some data, but fsch.ext4 fails. Do you see an opportunity to restore the partition table? Or to recover the filesystem? Edit: Topic can be deleted. I wasn't capable of restoring the filesystem.
  9. suchende

    AppArmor

    I tried to used AppArmor under the Linux cubietruck 4.4.1-sunxi #10 SMP Wed Feb 17 17:57:20 CET 2016 armv7l GNU/Linux. But I get a kernel panic after i rebooted the system. Some questions: 1. Did you integrate AppArmor into the kernel? 2. Did you use an alternative mandatory access control? 3. Need I an additional kernel argument in the /boot/boot.cmd other than these "apparmor=1 security=apparmor"? 4. Is there a major diffenrece between your kernel and that from danad.de? Unluckily I was not capable of getting a dump from the kernel panic. If you need it, I would take a photo.