Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck on sfdisk step of mk-sd-image script #34

Closed
0ena opened this issue Jun 14, 2021 · 9 comments
Closed

Stuck on sfdisk step of mk-sd-image script #34

0ena opened this issue Jun 14, 2021 · 9 comments

Comments

@0ena
Copy link

0ena commented Jun 14, 2021

Hi Eugene,

first of all congratulations on the massive work done in this repository. I was really glad when you posted this repo in the thread I had opened inside Xilinx's forum about RISC-V implementations.

I have a Genesys II board and I finally have time to start working with the designs provided in this repo too.
Unfortunately my current set-up is on a Centos 7 machine.
I believe I have solved all of the dependencies with respect to successfully generating a memory configuration file (genesys2-riscv.mcs) and a bitstream (riscv_wrapper.bit) for my board.

But I am having problems with generating and copying the Linux image on the SD card. I am running the ./mk-sd-card command to create the image on the SD card. I am facing a problem with the following lines in the mk-sd-image file:

sudo sfdisk --no-tell-kernel ${SD_LOOP} <<-__EOF__
1M,400M,0xE,*
,,,-
__EOF__

The script aborts with the following output:

SD image device: 
sfdisk: unrecognized option '--no-tell-kernel'

Searching about this, it has to do with fdisk being an older version than the one you are using to build inside Ubuntu.
The version inside Centos 7 doesn't support the --no-tell-kernel option.

If I try to omit the --no-tell-kernel option from the command, the script aborts with the following:

SD image device: 

Usage:
 sfdisk [options] <device> [...]

I have seen in #23 , that I should be getting at this point probably something like the following:

SD image device: /dev/loop#

So for whatever reason, the lines 38-64 do not seem to work in Centos, in terms of creating (?) the /dev/loop# :

mount -l | grep `pwd`/ | while IFS=' ' read -ra LINE ; do
  sudo umount ${LINE[0]}
done
losetup -a | grep `pwd`/ | while IFS=':' read -ra LINE ; do
  sudo losetup -d ${LINE[0]}
done
losetup -a | grep `pwd`/ | while IFS=':' read -ra LINE ; do
  echo "Cannot detach ${LINE[*]}"
  exit 1
done

rm -f $SD_IMG
dd if=/dev/zero of=$SD_IMG bs=1M count=$SD_SIZE
sudo losetup -f $SD_IMG

SD_LOOP=$(
losetup -a | grep `pwd`/ | while IFS=':' read -ra LINE ; do
  echo ${LINE[0]}
done
)

echo "SD image device: ${SD_LOOP}"

##sudo sfdisk --no-tell-kernel ${SD_LOOP} <<-__EOF__
sudo sfdisk ${SD_LOOP} <<-__EOF__
1M,400M,0xE,*
,,,-
__EOF__

When I am running the command losetup -a, I get the following output:

[user1@nassos2 vivado-risc-v]$ losetup -a
/dev/loop0: []: (/path/xilinx_riscv/vivado-risc-v/debian-riscv64/debian-riscv64.sd.img (deleted))
/dev/loop1: []: (/path/xilinx_riscv/vivado-risc-v/debian-riscv64/debian-riscv64.sd.img (deleted))
/dev/loop2: []: (/path/xilinx_riscv/vivado-risc-v/debian-riscv64/debian-riscv64.sd.img)

I am using CentOS Linux release 7.9.2009 (Core).

Any ideas on how to overcome this issue and be able to create the image in the SD card, would be really helpful!

Thank you in advance for your response and time!
Feel free to ask if more information are needed.

Kind regards,
Nassos

P.S. I tried installing a newer version of the fdisk in Centos, but with no success due to several dependency issues.

@0ena
Copy link
Author

0ena commented Jun 14, 2021

EDIT: thread updated

@eugene-tarassov
Copy link
Owner

The script fails to match working directory path to /dev/loopX device.
I think the problem is your working directory path contains a symbolic link.
At the beginning of the scrip, try to change
cd `dirname $0`
to
cd -P `dirname $0`

@0ena
Copy link
Author

0ena commented Jun 15, 2021

Good catch!
Indeed my working directory path contains a sym-link.
I changed this command in both the mk-sd-card and mk-sd-image scripts and was able to move on but not for long.
Now I am facing the following issue:

1500+0 records in
1500+0 records out
1572864000 bytes (1.6 GB) copied, 0.35178 s, 4.5 GB/s
SD image device: /dev/loop0
sfdisk: Disk /dev/loop0: cannot get geometry


Disk /dev/loop0: 191 cylinders, 255 heads, 63 sectors/track
sfdisk:  /dev/loop0: unrecognized partition table type

Old situation:
sfdisk: No partitions found

sfdisk: trailing junk after number

sfdisk: bad input

I will search why I get an unrecognized partition table type about my /dev/loop0 and try to solve it.
If in the mean time you have an idea why this might be happening feel free to comment.

Thank you very much again.

Kind regards,
Nassos

@eugene-tarassov
Copy link
Owner

I changed this command in both the mk-sd-card and mk-sd-image scripts and was able to move on

I'll make changes in the repo.

Now I am facing the following issue

The error, "sfdisk: trailing junk after number", is about these two lines:

1M,400M,0xE,*
,,,-

I see nothing wrong with the lines.
Perhaps, Centos 7 sfdisk does not like the bootable flag, which is not really needed, so the script can be changed to:

1M,400M,0xE
,,

@0ena
Copy link
Author

0ena commented Jun 16, 2021

Hmmm the

1M,400M,0xE
,,

didn't work. But I just tried

0xE
,,

and the script was able to proceed.

So apparently there is a problem with the M characters?
Would it be good if I make the following change?

1000000,400000000,0xE
,,

EDIT:
The last one doesn't work either, as I get the following:

1500+0 records in
1500+0 records out
1572864000 bytes (1.6 GB) copied, 0.349024 s, 4.5 GB/s
SD image device: /dev/loop0
Checking that no-one is using this disk right now ...
BLKRRPART: Invalid argument
OK
sfdisk: Disk /dev/loop0: cannot get geometry


Disk /dev/loop0: 191 cylinders, 255 heads, 63 sectors/track
sfdisk:  /dev/loop0: unrecognized partition table type

Old situation:
sfdisk: No partitions found

Warning: given size (400000000) exceeds max allowable size (0)
sfdisk: bad input

@0ena
Copy link
Author

0ena commented Jun 16, 2021

And from what I see the 1M and 400M must be the partitions(?) because when I reach the tar step, I get messages about not having enough space on the device:

make: `debian-riscv64/initrd' is up to date.
make: `debian-riscv64/rootfs.tar.gz' is up to date.
1500+0 records in
1500+0 records out
1572864000 bytes (1.6 GB) copied, 0.356968 s, 4.4 GB/s
SD image device: /dev/loop0
Checking that no-one is using this disk right now ...
BLKRRPART: Invalid argument
OK
sfdisk: Disk /dev/loop0: cannot get geometry

sfdisk:  /dev/loop0: unrecognized partition table type

sfdisk: No partitions found


Disk /dev/loop0: 191 cylinders, 255 heads, 63 sectors/track
Old situation:
New situation:
Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/loop0p1         14     190     177    1421752+  83  Linux
/dev/loop0p2          0+     13      14-    112454+  83  Linux
/dev/loop0p3          0       -       0          0    0  Empty
/dev/loop0p4          0       -       0          0    0  Empty
Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
Successfully wrote the new partition table

BLKRRPART: Invalid argument
Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
mkfs.fat 3.0.20 (12 Jun 2013)
unable to get drive geometry, using default 255/63
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=rootfs
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
28224 inodes, 112452 blocks
5622 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=33685504
14 block groups
8192 blocks per group, 8192 fragments per group
2016 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables:  0/14     done
Writing inode tables:  0/14     done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information:  0/14     Hdone

/Projects/Proj/xilinx_riscv/vivado-risc-v/debian-riscv64/rootfs /Projects/Proj/xilinx_riscv/vivado-risc-v
tar: swapfile: Wrote only 3072 of 10240 bytes
tar: sys: Cannot mkdir: No space left on device
tar: tmp: Cannot mkdir: No space left on device
tar: usr: Cannot mkdir: No space left on device
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib: Cannot mkdir: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu: Cannot mkdir: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libapt-private.so.0.0: Cannot create symlink to `libapt-private.so.0.0.0': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libargon2.so.1: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/liblber-2.4.so.2: Cannot create symlink to `liblber-2.4.so.2.11.5': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libattr.so.1.1.2448: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libssl.so.1.1: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libip4tc.so.2.0.0: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libgcrypt.so.20: Cannot create symlink to `libgcrypt.so.20.2.8': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libgnutls.so.30.29.1: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libcbor.so.0: Cannot create symlink to `libcbor.so.0.0.0': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libicutu.so.67.1: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libform.so.6: Cannot create symlink to `libform.so.6.2': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libffi.so.7: Cannot create symlink to `libffi.so.7.1.0': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libunistring.so.2.1.0: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libmagic.so.1: Cannot create symlink to `libmagic.so.1.0.0': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libpanel.so.6.2: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libcrypto.so.1.1: Cannot open: No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libsystemd.so.0: Cannot create symlink to `libsystemd.so.0.30.0': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libmenuw.so.6: Cannot create symlink to `libmenuw.so.6.2': No such file or directory
tar: usr: Cannot mkdir: No space left on device
tar: usr/lib/riscv64-linux-gnu/libldap-2.4.so.2: Cannot create symlink to `libldap_r-2.4.so.2': No such file or directory
...
...
...

@eugene-tarassov
Copy link
Owner

And from what I see the 1M and 400M must be the partitions(?)

No, each line is a partition: start, size, type and flags,
2 partitions: 400MB DOS, and the rest of available space is Linux.

So apparently there is a problem with the M characters?

It is possible that older versions of sfdisk don't recognize M suffix.
Another way to tell sfdisk to interpret numbers as Megabytes is to use -u option:

sudo sfdisk -u M ${SD_LOOP} <<-__EOF__
1,400,0xE,*
,,,-
__EOF__

By default, the numbers are in cylinders, so 400000000 * 8225280 bytes - way too much.

@0ena
Copy link
Author

0ena commented Jun 16, 2021

Yeap, your command did the trick.
I needed also to add the --no-reread flag at each use of sfdisk.

Now the last remaining problem is the use of the 2nd sfidisk inside the mk-sd-card.
Apparently the + in the
echo ", +" | sudo sfdisk --no-reread -N 2 ${DEVICE}
creates the same error about

sfdisk: trailing junk after number

sfdisk: bad input

If I completely omit the +
echo "," | sudo sfdisk --no-reread -N 2 ${DEVICE}

the script seems to finish and I get the following output:

Copy disk image to:

Disk /dev/sdd: 1936 cylinders, 255 heads, 63 sectors/track
Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdd1   *      0+     50      51-    409657    e  W95 FAT16 (LBA)
/dev/sdd2         51     190     140    1124550   83  Linux
/dev/sdd3          0       -       0          0    0  Empty
/dev/sdd4          0       -       0          0    0  Empty
Are you sure? [y/N] y
24000+0 records in
24000+0 records out
1572864000 bytes (1.6 GB) copied, 132.301 s, 11.9 MB/s

Disk /dev/sdd: 1936 cylinders, 255 heads, 63 sectors/track
Old situation:
Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdd1   *      0+     50      51-    409657    e  W95 FAT16 (LBA)
/dev/sdd2         51     190     140    1124550   83  Linux
/dev/sdd3          0       -       0          0    0  Empty
/dev/sdd4          0       -       0          0    0  Empty
New situation:
Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdd1   *      0+     50      51-    409657    e  W95 FAT16 (LBA)
/dev/sdd2         51     190     140    1124550   83  Linux
/dev/sdd3          0       -       0          0    0  Empty
/dev/sdd4          0       -       0          0    0  Empty
Successfully wrote the new partition table

Re-reading the partition table ...
BLKRRPART: Device or resource busy
sfdisk: The command to re-read the partition table failed.
Run partprobe(8), kpartx(8) or reboot your system now,
before using mkfs

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Does the output seem OK to you?

Kind regards,
Nassos

@eugene-tarassov
Copy link
Owner

The output is somewhat OK, the script has copied data to SD card and the card should be usable, but the script failed to extend Linux partition to occupy whole SD card. So, you got SD card with only 1.5GB of usable space regardless of actual card size.

The "+" in the command tells sfdisk to extend partition. It looks like it is not supported by your version of sfdisk. There are other ways to do the same, but I don't know what is supported in Centos 7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants