Quirky SlaQ 8.1.6 x86_64 released

Please post any bugs you have found
Message
Author
linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#61 Post by linuxcbon »

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.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#62 Post by prehistoric »

@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: Select all

#  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.
Attachments
Gparted_prepared_drive.png
(55.79 KiB) Downloaded 652 times

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#63 Post by prehistoric »

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: Select all

# 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
# 
Attachments
Gparted_booted.png
(56.83 KiB) Downloaded 202 times
first_run.png
(87.46 KiB) Downloaded 185 times

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#64 Post by BarryK »

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: Select all

# 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!
[url]https://bkhome.org/news/[/url]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#65 Post by prehistoric »

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?

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#66 Post by belham2 »

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

User avatar
escucha
Posts: 83
Joined: Sat 14 Mar 2009, 19:40
Location: Ainulindalë

#67 Post by escucha »

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.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#68 Post by belham2 »

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 :lol:

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#69 Post by belham2 »

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.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#70 Post by BarryK »

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.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#71 Post by BarryK »

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?
[url]https://bkhome.org/news/[/url]

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#72 Post by belham2 »

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

User avatar
escucha
Posts: 83
Joined: Sat 14 Mar 2009, 19:40
Location: Ainulindalë

#73 Post by escucha »

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!
[size=75]Trying Fossapup 64bit. Still daily work in Bionic64.[/size]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#74 Post by prehistoric »

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

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#75 Post by Sage »

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?

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#76 Post by belham2 »

prehistoric wrote:@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?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for :wink:

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#77 Post by prehistoric »

belham2 wrote:
prehistoric wrote:@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?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for :wink:
You do realize that the vast majority of people will not accept this don't you? If this is required I'm afraid puppy will become even more a minority choice than it is now. Unnecessary writes also shorten the useful life of a drive.

What's more, I don't think this is necessary. Fix the GPT and expand the filesystem, and none of the previous use will matter.

Also, if you are trying to eliminate the possibility that earlier data can be recovered from the drive it is not adequate. I've had friends who have had flash memory used in industrial applications who found companies who specialize in recovering data from such media after they have been overwritten. Also happened with a photographer I know. He carries insurance against losing data on flash drives that pays for recovery.

Added: Here is one example of a recovery service. Before you tell me this does not apply, I think you need to find out how flash drives work. Writing over data does not do what it does on magnetic disks.

So, what do you think you are actually accomplishing with this proposed procedure?
Last edited by prehistoric on Sun 15 Jan 2017, 12:43, edited 1 time in total.

linuxcbon
Posts: 1312
Joined: Thu 09 Aug 2007, 22:54

#78 Post by linuxcbon »

belham2 wrote: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.
No. No. No. :) The problem is NOT what was on the disk before.
The problem is sfdisk not calculating "empty space" correctly.
You should never need to "dd dev zero", except to erase the whole disk and it takes many many many minutes. That's never needed for installing iso to the disk.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#79 Post by belham2 »

prehistoric wrote:
belham2 wrote:
prehistoric wrote:@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?

Yes, and Yes, and even larger.......it's what beer and a night's sleep are for :wink:
You do realize that the vast majority of people will not accept this don't you? If this is required I'm afraid puppy will become even more a minority choice than it is now. Unnecessary writes also shorten the useful life of a drive.

What's more, I don't think this is necessary. Fix the GPT and expand the filesystem, and none of the previous use will matter.

Also, if you are trying to eliminate the possibility that earlier data can be recovered from the drive it is not adequate. I've had friends who have had flash memory used in industrial applications who found companies who specialize in recovering data from such media after they have been overwritten. Also happened with a photographer I know. He carries insurance against losing data on flash drives that pays for recovery.

So, what do you think you are actually accomplishing with this proposed procedure?
Listen, Prehistoric, Let's stop here. I am sorry I brought it up, and in fact, it was intended as an option for Barry, but of course others..well.... . Also, I try to stay reserved on the internet, but I work in the data security industry, 3+ decades now...we are NOT talking here about "securely" erasing drives and data on them. Don't mix and mash the discussion , trying to pull an apples to oranges comparison. I am not even sure if you know you are doing it. One thing I've learned over the decades of working securing databases & securing networks, is people, sometimes myself included, have trouble staying on point with "what" is being discussed and/or sorted out. Data recovery? Versus removing sectors on device sufficiently for home installs so partitioning schemes don't conflict? Two entirely diff subjects. Our objective with dd (for Barry's install's sakes) is not to securely, in totality, to wipe every bit off a drive. Also, we are NOT talking about attracting users to puppy or not, so please stop. Without Barry and the other creators, you and I and everyone else do not have anything to fuss over, period. I am not creating pups and their varities. Are you? Stop the childish insinuations. You, me and all the regulars here want the same thing; what is best for puppy. In essence, don't stand out in the sun and make the profound statement that it is warm out.

Enjoy the rest of your Sunday, prehistoric, and I do mean this sincerely. I hope you get your problems sorted out with Quirky....on every one & way (frugal + full) I've installed now, and it just hit 5 different (AMD+Intel, all diff storage mftrs) machines today. Plus a friend yesterday during the US football playoffs did his laptop, full install, with Quirkyslaq. A success. These installs are on two USBs, two HDs, and two SD cards, I guess it must be that we are only lucky that we do/did the things we did with dd commands before we installed and didn't run into the problems you and others did. [Edited: plz excuse the constant spelling/grammar errors...argh!)
Last edited by belham2 on Sun 15 Jan 2017, 13:19, edited 2 times in total.

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#80 Post by belham2 »

linuxcbon wrote:
belham2 wrote: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.
No. No. No. :) The problem is NOT what was on the disk before.
The problem is sfdisk not calculating "empty space" correctly.
You should never need to "dd dev zero", except to erase the whole disk and it takes many many many minutes. That's never needed for installing iso to the disk.

linuxcbon, :wink:

Did I ever tell you the story of GPT Ghosting?? Me no like :lol:

Post Reply