Blue Pup V6 Released 11th Oct 2014 32-bit

For talk and support relating specifically to Puppy derivatives
Message
Author
gcmartin

#61 Post by gcmartin »

Dont know if this will help any:

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.

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#62 Post by 8-bit »

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!

User avatar
ETP
Posts: 1193
Joined: Tue 19 Oct 2010, 19:55
Location: UK

Blue Pup V1 & V2 (Released 13th March 2014)

#63 Post by ETP »

@ 8-bit ,
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. :lol:
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
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
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#64 Post by 8-bit »

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.

gcmartin

#65 Post by gcmartin »

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.

Volhout
Posts: 547
Joined: Sun 28 Dec 2008, 08:41

physical versus logical

#66 Post by Volhout »

http://lwn.net/Articles/518988/

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....

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

Re: physical versus logical

#67 Post by 8-bit »

Volhout wrote:http://lwn.net/Articles/518988/

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.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#68 Post by greengeek »

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?
.

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

Blue Pup V1 & V2 (Released 13th March 2014)

#69 Post by Billtoo »

I used the linux method to install to an 8gb flash drive.

While running X-precise 2.3

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.

video-info-glx 1.5.3 Tue 25 Mar 2014 on Quirky Tahr 6.0.5 Linux 3.12.6 i686
0.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530 [Radeon X1600 PRO]
oem: ATI ATOMBIOS
product: RV530 01.00
X Server: Xorg Driver: modesetting
X.Org version: 1.15.0
dimensions: 1920x1080 pixels (507x285 millimeters)
depth of root window: 24 planes
AMD Athlon(tm) 64 Processor 3300+
Core 0: @2411 MHz
Attachments
screenshot.jpg
(42.02 KiB) Downloaded 476 times

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#70 Post by 8-bit »

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.

Volhout
Posts: 547
Joined: Sun 28 Dec 2008, 08:41

try different PC's

#71 Post by Volhout »

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.

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#72 Post by Billtoo »

8-bit wrote:
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.

video-info-glx 1.5.3 Wed 26 Mar 2014 on Quirky Tahr 6.0.5 Linux 3.12.6 i686
2.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
oem: Intel(R) Sandybridge/Ivybridge Graphics Chipset Accelerated VGA BIOS
product: Intel(R) Sandybridge/Ivybridge Graphics Controller Hardware Version 0.0
X Server: Xorg Driver: intel
X.Org version: 1.15.0
dimensions: 1920x1080 pixels (507x285 millimeters)
depth of root window: 24 planes
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop x86/MMX/SSE2
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.0.1
Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz
Core 0: @1600 1: @1600 2: @1600 3: @1600 MHz

Network controller Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe

There's one old and one fairly new, ati graphics to intel.
It works well on both computers but better on the newer one of course.

User avatar
ETP
Posts: 1193
Joined: Tue 19 Oct 2010, 19:55
Location: UK

Boot and stick issues.

#73 Post by ETP »

Boot and stick issues.

@ Billtoo,

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
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]

gcmartin

#74 Post by gcmartin »

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
    1. partitioning tools produce a layout report.
    2. dd produces statistic.
    3. xz command to create the container for posting
    4. any xz statistic resulting from creating the container
    5. create a container report
  • Creation of sticks by any PUP member downloading
    1. xz command/script to create the USB stick
    2. compare the created statistics with the container report
    3. run partitioning tool to compare layout with the container report
Here to help

Volhout
Posts: 547
Joined: Sun 28 Dec 2008, 08:41

RAM based, and USB sticks

#75 Post by Volhout »

@gcmartin,

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 ran 4 USB sticks through GPARTED to see what their sizes where.

8 Gb Kingston Traveler: 3.9Mb free at start of flash, size FAT32 : 7.21Gb
8 Gb La Cie: size FAT32: 7.21 Gb, 7.07Mb free at end of flash

4 Gb Sandisk Cruzer: 3.75Gb FAT32, 2 Mbyte free at end of flash
4 Gb Kingston ??: 3.74Gb FAT32, 8Mbyte free at end of flash.

This is how they came, virgin, out of the plastic.

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, 15:26, edited 1 time in total.

User avatar
ETP
Posts: 1193
Joined: Tue 19 Oct 2010, 19:55
Location: UK

Test Release – V3 – (V3 Released 02nd April 2014)

#76 Post by ETP »

Test Release – V3 – (V3 Released 02nd April 2014 - 323MB)

This is only intended at present for anyone who has had problems producing a bootable stick.
The target device remains as an 8GB or greater USB2 or USB3 stick. I have however tested it with both cards and sticks.

I will edit this post with a detailed write-up of those changes should it give a better booting success rate. Blue Pup itself only has minor non-critical changes. If you are happy with V1 or V2 there is no vital need to change but you could test on another stick.

blue_pup_v3_4gb.img.xz [323 Meg]together with the MD5 can be found here:
MD5 2eceada3a5220d89bb5f84365db26f37
https://drive.google.com/folderview?id= ... sp=sharing
&
https://archive.org/details/Puppy_Linux_blue_pup
NOTES:

1. Unplug any other cards or sticks before attempting to boot V3.

2. Use a port rather than a USB hub if possible as there is an underlying problem with QT.

3. Linux install terminal commands for V3:
(The target stick should not be mounted. In the directory that you downloaded the .img.xz file to, right click then /window/terminal here/ to access the terminal)
Only issue the sync command when the first command has completed which may take up to 20 minutes. If you wish you can monitor it running in HTOP.

Code: Select all

# xz --decompress --stdout blue_pup_v3_4gb.img.xz > /dev/sdx 
# sync
(replace the x at the end with your target device letter)
4. Syslinux.cfg has changed in V3 and now reads as follows:

Code: Select all

# Boot Blue Pup ETP 25th March 2014 
default /vmlinuz root=/dev/sdb2 rootwait rw
The assumption here is that there is only one hard drive in the PC and at boot time only one USB stick (V3) plugged in and no SD cards. If you have a second hard disc you will need to change the sdb2 reference to sdc2. If you have another USB device plugged in such as a wireless or BT dongle this may also apply.
In summary try the default sdb2 then move up to sdc2 then sdd2 until you boot successfully without seeing a kernel panic message.

If you first attempt to boot the stick on the same pc or laptop that you used to create it, make sure that before doing so, you shut down the device and remove all mains power from it for a couple of minutes.
This will ensure that your BIOS refreshes its view of the stick and sees it as bootable.


Edit: 31/03/14 A copy of my own rough build notes as below.
  • V3 Changes: (DPI left at 102)
    ************************
    1. Default apps - change HTML editor to geany (HTML viewer Chromium)

    2. Chromium:
    A - Clear P/Ws.
    B - Set allow local data to be set as the default. (Cookies)
    C - Update Metro to v 1.02 (supposed to update automatically but does not always do so)

    3. Line up GTK panel with extra space after QUIT but before :

    4. Change Metro & Panel to V3

    5. Program E-Mail button to launch T'bird (key 236) (For multimedia K/Bs)

    6. Eliminate typo from some scripts (usr instead of user!!!!)

    7. Zeroise build card with dd before starting build. (Compressed image then half the size of V2)

    8. Abandon QT stick layout to deal with difficult BIOSs.

    9. Use syslinux 4.04 instead of 4.05 and create 16 Meg Fat32 image instead of Fat16. Prepare with HP Utility before
    applying boot-loader.

    10. Start build by applying the above 16 Meg image to 4GB card then format rest as f2fs.
Last edited by ETP on Fri 04 Apr 2014, 17:40, edited 10 times in total.
Regards ETP
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]

Volhout
Posts: 547
Joined: Sun 28 Dec 2008, 08:41

4Gb image

#77 Post by Volhout »

Thanks ETP,

Downloading now, and will try if this V3 works.
It is a 4 Gbyte image ? Right ?
Just from my earlier post: there is actually only 7.21Gbyte (x1024x1024x1024) = 7.74 Gbyte in FAT32 on the stick.
Kingston (and La Cie) must reserve 8/7.74 - 100% = 3% on the USB stick to replace bad sectors.

Will try this tomorrow... as per your description, running UPUP Raring with 3.992 kernel.

Volhout

User avatar
ETP
Posts: 1193
Joined: Tue 19 Oct 2010, 19:55
Location: UK

4Gb image

#78 Post by ETP »

Hi Volhout,
It is a 4 Gbyte image ? Right ?
Yes. It will expand to just less than 4 GB but is intended to go on an 8GB stick.
This was a bit of lateral thinking to get around the fact that many 8GB sticks are “not the full shilling
Regards ETP
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]

gcmartin

Success with version 3 approach in latest BLUEPUP

#79 Post by gcmartin »

Chronology
  1. Download is BEST SPEED ever achieved! Good selection of the fastest free network in the world.
  2. Screen capture of USB stick before burn (see below)
  3. Burn accomplished in less than 20 minutes
    • No blanking USB stick (an unnecessary step)
    • Using the following command

      Code: Select all

      # xz --decompress --stdout /mnt/myNAS7/Downloads/Puppy/ETP/Blue/blue_pup_v3_4gb.img.xz  > /dev/sdd ; sync
  4. System booted on a touch laptop without boot failure this time. Desktop startup failed. xorgwizard & xwin to desktop.
  5. Also USB booted USB to a desktop without boot failure.
  6. Screen capture of USB stick after burn (see below)
Successful booting via 1 of my 8GB sticks.

Observation
In appearance, this V3 will find home on 4GB stick, as well.

Future
I will test the "touch" ability for you later and report for disability usage.

Hope this helps
Edited: Clarity and additional item
Attachments
1st 8GB drive before V3_2014-03-26.png
Drive picture before xz command use
(28.07 KiB) Downloaded 781 times
1st 8GB drive after V3_2014-03-26.png
Immediately after xz completion of downloaded file
(25.81 KiB) Downloaded 763 times
Last edited by gcmartin on Wed 26 Mar 2014, 17:50, edited 2 times in total.

gcmartin

#80 Post by gcmartin »

I pose a question to everyone who has followed the 8GB problem discussion in this thread. It is here. Respond if you have any info you feel would be helpful.

Post Reply