Mailinglist Archive: opensuse-arm (86 mails)

< Previous Next >
Re: [opensuse-arm] JeOS-2017-03-13 image for RPi 1 installs OK, Grub fails on reboot


On 27/03/2017 23:15, Alex Armstrong wrote:
Alexander Graf wrote:
Hi Alex,

On 23/03/2017 20:48, Alex Armstrong wrote:
Greetings,

I was testing:
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2017.03.13-Build1.8.raw.xz


from:
http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/images/


On RaspberryPi 1 Model B
It installs fine - expands the file system, creates the dracut based
init and boots to a usable system. But when I reboot, grub fails with:
error: attempt to read or write outside of partition.

This sounds like the repartitioning failed.

and drops me to the grub rescue system.
Poking around the rescue system, I've found that I can see 4 partitions,
one which is ext2 and has the normal Linux files. From here, most of

Can you also see the size? IIRC you see partition information with

(grub) ls (hd0)
No, using ls (hd0,gpt*), for all but the second partition grub returns:
Filesystem is unknown.

For the second partition, grub tells me that it is ext2, but no other
details.
the recovery guides say to set the root and prefix variables and then
load the normal module. I can execute the commands:
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub2

and list the files in the various directories - normal.mod exists in
/boot/grub2/arm-efi/ - but when I try:
insmod normal

I still get the error: attempt to read or write outside of partition.
Somewhat interestingly, if I miss-type the prefix (say; /boot/grub) the
error changes to a "file not found" one.

I was hoping someone might have some ideas about what to try next.

One thing you could try is check on a working system what the
partition table and file system look like. It almost sounds like the
ext4 partition got resized, but the partition table is still on the
old, small size.


Alex
Thanks for mentioning that, I took a look at the SD card with parted
and here's what I found:

Model: Generic- Multi-Card (scsi)
Disk /dev/sdb: 7948MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr

Number Start End Size File system Name Flags
1 1049kB 211MB 210MB fat16 UEFI boot
2 212MB 430MB 218MB ext4 lxboot
3 431MB 7427MB 6996MB lxroot
4 7428MB 7948MB 520MB linux-swap(v1) lxswap

I think you're right - the resizing didn't work as expected. I saw
the success message in the log and didn't think to check it further.

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.

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
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-arm+owner@xxxxxxxxxxxx

< Previous Next >