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
11

Thanks for your help. I don’t think it’s that. It happened on the brand new SeaGlass drives, and the old Sandisk. I haven’t found one that had the read-only set, that I wasn’t able to reformat one way or another, e.g. by writing all zeros to, and burn Tails or other ISO to. Why would it happen with all the brand new drives except one, evidently intermittently on all, and intermittently on a known good old SanDisk? I’ve never gotten an error while burning, except when it tries tries to install the bootloader. I know it’s not a lot to go on, but I also am not the only one this keeps happening to (e.g. similar posts for other thumb drive capable distros).

I suspect a multi-distro wide problem with the boot config, e.g. an uninitialized variable prob. Then again, I suspect there are many of you that it works reliably for; which might suggest a hardware issue. However, it could also be that I have some hardware that the install has a buggy driver for, that others don’t.

12

I’m saying I tried four brand-new USBs, and in the course of my testing, I must have tried installing at least twice on each one. Some would have read-only tripped; but I couldn’t say for certain that all the failures did. I never was unable to completely reset a read-only USB. I installed Tails and ran it on a few of them after that. These are the SeaGlass. Only one other Verbatim drive has as high a longevity rating. I was getting similar results with previously known good drives also. I tried it on different USB ports, and even an external USB hub. Occasionally it works, but usually it doesn’t. Maybe it’s a BIOS thing. The ones that didn’t work, ALWAYS got stuck at the same place! If it was defective USBs, I believe one should expect they’d have a write error at various points, right? Pity, that.

13

Not necessarily. I’m not an expert in silicon assembly, but I wouldn’t be surprised if some faulty part of a machine responsible for assembling a flash chip broke the chip in the same spot every time.

It could also be not a bad USB, but a bad USB controller. Maybe your system is putting too much power through the drives and frying them early?

1 Like
14

Again, it also happens with a known good SanDisk that’s easily a decade or two old. The first time it worked, but the second time, it didn’t. I just installed Tails again onto one of the new drives. No problem. How many times do I have to install Tails without a problem, or almost always have a KickSecure install has a problem; at the same point. When the SanDisk failed, it was, again, when trying to install the bootloader. I have also had the same problem with ParrotOS; although I haven’t tested it anywhere near as extensively. It’s not unique to KickSecure, but I can repeatedly burn Tails to these same drives, but rarely have a success with KickSecure. Too bad I didn’t keep exact numbers for you; but I believe I tried all four USBs 2-3X, and only once got a success. If it was a bad USB controller, then why did it fail when plugged into my computer; AND when I used an external USB hub? I also tried burning plugged into my solitary USB 3.2 point. I admit, I’ve only tried the old USB 2X I think, but again, they only ever fail when they try to install the bootloader.

The classic thing, is if an OS won’t install, it’s the hardware. I wouldn’t rule it out; except it happened once on an old HP desktop refurb. It does not seem to be a defect in all the new drives, nor a bad USB controller. Come to think of it, I believe I tried and failed to write it on another computer once; only to have it fail at the same point yet again. I have gone around and around with problems with my MOTU audio interface; and they asked me to try a lot of things; except one cannot eliminate Win11 involvement in that case. I was trying a lot of similar things with KickSecure. They are evidently failing at the same point, no matter what make of USB, mostly on one computer; but with one failure on another, too. I’m leaning toward an uninitialized variable from somewhere upstream to you, that only happens on certain hardware. The really maddening thing, is everything appears to work perfectly until the very end and then hang indefinitely - requiring the trials to waste the maximum amount of time possible.

15

Correction again. I’d never had a problem running Tails or writing the ISO to a USB before; but then I never tried to use it much. I tinkered around with it, making some customizations, and it started doing this stuff where it would say “The Persistent storage needs to be checked for errors. This may take a long time.” I reboot, make another change (pretty minor customizations only, at this point), and goes thru the long checking procedure. None of this involves writing more than a few really small falls, but a lot of rebooting. It appears, it fails if you only have it even read a lot. About two other times, it failed to install software that was supposed to install upon every boot, automatically. I did see a post about those USB 3.2 drives being sheite, as they overheat and fail. This drive was noticeably warm to the touch. It’s the first time I’ve had a hint of a problem on Tails on these drives; so it changes my opinion of the errors entirely.

Does anybody have a handy link to USB drive models that are considered to function reliably for this type of application?

16

I haven’t found a USB drive manufacturer that always delivers good USB keys. The ones I use for most of my work at the moment are 32 GB PNY Attaché drives (I got a 5-pack of them), but I didn’t get them that long ago and one of those five drives has already started showing signs of failure (failed integrity checks when using the built-in integrity checking of a Linux distro), so I wouldn’t call them necessarily reliable. Flash memory in general can be rather hit-and-miss, so it may be a good idea to just warranty-claim the bad drives and try again with another major vendor.

17

The logical corollary to that would be: Don’t use USB thumb drives for ANY long-term storage; when they frequently fail at random for no better reason than even just getting read. Backups to something that is actually meant to last would seem called for. M-Disk disks come to mind, as they are intended to last decades, if not longer. True, they are WORM, but let’s hope one can append sessions, like with DVD+/-R’s.

Running a portable drive distro on other RMWM media that are more durable suggests itself, say: SD-cards or something like WD Passport drives. From what you are describing, USB Flash drives these days, in general, are exceptionally bad for anything but temporary storage. I hope KickSecure can run on these other types of drives.

By the way: KickSecure seems like a poor name for a security-oriented OS. We don’t want to kick security out, as the name implies. If a product were named KickSmoking, we would expect it to help us eliminate smoking. SecurityKick, e.g., IMHO, would convey more the intention of this OS.

18

True, and that is indeed the case.

Long-term archival of data without substantial risk of corruption is somewhat of an art. There are many techniques, many of them with varying levels of risk.

True, and there isn’t any reason Kicksecure wouldn’t work on such drives that I’m aware of. I haven’t personally tried it, but they’re “just block devices” in the end, so they should work. (Note that standard SD cards are as bad or worse than standard USB drives, but there are “high endurance” SD cards that at least claim to be more robust. I haven’t tried them and can’t vouch for them.)

1 Like
19

Here’s the best write-up on SD cards I’ve been able to find so far:

How reliable are microSD cards? Well, as it turns out…

He seems to like Kingston Industrial best, but while he hasn’t tested enough to make a call on PNY, the tests he has run has shown them to be doing excellent.