Ventoy: easy.sfs cp: write error: No space left on device

[measter]

Since the ventoy problem has evolved for me, I'll start a new topic.

From the earlier Ventoy problem thread:

Easy OS wouldn't boot on the current Ventoy release 1.0.74 as described in the ./dax/dax.ko not found thread (I don't know how to link threads).

There are evolutionary dev of Ventoy called 'CI' which I used to up Ventoy to CI #776 which is 05080402. Then Easy was able to try to boot, getting past the dax problem, but the boot failed at:

One-time only operation, creating a snapshot of EasyOS
This will allow future follback with the Easy Version Control Manager
Populating: /mnt/ventoy2/easyos/releases/easy-3.4.7
initrd vmlinux easy.sfs cp: write error: No space left on device
This copy failed:
cp /mnt/ventoy1/easy.sfs /mnt/ventoy2/easyos/sfs/easyos/oe/dunfell/easy_3.4.7_amd64.sfs
It is possible that the drive is failing.
Attempting to copy again...
cp: write error: No space left on device

This is a different problem. It may be useful to someone to know how Ventoy works. It puts a little bitty linux on a USB and then the user can write .iso/s or .img/s or any number of different formats to the USB and the Ventoy boot gives a boot menu to multiboot whatever format has been written there. Here is one page where Ventoy shows how the MBR is fixed

https://www.ventoy.net/en/doc_disk_layout.html
Ventoy Disk Layout In MBR

Maybe Easy is not expecting this type of layout when it is trying to copy easy.sfs. There were gigs of space left on the USB when I was trying to boot Easy.

[measter]

This is one view of the Ventoy USB I'm using, using fdisk:

Model: General USB Flash Disk (scsi)
Disk /dev/sdc: 15.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 15.6GB 15.6GB primary boot
2 15.6GB 15.6GB 33.6MB primary fat16 esp

As you can see, almost the entire stick belongs to the first part where Easy .img and 3 other .iso/s reside.
Here's ls -lh w/ some columns removed:

$ ls -lh
total 9.3G
1.9G Fedora-Workstation-Live-x86_64-36-1.5.iso
1.3G easy-3.4.7-amd64.img
3.5G kubuntu-22.04-desktop-amd64.iso
2.8G ubuntu-mate-22.04-desktop-amd64.iso

As you can see, the use of 9.3G by the distro/s incl Easy should provide enough space if Easy wants to write something on the usb.

[measter]

I tried a different boot method and got a different error.

I don't remember the exact words of the boot option, but it was to copy easy to ram & disable drives

Boot-partition: ventoy1 Working-partition: ventoy2
Copying easy.sfs to ram, then mounting
mount: mounting /dev/loop0 on /easy_ro/easy_sfs failed: Invalid argument
Error: failed to mount easy.sfs

I get that same error if I try the boot option to copy to ram and unmount the partitions

[measter]

This is a continuation of the same Ventoy problem, now w/ a different stick, more room, different Easy 3.4.5

One-time only operation, creating a snapshot of EasyOS
This will allow future follback with the Easy Version Control Manager
Populating: /mnt/ventoy2/easyos/releases/easy-3.4.5
initrd vmlinux easy.sfs cp: write error: No space left on device
This copy failed:
cp /mnt/ventoy1/easy.sfs /mnt/ventoy2/easyos/sfs/easyos/oe/dunfell/easy_3.4.5_amd64.sfs
It is possible that the drive is failing.
Attempting to copy again...
cp: write error: No space left on device

Now the different 16G stick reported as 14.56GiB has only 3.4G used:
<columns removed>
$ ls -lh
total 3.4G
1.3G easy-3.4.5-amd64.img
2.1G linuxmint-20.3-mate-64bit.iso

I think there is something incompatible between how Ventoy constructs the partition that Easy does properly recognize. Also; is it possible to choose a boot option that doesn't require the step of creating the snapshot that tries to write to the Ventoy2?

[jan]

The error you see is very logical.
As easy is made to write to a partition on an usb drive that is grown at first start.
The initial partition in the .img file is very small and easy is not made to grow the image file .
You could make the image bigger ( something like dd if=/dev/zero bs=1M count=2048 >> easy-3.4.7-amd64.img )
Then I think easy would be able to grow the partition in the image and run!

[measter]

The error you see is very logical.
As easy is made to write to a partition on an usb drive that is grown at first start.
The initial partition in the .img file is very small and easy is not made to grow the image file .
You could make the image bigger ( something like dd if=/dev/zero bs=1M count=2048 >> easy-3.4.7-amd64.img )
Then I think easy would be able to grow the partition in the image and run!

I'm not understanding.

I have a 4G USB stick that I wrote Easy 3.4.7 to w/ Win Etcher. That works just fine So, Easy is able to do whatever it needs to do on that little stick.

The problem seems to be that on a stick w/ even more 'spare room', the 16G Ventoy stick, Easy can't find a place to do whatever it does.

[measter]

I have a 4G USB stick that I wrote Easy 3.4.7 to w/ Win Etcher. That works just fine So, Easy is able to do whatever it needs to do on that little stick.

The problem seems to be that on a stick w/ even more 'spare room', the 16G Ventoy stick, Easy can't find a place to do whatever it does.

However, the difference is that when Etcher writes the .img to the USB, the filestructure of Easy is restored/created; but when I provide the .img file to the Ventoy USB, it is simply 'copied' as an .img file, like a data file; it is not de-archived/expanded.

[measter]

It may be useful to someone to know how Ventoy works. It puts a little bitty linux on a USB and then the user can write .iso/s or .img/s or any number of different formats to the USB and the Ventoy boot gives a boot menu to multiboot whatever format has been written there. Here is one page where Ventoy shows how the MBR is fixed

https://www.ventoy.net/en/doc_disk_layout.html
Ventoy Disk Layout In MBR

Maybe Easy is not expecting this type of layout when it is trying to copy easy.sfs. There were gigs of space left on the USB when I was trying to boot Easy.

Ventoy also has a plugin function by which it can enable persistence for certain supported distro/s. I'm thinking that maybe if I learn how to use Ventoy's persistence plugin and provide some of that persistence function for the Easy .img, that Easy will somehow be able to use that persistence space to do whatever it is trying to do about writing the easy.sfs onto the Ventoy. Except that I don't believe that Easy does its persistence in the same way as Ubuntu or Mint. I just don't know how to help Easy find the available space on the Ventoy USB.

Ventoy is pretty slick about how it enables the .json plugins by giving the user a web interface to configure it; I find that very useful compared to editing a .json file which I know nothing about.

[Clarity]

EASY will NOT boot via Ventoy; as EASY is not constructed as no other distro. Its architecture is not one that these ISO-IMG booters understand. EASY has an initial REQUIREMENT that it expects.

Hope that makes sense. Barry has explained EASY architecture before and if you read it, you can understand 'why' the booting process is not going to work with its image file via Ventoy.

I will not try this idea, but, you can try:

1. Try moving the image file to your system drive

2. create a VLINK file and place it on your USB stick.

3. Select the VLNK when booting to see if this fools EASY enough to allow it to proceed

4. Report back here success/failure

Hope this instruction is clear and allows you to achieve the objectives you want for your USB stick's ISO & IMG files.

P.S. Keep ALL ISO & IMG files in a folder on your USB named "BOOTISOS"...ie. /BOOTISOS. Dont worry, VENTOY is smart enough to locate them on your USB,

[jan]

I'm not understanding.

I have a 4G USB stick that I wrote Easy 3.4.7 to w/ Win Etcher. That works just fine So, Easy is able to do whatever it needs to do on that little stick.

The problem seems to be that on a stick w/ even more 'spare room', the 16G Ventoy stick, Easy can't find a place to do whatever it does.

ventoy is MOUNTING the image and then booting (so a virtual usb stick ).
That virtual stick is in case of easy-3.4.7-amd64.img 1,3G and will not grow (as ventory and easy is not made for that).
If you make the image itself bigger by say 2G before first boot , then easy can grow the second partition by 2G and have space to copy the sfs file.

If you would make an image of the install on the 4G usb stick and write to the stick with ventoy , i think it will work to.

As ex-planed ventory provides only the space available IN THE IMAGE to easy!!

[BarryK]

At first bootup, Easy will copy easy.sfs from the boot-partition to the working-partition, after having resized the working-partition to the free space on the drive.

Easy will only expand the working-partition if it is exact size 640MiB or 4MiB, and starts at a certain exact number of blocks from the start of the image.

As advised above, you can prevent Easy trying to resize the working-partition, and make enough room to copy easy.sfs, by increasing the size of the working-partition in the image file.

That can be done from the commandline, using fdisk; however, the easiest way is just to dd the img file to a usb-stick, then run gparted to increase the size of the second ext4 partition, then dd it back. Like this, where the usb-stick is /dev/sdc:

Code: Select all

# gunzip easy-3.4.7-amd64.img
# dd if=easy-3.4.7-amd64.img of=/dev/sdc bs=1M
# sync
# gparted /dev/sdc
...resize 2nd partition, make a note of the total new size
# sync
# dd if=/dev/sdc of=easy-3.4.7-bigger-amd64.img bs=1M count=<size in MiB>
# sync

[BarryK]

If you want to do it without writing the img file to a usb-stick... more complicated, it is going to tax my brain right now. let's see...

Increase the file to 2G, then increase the second partition to fill the img file:

Code: Select all

# truncate -s 2G easy-3.4.7-amd64.img 
# WKG_PARTNUM=2
# Wstart=1310720
# echo -e "d\n${WKG_PARTNUM}\nn\np\n${WKG_PARTNUM}\n${Wstart}\n\nw" | fdisk -u easy-3.4.7-amd64.img

...That 1310720 is the offset in the img file, in sectors, where the 2nd partition starts. For Easy Bookworm 0.1, the offset is 1572864

Although the 2nd partition has been increased, the ext4 f.s. has not. That has to be resized to fill the partition...

Code: Select all

# LOOPDEV="$(losetup -f)"
# echo $LOOPDEV
/dev/loop3
# losetup -o 671088640 $LOOPDEV easy-3.4.7-amd64.img 
# resize2fs -f $LOOPDEV
# sync
# umount $LOOPDEV

...that 671088640 is 1310720*512, where 512 is the sector size.

That should do it.

If you want to see for yourself the offsets of start of each partition:

Code: Select all

# fdisk -u -l easy-3.4.7-amd64.img
....
Device                          Boot   Start     End Sectors  Size Id Type
easy-3.4.7-amd64.img1 *       2048 1310719 1308672  639M ef EFI (FAT-1
easy-3.4.7-amd64.img2      1310720 4194303 2883584  1.4G 83 Linux

[measter]

Thanks for the replies by Clarity & jan

For the time being, I'm just going to use the Easy 3.4.7 I have on the independent USB, not on the Ventoy multiboot USB. I'm carrying on my 'campaign' on the Ventoy forum in the Ventoy forum thread that solved the dax problem w/ the ventoy CI tweak. Ventoy currently thinks the Easy problem is solved, but it is not; I'm addressing that.

[measter]

Thanks for the replies by Clarity & jan

Oops. When I was thanking Clarity & jan, I was 'missing' BarryK's input on the next page. Thanks much BarryK.

For the time being, I'm just going to use the Easy 3.4.7 I have on the independent USB, not on the Ventoy multiboot USB. I'm carrying on my 'campaign' on the Ventoy forum in the Ventoy forum thread that solved the dax problem w/ the ventoy CI tweak. Ventoy currently thinks the Easy problem is solved, but it is not; I'm addressing that.

But I'm still going to 'correct' some misunderstandings at the Ventoy site and forum.

[Clarity]

No offense to either @measter and certainly NOT @BarryK: BUT, shouldn't Barry be the one addressing this. You may want to confer privately with him on this as it does affect his distro's design...this is not a Ventoy problem as I review this; even though I fully recognize that community's willingness to help. This appears to be more of the uniqueness of EASY's design for how Barry wants it implemented for user consumption. "Barry knows best."

FWIW

[measter]

No offense to either @measter and certainly NOT @BarryK: BUT, shouldn't Barry be the one addressing this. You may want to confer privately with him on this as it does affect his distro's design...this is not a Ventoy problem as I review this; even though I fully recognize that community's willingness to help. This appears to be more of the uniqueness of EASY's design for how Barry wants it implemented for user consumption. "Barry knows best."

FWIW

Part of the reason I'm posting about this in the ventoy forum is to correct some misinformation there. Ventoy has a high success rate, but it isn't 100% and there is a table which lists those distro/s which don't work along w/ those which do.

https://www.ventoy.net/en/distrowatch.html

Easy doesn't, as is. I might like to tweak an .img file. Currently I have a copy parked in a dir on a hdd; my preference would be to open it there and tweak it and then write it back to a big .img, but I don't know how to adjust the commands BarryK provided for the usb strategy to a hdd dir.

[measter]

If you want to do it without writing the img file to a usb-stick... more complicated, it is going to tax my brain right now. let's see...

Increase the file to 2G, then increase the second partition to fill the img file:

Code: Select all

# truncate -s 2G easy-3.4.7-amd64.img 
# WKG_PARTNUM=2
# Wstart=1310720
# echo -e "d\n${WKG_PARTNUM}\nn\np\n${WKG_PARTNUM}\n${Wstart}\n\nw" | fdisk -u easy-3.4.7-amd64.img

...That 1310720 is the offset in the img file, in sectors, where the 2nd partition starts. For Easy Bookworm 0.1, the offset is 1572864

Although the 2nd partition has been increased, the ext4 f.s. has not. That has to be resized to fill the partition...

Code: Select all

# LOOPDEV="$(losetup -f)"
# echo $LOOPDEV
/dev/loop3
# losetup -o 671088640 $LOOPDEV easy-3.4.7-amd64.img 
# resize2fs -f $LOOPDEV
# sync
# umount $LOOPDEV

...that 671088640 is 1310720*512, where 512 is the sector size.

That should do it.

If you want to see for yourself the offsets of start of each partition:

Code: Select all

# fdisk -u -l easy-3.4.7-amd64.img
....
Device                          Boot   Start     End Sectors  Size Id Type
easy-skeleton-amd64-1280mb.img1 *       2048 1310719 1308672  639M ef EFI (FAT-1
easy-skeleton-amd64-1280mb.img2      1310720 4194303 2883584  1.4G 83 Linux

For the record;

This works.

I'm posting this reply from easy-3.4.7-bigger-amd64.img booted from Ventoy upped to CI #776 ie 05080402 to avoid the dax problem which -bigger is what I renamed 3.4.7 after performing BarryK's truncate loopdev mod he provided above.

The 3.4.7 .img was residing on a hdd dir. I booted a persistent KDE Neon outfitted w/ Kleopatra which I use to dl, hashcheck, and authenticate linux distro/s which I then copy to Ventoy sticks. I made a dir for a copy of the 3.4.7 .img, opened a term there, shifted into su and performed the command operations, then renamed the .img to bigger and copied it to the above described Ventoy stick, from which it booted fine. I will also report this success in the Ventoy forum w/ a link to this thread if someone else wants to fix their Easy .img for Ventoy compatibility.

[jan]

Congratulations!!

I think not all of this is needed .

#gunzip easy-3.4.7-amd64.img.gz ( unpacking image )
#truncate -s 2G easy-3.4.7-amd64.img ( make it bigger )
Place on Ventoy stick

On the latest version the image is not compressed so no need to unpack.
I think that in this case the script inside easy will do the growing!

[BarryK]

Congratulations!!

I think not all of this is needed .

#gunzip easy-3.4.7-amd64.img.gz ( unpacking image )
#truncate -s 2G easy-3.4.7-amd64.img ( make it bigger )
Place on Ventoy stick

On the latest version the image is not compressed so no need to unpack.
I think that in this case the script inside easy will do the growing!

That's right no need to gunzip; however, still need to make it bigger. The special situation of Ventoy, the ext4 partition has to be "pre grown" to the desired size.

Latest Easy Bookworm, the ext4 second partition is only 4MiB, so it has to be increased big enough to copy easy.sfs, and more room for basic usage.

After resizing the ext4 partition, you could fill it with zeros:

Code: Select all

# dd if=/dev/zero of=<path to mounted ext4 partition>/dummyfile bs=1M
# sync
# rm -f <path to mounted ext4 partition>/dummyfile
# sync
# umount <path to mounted ext4 partition>

The reason for doing that, is you could then gzip the .img file to make it small, and upload somewhere.