Quirky SlaQ 8.1.6 x86_64 released

[BarryK]

Code: Select all

# cat /sys/block/sdb/sdb2/start 
136
# cat /sys/block/sdb/sdb2/size 
16384
# expr 136 + 16384
16520
# sfdisk -F /dev/sdb
Unpartitioned space /dev/sdb: 2 GiB, 2109210624 bytes, 4119552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Start     End Sectors Size
18432 4137983 4119552   2G

Very interesting, thanks for reporting that promptly. Would you also report the result of this:

# fdisk -u -l /dev/sdb

...that's fdisk, not sfdisk!

[linuxcbon]

Code: Select all

# fdisk -u -l /dev/sdb 
Disk /dev/sdb: 2 GiB, 2118647808 bytes, 4137984 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x71039dee

Device     Boot Start    End Sectors  Size Id Type
/dev/sdb1  *        0 622591  622592  304M  0 Empty
/dev/sdb2         136  16519   16384    8M ef EFI (FAT-12/16/32)

[Billtoo]

I installed the devx pet and have compiled a few
programs,lxterminal,cmus,mplayer-1.3.0,Smplayer and Smtube.
I found that some SlackBuilds from my Slackware64-14.2 install and work,
also lxrandr from Fatdog64-710.
I couldn't get Google Chrome from Fatdog working though.

I haven't tried the snapshot utility yet.

Thanks.

I took a snapshot, it seems to have worked fine, it created a 3.5GB sys file.

[Rodney Byne]

Hi to Sage,

Re your earlier line about Flashplayer working, while hoping
I've got your meaning correctly, I see that Seamonkey 2.46
already has flashplayer built in for browsing, so there's no need
anymore to install to Tools/Add-on, the version obtainable in
Menu/Internet or from OscarTalks Index.

I found out recently that FirefoxESR has the same facility now,
so it seems some browsers are following Chromium's lead with Pepperflash.

For me that's great because I can watch UK's BBC News Channel
without effort.

Best regards.

[Sage]

RB: yes, built-in, ootb. BBC iPlayer works.
Still unable to activate sound. Retrovol doesn't show options with sliders like the previous versions?

[TeX Dog]

Whoa there, Hoss! seem to kick over a hornets nest. Snapshot= (pic of desktop) not the new fangled reuse of the term. Can’t find the resulting pic,gif,png etc to upload.
T2 and LFS are the only built systems I have good use/knowledge of inter-workings, T2 is setup-ible for distributed compile across multiple hardware, surprised it takes more than a day, unless you like to single computer compile.
DVD multisession existed in older Puppylinux worked well, BIOS problems do not exist in my desktop DVDs or Macs, which is what I use most for evaluations. My ‘post count’ does not equal my decade + work with PuppyLinux.
I kinda know more about multi session and optical drives, came out of forced Forum retirement just to post fixes for BluRay/DVD multisession in FatDog.

[BarryK]

Code: Select all

# fdisk -u -l /dev/sdb 
Disk /dev/sdb: 2 GiB, 2118647808 bytes, 4137984 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x71039dee

Device     Boot Start    End Sectors  Size Id Type
/dev/sdb1  *        0 622591  622592  304M  0 Empty
/dev/sdb2         136  16519   16384    8M ef EFI (FAT-12/16/32)

Very interesting! This is confirming, the second partition has last sector 16519, which means the unused space starts at 16520, which agrees with your earlier post.

But sfdisk is reporting unused space starts at sector 18432.

Hmmm. I wonder what Gparted reports?

Anyway, I can probably take this error into account.

Got it!

What sfdisk is doing, is rounding-up to the nearest 1MB boundary.

16520 sectors is 8.066MB
18432 sectors is 9.0MB

Good, I can handle that in the code. Thanks for posting that info, it enabled me to solve the mystery.

At least in your case. For the others who did not get the resize-checkbox, I still don't know why, as the 8GB drive image has the second partition ending on a 8MB boundary, so sfdisk will not do any rounding up.

[linuxcbon]

Hmmm. I wonder what Gparted reports?.

gparted also reports unused space starts at 16520, like fdisk. Mystery solved for me

[prehistoric]

Here's a clue about that other mystery. Gparted has a strange report when it looks at a 32 GB flash drive used for installing SlaQ via that commandline. The partition is said to be 27.12 GB, but the sum of used and unused is what I would expect if the filesystem had not been expanded. I'm also a little mystified about the 1.26 GB left at the end of the device.

[BarryK]

Here's a clue about that other mystery. Gparted has a strange report when it looks at a 32 GB flash drive used for installing SlaQ via that commandline. The partition is said to be 27.12 GB, but the sum of used and unused is what I would expect if the filesystem had not been expanded. I'm also a little mystified about the 1.26 GB left at the end of the device.

Yeah, that 1.2GB is another odd thing. It is something to do with sfdisk again. I am using sfdisk to determine the size of unused space, which is used to resize the partition. However, in the case of 32GB Flash drives, sfdisk is getting it wrong.

If you run, before having done the resizing:

# sfdisk -F /dev/sdf

it is misreporting the size of unused space after partition#2.

prehistoric,
With your current sdf drive, with that 1.2GB left over, what does that sfdisk command report about unused space?

[BarryK]

Here's a clue about that other mystery. Gparted has a strange report when it looks at a 32 GB flash drive used for installing SlaQ via that commandline. The partition is said to be 27.12 GB, but the sum of used and unused is what I would expect if the filesystem had not been expanded. I'm also a little mystified about the 1.26 GB left at the end of the device.

Oh, and that other thing. Your partition has been increased, but not the filesystem.

The resize operation first deletes the second partition then recreates it, bigger.

It then does a f.s. check, and then runs 'resize2fs' to increase the ext4 f.s. to fill the partition.

Somehow, this latter step has not worked for you. Which puzzles me immensely, as it works for me.

The script that does this magic is /sbin/fscheck, found by clicking on /boot/easyinit

[Sage]

Above refers: apart from sound issue, other delays, etc seem to be machine specific. Shouldn't happen, but as we all know - it does. [Nothing intrinsically wrong with machine, though.]

[linuxcbon]

Quirky SlaQ 8.1.6 x86_64

- jwmrc not correct. That's why startup programs (network tray, retrovol) don't appear in tray.

Code: Select all

Generating /root/.icewm/menu...
mv: cannot move '/root/.icewm/menu' to a subdirectory of itself, '/root/.icewm/menu-previous'
Generating /root/.jwmrc...
mv: cannot move '/root/.jwmrc' to a subdirectory of itself, '/root/.jwmrc-previous'

Code: Select all

# jwm -p    
JWM: warning: /root/.jwmrc[423]: close tag "Program" does not match open tag "?xml" 

[prehistoric]

Here's the output from sfdisk. I was careful to use the sfdisk actually in SlaQ.

Code: Select all

# sfdisk -F /dev/sdg
Unpartitioned space /dev/sdg: 1.3 GiB, 1355005440 bytes, 2646495 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
57933824 60565982 2632159  1.3G
#

Another possible complication, this flash drive was not pristine, it had been used for previous installations. I ran the command line code exactly as shown, except for the change in filename and drive. I did sync afterward, and I unmounted the drive before removing it. I did not zero everything as that takes a long time on a 32 GB drive.

[prehistoric]

Here's another clue: this machine is one of those which reports it was unable to access the hardware clock. Also reports errors about not being able to delete two directories because not empty.

I ran dmesg to see the state during boot, and found a problem with syncing the cache on a scsi device. There is only one block device on the test machine, the flash drive, as I have disconnected hard drive and SSD.

[linuxcbon]

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

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

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

[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
# 

[BarryK]

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!

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