No boot
Closed this issue · 11 comments
I had my LS220D work with Debian 9, and did a successful upgrade to Buster. For some reasons I have to downgrade to Stretch.
Removing everything on the boot partition and put Stretch initrd and uImage onto it didn't work (white LED blinking fast for a minute and then the red LED flashing 7 time)
So I ran everything again from the beggining :
Erasing the drive, creating the partitionning system (fdisk g) and creating a 1Gb ext3 (with -I 128) partition but it still doesn't boot (7 red flash again)
Do you have any idea of what am I doing wrong ?
7 flashes typically means it can't find/read the boot partition. Could you print out what your partitions look like in fdisk/gdisk?
Is this the only disk you are using?
The other disk is totally blank, and I boot with only one, I insert the second disk when the installer is detecting hardware (already worked for my first installation)
If the other disk isn’t there when you get the 7 blinks then it isn’t the problem. The partition size and number looks good.
I think that’s showing me that you’re using a valid gpt partition table, you can verify by opening the disk in gdisk which starts by checking the table. If the secondary gpt table shows as damaged it would explain the issue you’re seeing. If so gdisk will fix it it you write the table again.
if that’s not it then something about the filesystem would be my next guess. Could you mount it and show me the contents of the filesystem with ls?
That looks right, what’s the output of:
mount | grep nas2
It says ext3, rw, realtime
Can you post the output of gdisk where is it shows the status of the gpt headers?
I was partitionning with fdisk under a very light Debian (only console and no internet), and I just did exactly the same procedure with gdisk under Fedora Workstation and it works !
May be a default parameter wich isn't the same
a problem that comes up pretty frequently is folks have a GPT partitioned disk then re-create the partition table as MBR. A lot of tools will not wipe the backup GPT header when they create the new MBR. U-boot will see the mismatch between the MBR and the backup GPT table and refuse to use the disk. I think that's what happened here.
The main way I avoid this is just always using gdisk when I want to wipe out a table.