Warning: Prob. with installing on Verbatim SeaGlass drives - False alarm

Support
1

I don’t expect this to require any bug fix, unless one comes to mind, but just wanted to warn others of my ordeal. Kicksecure seems an ideal OS for booting on a thumb drive for a very secure environment. It seems more suitable than Tails for my use cases, as I’d also like to install some software to it. To test it out, I burnt the live disk to a really OLD Kingston thumb drive of 8GB, and used it to install a persistent, encrypted thumb drive OS that I could e.g. install other softs on with SU privileges, a really old SanDisk 16 GB. It booted and worked great. I can even install other software by removing the split.

The Verbatim Seaglass drives seemed attractive, as they have lifetime warranties, which seems like a fairly strong expression of confidence in their shelf life. I bought two 32GB and two 64, burnt the ISO on a Seaglass, and tried to boot it - this from the same ISO which previously worked. It generated a bunch of errors and then said something like ‘Boot Failed’. Note that virtual machines are enabled in both the BIOS’s I tried. I then tried burning it without the extended volume name option in Rufus, and burnt onto a 64GB instead of a 32, and it worked. I then plugged in the live disk in with another 64GB, and installed to it from Maint. It seemed to complete quite happily, but it would not boot on any computer I tried it on, just like the first Live disk I originally burnt. I compared it to the ancient SanDisk drive that worked. I noticed in the boot order in the BIOS, I had a choice for the USB itself, and another for the same drive, with a Kicksecure name. The one that started with USB wouldn’t boot, but the Kicksecure choice would. Looking at two SeaGlass drives I tried to install to, neither show a Kicksecure choice in the BIOS. It does not work with Secure Boot turned off.

These Seaglass drives SAY that they work for formatting in EXT4 on Linux. I seem to have only one significant choice on how to create the installed version: EXT4 or BTFS. I tried both on one of the drives, but neither gave me a Kicksecure boot choice. I tried booting it on a port on a hub, and two different ports on my desktop. No dice.

Based on the principle that if you try to install Windows on a machine, and you get errors instead of an OS, it is a virtual certainty that the HW is bad or incompatible It seems like a foregone conclusion that the reason for the difference is the thumb drives; but feel free to make any suggestions. I’ve had mostly good luck with Verbatim blank optical media over the years, but IMHO, this does not look good for them. It seems like they are Kicksecure incompatible, as is. I don’t know if it’s a bug in the design, M$ paid ‘em to be incompatible (which here seems unlikely, since they advertise Linux compatibility), or there’s a problem with USB 3.2 Gen 1; or maybe I’m missing something. Maybe a bug in the KickSecure installer is more likely than Windows, but it seems less likely given that the prob. seems to show up depending on the thumb drive it’s installed on. Implementing a thumb drive should under it all just be a big block of memory..

My machine is an ancient ASRock Tai Chi X570, with a Ryzen 5 3800X. The SeaGlass USB drives are for USB 3.2 Gen 1. This matches the specs on most of the USB ports on my desktop, AND on my USB hub.

2

Generally, USB drives themselves act like any other drive under Linux; it’s theoretically possible a drive could be compatible with Windows and not Linux, but in practice I have never seen this be the case.

You’re using Rufus to burn the ISO to the drives. Rufus might not install Kicksecure to a USB drive properly; the ISO is designed to be written directly to a disk, not unpacked into a filesystem on the disk. If you must use Rufus, try using “dd mode” to write the ISO. Better yet, use an existing Linux installation and flash the ISO using dd, i.e. sudo dd if=./kicksecure.iso of=/dev/sdX bs=4M.

(There is, of course, always the possibility that the drives themselves are failing. Drives are most likely to fail when they’re brand new and when they’re relatively old. There are command-line utilities for Linux such as badblocks you can use to check this, see man badblocks.)

1 Like
3

It’s worth a try. Still, the USB drive it runs on shouldn’t make the difference, IMHO. I’m not saying it’s not compatible with Linux, but rather that hardware was the only difference between the drives I created that did work, and that didn’t work..

I burnt an ISO onto a thumbdrive. I did not unpack it. Next, I left in the live disk, and added a blank one. I installed Kicksecure onto the empty thumb drive. I don’t see where I unpacked anything.

Thx for some great things to try, BTW.

This question mentioned the use of DD is addressed here:

https://www.reddit.com/r/SolusProject/comments/ly41ay/rufus_3141735_doesnt_show_dd_image_mode_option/

It says it has changed, so that you only get the option if it’s a hybrid ISO. Burning again, I do get the question. Perhaps I chose it one time, and didn’t another, heh.

I do remember that the Tails instructions have a notice there that said Balena Etcher used to be their recommended burner, as the KickSecure instructions still do; but that the app was found to be phoning home. If memory serves, they are now recommending Rufus.

4

Further tests have shown that when I burn in DD mode in Rufus, I get a working Live setup on the original thumb drive that worked. I burnt it to a thumb drive that worked for the ISO previously. When I try install to HD on the other thumb drive, no matter if it’s the drive that worked originally or not, I get errors such as 'The bootloader could not be installed.; or ‘Failed to execute command /bootloader-config.’ It originally worked when burning it as an ISO. I’m interested to find out the prob. now. I will try it a little more before trying the “dd” command from Linux. (I instolled PI-OS, and then switched to Technecium, and have been meaning to get around to installing NixOS for the WSL Linux.)

5

I decided to try using the drives that had worked previously again. If I installed in dd mode, the created disk wouldn’t launch the maint menu item. If I installed in ISO mode, I had two boot choices in the BIOS: USB & GPT. The USB choice resulted in “542: Index out of bounds” in a console window; but no maint mode. I finally got the live disk to boot with Rufus only if burned as an ISO, and booted from it’s GPT boot entry. Using the same ISO, and the same drives that previously had worked with Rufus, I was unable to recreate my initial success. Burnt as an ISO, they all had errors about not being able to config the bootloader, which had timed out after 600 secs., not being able to run config_bootloader, or index out of bounds. It ultimately failed on the hardware it previously worked on.

It looked very nice, the time it did work. It seemed like just the thing I needed, the one time it did work. It may take a while for me to install a Linux and give it a try there. The point is, however, the problem was intermittent, and extended to all the thumb drives I tried it on. It may well turn out that Rufus might turn out to be the problem, and just doesn’t burn it right.

6

I thought I was getting somewhere by finding a portable vers. of a prog. to run in Tails, but they are dead-set against Internet access in it outside of Tor. A supposed method to allow it in a vid on YT, no longer works. I did take the opportunity to burn a Live disk in Linux from it, using the dd command above. It burnt a LOT faster than in Rufus.

The first time I tried to install Kicksecure in it, it worked! This was even burning onto one of the SeaGlass drives I’d had probs. with before. Kicksecure looks very promising, IF there’s a way to disable Tor and/or allow third-party apps internet access. With a presumably good Live disk on a USB, and full of something (perhaps enthusiasm?), I proceeded to spend lots of time trying to install it to other USB drives. It failed on two yet different 32 GB SeaGlass drives, and to make it complete, it failed to install on the original ancient SanDisk it originally worked on. That makes it four fresh tries, using the Live ISO burnt with with dd: One of them a success, and three more failures - including a non-Verbatim drive which had previously worked. In each failure this time, and most of the previous ones, it gave the error about bootloader_config not finishing after 600 secs. Failures occurred burning from at least two different USB drives that had worked for the Live ISO on other occasions.

This seems like an uninitialized variable problem in the installation from the Live disk; or a timing problem. It manifested if I booted up the Live USB with the GUID partition entry, or with its USB boot menu entry. It looks like the problem isn’t Rufus, nor is it the SeaGlass drives. One of the SeaGlass drives had been triggered to go into a Read-Only mode. I couldn’t even format it until I went into Windows and did “DISKPART”. I navigated to the drive, and did “CLEAN”. This erases it, but makes it it writable. I think you have a problem in your “bootloader_config” script, causing installing it to be a mostly hit or miss process (mostly miss). It looks quite nice, from the two times the installer completed successfully..

7

That sounds like the drives you’re using are so slow that the default timeout value isn’t long enough; I’ve seen these errors when installing to some USB 3 TeamGroup drives in the past. Many USB flash drives have decent read speed but horrible write speed, even USB 3 drives.

The good solution would be to use faster drives, but if you need to use the drives you have, you can lengthen the timeout:

  • Boot the live ISO, and select LIVE Mode | SYSMAINT Session | system maintenance, install.
  • Click Open Terminal.
  • Run sudo nano /usr/lib/calamares/modules/bootloader-config/module.desc.
  • Adjust the timeout: 600 line to something longer, like timeout: 5000.
  • Save with Ctrl+S, exit with Ctrl+X.
  • Close the terminal window.
  • Click Install System.
  • Install like normal.

Because USB installations like you’re doing are explicitly supported, and USB drives are so frequently slow, we should probably lengthen some of these timeouts.

This sounds like Rufus is buggy to me. That message is most likely from GRUB. Etcher exists and probably would work better, but I didn’t mention it since like you mentioned, it does phone home. I don’t know of any other good ISO burning tools for Windows unfortunately. Thankfully, it looks like dd in Linux is doing the trick, so hopefully you won’t need to use Windows for this sort of thing :slight_smile:

1 Like
8

Thanks for the instructions.

It seems worth a try, but as both the drives and the ports are USB 3.2 Gen1, they don’t seem especially slow to me. It seems like it ought to be set slow enough to allow for installation to slower thumb drives, not just 3.2 gen1. Of course, maybe they just had HDDs and SSDs in mind …

In my previous reply, I pointed out that my last four tries were made using a disk burned from a Live ISO on Tails, using the Linux “dd” command; not Rufus.

Perhaps the intermittent nature of the issue, as I mentioned above, does point to a timing prob. 600 secs. is, of course, 10 mins.; which is a long time for the installation of a bootloader. While I would expect one to install <10 mins., your experience with this prob. on other USB3 drives prove be invaluable here.

Some Web searches on this prob. have indicated that this prob. occurs across a wide variety of Linuces. I’m gonna read some of these posts RE: other dristros, too. Will let you know how my next round of tests comes out.

9

Sorry for the late reply. I have had some technical issues and life issues that delayed me for about a couple of weeks. OK. I followed the procedure you gave me, to lengthen the bootloader-config timeout. It didn’t work. It never came back to life again, after about 1/2 hour.

I also notice that even with trying to burn it to a drive that previously had burned successfully, the SanDisk, not only didn’t it work; but it tripped the Read-Only attribute of the drive. This had happened previously, too. Yet, Tails burns and runs fine. The same problem showed up with Toucan Linux. A bug in a standard distribution of the bootloader-config script?

10

Ouch, that sounds like dying flash drives. Flash drives don’t do that unless they’re too burned up to write to anymore. It’s theoretically possible that maybe it’s just a filesystem-level read-only attribute, but that seems pretty unlikely since Kicksecure doesn’t install any read-only filesystems by default.

Sometimes dying flash drives will limp along even after showing odd behavior. They’re still likely dying and may need replaced.

1 Like