stamasd

I don't think that's the case. The USB stick is almost new, and it has only had a few MB of files written to it once. Also even 8GB is not a significant part of the drive's capacity of 128GB. For testing I only wrote one file at a time, and I did a total of 5-6 tests. Wear leveling should not come into play unless Lexar is totally off their game. Regardless like you said there isn't much I can do. I'll go back to using external enclosures. A small stick that fits in a pocket would have been a nice upgrade. Or maybe try a stick that's below 64GB.

Small update, it seems that this USB stick is not very adequate for my purpose. It does not handle large files well. I tested it with a few files, between 5 and 8GB. They appear to copy well, but the stick's activity LED continues to flash as if stuff still happens (and it doesn't stop for a long time: I waited at one point for 1h and it still continued to do it). This activity continues even if I unmount the drive. No error message is generated, and if I try to mount the stick again it gives me a device busy error. If I physically remove the stick after unmounting and then plug it back in and mount it, the files copied over are damaged. Looks like I'll have to look elsewhere for a large file transfer medium.

Hm, interesting. Gdisk says it's a MBR volume, not GPT. It also complains of overlapping partitions... like cfdisk does. Doesn't find any other partition schemes either, which is normal. Dirty tricks, I tell ya. However, sgdisk -Z /dev/sdb worked at destroying all partitioning tables on the disk and I was able to partition it and format the usual way. I now have a /dev/sdb1 of 128GB formatted ext4, exactly what I wanted. Thank you!

I have a Lexar 128GB USB stick, formatted exFAT out of the box. I have been trying to repartition it and format it ext4 so I can use it to transfer large files between Linux machines. I don't know what dirty tricks Lexar used to partition and format it, but the partition table is really screwed up. Moreover, I can't change it. If I delete the fictitious partitions on the stick in cfdisk, write a new partition to the stick, exit and try to read the stick again it fails. I have to physically disconnect and reconnect it, and then the original partition table is back. It looks like I'm getting some cache errors when trying to write the partition table: [ 417.015912] sd 6:0:0:0: [sdb] Synchronizing SCSI cache [ 417.015960] sd 6:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK I've looked for a solution but haven't really found anything. The stick itself works when attached to a Windows machine. I'm attaching a screenshot of the partition table, and the output of dmesg. Did anyone have success partitioning and formatting one of these in Linux?

Hmm, with the new fix in place mesa emerges successfully, however I still can't start a X server. The Xorg log says it can't find module "nouveau". Nouveau is in fact compiled and installed in the usual kernel module tree, and loaded (it's listed with lsmod).

Thanks. I did that. FL-6604 https://bugs.funtoo.org/projects/FL/issues/FL-6604

I'm testing the new 1.4. My test system is an older laptop, MSI GX720, core2duo P8400 with a nvidia GT9600M video card. I started with a blank disk, installed the minimal 1.3 system from the latest stage3 (core2 subarch) and from there proceeded to upgrade to 1.4 as per instructions. I tried the nvidia driver first (gfxcard_nvidia) but it seems that there's no driver compatible with my video card. So then I switched to gfxcard_nouveau and I get an error emerging mesa-19.1.3. Everything else emerges fine but the last step, mesa, fails. I'm attaching an archive of logs. I think the issue is related to the following in build.log: . >>> Configuring source in /var/tmp/portage/media-libs/mesa-19.1.3-r1/work/mesa-19.1.3 ... meson /var/tmp/portage/media-libs/mesa-19.1.3-r1/work/mesa-19.1.3 /var/tmp/portage/media-libs/mesa-19.1.3-r1/work/mesa-19.1.3-build --buildtype release -Db_ndebug=if-release --libdir lib64 --localstatedir /var/lib --sharedstatedir /usr/share/mesa-19.1.3 --prefix /usr --wrap-mode nodownload --prefix=/usr --libdir=lib64 -Dplatforms=x11,drm,surfaceless -Ddri3=false -Ddri-drivers=swrast,nouveau -Dgallium-drivers=gallium-nouveau -Dgallium-extra-hud=false -Dgallium-vdpau=auto -Dgallium-xvmc=auto -Dgallium-omx=disabled -Dgallium-va=auto -Dgallium-xa=auto -Dgallium-nine=false -Dgallium-opencl=disabled -Dvulkan-drivers= -Dshader-cache=auto -Dshared-glapi=true -Dgles1=auto -Dgles2=auto -Dopengl=true -Dgbm=auto -Dglx=auto -Degl=auto -Dglvnd=true -Dasm=true -Dglx-read-only-text=false -Dllvm=true -Dvalgrind=false -Dlibunwind=false -Dlmsensors=false -Dbuild-tests=false -Dselinux=false -Dosmesa=classic -Dosmesa-bits=8 -Dswr-arches= -Dtools=glsl,nir,nouveau -Dxlib-lease=auto . . meson.build:21:0: [1;31mERROR:[0m Options "gallium-nouveau" are not in allowed choices: ", auto, kmsro, radeonsi, r300, r600, nouveau, freedreno, swrast, v3d, vc4, etnaviv, tegra, i915, svga, virgl, swr, panfrost, iris, lima" mesaerror.tar.bz2

The linked article "why hard drives fail" from the above fails to mention one of the most frequent failure modes that I have observed with my usage: the SATA connectors breaking after only 2-3 uses due to poor plastics used. Sometimes they can be repaired (on one drive I cut the end of a SATA cable and soldered the wires directly to the drive's PCB) but sometimes they're not.

Now with 1.4 up, how long will 1.3 be supported? Here is the reason for my question. Yesterday I started experimenting with upgrading from 1.3 to 1.4. On a test machine (Core2Duo, 2 cores at 2.53GHz, -j2) I first installed a minimal 1.3 system, basically just the stage3 and a couple extra packages (firmware for wifi card etc). Then I started upgrading it to 1.4 as per instructions. The first part of the process, up to and including gcc, took over 9h. I stopped there for now as the day was running out, I'll continue later to get a total time for this minimal system. Now, my main system that I'm looking at upgrading isn't that much more powerful; it's a laptop with dual-core Ivy Bridge CPU at 2.6GHz. Yes it is hyperthreaded so I can expect 1.5 to 2x the performance maybe. But it's not a minimal system so I'll have to budget a couple of days at least to upgrade it to 1.4, and I'd like to plan that in advance a few months. I'm hoping thus that 1.3 will continue to be supported at least through the end of the year.

I tried to emerge Kicad today; the emerge failed in the final step - kicad itself, though the dependencies all emerged successfully.. I'm attaching the required logs as a compressed archive. kicad_errorlogs.tar.bz2

Thanks for the explanation. That worked.

Thanks for your answer. I'm not familiar with using custom patches with portage. Which part of the message you linked to is the actual patch? I see the output of 2 diff commands, neither of which is an actual patch. I don't know what format portage expects the patch to be in.

I need to install the allegro library to work with an older piece of code. However allegro fails to emerge. I'm attaching the output of "emerge media-libs/allegro" as allegro.log, the output of "emerge --info '=media-libs/allegro-5.2.4.0::media-kit'" as info.log and the output of "emerge -pqv '=media-libs/allegro-5.2.4.0::media-kit'" as pqv.log allegro.log info.log pqv.log

Thank you, that worked. Steam started after reboot, updating now. (edit) Yes it works fine.

Current up-to-date installation of Funtoo (1.3), trying to have Steam installed via flatpak. The installation of flatpak was successful, then I added the Steam flatpak repo. Now trying to run Steam with flatpak. As regular user, the output of "flatpak run com.valvesoftware.Steam" is bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. error: ldconfig failed, exit status 256 I looked around and the only mention of a similar problem was The solution there was to run as root. However trying to run the above as root fails because Steam cannot run as root. All help appreciated.