Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 19 Dec 2018, 05:14
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Quirky SlaQ 8.1.6 x86_64 released
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 5 of 8 [115 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
Author Message
linuxcbon

Joined: 09 Aug 2007
Posts: 1202

PostPosted: Fri 13 Jan 2017, 10:58    Post subject:  

prehistoric wrote:
..Another possible complication, this flash drive was not pristine, it had been used for previous installations....
it doesn't matter since the partition table is erased when copying to stick.

prehistoric wrote:
...I ran dmesg to see the state during boot, and found a problem with syncing the cache on a scsi device....
my machine dont have scsi, and it also shows problem with hardware clock.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1736

PostPosted: Fri 13 Jan 2017, 11:50    Post subject:  

@linuxcbon,

I'm afraid the kernel treats SATA devices as if they were SCSI, at some level. This is now a purely historical anomaly. We dropped real SCSI devices some time back.

@all,

To eliminate some variables in troubleshooting I've just prepared the same drive to boot SlaQ again, this time trying to stick as closely as possible to a single OS. (I've been using Fatdog 710, Quirky 8.1.5 and SlaQ 8.1.6 up to now, assuming the code runs the same on each.)

I booted from the SlaQ 8.1.6 DVD on the test machine, which guarantees that I will not be using any changed binaries. I then transferred the files needed to prepare a flash drive using another flash drive. Because I suspect problems with block devices, I ran an md5sum after the transfer. The transfer took place without errors. I also noticed that the clock was correct, even though there were errors reported during boot-up. This makes me suspect we are dealing with time-dependent problems.

I then plugged in the 32 GB drive I used before, and ran the code recommended in the SlaQ instructions:

Code:
#  md5sum slaq-8.1.6-amd64-8gb.img.gz
14f4eb61edc5267f6edbc4ab5a89f5cb  slaq-8.1.6-amd64-8gb.img.gz
#  gunzip --stdout slaq-8.1.6-amd64-8gb.img.gz | dd of=/dev/sdg bs=4M
0+208881 records in
0+208881 records out
7415529472 bytes (7.4 GB, 6.9 GiB) copied, 818.539 s, 9.1 MB/s
# sync
#


Immediately after this I checked on the prepared drive using Gparted. Predictably, Gparted complained that the backup GPT was corrupted, even though the primary GPT was OK. I told it to ignore this. I'll report again after I boot this drive on the test machine.
Gparted_prepared_drive.png
 Description   
 Filesize   55.79 KB
 Viewed   620 Time(s)

Gparted_prepared_drive.png

Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1736

PostPosted: Fri 13 Jan 2017, 12:12    Post subject:  

After rebooting we see a first-run window without the option to resize the partition, as seen in my screenshot below.

Next, notice what Gparted shows after booting off the prepared 32 GB flash drive. What you do not see is the message that the backup GPT is corrupt, which I told it to ignore.

This leads to the suspicion sfdisk has been fooled. Here's what it reports:

Code:
# sfdisk -F /dev/sdg
GPT PMBR size mismatch (15138815 != 60566015) will be corrected by w(rite).
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Unpartitioned space /dev/sdg: 327 MiB, 342867456 bytes, 669663 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

   Start      End Sectors  Size
    2048     2048       0    0B
 1050624  1064959   14336    7M
14483456 15138782  655327  320M
#
Gparted_booted.png
Description 
png

 Download 
Filename  Gparted_booted.png 
Filesize  56.83 KB 
Downloaded  127 Time(s) 
first_run.png
Description 
png

 Download 
Filename  first_run.png 
Filesize  87.46 KB 
Downloaded  117 Time(s) 
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8756
Location: Perth, Western Australia

PostPosted: Sat 14 Jan 2017, 08:03    Post subject:  

prehistoric wrote:
After rebooting we see a first-run window without the option to resize the partition, as seen in my screenshot below.

Next, notice what Gparted shows after booting off the prepared 32 GB flash drive. What you do not see is the message that the backup GPT is corrupt, which I told it to ignore.

This leads to the suspicion sfdisk has been fooled. Here's what it reports:

Code:
# sfdisk -F /dev/sdg
GPT PMBR size mismatch (15138815 != 60566015) will be corrected by w(rite).
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Unpartitioned space /dev/sdg: 327 MiB, 342867456 bytes, 669663 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

   Start      End Sectors  Size
    2048     2048       0    0B
 1050624  1064959   14336    7M
14483456 15138782  655327  320M
#


Hmmm, yes, sfdisk has got it wrong!

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
prehistoric


Joined: 23 Oct 2007
Posts: 1736

PostPosted: Sat 14 Jan 2017, 09:37    Post subject:  

Having created a problem installation on a flash drive, I want to save this to test solutions. There is another option here to consider. As a workaround we could change the instructions for making an installation to a flash drive that has been used before.

Since recent versions of Gparted detect a corrupted GPT, and offer to fix the problem, that may take care of it. I didn't do this because I was trying to expose the bug. Could someone else with a problem installation on a flash drive use Gparted to examine an unmounted drive, and tell us what happens when you accept the offer to fix it?
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Sat 14 Jan 2017, 12:10    Post subject:  

Hi all,

Just for sh#ts & giggles, has anyone tried to take the downloaded ISO, and instead of installing it DVD and/or USB (via dd), tried to install it 'frugally'? You know, just clicking on the ISO and dragging to a folder (mine is named "quirkyslaq") over the vmlinuz, the initrd.q and q.sfs and amending your grub4dos like:

title QuirkySlaq 8.1.6 (sda/quirkyslaq)
uuid (whatever your uuid is)
kernel /quirkyslaq/vmlinuz psubdir=quirkyslaq pmedia=usbflash pfix=ram (tried fsck too)
initrd /quirkyslaq/initrd.q



I don't even know if a 'frugal' install is possible with this quirky edition, but I've successfully (using the Q_ID trick and others) have frugal-installed all previous versions of Quirky.

Anyone try and/or have any success frugal installing this version? I'm getting hardwareclock error messages at boot, on every machine I have tried (four different ones), and each of them drop fairly quick into kernel panic lockup. (Barry, don't waste your time replying to this craziness, just wondering if any others tried....I don't mess with DVDs, hate 'em for many reasons (but I do understand & empathize with prehistoric's worries). For me personally, it's either gz-ing to a USB/hard drive, which this version works great, and/or a frugal install).

Thanks for any replies, gang!!
Back to top
View user's profile Send private message 
escucha


Joined: 14 Mar 2009
Posts: 65

PostPosted: Sat 14 Jan 2017, 12:25    Post subject:  

Yes frugal install in full sda ext4 formated, using tricky grub4dos entry point as follows:

title Quirky SlaQ 8.1.6 x86_64 (sda1/slaq-8.1.6)
uuid 28dc1b2d-ffab-49e9-b504-46cce045626a
kernel /slaq-8.1.6/vmlinuz install_specs=UUID=28dc1b2d-ffab-49e9-b504-46cce045626a:ext4:slaq-8.1.6
initrd /slaq-8.1.6/initrd.q

obviously my SlaQ folder is 'slaq-8.1.6' and needs contain vmlinuz, initrd.q and q.sfs files (iso extracted) in it.
your drive ID must be known through blkid command using any previous usb puppy.
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Sat 14 Jan 2017, 13:52    Post subject:  

escucha wrote:
Yes frugal install in full sda ext4 formated, using tricky grub4dos entry point as follows:

title Quirky SlaQ 8.1.6 x86_64 (sda1/slaq-8.1.6)
uuid 28dc1b2d-ffab-49e9-b504-46cce045626a
kernel /slaq-8.1.6/vmlinuz install_specs=UUID=28dc1b2d-ffab-49e9-b504-46cce045626a:ext4:slaq-8.1.6
initrd /slaq-8.1.6/initrd.q

obviously my SlaQ folder is 'slaq-8.1.6' and needs contain vmlinuz, initrd.q and q.sfs files (iso extracted) in it.
your drive ID must be known through blkid command using any previous usb puppy.


Hi Escucha,

Yes, that's how I have it all setup and frugal install/booting is not working......on 4 different machines I'm getting the same "hardwareclock,,,," error message, then I see the "switch root: can't execute '/sbin/init': No such directory" message, and then a few lines later it drops fairly quickly into a kernel panic. Same on all four machines, diff motherboards, different chips/,memory.

I'm ging to download the ISO again, this time from NLUUG. Maybe I got a bad copy from ibiblio, though the md5 sum checked cleanly on the ibiblio download.

Thank you for replying......at least I know someone got a 'frugal' install working. Thus, its just a matter of time tracking down what's going on my contraptions...haha Laughing
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Sat 14 Jan 2017, 17:35    Post subject:  

escucha wrote:
Yes frugal install in full sda ext4 formated, using tricky grub4dos entry point as follows:

title Quirky SlaQ 8.1.6 x86_64 (sda1/slaq-8.1.6)
uuid 28dc1b2d-ffab-49e9-b504-46cce045626a
kernel /slaq-8.1.6/vmlinuz install_specs=UUID=28dc1b2d-ffab-49e9-b504-46cce045626a:ext4:slaq-8.1.6
initrd /slaq-8.1.6/initrd.q

obviously my SlaQ folder is 'slaq-8.1.6' and needs contain vmlinuz, initrd.q and q.sfs files (iso extracted) in it.
your drive ID must be known through blkid command using any previous usb puppy.



Hi again Escucha,

Copied your grub4dos entry (just exchanging my uuid & folder), and success!!

Thank you very much! Wink I wonder why we have to write the UUID in twice?? Does that have to do with the fact were trying to fool the 'frugal' install that we are live?? Anyhow, thanks again....I really like this latest version BarryK made.
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8756
Location: Perth, Western Australia

PostPosted: Sun 15 Jan 2017, 05:06    Post subject:  

prehistoric wrote:
Having created a problem installation on a flash drive, I want to save this to test solutions. There is another option here to consider. As a workaround we could change the instructions for making an installation to a flash drive that has been used before.

Since recent versions of Gparted detect a corrupted GPT, and offer to fix the problem, that may take care of it. I didn't do this because I was trying to expose the bug. Could someone else with a problem installation on a flash drive use Gparted to examine an unmounted drive, and tell us what happens when you accept the offer to fix it?


When you use "dd" to write to a flash drive, it shouldn't matter what was on the drive before.

However, GPT is strange -- it has a secondary GUUID Partition table at the physical end of the drive. And this is where I am suspicious that may be the cause of problems with resizing that you guys are reporting, but not me. I am wondering if a left-behind secondary GPT is confusing sfdisk.

Coz dd is only going to write the approx. 8GB image, and everything past that is as it was before.

A secondary GPT that is different from the main one, would certainly be the cause of the error reported by Gparted.

There are various ways to fix this. A simple "dd if=/dev/zero ..." to the end of the drive would wipe the old invalid GPT.

Actually, fdisk does fix this at bootup when a f.s. resize is being performed. But it is before that, at the first bootup, where we have the problem -- sfdisk getting confused and thus not offering to do a resize in the first place.

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8756
Location: Perth, Western Australia

PostPosted: Sun 15 Jan 2017, 05:11    Post subject:  

A bug report: PPLOG, in the Personal menu, doesn't work.

This has been discussed recently in a couple of Slacko threads. It wasn't working in Slacko either, but they fixed it.

I only glanced there yesterday, didn't follow what it was exactly that fixed it.

I wonder though, does anyone use that personal blog?

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Sun 15 Jan 2017, 06:14    Post subject:  

BarryK wrote:


When you use "dd" to write to a flash drive, it shouldn't matter what was on the drive before.

However, GPT is strange -- it has a secondary GUUID Partition table at the physical end of the drive. And this is where I am suspicious that may be the cause of problems with resizing that you guys are reporting, but not me. I am wondering if a left-behind secondary GPT is confusing sfdisk.

Coz dd is only going to write the approx. 8GB image, and everything past that is as it was before.

A secondary GPT that is different from the main one, would certainly be the cause of the error reported by Gparted.

There are various ways to fix this. A simple "dd if=/dev/zero ..." to the end of the drive would wipe the old invalid GPT.

Actually, fdisk does fix this at bootup when a f.s. resize is being performed. But it is before that, at the first bootup, where we have the problem -- sfdisk getting confused and thus not offering to do a resize in the first place.


Hi Barry,

I think you should write a simple explanation on your website and also let it be known here:

It is flatout crazy that anyone who does a compressed image install using the dd command does not first do a complete dd wipe of that install device, whether they had GPT-related partitions previousy or not. Especially this is true if they've previously used that device for other pups, pup-related & any-Linux installs..just dd wipe it first, then dd install it.

For all Quirky installs (acutally since you first released the format of compressed images), I run this command first:

dd if=/dev/zero of=/dev/sd# bs=1M. After that, only then do I follow your dd-ing command for installing to that device.

Thus, I believe, make the above mandatory, for installation instructions for Quirky and/or any compressed image install. I know, from experience, that what suspicions you have now and are writing about must be happening. More than a few times I have found friends, knowledgeable Linux friends, who make the mistake of doing an compressed image install to a USB/SD/external drive where they first did not do a complete dd-ing wipe pass. These exact same problems being described here pop up. The only way to get the problems resolved is by starting over, first dd-ing the "whole" device (even large drives), then doing the dd command for the compressed image.

It is my opinion no one should ever think that dd-ing once with a compressed image install is going to be all peaches and roses.

Two levels of dd-ing everyone, not one.



That'll let Barry (and us all) focus on other issues
Back to top
View user's profile Send private message 
escucha


Joined: 14 Mar 2009
Posts: 65

PostPosted: Sun 15 Jan 2017, 06:46    Post subject:  

belham2 wrote:
I wonder why we have to write the UUID in twice?? Does that have to do with the fact were trying to fool the 'frugal' install that we are live?? Anyhow, thanks again....I really like this latest version BarryK made.


Well, well, well... the first UUID is futile in my grub4dos entry.
Tried this new frugal install on Quirky Xerus 8.1.6 for x86_64 and it works for me:

title Quirky Xerus UUID providing (sda1/your_folder_name)
kernel /your_folder_name/vmlinuz install_specs=UUID=YOURUUID-WITH-BLKID-CMND-OBTAINED:ext4:your_folder_name
initrd /your_folder_name/initrd.q

Good luck!

_________________
Definitely moved to 64bit. A great step for me.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1736

PostPosted: Sun 15 Jan 2017, 07:23    Post subject:  

@belham2

Have you ever zeroed a 32 GB or larger flash drive? Believe me this takes a while. If you find that acceptable, what about my 128 GB drive?

I also think that letting Gparted repair the drive when the two GPTs don't match will solve this, but I have not tested this on the drive that exposed the bug. Will someone else test it on a large drive?

I'd do this test myself if I had a large previously-used drive with nothing I want to save. In a day or so I will have one.
Back to top
View user's profile Send private message 
Sage

Joined: 04 Oct 2005
Posts: 5432
Location: GB

PostPosted: Sun 15 Jan 2017, 07:33    Post subject:  

Quote:
first do a complete dd wipe of ... device

He's right, of course, and it's not a new issue, but has been necessary on HDs for centuries. Have been in the habit of using a DOS debug script to clean out old HDs. Sometimes re-format with a FreeDOS, DRDOS, even M$DOS using a FDD (that everyone tries to ignore these days!) before wiping that with GPartEd, dd, w.h.y.
And it doesn't stop there. Yesterday, was unable to restore and re-format an HD using a new embedded GPartEd version from Mint 18.1 install. Reverted to a live-CD Fatdog710, older(?) GPartEd ran like a dream. Subsequent Mint install flawless.
So what do we learn?
Always keep an old banger with FDD under your desk. Always keep an 'established' (ie not the latest!), live-CD Puppy to hand for diagnoses and rectification. Always keep an old HD available for dumping big files, valuable info, etc, (vide supra - prehistoric!) Try to remember the old stuff...
Same ideas and principles often necessary with newer media. It may be SD cards, USB fobs today - who knows what the industry will hit us with next. Qbits?
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 5 of 8 [115 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0743s ][ Queries: 14 (0.0112s) ][ GZIP on ]