# [SOLVED] OpenRC 0.9.0; where did /dev/sda* go?

## RazielFMX

So, I recently upgraded to openrc-0.9.0 (as part of an emerge -puDN world).  I did all the required etc-update stuff (merged conf.d/modules and rc.conf manually to keep my settings) and now my machine will not boot into any sort of usable state.

So, besides init complaing things like 'c4' has respwned to fast, I notice the following things:

1)  Nothing is mounted besides my rootfs.

2)  A mount -a complains all my drive UUIDs do not exist

3)  Using absolute device paths (/dev/sda*) in /etc/fstab and rebooting does not resolve it; I simply get /dev/sda* do not exist.

4)  Since most of my FS is not available, most services won't start (particularly missing /var and /tmp are pretty bad).

A df shows I have udev, shm, rc-svcdir, /dev/root, and rootfs mounted.

I have no clue how to get my system back to a usable state, so any help you can provide would be awesome.  Since the box is pretty foobar, it will be hard for me to get you log files (there are none, no /var/log) or send you config files (I have no ssh at the moment) but I will do my best.

As a first piece of information, an ls  of /dev shows the following:

console

initctl

kmsg

null

pts

shm

tty

tty1-12

Any advice you can give would be very appreciated.Last edited by RazielFMX on Thu Sep 01, 2011 8:02 pm; edited 2 times in total

----------

## RazielFMX

Alright... it looks like the updates to PAM made by the openrc update.  UDEV did not start due to pam error: Authentication failure, failed to start /sbin/udevd.

Any ideas how to fix this?

EDIT:

Specifically I allowed openrc 0.9.0 to overwrite my /etc/pam.d/start-top-daemon to look like this:

```

account required pam_permit.so

session include system-services

```

The one I had used to have four lines.  I'm going to see if I can find the old one and put it back.Last edited by RazielFMX on Thu Sep 01, 2011 7:44 pm; edited 2 times in total

----------

## gerard27

Apparently you're on ~arch.

Openrc-0.90 is masked.

Did you try downgrading to 0.8.3-r1?

Gerard.

----------

## RazielFMX

I'd love to (and am going to ASAP), however I am missing important file systems and can't do much of anything.  I'm about to crack open the old one, pirate the start-stop-daemon settings, reboot, and if I've got disk, I'll downgrade  :Smile: 

----------

## RazielFMX

UPDATE: I pulled the src/rc/start-stop-daemon.pam out of openrc-0.8.3-r1 which I had sitting in /usr/portage/distfiles (I am very glad my /usr lives on rootfs).

```

nightshade rc # pwd

/root/tmp/openrc-0.8.3/src/rc

nightshade rc # cat start-stop-daemon.pam

#%PAM-1.0

auth            required        pam_permit.so

account         required        pam_permit.so

password        required        pam_deny.so

session         optional        pam_limits.so

nightshade rc #

```

I am now downgrading openrc.

----------

## RazielFMX

Downgrade complete.  At some point I'll have to bring this box down to single user mode to cleanup some artifacts on my root disk that belong on other partitions as a result of only having rootfs, but my box is stable.

Thanks for the help!

----------

## avx

Also hit me, posted a bug: https://bugs.gentoo.org/show_bug.cgi?id=381497

----------

## tnt

same problem here.

update to openrc-0.9.1 solved the problem.

it's such a shame this kind of system-breaker slips in the portage  :Sad: 

----------

## asturm

It's ~arch, things like those can happen to us.

Because of this thread I actually knew of the issue right after upgrading yesterday evening, but was too tired to not making the mistake of shutdown before the fixed package hit portage anyway.  :Laughing:  That's when you love your little USB-stick booting the machine with a tailor-made chroot script to fix things in no time.  :Smile: 

----------

## Naib

i just got bitten by this and 0.9 hardly any of the init services were starting. i had downgraded to 0.8.* before i saw this thread

----------

## Fitzcarraldo

Serendipity: I happened to be browsing this thread last night whilst 'emerge -uvDN world' was running on my laptop. Although the merge of openrc-0.9.0 was already in progress at the time, I was able to revert immediately after emerge world finished, thus averting a major panic attack on my part this morning! Thanks for posting RazielFMX.

How on Earth can a severe bug like this get committed to Portage? Didn't someone test the ebuild beforehand?

----------

## asturm

It's ~arch, you know, it can happen. This is the place where obscure bugs can happen all the time, think lvm update that broke boot process for all systems with separate /usr partition.

----------

## Fitzcarraldo

 *genstorm wrote:*   

> It's ~arch, you know, it can happen. This is the place where obscure bugs can happen all the time, think lvm update that broke boot process for all systems with separate /usr partition.

 

Understood, but it's not as if it is an obscure bug. It is an immediate show-stopper of a bug, something that would be apparent immediately. Subtle bugs or bugs that are not immediately apparent I could understand, but committing a package with a bug that would be patently obvious simply by merging the ebuild and rebooting to check it (it's openrc, after all) seems rather remiss to me, ~ arch or not.

----------

## asturm

Yes it's unfortunate, but it's still possible to have passed under the radar as many other bugs that we ~arch users risk to be hit in the face with. That's why you should always know which packages you have been updating, reducing the guessing game (and time) in search of the culprit, have a bootable external medium at hand, fix it, report, and feel good about it afterwards.

----------

## Naib

bu tthis is partly why we do ~arch

for the shinies and for things like this  :Very Happy:  Gentoo gets boring when it just works

----------

