SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm having trouble with kernel version 4.19.5 in Slackware64-current where I am not able to write data to my LTO tape drives. Using a Dell PowerVault 132t, I can run the mtx command to load/unload and move tapes around fine, and the mt command also works fine with accessing tapes in either of the LTO2 drives. However, if I run the command "tar -cvf /dev/st0 /path/to/backup", the system acts like it is writing the files to tape, but nothing seems to get actually written. Running a "tar -tvf /dev/st0" immediately exits. After hours of troubleshooting, rolling back to kernel-generic-4.19.4 and everything works fine again. This same thing is happening on a second Slackware64-current machine, with a different SCSI card, accessing a second PowerVault 132t. There are no logs generated in /var/log/syslog or /var/log/messages either. Tried kernel 4.19.6 and it does the same thing as 4.19.5. Looked at the 4.19.5 changelog, and I can't see anything obvious which would be responsible for causing this behavior.
Just wondering if anyone else can confirm this happening on their systems?
Unfortunately, 4.19.7 behaves the same as 4.19.5 and 4.19.6. I noticed I can read a tape that was dumped with tar in 4.19.4, but as soon as I try to tar something new in 4.19.7, I am unable to read it back.
That was also my first thought rkelsen. But that bug existed on all 4.19.y versions and I think was most prevalent on nvme drives or devices where mq was used heavily. Not sure about tape. *edit* although high volumes of data copy were very much a part of the scenario where the corruption hit
Supposedly 4.19.8 will be released this weekend and that bug will be fixed.
Couldn't hurt to wait and test again after 4.19.8 is released...
If it still doesn't work you may want to report it to kernel devs....
I saw that, but am not sure this is the issue in my case, since it isn't really corruption that is happening but actually nothing at all being written to the tape except for filemarks. It is like the data is being sent over the SCSI bus, but the drive is not accepting it. Plus, up until 4.19.5, everything worked fine. Copying files from disk to disk appears to be fine as well.
Quote:
Originally Posted by tramtrist
Supposedly 4.19.8 will be released this weekend and that bug will be fixed.
Couldn't hurt to wait and test again after 4.19.8 is released...
If it still doesn't work you may want to report it to kernel devs....
Will do. Not a critical problem because I can keep 4.19.4 on my main server, and test newer kernels on the second machine.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.