Re: [qubes-users] USB Root Drive Corruption
johnyju...@sigaint.org: >> This problem persists in 3.2rc2. >> >> (And I get 0 errors on the same USB drive under Tails. When I can find >> the SATA power connector around here somewhere, I'll try moving the drive >> direct onto the SATA bus.) > > I think the problem *may* be that systemd has a default 90 second timeout > on jobs, including unmounting root. > > On an external USB drive, due to slower transfer times, the shutdown > process of all the VM's, killing processes, flushing buffers, etc., > happens to take long enough that a clean unmount of the drive doesn't get > a chance to occur, leaned to a corrupted filesystem. > > If I shut down each Appvm manually before finally doing the reboot, the > work left to do on shutdown lets the unmount occur with in 90 seconds, so > the drive shuts down cleanly. > > I think that's what I've been seeing, anyway. There's a lot of disk > activity while systemd talks about outstanding jobs, and while the time > remaining of waiting for the jobs, ticks down to zero. > > Now, why the fsck on boot fails (and things fall into r/o mode, and fail > thus hang the boot sequence), I'm not sure. It could be a similar > problem, that startup jobs aren't happening within the 90 second default > job window for systemd (due to slower USB transfers, and the time taken > for the fsck), and the boot process gives up. > > People with internal drives and killer machines wouldn't see this issue. > > I'm going to try cranking up DefaultTimeoutStartSec and > DefaultTimeoutStopSec in /etc/systemd/system.conf, and see if that > improves the situation. I'll also scrutinize systemd-analyze (which I > just learned about, being an old-school /etc/init.d guy, lol) and see if > that confirms my suspicions. > > Cheers, > > JJ This might explain why I didn't see this behavior, because the external USB drive that I booted 3.2rc1 from was a USB3 drive that internally used RAID0, so it's probably faster than most. Might I ask whether your external USB drive was USB2 or USB3, whether it was an HDD or SSD, and whether it used RAID0? Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/168f1392-c917-c2f7-ce6f-70236a734eab%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] USB Root Drive Corruption - Solved???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-19 06:18, johnyju...@sigaint.org wrote: >>> This problem persists in 3.2rc2. >>> >>> (And I get 0 errors on the same USB drive under Tails. When I can >>> find the SATA power connector around here somewhere, I'll try moving >>> the drive direct onto the SATA bus.) >> >> I think the problem *may* be that systemd has a default 90 second >> timeout on jobs, including unmounting root. >> >> On an external USB drive, due to slower transfer times, the shutdown >> process of all the VM's, killing processes, flushing buffers, etc., >> happens to take long enough that a clean unmount of the drive doesn't >> get a chance to occur, leaned to a corrupted filesystem. > > I am very new to systemd, but I believe the cause of my corruption is that > there may be a typo bug in one of the directives for systemd's > umount.target. > > "systemctl show umount.target" reveals: > >> JobTimeoutUSec=0 > > "man systemd.directives" and "man system.unit" do not show any such > directive; however, they do show "JobTimeoutSec" which I believe was likely > the intended directive, and which would set no limit on waiting for that > shutdown filesystem unmount, and I believe would prevent the corruption I > was seeing. > > A zgrep of all the man pages shows no indication of JobTimeoutUSec being a > legit property. > > Cheers. > > JJ > Thanks for the report! Updated: https://github.com/QubesOS/qubes-issues/issues/2245#issuecomment-241107927 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXt1kbAAoJENtN07w5UDAwTdkP/jcUco65Mh1pBLqCXhFBfZ9s s57imQlP8jfUfE+zXAZ8PeYYA07cw31QXx+K3jcKvDyFOo3xfMvL+t9XH0WkM2B0 FUpFLn+YO3MEClLQM4ZC3hTZz7fl0npuhJBEPkOiGXMgbkycxP2rrqNTi9M7yoYi Zg4/sAzi7PyLC8/gaUJ6c5LdsZ3KB2k8QQWRpgFbEBdYQ7b0kHF7hyjZqHo6Rnrd 26b8NTwKaCJR07tf2/BVuMzgskQpkzugDE083nVpyqKqBo9c6lZANETavd7JiVLD O6Yt7NVM1ZHWKU8dPuEvBQ8yleEOmXRPDqrs9sXS2R2AdPpnmUOxYU8Tyi6MBTYi +acp9A4gyduHbufhiDOv6Mh4rYpaItRQixutk6Q89UzgsjarR9Fj9IH/JqR4KmAK mUdcok1rrzpcMGOOMH34kMJ/IkgxlWe7LNypn+kDattwULeoPYp+MMkRI2h/OJRR bPdsXU5RN1Yc1x2hiGYdGBXn2QXT28I06AHq2fvLCXpIo90ia7lBr5u7DzzEVKp/ YkJgNp7QVR7rjE1WbmXWx43K8gUT5+0yYE7hPP72GSmQqZz3j5BlbheVrzzruEbz EnsIfiwbl2Xj9wZNnSOuOnxNHSDaPtFRR+pRwBooIBsK8bP3vj4wajdg8mby8nI9 kh3DJ51P4tpeHGltp9LT =Idxb -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/10c08c9c-a1ac-4a28-295a-22cdd0971b7a%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB Root Drive Corruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-19 04:32, johnyju...@sigaint.org wrote: > If I shut down each Appvm manually before finally doing the reboot, the > work left to do on shutdown lets the unmount occur with in 90 seconds, so > the drive shuts down cleanly. > Hm, I wonder if this could be related to this: https://github.com/QubesOS/qubes-issues/issues/1826 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXt1jSAAoJENtN07w5UDAwPgkP/3XynrrWe1d0LbIX1wW+QSDy Njd6dZkBs1bCZRaVl1QjM3prAmbHlEsgcHtpYvgqS50lSXclr7A8E4wU6Vyu2bIg XH/1kKLdCxNnVTBkTLM5aeZosNittvEA3/6HLW/wQWrZw3kLP5Lf2wJmmnAO3eOj V2joY3vhAnpGuq8vmnRX8RTwGBDAOPnNh37decjqw+kx5FxNumYMRnZPJsnbmcoU Qo+cwFCuVI3+0NYOXypVrTyR9nV2Dc68dyAEJ+LHECyTfXaWukx5UQo3800C1qTx XQjQi9ZDZnIr+PrIdzdKsKBz/S0EtzayiX7voT65QNFXi2F1e+/EwyOnqIS0zRRX OSNCQG4k0yeD35QXfTQNFsPJ8L176cy7hk1Vgs7P4bR3KxNdjkx7ukneLMkJOkqE adU8t8DBGewj3wQ/FnI9G3x99NRafoBPq/+xD6/qUPI6UeKWIlXcPZPQGr8Oxsso z8kQdAPSSX6SxycMLLGKhrXlF8gnJwo/N2ZHXgSpPnMIhUWm+FgDidSo6XtfOb9v cAbYDMOn+KKOMwTOvJGclS+R8yi3DZPlhH9qTVgMc9XdXvPHSF91GdU7Pmc2mAJ7 c+1pP4zgTs3TKnWk/NKax0AEk+5mdqkP6aUzmdNZtASfgw+V7xyvrB2fMuLW3ElT wbQKUe9P1X6uXHCltLDo =B9TE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/061b8345-5906-4fbe-5896-6cd7c85ea859%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB Root Drive Corruption - Solved???
>> This problem persists in 3.2rc2. >> >> (And I get 0 errors on the same USB drive under Tails. When I can find >> the SATA power connector around here somewhere, I'll try moving the >> drive >> direct onto the SATA bus.) > > I think the problem *may* be that systemd has a default 90 second timeout > on jobs, including unmounting root. > > On an external USB drive, due to slower transfer times, the shutdown > process of all the VM's, killing processes, flushing buffers, etc., > happens to take long enough that a clean unmount of the drive doesn't get > a chance to occur, leaned to a corrupted filesystem. I am very new to systemd, but I believe the cause of my corruption is that there may be a typo bug in one of the directives for systemd's umount.target. "systemctl show umount.target" reveals: > JobTimeoutUSec=0 "man systemd.directives" and "man system.unit" do not show any such directive; however, they do show "JobTimeoutSec" which I believe was likely the intended directive, and which would set no limit on waiting for that shutdown filesystem unmount, and I believe would prevent the corruption I was seeing. A zgrep of all the man pages shows no indication of JobTimeoutUSec being a legit property. Cheers. JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/db8ae328392da35722270028da397924.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB Root Drive Corruption
> This problem persists in 3.2rc2. > > (And I get 0 errors on the same USB drive under Tails. When I can find > the SATA power connector around here somewhere, I'll try moving the drive > direct onto the SATA bus.) I think the problem *may* be that systemd has a default 90 second timeout on jobs, including unmounting root. On an external USB drive, due to slower transfer times, the shutdown process of all the VM's, killing processes, flushing buffers, etc., happens to take long enough that a clean unmount of the drive doesn't get a chance to occur, leaned to a corrupted filesystem. If I shut down each Appvm manually before finally doing the reboot, the work left to do on shutdown lets the unmount occur with in 90 seconds, so the drive shuts down cleanly. I think that's what I've been seeing, anyway. There's a lot of disk activity while systemd talks about outstanding jobs, and while the time remaining of waiting for the jobs, ticks down to zero. Now, why the fsck on boot fails (and things fall into r/o mode, and fail thus hang the boot sequence), I'm not sure. It could be a similar problem, that startup jobs aren't happening within the 90 second default job window for systemd (due to slower USB transfers, and the time taken for the fsck), and the boot process gives up. People with internal drives and killer machines wouldn't see this issue. I'm going to try cranking up DefaultTimeoutStartSec and DefaultTimeoutStopSec in /etc/systemd/system.conf, and see if that improves the situation. I'll also scrutinize systemd-analyze (which I just learned about, being an old-school /etc/init.d guy, lol) and see if that confirms my suspicions. Cheers, JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7c13a5de2f52dc81b5b34fc3b2d74474.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB Root Drive Corruption
This problem persists in 3.2rc2. (And I get 0 errors on the same USB drive under Tails. When I can find the SATA power connector around here somewhere, I'll try moving the drive direct onto the SATA bus.) > Thanks for the feedback. The fact USB is a bad idea all around for > security (and potentially stability), and the fact I was getting minor > corruption, should have been a warning to me to move the drive right onto > the SATA bus, rather than risking worse corruption. I guess I only have > myself to blame. > > I guess I'll "get back on the horse," lol, with the 3.2 release candidate, > and an internal drive. Qubes offers enough to keep on tryin'. > > Thankfully I run things in a relatively "amnesiac" fashion to start with, > so any useful or valuable data was on a separate, internal, encrypted hard > drive, and unharmed. > > Thanks. > >> johnyju...@sigaint.org: >>> Well, my wild enthusiasm with Qubes has turned into complete >>> frustration >>> and exasperation this morning. >>> >>> The "mild" corruption I was seeing on boot (running Qubes from a USB >>> 2.5" >>> HD) wasn't quite so mild the last time I booted. >>> >>> This time, rather than "recovering journal... done," the fsck spewed >>> more >>> than I've ever seen an fsck spew, and the filesystem was trashed. /var >>> ended up as a symlink to liblber-2.4.so.2.10.2. I found /var/lib/qubes >>> in >>> lost+found (along with 350 other directories). Argh! >>> >>> I'd highly recommend that nobody run Qubes 3.1 from an external USB >>> drive. >>> >>> I'm going back to another OS as my daily system. >>> >>> I'll probably give Qubes 3.2rc a try on an internal hard drive, as a >>> secondary OS, to see if that solves my HD and video corruption issues. >>> If >>> not, I'll probably wait for Qubes to mature a bit more before using it >>> in >>> any serious manner. >> >> I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive >> (for about a month each). 3.0rc1 encountered kernel panics about once >> per day (which wasn't the case when run from an internal drive) and >> booted much slower than from an internal drive, but I didn't notice any >> obvious drive corruption from it. 3.2rc1 had no issues whatsoever and >> wasn't much slower than internal. I haven't tried any release of 3.1. >> >> So, my guess is that the issue you're encountering either was fixed >> between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in >> some way unique to your setup. Maybe a hardware issue? >> >> Cheers, >> -Jeremy Rand >> >> -- >> You received this message because you are subscribed to the Google >> Groups >> "qubes-users" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an >> email to qubes-users+unsubscr...@googlegroups.com. >> To post to this group, send email to qubes-users@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/qubes-users/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/242ab62b9fdfba9c77ebf9748842b412.webmail%40localhost. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4a81af3ff3636f8193043810d9c82678.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB Root Drive Corruption
Thanks for the feedback. The fact USB is a bad idea all around for security (and potentially stability), and the fact I was getting minor corruption, should have been a warning to me to move the drive right onto the SATA bus, rather than risking worse corruption. I guess I only have myself to blame. I guess I'll "get back on the horse," lol, with the 3.2 release candidate, and an internal drive. Qubes offers enough to keep on tryin'. Thankfully I run things in a relatively "amnesiac" fashion to start with, so any useful or valuable data was on a separate, internal, encrypted hard drive, and unharmed. Thanks. > johnyju...@sigaint.org: >> Well, my wild enthusiasm with Qubes has turned into complete frustration >> and exasperation this morning. >> >> The "mild" corruption I was seeing on boot (running Qubes from a USB >> 2.5" >> HD) wasn't quite so mild the last time I booted. >> >> This time, rather than "recovering journal... done," the fsck spewed >> more >> than I've ever seen an fsck spew, and the filesystem was trashed. /var >> ended up as a symlink to liblber-2.4.so.2.10.2. I found /var/lib/qubes >> in >> lost+found (along with 350 other directories). Argh! >> >> I'd highly recommend that nobody run Qubes 3.1 from an external USB >> drive. >> >> I'm going back to another OS as my daily system. >> >> I'll probably give Qubes 3.2rc a try on an internal hard drive, as a >> secondary OS, to see if that solves my HD and video corruption issues. >> If >> not, I'll probably wait for Qubes to mature a bit more before using it >> in >> any serious manner. > > I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive > (for about a month each). 3.0rc1 encountered kernel panics about once > per day (which wasn't the case when run from an internal drive) and > booted much slower than from an internal drive, but I didn't notice any > obvious drive corruption from it. 3.2rc1 had no issues whatsoever and > wasn't much slower than internal. I haven't tried any release of 3.1. > > So, my guess is that the issue you're encountering either was fixed > between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in > some way unique to your setup. Maybe a hardware issue? > > Cheers, > -Jeremy Rand > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/242ab62b9fdfba9c77ebf9748842b412.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB Root Drive Corruption
johnyju...@sigaint.org: > Well, my wild enthusiasm with Qubes has turned into complete frustration > and exasperation this morning. > > The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5" > HD) wasn't quite so mild the last time I booted. > > This time, rather than "recovering journal... done," the fsck spewed more > than I've ever seen an fsck spew, and the filesystem was trashed. /var > ended up as a symlink to liblber-2.4.so.2.10.2. I found /var/lib/qubes in > lost+found (along with 350 other directories). Argh! > > I'd highly recommend that nobody run Qubes 3.1 from an external USB drive. > > I'm going back to another OS as my daily system. > > I'll probably give Qubes 3.2rc a try on an internal hard drive, as a > secondary OS, to see if that solves my HD and video corruption issues. If > not, I'll probably wait for Qubes to mature a bit more before using it in > any serious manner. I've run Qubes 3.0rc1 and Qubes 3.2rc1 from an external USD hard drive (for about a month each). 3.0rc1 encountered kernel panics about once per day (which wasn't the case when run from an internal drive) and booted much slower than from an internal drive, but I didn't notice any obvious drive corruption from it. 3.2rc1 had no issues whatsoever and wasn't much slower than internal. I haven't tried any release of 3.1. So, my guess is that the issue you're encountering either was fixed between 3.1 and 3.2rc1 (and didn't seem to exist in 3.0rc1), or is in some way unique to your setup. Maybe a hardware issue? Cheers, -Jeremy Rand -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/df5ff24c-c6ce-8dda-dfac-5f07bea4f9c0%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] USB Root Drive Corruption
Well, my wild enthusiasm with Qubes has turned into complete frustration and exasperation this morning. The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5" HD) wasn't quite so mild the last time I booted. This time, rather than "recovering journal... done," the fsck spewed more than I've ever seen an fsck spew, and the filesystem was trashed. /var ended up as a symlink to liblber-2.4.so.2.10.2. I found /var/lib/qubes in lost+found (along with 350 other directories). Argh! I'd highly recommend that nobody run Qubes 3.1 from an external USB drive. I'm going back to another OS as my daily system. I'll probably give Qubes 3.2rc a try on an internal hard drive, as a secondary OS, to see if that solves my HD and video corruption issues. If not, I'll probably wait for Qubes to mature a bit more before using it in any serious manner. By chance, I did manage to stash away the dmesg from the last failed boot, before the fsck destroyed the filesystem. Just for posterity, some system details: - Qubes 3.1 - USB->Sata controller was ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge - AMD64 dual core system, 4G RAM - Drive was a Samsung HM500LI Qubes reported errors on it during the excitement, but repeated badblocks scans from Tails showed zero errors on the drive. Relevant portions from the dmesg save: ... [Wed Aug 17 06:42:41 2016] usb 1-8: new high-speed USB device number 6 using ehci-pci [Wed Aug 17 06:42:41 2016] usb 1-8: New USB device found, idVendor=152d, idProduct=2329 ... [Wed Aug 17 06:42:41 2016] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [Wed Aug 17 06:42:41 2016] usb 1-8: Product: USB to ATA/ATAPI Bridge [Wed Aug 17 06:42:41 2016] usb 1-8: Manufacturer: JMicron [Wed Aug 17 06:42:41 2016] usb 1-8: SerialNumber: [Wed Aug 17 06:42:41 2016] usb-storage 1-8:1.0: USB Mass Storage device detected [Wed Aug 17 06:42:41 2016] usb-storage 1-8:1.0: Quirks match for vid 152d pid 2329: 8020 [Wed Aug 17 06:42:41 2016] scsi host7: usb-storage 1-8:1.0 ... [Wed Aug 17 06:42:41 2016] scsi 4:0:0:0: Direct-Access SAMSUNG HM500LI PQ: 0 ANSI: 2 CCS [Wed Aug 17 06:42:41 2016] sd 4:0:0:0: Attached scsi generic sg2 type 0 [Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB) [Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Write Protect is off [Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Mode Sense: 34 00 00 00 [Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [Wed Aug 17 06:42:41 2016] sdb: sdb1 sdb2 [Wed Aug 17 06:42:41 2016] sd 4:0:0:0: [sdb] Attached SCSI disk ... [Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): INFO: recovery required on readonly filesystem [Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): write access will be enabled during recovery [Wed Aug 17 06:42:52 2016] EXT4-fs warning (device dm-2): ext4_clear_journal_err:4737: Filesystem error recorded from previous mount: IO failure [Wed Aug 17 06:42:52 2016] EXT4-fs warning (device dm-2): ext4_clear_journal_err:4738: Marking fs in need of filesystem check. [Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): recovery complete [Wed Aug 17 06:42:52 2016] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [Wed Aug 17 06:42:53 2016] systemd-journald[84]: Received SIGTERM ... [Wed Aug 17 06:43:04 2016] Adding 3948540k swap on /dev/mapper/qubes_dom0-swap. Priority:-1 extents:1 across:3948540k FS [Wed Aug 17 06:43:17 2016] EXT4-fs (dm-2): re-mounted. Opts: (null) [Wed Aug 17 06:43:17 2016] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [Wed Aug 17 06:43:17 2016] systemd-journald[638]: Received request to flush runtime journal from PID 1 [Wed Aug 17 06:43:18 2016] sd 4:0:0:0: [sdb] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [Wed Aug 17 06:43:18 2016] sd 4:0:0:0: [sdb] CDB: Write(10) 2a 00 1d 4c 41 a8 00 00 08 00 [Wed Aug 17 06:43:18 2016] blk_update_request: I/O error, dev sdb, sector 491536808 [Wed Aug 17 06:43:18 2016] Aborting journal on device dm-2-8. [Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2): ext4_journal_check_start:56: Detected aborted journal [Wed Aug 17 06:43:18 2016] EXT4-fs (dm-2): Remounting filesystem read-only [Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2): ext4_journal_check_start:56: Detected aborted journal [Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2): ext4_journal_check_start:56: Detected aborted journal [Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2): ext4_journal_check_start:56: Detected aborted journal [Wed Aug 17 06:43:18 2016] EXT4-fs error (device dm-2): ext4_journal_check_start:56: Detected aborted journal ... [Wed Aug 17 06:50:11 2016] EXT4-fs (dm-4): recovery complete [Wed Aug 17 06:50:11 2016] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null) - The sys
Re: [qubes-users] USB Root Drive Corruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-12 15:31, johnyju...@sigaint.org wrote: > I realize USB drives (or USB *anything*) is a stupid, stupid idea when it > comes to being security conscious, but while trying out Qubes, I do have my > root drive on an external USB HD. > > (And there's something to be said for taking your drive with you.) > > It works great in general, is fast enough, and seems very reliable. > > Until shutdown time. > > Things seem to shut down okay, but on the following boot, I see complaints > about the disk errors on the journal; it does a FSCK but fails and goes > into Read-Only mode, which prevents proper system startup, so most of the > system just sits there doing nothing, presumably waiting for the root drive > to go rw, which it never does. > > Doing an fsck from a console terminal on the ro partition notes the journal > repair required, does its work, and says everything is ducky. > > Then I reboot, and get the same problem. > > If I reboot into Tails, do the cryptsetup, lvmchange, fsck to tidy up the > drive, and *then* reboot, the system will start up okay. > > So every time I reboot the system, I need to first boot into Tails to > repair the drive, to get back into Qubes. More than a minor inconvenience, > and booting other OS's always adds to the risk of compromise. > > I'll try moving the drive onto the SATA bus and see if the problem goes > away, just to verify that it's a USB-only thing. > > It's also a bit weird that it gives a disk error (IO Buffer error I think). > I've badblocks scanned the drive repeatedly, and its healthy and fine, not > a bad sector to be found. But something in the Qubes shutdown/startup is > making Qubes think there's some bad sectors (maybe a problem the luks or > lvm level? The ext4/lvm/luks/usb layering might not be shutting down > elegantly.) > > (At boot, things fly by pretty quickly, and where the system crashes, I > don't have the logs stored in a file, but it almost appears to me that more > than one fack gets run [perhaps stepping on each other]. That's just a > hunch though, I'll try to narrow it down more. The fact the journal needs > recovering at all after a normal shutdown still remains a problem.) > > System is an AMD64 with 4G memory, JMicron SATA->USB Controller on a 2.5" > 500G Samsung drive. > > JJ > Thanks for the report. Tracking here: https://github.com/QubesOS/qubes-issues/issues/2245 Please let us know how it goes when you try moving the drive onto the SATA bus. By the way, have you tested this on any other hardware (e.g., different SATA->USB controller)? - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXrsp5AAoJENtN07w5UDAw9nIQAKmmvfzSRoZyprxr29UM4kCh QVfPKUoOVo6aXE3YJVDJebhQQmvbKlzlTcGaYTWZYIdwg9I/Ugpo/DtutlwptMfP xRZ4wUDMkGMA3/Z8iE1R7+sdCCx7R3QPktmZAcUJwnOlQ2HcYkX83xgbnWPChL0/ 22uiaM3XXJdPs0AQvnLPHU7eeIajJo7a7Yqiqiid/SAcUYzKenDpqcdwTv29VIi8 mhwo2hntEqV2aYCBsVgMGL8jNh++Kq2c2+TgU1ZYXNLwwWDLQfr6Jy9kMaVBh+uQ Z5dFtbaxnOZNsX+fxbY6N/LBkXrNYR67vK28wNY6oPeQrCBgHy1/bQ9WMlnsgL++ /pFQwhAKCheq8NpVVzTyWU3XlHPx5th3z9CMkX1YMUbIU0D28dcUOXf0Rx5ZTAdX znc/7cdgfkKUwONm90Pip2bAV0uC3qAlJUIn4S7CITsJiyl0zjlLl7bMECG74Z1i 27WnPMS0iwoD646iACYSJ21YDusfolQmIAI/RsvVVDK7qEdCgNsdLRFeFABN95jO 37Gpwd+OrQmx+Y27se7dSsODpXWj6/9gbgZSS1cpH4G1+hV8LEJdM2eV0mhNsIcx ALQmG3NpmDpxOBkRhhe6paFiEeiOAcLLcoO39ehPNGhE3ahp5dQUZ5cvUCy1Lw8F kiuWm6Os+3j/BOvK4Nwo =XDnZ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3effc0e9-4513-cce2-e6fb-0a175bd58aec%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] USB Root Drive Corruption
I realize USB drives (or USB *anything*) is a stupid, stupid idea when it comes to being security conscious, but while trying out Qubes, I do have my root drive on an external USB HD. (And there's something to be said for taking your drive with you.) It works great in general, is fast enough, and seems very reliable. Until shutdown time. Things seem to shut down okay, but on the following boot, I see complaints about the disk errors on the journal; it does a FSCK but fails and goes into Read-Only mode, which prevents proper system startup, so most of the system just sits there doing nothing, presumably waiting for the root drive to go rw, which it never does. Doing an fsck from a console terminal on the ro partition notes the journal repair required, does its work, and says everything is ducky. Then I reboot, and get the same problem. If I reboot into Tails, do the cryptsetup, lvmchange, fsck to tidy up the drive, and *then* reboot, the system will start up okay. So every time I reboot the system, I need to first boot into Tails to repair the drive, to get back into Qubes. More than a minor inconvenience, and booting other OS's always adds to the risk of compromise. I'll try moving the drive onto the SATA bus and see if the problem goes away, just to verify that it's a USB-only thing. It's also a bit weird that it gives a disk error (IO Buffer error I think). I've badblocks scanned the drive repeatedly, and its healthy and fine, not a bad sector to be found. But something in the Qubes shutdown/startup is making Qubes think there's some bad sectors (maybe a problem the luks or lvm level? The ext4/lvm/luks/usb layering might not be shutting down elegantly.) (At boot, things fly by pretty quickly, and where the system crashes, I don't have the logs stored in a file, but it almost appears to me that more than one fack gets run [perhaps stepping on each other]. That's just a hunch though, I'll try to narrow it down more. The fact the journal needs recovering at all after a normal shutdown still remains a problem.) System is an AMD64 with 4G memory, JMicron SATA->USB Controller on a 2.5" 500G Samsung drive. JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0ec3b77ca1c05033fa0d73792eff9b7c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
