When I did use the Windows utility, I got a error message that accessed that the image could not fit on the stick. This also occurred on the 2nd stick. It was because of that message that I switched to the 16GB stick for Blue.

Further, the "dd" approach should be as reliable as it tries to emulate a sector coverage onto the stick versus anything that GParted would do in stick preparation. The stick only needs a partition table of any kind for "dd "to do it make. And as long as there is space (16GB/large sticks in my case), dd will yield an acceptable stick for booting Blue.

Again, this has an external appearance of size and geometry that occurs in your packaging of the compress image followed by the unpackaging process we do when running the xz command or by using the Windows tools. I used a current 7-zip in my failed Windows attempt to put Blue on 8GB sticks.

I view the "safe" short-term circumvention to be to use a 16GB stick. You may want to strongly suggest that in your opening post or remove the 8GB reference, temporarily. until a better approach to creation is determined.

My 2 sticks from different manufacturers, both, reach the same conclusion; namely, failure to boot. While 16GB and larger are not hitting the space issue that the unpackaging tools are exhibiting.

Again, this does not root out the problem, but, may be useful somehow._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

ETP,
After using the linux method of trying to create Blue on the flash drive, I used Gparted to check the partitions while running from Precise 5.7.1.
It showed around 400 megs of unpartitioned space following the f2fs partition and a short amount of unpartitioned space between the fat partition and the f2fs partition.
When trying to boot from it, no error messages or any messages were seen and the PC then went to boot from the next available device which in my case is a hard drive with Puppy versions and Grub for DOS.
Since there was a fair amount of unpartitioned space on the flash drive after the install, I am assuming it had enough free space for the install. Also, on the fat partition after the install, I saw a syslinux.cfg file and one called ldinlunux. But there was no sign of a syslinux executable.

It sounds to me like we need a fool-proof install method that just works irregardless of if the install is done from windows or linux!

It sounds to me like we need a fool-proof install method that just works irregardless of if the install is done from windows or linux!
It sounds to me like we need a fool-proof install method that just works irregardless of if the install is done from windows or linux!

You can say that again! Ahhh…you did.
I see that this thread has had quite a few views. People must enjoy seeing us suffer!

What you describe means that your BIOS never even sees the stick as bootable and makes no attempt to boot from it.

The file that you observed on the 16 Meg fat partition (ldlinux.sys) is the syslinux boot loader. You can regard that as the syslinux executable. When one takes an image of a stick, it is by definition the complete thing and includes both allocated and unallocated space. There is no option to take anything less so the free space at the end is all part of the image.

May I ask that you try what I described in my previous post, first returning the target stick to its virgin state and then monitoring the creation process in HTOP?
Thanks for sticking with it!

@ gcmartin

Quote:

I view the "safe" short-term circumvention to be to use a 16GB stick. You may want to strongly suggest that in your opening post or remove the 8GB reference, temporarily. until a better approach to creation is determined.

I would do so but for one user reporting failure with two 16GB sticks. Further enquiry revealed that the sticks had seen heavy use and had a history of being formatted with different file systems on multiple partitions. Whilst you may stand a better chance with a 16GB stick, I think that returning a target stick of any size to its virgin state may be more important._________________Regards ETP
Kennels

I have already tried having HTop open when I ran the install script I made and I ran it from a terminal opened in the directory containing the Blue image file.
At no time did I see anything strange reported in HTop or the terminal.
The check I did though, if you examine it, kept coming up with a fault in block/area 509. That makes me wonder if that area on the flash drive is messing up the continuity of the install by data being put in an alternative area.
It is just a thought though.
Also, I may try to make an sfs file that only contains the contents of the f2fs partition and see if I can treat it like a Puppy full install that one does using Puppy's install menu. I think someone else is trying it as they had a post asking if they could create an sfs file using xz compression.

Can someone create this?And can this be a good implementation for messages that would surface during a dd operations where is aborts and can be seen?

If found to be helpful, this would be a good tools for the Puppy utilities menu (Menu>Utilities>"dd copy to partition/disk")

I will test it on my 8GB sticks, if someone produces it to see if its helpful._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

My original message was incorrect. F2FS is designed to work in combination with FTL support in NAND flash devices. It however also ties into it directly, and that may be part of the problem. There may be NON-SAMSUNG FTL logic in USB sticks that caus these problems (the 16Gbyte parts that won't work ?)

My original message was incorrect. F2FS is designed to work in combination with FTL support in NAND flash devices. It however also ties into it directly, and that may be part of the problem. There may be NON-SAMSUNG FTL logic in USB sticks that caus these problems (the 16Gbyte parts that won't work ?)

Buy USB sticks with Samsung NAND flash in it....

Since USB sticks do no specify if they have this feature, how does one go about choosing a brand that does?
Is a list of compatible sticks needed?
The 8gig stick I was trying is brand name PNY. ce fe.
I do not know what the "ce fe" represents. But the same size stick by the same company I have sen come in different designations. So that might have something to do with stick compatibility.

Don't know if it is of any use in understanding formatting issues in setting up a usb stick for Blue, but there is an interesting article about setting up file systems for Linux here
(Got that link from anikin in another thread)
It discusses reformatting / repartitioning on SD cards to allow alignment of "boundaries" in order to optimize handling of certain file sizes.. Doesn't discuss USB sticks - but maybe the principle has some potential impact for usb given similar flash technology?
.

1.I ran gparted which showed the drive as 7.5 gb, created a new
partition table and then formatted the drive fat 32, didn't set the
boot flag then exited gparted.
2.I had the blue_pup_v2_8gb.img.xz file in /root/hold where I right clicked and opened the terminal, then entered the
xz --decompress --stdout blue_pup_v2_8gb.img.xz > /dev/sdf command, the activity light on the drive flashed for about
15 minutes, when that stopped I entered the sync command.
3.Rebooted from the flash drive and it got to the command prompt where I ran xorgwizard and chose the modesetting driver,
when finished with that xwin to get to the desktop.

I just got through using Puppy Precise 5.7.1 to try installing Blue to an 8gig flash stick.
It was the same PNY brand stick I had used before.
Now for the good/bad news!

My desktop PC was unable to see the flash drive as a bootable device in both the Desktop's boot selection menu and also in BIOS. That was the bad news.

Now for the Good news.
I went over to my Toshiba laptop and tried using its boot menu with the USB stick still not showing up.
But...
I then went to the BIOS and set the USB stick, now visible, as my first boot device.
And it booted!!
The auto guess at my graphics failed and I did not run xorgwizard at that time.
But it seems that the ability to boot the USB flash stick is dependent on the computer's BIOS seeing it as bootable.
So it will work on some PCs and fail on others depending on the BIOS being able to see the stick as a bootable device.
This makes me wonder if one could create a boot floppy to boot to the USB stick though on a PC with a flakey BIOS.
Even on the Toshiba laptop, its boot menu failed to see any USB bootable device whereas the BIOS on it recognized the USB device and gave one the ability to boot from it.
The problem I am seeing is that there may be a lot of PCs that will fail at booting Blue.
And I have a request of those with more than one PC to try Blue on their other PCs and see if it still boots or they are experiencing the problems I had.

Sorry 8-bit....
Can't be of any help here short time. I have 3 different 8G USB sticks, and tons of 1/2/4G(*) running X flavors of Puppy already (bought a virgin one just for this F2FS project), and neither will fit the image.

I may buy a 16G stick in the future, but for now, I can't help you boot testing Blue (But I do have 2 laptops, 2 netbooks and 1 desktop to test on).

Volhout

When I stopped being my own boss, and started working for another, I had to write off many smaller sticks...

b.t.w. I do see the intellectual challenge of making F2FS work, but fail to see what it could benefit for Puppy. Puppy runs in RAM, a frugal install only writes to flash every 10 minutes and at shutdown to a USB stick that autonomously does the wear leveling, and with the faster USB sticks as used in these tests (write speeds of 30Mbyte per second or more) this doesn't cost the time. Only when the RAM can't hold the full puppy image and leave room for apps, you may be at an advantage with F2FS. But since it may not even work on older machines (who made the remark ?) you are looking at machines with several Gbytes of RAM. I don't see the benefit yet. Maybe someone can enlighten me.

The problem I am seeing is that there may be a lot of PCs that will fail at booting Blue.
And I have a request of those with more than one PC to try Blue on their other PCs and see if it still boots or they are experiencing the problems I had.

I moved my 8gb flash drive that was created on my 8+ year old hp
desktop to a less than 2 year old hp desktop and booted it up
(pressing the esc key then F9 gets me to the boot menu).
It booted straight to the desktop on this pc, I did have to run the
network wizard to set up the wireless connection.

Thanks for continuing to test. It has provided much needed encouragement.

@ 8-bit,

You are spot on with your comments about BIOS issues and will be pleased to learn that within the next few hours I will be uploading a new test version (V3) which includes a raft of measures in an attempt to combat the stick issues that some people have experienced plus a couple to hopefully address your BIOS issue. It should fool the Bios into believing that the stick is a USB HDD. I have also departed from the partition layout used in QT and done my own (simpler) thing._________________Regards ETP
Kennels

The requested utility where I ask for assistance seemingly could provide us with some good information when using Linux as the pathway creating these USB sticks. Reason: messaging...useful messaging; for example "aborting ..." messages.

If we were getting useful messaging, as I have gotten using Windows, Linux could also give info helpful to pinpoint these problem. Other than myself, only one other member has shared messaging about the aborted creation attempt.

Another member has also offered a very GOOD piece of information. RAM booting: The NEW Quirky XZ Delivery plan does NOT appear to be a RAM based system. It appears externally, as a alternate way of booting a PUP as a "full" install versus a RAM centric "frugal" install. Have others noticed this departure from tradition? Am I correct in pointing this out?

If the system were a RAM centric system and if session saving occurred at end of session, then there would be no need for an F2FS as, with this arrangement it would offer no benefit to the life of the USB stick than any other filesystem, i.e. ext2/fat32/ntfs/... Reason: After initial creation, the only time a write would occur is at shutdown. The problem with USB use is the many millions of writes over time. A RAM based PUP using session saves at shutdown NEVER gets booted millions of times....never.

Thanks @ETP for an alternate process, @Volhout on RAM architecture reminder, @GreenGeek and everyone trying to identify the root cause of the problem and the direction of USB stick use in current and future PUPs

Again, I ask if someone would provide the utility for our evaluation. If it provides useful messaging, we may get to the root cause in addition to the alternate pathways underway. should this utility be useful, it could accompany the "xz" so that Linux users could use it in USB stick creation process and have useful feedback should something go wrong in creation.

Lastly, I offer an idea on this specific problem and more general in use of "DD" command(s).

Idea #1 - a idea on how to position so that creation problems are more evident

Preparation of the xz based shipment container

partitioning tools produce a layout report.

dd produces statistic.

xz command to create the container for posting

any xz statistic resulting from creating the container

create a container report

Creation of sticks by any PUP member downloading

xz command/script to create the USB stick

compare the created statistics with the container report

run partitioning tool to compare layout with the container report

Here to help

_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

Your english is infinitely better than mine, questioning the value of F2FS for puppy (small distro that fits in RAM). I fully understand if an W8 (after 1 year of upgrades easilly 50Gbyte) cannot run from RAM, and needs F2FS for smooth operation from flash.

I checked the 4Gbyte ones just to see if Kingston uses the free space at start of flash as a standard, but they do not on the 4Gbyte parts.Last edited by Volhout on Wed 26 Mar 2014, 11:26; edited 1 time in total

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum