Re: Hibernate/resume fails after adding SSD to debian 7

2013-09-29 Thread Osamu Aoki
Hi,

On Sun, Sep 29, 2013 at 12:31:01AM -0400, Len Berman wrote:
 I moved my SSD from SATA 1 - SATA 5 and reran update-initramfs.  The
 resume now works.  Don't understand why this should be the case since all
 disks are referenced by their UUIDs.

All tools might not support UUID on your system.  mount may be
isupported but resume scripts, at least, was not supporting UUID before.

Oh, one more thing.

I had problem with my SSD this week.  System root file system became
read-only and crashed badly  I turned out to be the firmware version
issue of Crucial/Micron RealSSD m4/C400/P400 causing problem after 5184
hours of usage. So, you may also wish to check:

$ sudo smartctl -a /dev/sda

or similar.  My case prints:

This drive may hang after 5184 hours of power-on time:\n
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html\n;
See the following web pages for firmware updates:\n
http://www.crucial.com/support/firmware.aspx\n;
http://www.micron.com/products/solid-state-storage/client-ssd#software;,

I see many other drives has firmware bug issues.
/var/lib/smartmontools/drivedb/drivedb.h

Firmware update was iso image so I could do it without having any
windows for my drive. 

Osamu


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130929143008.GD5889@goofy.localdomain



Re: Hibernate/resume fails after adding SSD to debian 7

2013-09-28 Thread Len Berman
I moved my SSD from SATA 1 - SATA 5 and reran update-initramfs.  The
resume now works.  Don't understand why this should be the case since all
disks are referenced by their UUIDs.


Hibernate/resume fails after adding SSD to debian 7

2013-09-27 Thread Len Berman
I added an SSD as follows:
1) added SSD (on SATA 1),
 2) updated /etc/uswsusp.conf,
 3) copied /usr and /opt to  SSD partitions,
 4) modified /etc/fstab to mount /usr  /opt partitions,
 5) ran update-grub2.

And resume fails after hibernate.  It used to work.  If I unplug the SSD,
it still works (after removing new partitions from fstab).

hibernate.log doesn't indicate a problem.  The failure causes journal
recovery on all partitions except /.

Can someone help?  I'm at a loss.  Thanks.

--Len

PS: Please respond directly to me as well as to list.  Thanks.

/var/log/hibernate.log:
Starting suspend at Thu Sep 26 13:40:17 EDT 2013
hibernate: [01] Executing CheckLastResume ...
hibernate: [01] Executing CheckRunlevel ...
hibernate: [01] Executing LockFileGet ...
hibernate: [01] Executing NewKernelFileCheck ...
hibernate: [10] Executing EnsureUSuspendCapable ...
hibernate: [11] Executing XHacksSuspendHook1 ...
hibernate: [59] Executing RemountXFSBootRO ...
hibernate: [89] Executing SaveKernelModprobe ...
hibernate: [91] Executing ModulesUnloadBlacklist ...
hibernate: [95] Executing XHacksSuspendHook2 ...
hibernate: [98] Executing CheckRunlevel ...
hibernate: [99] Executing DoUSuspend ...
hibernate: Running /usr/sbin/s2disk ...



/etc/uswsusp.conf:
resume device = /dev/disk/by-uuid/abec2610-c8d7-4a2c-98f7-cfa2b338fb9b
splash = y
compress = y
early writeout = y
image size = 5.6888e+09
RSA key file = /etc/uswsusp.key
shutdown method = platform

/etc/fstab
UUID=1796cdd5-7bf3-4334-a5cb-7aed099e57f7   /   ext3
 errors=remount-ro 0   1
#SSD
UUID=74c7d1c9-0807-4f40-99bf-55766f9ecaeb   /usrext4
 commit=100,noatime0   1
UUID=e70718c9-ee8a-4679-a486-be8e5be2821a   /optext4
 commit=100,noatime0   1
# /home was on /dev/sda5 during installation
UUID=488cfe1d-439f-45b7-82d0-fb3b31e9b1ee   /home   ext3
 defaults0   2
# swap was on /dev/sda1 during installation
UUID=abec2610-c8d7-4a2c-98f7-cfa2b338fb9b   noneswapsw
 0   0
/dev/sr0/media/cdrom0   udf,iso9660
user,noauto 0   0
/dev/sdd1   /media/usb0 auto
 rw,user,noauto  0   0
UUID=2ffe2063-c413-4cce-9007-a79f1ae9a122   /mnt/2TBext3
 defaults 0   2
UUID=9622-9733  /mnt/dane2GBauto
 rw,user,auto  0   0


--Len Berman