Alexander Graf wrote: > The partition table looks pretty sane to me. You have an 8GB disk and > / is properly expanded to 7GB. > >> Additionally when I try to mount partition 2, it fails with this >> message: >> EXT4-fs (sdb2): bad geometry: block count 1761625 exceeds size of >> device (53248 blocks) > > Ok, so something really is broken there ;). Good. > > It looks like your block size is 4kb (default size for ext4 IIRC). > 53248 blocks translate to 218MB (with 1000 bytes as kbyte) while > 1761625 blocks would be 7215MB. > > If I had to guess, I'd say someone dropped the requirement for a > separate boot partition but forgot to update the partitioning script > in the JeOS package. > > If I'm right, /dev/sdb3 should not contain a valid file system. Correct - no filesystem there. > > In that case, can you manually try to fix it up for now? Remove > partitions 2 and 3. Then create a new partition from beginning of > current partition 2 until end of partition 3. Switch to unit type > sector (unit s I think in parted) to make sure they really are aligned. > > Then try to mount that new partition. Does it work? If so, does it boot? > > > Alex Removing both partitions 2 & 3 and then creating a new one fixes the mounting problem. But it doesn't boot - I may not have the correct flags, as the RPi doesn't show anything at all after power on. The other thing that occurs to me is that parted might not write a hybrid partition table that the Pi can boot.
----- Testing the image from: http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ yields different results. In summary, it seems that the partition table is not completely written - leaving some entries from the previous table around and leading to much confusion at boot time. I noticed a few errors in the initial boot messages, but nothing that stopped it from completing start up. Hopefully I'm missing something obvious. ----- Below are my troubleshooting steps. ### First Try: The very first time I tried the image, it gave me a working system that rebooted to a working system. But it had trouble finding the swap partition, so I (foolishly) took the SD card out and inspected it with parted on a separate machine. I saw that the swap partition was still #4 (as it had been from the previous tests) and so I changed the 4 to a 3 and wrote the changes. After I did that it wouldn't boot at all. ### Second Try: It boots to a working system, but reboot fails to even bring up the boot loader. No u-boot, grub, etc. I'm working thru a serial terminal at the moment, so would expect to see something. When I inspect the SD card on a different computer, I get this: GPT fdisk (gdisk) version 0.8.7 Type device filename, or press <Enter> to exit: /dev/sdb Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. and then trying to list the partitions: Command (? for help): p Disk /dev/sdb: 15523840 sectors, 7.4 GiB Logical sector size: 512 bytes Disk identifier (GUID): 100CFB37-F6C4-48FF-B891-09C49CAB0A5F Partition table holds up to 128 entries First usable sector is 34, last usable sector is 15523806 Partitions will be aligned on 2048-sector boundaries Total free space is 15523773 sectors (7.4 GiB) Number Start (sector) End (sector) Size Code Name Noting at all in the GPT table. Which doesn't seem right. The MBR table shows one partition: Expert command (? for help): o Disk size is 15523840 sectors (7.4 GiB) MBR disk identifier: 0x00000000 MBR partitions: Number Boot Start Sector End Sector Status Code 1 1 15523839 primary 0xEE Which apparently takes up the entire disk. ### Third Try: Now, I'm using the same SD card for all of this, and the partition table has been written a number of times. So, thinking the card might be going bad, I formatted it with YaST - 3 partitions in a similar way to what the RPi wants: fat, ext4 and swap. That went OK and I was able to mount the partitions fine. Next I dd'ed the image back onto the card and tried again. This time it rebooted to a fully functional grub - not just the rescue system. But complained: error: no such device: ce7e3539... I could list the various partitions and the first (fat) one showed the expected RPi files. But the other two gave an error: No known filesystem detected - Partitions start at 217099KiB - Total size 7289184KiB And wouldn't show any files. The interesting thing is that, on inspection, the partition table entries were exactly the same size as I had written with YaST. And I would expect them to slightly different (I'm not that good). So, seemingly it doesn't write a the partition table at all, and your left with whatever was there to begin with. So the first time I did it I had a valid setup from before and it worked - but not the swap. And the rest of the times it wasn't even close. ### Fourth Try: Next I tried reformatting the card as full FAT partition - then dding image and testing. After it did it's initial boot, it rebooted to the full grub environment. Inspecting the SD card partition table with gdisk give me this: GPT fdisk (gdisk) version 0.8.7 Partition table scan: MBR: hybrid BSD: not present APM: not present GPT: present Found valid GPT with hybrid MBR; using GPT. Command (? for help): p Disk /dev/sdb: 15523840 sectors, 7.4 GiB Logical sector size: 512 bytes Disk identifier (GUID): 100CFB37-F6C4-48FF-B891-09C49CAB0A5F Partition table holds up to 128 entries First usable sector is 34, last usable sector is 15523806 Partitions will be aligned on 2048-sector boundaries Total free space is 4029 sectors (2.0 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 15521791 7.4 GiB 0700 primary So there is one GPT table entry. And looking at the MBR table: Expert command (? for help): o Disk size is 15523840 sectors (7.4 GiB) MBR disk identifier: 0x00000000 MBR partitions: Number Boot Start Sector End Sector Status Code 1 2048 15521791 primary 0x0C 2 1 2047 primary 0xEE 4 15521792 15523839 primary 0x83 Note that the GPT entry is the same as I crated for the initial FAT partition. The three MBR entries are new though. ### And the initial boot error messages: skiped writing MBR ID for armv6l GPT fdisk (gdisk) version 1.0.1 Caution! After loading partitions, the CRC doesn't check out! Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: damaged Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.) ... Recovery/transformation command (? for help): Warning! Mismatched GPT and MBR partition! MBR partition 4, of type 0x83, has no corresponding GPT partition! You may continue, but this condition might cause data loss in the future! Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! My next thoughts are to try, in the initial running system, somehow writing the partition table. Seemingly difficult in a running system, so it'll have to wait till tomorrow. -Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
