Re: Controlling power settings for external USB disk drives using sdparm

[Jesse Molina]

Update to this:

In the message below, I said that setting "SCT=18000" would be a 15 
minute spindown, but this does not appear to be correct.


I suspect this parameter is like the hdparm -S argument, which is 
non-linear.


I have confirmed that SCT=1200 is 1-minute, and SCT=3000 is 5-minutes.

I tested with SCT=9000 but about two hours later the drive is still 
spinning.


If you want a spindown time longer than 5-minutes, you'll have to figure 
it out yourself, because I have no idea.


Additionally, I wrote the following compound "--set" command below:
"sdparm --flexible -6 -l --set SCT=18000 --set STANDBY=1 /dev/sdb"

This doesn't appear to work right, even though the man page says it's 
possible and there are no errors. If you issue the set commands 
independently though, it works:


sdparm --flexible -6 -l --set SCT=18000 /dev/sdb
sdparm --flexible -6 -l --set STANDBY=1 /dev/sdb



Notes updated with corrections:

# Show your disks and devices
udisksctl status
udisksctl info -b /dev/sdb

# Interogate the device to collect info:
sudo sdparm --flexible -6 -l -i /dev/sdb
sudo sdparm --flexible -6 -l -i -a /dev/sdb

# Show all of the parameters/settings:
sudo sdparm --flexible -6 -l -a /dev/sdb

# Immediately start and stop the disk:
sudo sdparm --readonly --command=stop /dev/sdb
sudo sdparm --command=start /dev/sdb
# Per the hdparm man page, It may be necessary to mark the disk 
as "offline" with:

#   sudo bash -c 'echo offline > /sys/block/sdb/device/state'
# Normalize with:
#   sudo bash -c 'echo running > /sys/block/sdb/device/state'

# Get the auto-spindown parameter current settings:
sudo sdparm --flexible -6 -l --get SCT /dev/sdb
sudo sdparm --flexible -6 -l --get STANDBY /dev/sdb
# SCT = spindown timer in 100 miliseconds.
# NOTE: The sdparm man page says SCT is measured in 100ms. but 
for my Seagate drive, it varies.
# STANDBY = the spindown timer on/off switch. 0=off (never spin 
down), 1=on (spin down to timer)

# These were my default values on my ST4000DM000:
#  STANDBY 0  [cha: y, def:  1, sav:  1]
#  SCT   4294967286  [cha: y, def:9000, sav:9000]
# This means the device NEVER spins down by default.

# Set the auto-spindown parameters to spin down after 5 minutes of 
inactivity:

sudo sdparm --flexible -6 -l --set SCT=3000 /dev/sdb
sudo sdparm --flexible -6 -l --set STANDBY=1 /dev/sdb
# NOTE: this these settings are lost on reboot.

# Set and save the auto-spindown parameters to spin down after 5 minutes 
of inactivity:

sudo sdparm --flexible -6 -l --save --set SCT=3000 /dev/sdb
sudo sdparm --flexible -6 -l --save --set STANDBY=1 /dev/sdb
# NOTE: Values will be saved to the device and *should* be 
retained between reboots and host moves.
# NOTE: My Seagate ST4000DM000 failed to save settings. Not all 
drives will support this.




On 8/4/15 3:09, Jesse Molina wrote:


Hi everyone

I wanted to post, for posterity, what I recently learned while playing 
with my new external USB3 disk drive.


I needed to control the power settings for this drive. I noticed that 
it was never ever spinning down, so I wanted to be able to either 
power in up/down on command, or have it automatically spin down after 
a period of inactivity. In the end, I was able to do both.


My device is a Seagate ST4000DM000. This should probably work for 
similar Seagate enclosures, like the STEB2000100, STEB3000100, and 
STEB5000100.


I wasn't able to get hdparm to work with my device at all, but that 
should probably be your first step. See if "hdparm -i" works, then do 
a -I, then try setting the spin-down with -S.


I had to use the sdparm tool instead, and the notes here reflect what 
worked for me.


WARNING: Use the /dev/disk/by-id path for USB devices, not 
letter-device path like the sdb example I used below.


# Show your disks and devices
udisksctl status
udisksctl info -b /dev/sdb

# Interogate the device to collect info:
sudo sdparm --flexible -6 -l -i /dev/sdb
sudo sdparm --flexible -6 -l -i -a /dev/sdb

# Show all of the parameters/settings:
sudo sdparm --flexible -6 -l -a /dev/sdb

# Immediately start and stop the disk:
sudo sdparm --readonly --command=stop /dev/sdb
sudo sdparm --command=start /dev/sdb
# Per the hdparm man page, It may be necessary to mark the 
disk as "offline" with:

#   sudo bash -c 'echo offline > /sys/block/sdb/device/state'
# Normalize with:
#   sudo bash -c 'echo running > /sys/block/sdb/device/state'

# Get the auto-spindown parameter current settings:
sudo sdparm --flexible -6 -l --get SCT /dev/sdb
sudo sdparm

Re: Bizarre issue: USB 3 disconnecting and dying

[Jesse Molina]

Hey David, did you ever get this figured out?

Did you ever inspect the device parameters via sdparm or hdparm?

I have *heard* of some Seagate devices disappearing when they go into 
suspend, but your problem doesn't sound like this issue since it happens 
in the middle of writing. Still, I thought I'd mention it.


My experience with hdparm on USB devices isn't good, but it works for 
some people. hdparm -I that thing.


For sdparm, do this:
sudo sdparm --flexible -6 -l -a /dev/sdb

You might be able/need to remove "--flexible" and "-6". Those are 
compatibility options that some of my devices need.


Good luck to you!



On 7/22/15 16:20, David Fuchs wrote:



On Wed, Jul 22, 2015 at 3:17 PM, Håkon Alstadheim 
mailto:ha...@alstadheim.priv.no>> wrote:


How long are your USB-cables? What kind of power supply do you
have, and what else is drawing power?

The USB cable the drive is currently on is fairly short - about 80cm 
if I had to guess. The drive has its own wall-wart specced at 2A 
(12V). There's nothing plugged into the USB ports that would draw 
power (the only other device plugged in is a UPS).



I just went from a PSU specced at 5x the needed sustained power to
10x . Got a slight but definite improvement in USB stability. Yes,
my system is drawing ~ 150w from a 1200w supply. Externally
powered hubs were no help. 5v is specced at 30amps max. I still
get drop-outs , very rarely reqiuring hard boot now, except if I
try the multi-media-keys on my back-lit usb2.0 keyboard.

The host is powered by a 300W  Fortron SFX PSU, which should be about 
5-6x of actual power draw. It's plugged into the UPS so power should 
be fairly stable... but you do bring up a good point, the PSU is one 
element I hadn't considered. Might try to swap that out, too, when I 
get a chance.




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org 
Archive:

https://lists.debian.org/fa2b0565-1df4-4fbc-b280-8866b2083...@alstadheim.priv.no





--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/55c0814b.4090...@opendreams.net

Controlling power settings for external USB disk drives using sdparm

[Jesse Molina]

Hi everyone

I wanted to post, for posterity, what I recently learned while playing 
with my new external USB3 disk drive.


I needed to control the power settings for this drive. I noticed that it 
was never ever spinning down, so I wanted to be able to either power in 
up/down on command, or have it automatically spin down after a period of 
inactivity. In the end, I was able to do both.


My device is a Seagate ST4000DM000. This should probably work for 
similar Seagate enclosures, like the STEB2000100, STEB3000100, and 
STEB5000100.


I wasn't able to get hdparm to work with my device at all, but that 
should probably be your first step. See if "hdparm -i" works, then do a 
-I, then try setting the spin-down with -S.


I had to use the sdparm tool instead, and the notes here reflect what 
worked for me.


WARNING: Use the /dev/disk/by-id path for USB devices, not letter-device 
path like the sdb example I used below.


# Show your disks and devices
udisksctl status
udisksctl info -b /dev/sdb

# Interogate the device to collect info:
sudo sdparm --flexible -6 -l -i /dev/sdb
sudo sdparm --flexible -6 -l -i -a /dev/sdb

# Show all of the parameters/settings:
sudo sdparm --flexible -6 -l -a /dev/sdb

# Immediately start and stop the disk:
sudo sdparm --readonly --command=stop /dev/sdb
sudo sdparm --command=start /dev/sdb
# Per the hdparm man page, It may be necessary to mark the disk 
as "offline" with:

#   sudo bash -c 'echo offline > /sys/block/sdb/device/state'
# Normalize with:
#   sudo bash -c 'echo running > /sys/block/sdb/device/state'

# Get the auto-spindown parameter current settings:
sudo sdparm --flexible -6 -l --get SCT /dev/sdb
sudo sdparm --flexible -6 -l --get STANDBY /dev/sdb
# SCT = spindown timer in 100 miliseconds.
# NOTE: The sdparm man page says SCT is measured in 100ms. but 
for my Seagate drive, it's actually 1=50ms.
# STANDBY = the spindown timer on/off switch. 0=off (never spin 
down), 1=on (spin down to timer)

# These were my default values on my ST4000DM000:
#  STANDBY 0  [cha: y, def:  1, sav:  1]
#  SCT   4294967286  [cha: y, def:9000, sav:9000]
# This means the device NEVER spins down by default.

# Set the auto-spindown parameters to spin down after 15 minutes of 
inactivity (assuming SCT=50ms instead of 100ms):

sudo sdparm --flexible -6 -l --set SCT=18000 /dev/sdb
sudo sdparm --flexible -6 -l --set STANDBY=1 /dev/sdb
# NOTE: this these settings are lost on reboot.

# Set the auto-spindown parameters to spin down after 15 minutes of 
inactivity (assuming SCT=50ms instead of 100ms):

sudo sdparm --flexible -6 -l --save --set SCT=18000 /dev/sdb
sudo sdparm --flexible -6 -l --save --set STANDBY=1 /dev/sdb
# NOTE: Values will be saved to the device and *should* be 
retained between reboots and host moves.
# NOTE: My Seagate ST4000DM000 failed to save settings. Seagate 
sucks. Whatever.




Finally, I put this in my /etc/rc.local to set on boot:

sdparm --flexible -6 -l --set SCT=18000 --set STANDBY=1 /dev/sdb


I hope this helps someone. The HOWTOs and examples I found while 
searching the internet didn't really help me that much. I had to do a 
lot of experimenting before I discovered that this device would not 
really talk to me without "--flexible -6" being set, and that 
"--readonly" was required with the stop command (or it just spun right 
back up).


If you have any feedback or corrections, let me know!



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/55c08f71.1070...@opendreams.net

Re: reboot and poweroff fails on Zotac ZBOX Nano CI320

[Jesse Molina]

I have resolved my problem.  I will document here to help out anyone 
else who has this issue in the future.


This is a Zotac ZBOX Nano CI320 (ZBOX-CI320NANO).
My BIOS version is "B219P 026 x64" with a date of "05/19/2015". That is 
current as I write this. I also saw this problem with previous versions 
of BIOS.


The root cause of the problem was that I set the "Boot Mode" to "Legacy 
Only" and "OS Selection" to "Windows 7". Instead, set it to "Windows 8.X".


I saw the following problems when the OS Selection was Windows 7:
Reboots, poweroff, suspend, and hibernate all hung.
Installation of Debian and Ubuntu hangs on "Running dpkg" under 
"Select and install software".


When set to "Windows 8.X", The system reboots Linux as expected.



Be sure to update the BIOS if you have not already. I used FreeDOS on a 
USB flash drive made with unetbootin. Copy the firmware .zip files onto 
the root of the flash drive. Boot into FreeDOS and load no drivers (Safe 
Mode). Type "cd C:" and then you should see the files there. Run the 
"batch.bat" file and that should update the firmware.


There is also a USB hub firmware upgrade available for this system, but 
I wouldn't bother since it requires Windows 7 to install, and I had a 
lot of problems doing it.


Beware that these BayTrail-M systems (Intel NUC, Gigabyte BRIX, HP 
Stream, Asus ChromeBox, Asus Vivo, and a huge number of laptops) have a 
large number of reported problems with USB also causing problems:


About the reboot hang issue with EHCI driver on the Baytrail platform
http://www.spinics.net/lists/linux-usb/msg112624.html

[SOLVED] Random hang/freze on reboot/shutdown/suspend, only under Arch
https://bbs.archlinux.org/viewtopic.php?id=192821



On 6/25/15 2:42, Jesse Molina wrote:


Hi all

I have a new Zotac ZBOX Nano CI320. It's a mini-PC based on an Intel 
Celeron N2930 (Bay Trail).


This has been a very problematic system. I blame my troubles on the 
less-than-quality Zotac (AMI) BIOS.


My current problem is that the system will not reboot or poweroff 
correctly. It just hangs.


I have upgraded the BIOS to the current version, which fixed a lot of 
other issues, but not this one.


I've confirmed this bad reboot/poweroff behavior on Debian 8.1 and the 
current unstable. One thing to note is that I was having some 
intermittent success adding the kernel argument "reboot=bios" on 
Debian 8.1, but now that I've upgraded to unstable, it's not working 
any more. I need to do more testing to verify what works and what 
doesn't, but everything is mostly not-working.


I also confirmed this bad behavior with the current Fedora release.

Interestingly, the current Linux Mint seems to reboot and poweroff 
normally:

http://www.linuxmint.com/edition.php?id=172

Other than testing various linux "reboot=" arguments, what other 
things should I look into?


For permanent application, that reboot= would go into 
/etc/default/grub, right?


Any other advice before I bug this?

Thanks for reading.





--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/558e0b97.8020...@opendreams.net

reboot and poweroff fails on Zotac ZBOX Nano CI320

[Jesse Molina]

Hi all

I have a new Zotac ZBOX Nano CI320. It's a mini-PC based on an Intel 
Celeron N2930 (Bay Trail).


This has been a very problematic system. I blame my troubles on the 
less-than-quality Zotac (AMI) BIOS.


My current problem is that the system will not reboot or poweroff 
correctly. It just hangs.


I have upgraded the BIOS to the current version, which fixed a lot of 
other issues, but not this one.


I've confirmed this bad reboot/poweroff behavior on Debian 8.1 and the 
current unstable. One thing to note is that I was having some 
intermittent success adding the kernel argument "reboot=bios" on Debian 
8.1, but now that I've upgraded to unstable, it's not working any more. 
I need to do more testing to verify what works and what doesn't, but 
everything is mostly not-working.


I also confirmed this bad behavior with the current Fedora release.

Interestingly, the current Linux Mint seems to reboot and poweroff normally:
http://www.linuxmint.com/edition.php?id=172

Other than testing various linux "reboot=" arguments, what other things 
should I look into?


For permanent application, that reboot= would go into /etc/default/grub, 
right?


Any other advice before I bug this?

Thanks for reading.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/558bcd20.1050...@opendreams.net

Re: linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

As previously noted, this was a bug in mdadm and has already been fixed 
in the current version.  Just update your mdadm package and then 
re-build your initramfs file with the "update-initramfs" command.  Be 
sure to read the manpage for that command.  Probably "update-initramfs 
-u" alone will fix your problem.


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726237

This problem never had anything to do with the linux-image package. It 
was actually just a bad mdadm udev rule file.  It just happened to me 
when I updated my kernel, since it generated a new initramfs file to go 
along with it.




On 10/17/13 7:54 AM, Jogi Hofmüller wrote:

Dear all,

We ran into the same (or a similar) problem yesterday and could not fix
it until now.  The machine in question was setup using wheezy and then
upgraded to jessie.  Since the only kernel 3.2 will boot, anything else
fails.

The setup is as follows:

* one raid10
* lvm lvs for / /boot

/etc/mdadm/mdadm.conf is present in the initramfs.

As reported by others the boot process drops into initramfs shell
complaining about not finding /dev/vg0/rootfs.  The array is never
assembled, hence no pv, vg, lv ...

We tried linux-image-3.10-2-amd64 and linux-image-3.10-3-amd64.  mdadm
is 3.2.5-5.

Cheers!

PS:  Please include my address in your reply since I am not subscribed
to the list.  Thanx.



--
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/5260f2d1.1010...@opendreams.net

Re: Question for you network/DNS/Apache gurus;

[Jesse Molina]

Sounds like your Apache config may not be correct.  You should post the 
relavant portion.


You need to elaborate on "It opens the startup page but will do nothing 
else.".  What is a startup page?  Nobody but you knows what this means.



On 10/15/13 11:50 AM, John W. Foster wrote:

I have a web site established on a remote hosted VPS server system.
I have full root access.
I use Debian linux on my personal system (wheezy) & on the remotely
hosted site (squeeze).
I use Godaddy as my domain registrar.
I have the domain for the remotely hosted VPS site set up at Godaddy.
I have the exact IP address set up there to forward to the VPS site with
masking.
I have a tarball based mediawiki set up on the VPS site in /var/www/
There are no links in /var/www/ to the site, the opening page is
index.php & is in this directory.
I simply use the "/sites-enabled/default" in apache2 to send web queries
to the VPS site.

Up to here all seems to work OK.
Here is the issue.
When I try to access the mediawiki for configuration, using
http://my.mediawiki.net (example)  the site will not work as it should.
It opens the startup page but will do nothing else.
When I access the site with http:// 123.123.123.123 (example numerical
IP address) the VPS site allows the mediawiki to run the configuration &
setup as it should.

This is my first attempt to manage a remote site so I really need
advice.
Any Tips are appreciated & BTW I did ask these questions on the
Mediawiki site, but alas no help there.
john





--
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/525da383.3020...@opendreams.net

Re: linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

This is confimed bug # 726237.  It's actually mdadm.  Bad udev rule file.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726237



On 10/12/13 2:40 AM, Jesse Molina wrote:


Hi

I have a Debian unstable host which successfully boots from the 
linux-image-3.10-1-amd64 kernel package.  However, I recently 
installed the linux-image-3.10-3-amd64 kernel package, and it is 
unbootable.


When I boot from the linux-image-3.10-3-amd64 package kernel, the boot 
fails and drops me into the initramfs busybox.  The messge "Gave up 
waiting for the root device." appears, along with "ALERT! 
/dev/disk/by-uuid/bla-bla-bla-my-id-here does not exist.".


The problem appears to be that udev is not creating 
/dev/disk/by-uuid/* and similar objects.  The only directory being 
created in /dev/disk is "by-id".  Note that the mdadm arrays are being 
successfully assembled and I can see them if I cat /proc/mdstat.


the root= argument in grub is a UUID of a mdadm RAID1 array.  This 
host's boot part is a RAID1, and the root part is a RAID5.  This is 
standard PC desktop hardware with four disk drives upon which the md 
RAIDs are built.


The host has been dist-upgraded as of this time.

Advice appreciated.  Otherwise, I'll file a bug on it.






--
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/525bd4e2.4030...@opendreams.net

Re: linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

I did the following today:

Indeed, the /lib/udev/rules.d/60-persistent-storage.rules file does 
exist in the initramfs.


I tried "udevadm control --reload-rules", but there was no output that I 
can use.  I also think I tried it with --debug, and I saw some info, but 
nothing helpful.


I decided to try to rebuild my 3.10-1 initramfs, to see if the newly 
build package would cause the same problems, and indeed it did.  I have 
the old working initramfs, and now a broken one which gives the same 
behavior as the 3.10-3 version.  So, it's not the kernel so much as it's 
something else being packaged on the initramfs.  I'm thinking this is a 
udev problem thus far, but I really don't know that for certain yet.


I'll decompress the initramfs files tomorrow and look at the differences 
between them.


Unfortunately the host in question is important to me, and at a remote 
location, so I can't play with it right now.  I will look into setting 
up a test system though and see if I can duplicate the problem locally.




On 10/12/13 11:58 PM, Jesse Molina wrote:


Okay, this is helpful.  Unfortunately, I don't know a lot about 
Debian's initramfs scripts, and I'm fairly ignorant of udev beyond 
it's basic functions and rule files.  So, advice on basic 
troubleshooting of udev would be helpful to me.


I am going to go play with this system here shortly, so hopefully I 
can discover a little bit more which will be helpful to us.



On 10/12/13 5:12 PM, Tom H wrote:

Since the "by-id" links are being created, I assume that the answer to
the following question will be "yes" but just in case: does
"lib/udev/rules.d/60-persistent-storage.rules" exist in the initramfs?

Can you add a line to "scripts/local" to retrigger the udevadm
creation of the "by-uuid" links? I don't know the  syntax
offhand, sorry. ("udevadm trigger ...)






--
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/525a76e0.3010...@opendreams.net

Re: linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

Okay, this is helpful.  Unfortunately, I don't know a lot about Debian's 
initramfs scripts, and I'm fairly ignorant of udev beyond it's basic 
functions and rule files.  So, advice on basic troubleshooting of udev 
would be helpful to me.


I am going to go play with this system here shortly, so hopefully I can 
discover a little bit more which will be helpful to us.



On 10/12/13 5:12 PM, Tom H wrote:

Since the "by-id" links are being created, I assume that the answer to
the following question will be "yes" but just in case: does
"lib/udev/rules.d/60-persistent-storage.rules" exist in the initramfs?

Can you add a line to "scripts/local" to retrigger the udevadm
creation of the "by-uuid" links? I don't know the  syntax
offhand, sorry. ("udevadm trigger ...)



--
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/525a44a4.2000...@opendreams.net

Re: linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

Nope.  No changes since the original system creation.  Thanks for trying 
though.



On 10/12/13 7:18 PM, Bob Proulx wrote:

Jesse Molina wrote:

As I said before, the md RAIDs are being assembled.  udev, or
something else, is failing to properly create the device nodes.

A shot in the dark but...  Have you added a new md device recently but
forgotten to update the /etc/mdadm/mdadm.conf file?  The initrd
creation will only have the information about it if it is in that
file.  If the root file system depends upon it then it won't be able
to boot in that case.  This is usually when the root file system is on
LVM and LVM includes several physical volumes in the volume group and
a new md is added to the volume group.  As I said, a shot in the dark.

Bob



--
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/525a22be.8030...@opendreams.net

Re: linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

That's a good idea, but this system already had a rootdelay=5 
configured, and I even raised it to 15 during testing with no effect 
upon the situation.


I have had problems on a different host using md RAID5 as it's boot 
array, which requires a rootdelay on the 3.8 and 3.10 kernels. There are 
some bugs out there with my name on them regarding this.


Reference bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718533
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678696

And this is the long-term solution which needs to be implemented:
https://wiki.debian.org/InitramfsEventBased

Anyway, the above doesn't seem to be the problem.

As I said before, the md RAIDs are being assembled.  udev, or something 
else, is failing to properly create the device nodes.




On 10/12/13 8:22 AM, Hugo Vanwoerkom wrote:

Jesse Molina wrote:


Hi

I have a Debian unstable host which successfully boots from the 
linux-image-3.10-1-amd64 kernel package.  However, I recently 
installed the linux-image-3.10-3-amd64 kernel package, and it is 
unbootable.


When I boot from the linux-image-3.10-3-amd64 package kernel, the 
boot fails and drops me into the initramfs busybox.  The messge "Gave 
up waiting for the root device." appears, along with "ALERT! 
/dev/disk/by-uuid/bla-bla-bla-my-id-here does not exist.".


The problem appears to be that udev is not creating 
/dev/disk/by-uuid/* and similar objects.  The only directory being 
created in /dev/disk is "by-id".  Note that the mdadm arrays are 
being successfully assembled and I can see them if I cat /proc/mdstat.


the root= argument in grub is a UUID of a mdadm RAID1 array. This 
host's boot part is a RAID1, and the root part is a RAID5. This is 
standard PC desktop hardware with four disk drives upon which the md 
RAIDs are built.


The host has been dist-upgraded as of this time.

Advice appreciated.  Otherwise, I'll file a bug on it.


try 'rootdelay=5' (w/o quotes) as bootparam.

Hugo





--
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/5259a33b.8070...@opendreams.net

linux-image-3.10-3-amd64 unbootable: /dev/disk/by-uuid not created

[Jesse Molina]

Hi

I have a Debian unstable host which successfully boots from the 
linux-image-3.10-1-amd64 kernel package.  However, I recently installed 
the linux-image-3.10-3-amd64 kernel package, and it is unbootable.


When I boot from the linux-image-3.10-3-amd64 package kernel, the boot 
fails and drops me into the initramfs busybox.  The messge "Gave up 
waiting for the root device." appears, along with "ALERT! 
/dev/disk/by-uuid/bla-bla-bla-my-id-here does not exist.".


The problem appears to be that udev is not creating /dev/disk/by-uuid/* 
and similar objects.  The only directory being created in /dev/disk is 
"by-id".  Note that the mdadm arrays are being successfully assembled 
and I can see them if I cat /proc/mdstat.


the root= argument in grub is a UUID of a mdadm RAID1 array.  This 
host's boot part is a RAID1, and the root part is a RAID5.  This is 
standard PC desktop hardware with four disk drives upon which the md 
RAIDs are built.


The host has been dist-upgraded as of this time.

Advice appreciated.  Otherwise, I'll file a bug on it.



--
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/52591922.7040...@opendreams.net