# [SOLVED] Migrated rootfs to a new, booting gets stuck at USB

## shazow

I installed a new SSD and after some partitioning issues I finally got it to work. I used rsync to move most of the rootfs over, excluding things like /dev, /proc, etc of course. Grub2 boots just fine, gives me the correct options after I updated it, but half way through the booting—right after the USB stuff is wrapped up—it hangs.

Looks something like this... (taken from dmesg, so sans the timestamps in reality) 

```

*snip* ...

[    4.467130] usb 6-2: Product: Generic USB Hub

[    4.467170] usb 6-2: Manufacturer:

[    4.473905] hub 6-2:1.0: USB hub found

[    4.475823] hub 6-2:1.0: 3 ports detected

[    4.842804] systemd-udevd[1632]: starting version 215

[    4.971316] usb 2-6.1: new high-speed USB device number 6 using ehci-pci

[    5.058563] usb 2-6.1: New USB device found, idVendor=1415, idProduct=2000

[    5.058567] usb 2-6.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[    5.058570] usb 2-6.1: Product: USB Camera-B3.04.06.1

[    5.058573] usb 2-6.1: Manufacturer: OmniVision Technologies, Inc.

[    5.137829] usb 6-2.1: new full-speed USB device number 4 using uhci_hcd

[    5.268826] usb 6-2.1: New USB device found, idVendor=0dc6, idProduct=9801

[    5.268831] usb 6-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[    5.268834] usb 6-2.1: Product: SCISSORS Keyboard + 2P Hub

[    5.268837] usb 6-2.1: Manufacturer:

[    5.277235] input:      SCISSORS Keyboard + 2P Hub as /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2.1/6-2.1:1.0/0003:0DC6:9801.0005/input/input6

[    5.277303] hid-generic 0003:0DC6:9801.0005: input: USB HID v1.00 Keyboard [     SCISSORS Keyboard + 2P Hub] on usb-0000:00:1d.0-2.1/input0

```

Here it just hangs. I can scroll up/down using my keyboard but nothing else works, not even ctrl+alt+del.

When I boot from the old drive, what usually comes next is...

```

...

[    5.873799] nvidia: module license 'NVIDIA' taints kernel.

[    5.873801] Disabling lock debugging due to kernel taint

[    6.144748] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=none

[    6.145142] [drm] Initialized nvidia-drm 0.0.0 20130102 for 0000:01:00.0 on minor 0

[    6.145150] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.24  Wed Jul  2 14:24:20 PDT 2014

[    6.182113] gspca_main: ov534-2.14.0 probing 1415:2000

[    6.252831] usb 6-1: current rate 30465 is different from the runtime rate 96000

```

 (Full dump from when it works here: http://pastebin.com/bg7LymQD, as far as I can tell all the parts before nvidia are the same.)

Since it hangs right before nvidia's tainting, it makes me think that it's related to nvidia. Any thoughts?

I tried chrooting into the new rootfs from the old rootfs (with the corresponding root dirs mount-bounded of course) and re-installed nvidia-drivers, but it didn't help.

Versions:

- nvidia-drivers 340.24

- gentoo-sources 3.15.6

- grub 2.02_beta2

Relevant grub.conf section:

```

        load_video

        insmod gzio

        insmod part_gpt

        insmod ext2

        set root='hd2,gpt2'

        if [ x$feature_platform_search_hint = xy ]; then

          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 --hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2  7458fa7d-7931-47b4-9c07-414fe6dbe007

        else

          search --no-floppy --fs-uuid --set=root 7458fa7d-7931-47b4-9c07-414fe6dbe007

        fi

        echo    'Loading Linux stable ...'

        linux   /boot/kernel-stable root=/dev/sdc2 ro

```

/dev/sdc is my new SSD drive. Changing root=/dev/sda5 boots the old rootfs without problems.

When I migrated to the SSD, I also switched to gpt (and grub accordingly). Not sure if this is related.

Relevant fstab:

```

/dev/sdc2      /      ext4      defaults,noatime,discard   0  1

/dev/sda5      /mnt/hdd   ext4      noatime      0 1

/mnt/hdd/var      /var      none      bind      0 0

```

I decided to keep /var on the old hard drive for now. /boot is part of the same rootfs partition (it was on a separate partition before).

Any ideas?

Thanks again in advance!  :Smile: Last edited by shazow on Wed Jul 23, 2014 6:04 am; edited 3 times in total

----------

## shazow

Update: Looks like it's not entirely frozen. If I unplug/plug USB devices, this will get printed in the output. So it's still processing events. It's just that whatever is supposed to happen next is not happening.

Any idea what's missing? Is there any way to increase verbose/debugging output? I tried adding `verbose` to the `linux` boot line but it didn't do anything.

----------

## the.root

I assume you created the /dev/, /sys, /proc directories with proper permissions?

It's been many years since i've tried a straight rsync copy, but if I recall correctly I had a similar issue of it hanging during boot. It was either my /dev wasnt there or some device in /dev wasnt there that needed to be - before udev would mount it. It probably doesn't apply, just figured I'd mention it. You can try copying over your old /dev to your new drive then giving it a go. I just booted off a liveusb and checked out my laptop root partition and /dev is populated even though it didn't boot to properly mount udev there. Also the stage3 tar contains /dev entries.

FYI Your pastebin link "has been removed".

----------

## shazow

 *the.root wrote:*   

> I assume you created the /dev/, /sys, /proc directories with proper permissions?

 

Great point. I double-checked and permissions are fine but it looks like I missed mkdir'ing /run altogether. Fixed now, will update what happens next time I reboot.

 *the.root wrote:*   

> FYI Your pastebin link "has been removed".

 

Arg, the comma snuck into the URL. Fixed now.

----------

## shazow

Nope, fixing /run did not do the trick.  :Sad:  Will continue messing with things.

Seeing a lot of forum posts saying "udev is broken for me with the new version", maybe worth trying to downgrade...

----------

## the.root

Did you try copying the contents of your old /dev to your new /dev? I want to say thats what fixed it for me, hard to remember though. Or maybe using the /dev from a stage3 tarball or whatever else you have available.

----------

## shazow

Aha, rsync'ing the contents of /dev totally did the trick, thank you kind the.root!

Marked as solved.

----------

## Goverp

I know this is a necropost but I've had the exact same problem, and fixed it using an up-to-date version of the above solution.  It's a fair bit shorter, as it turns out /dev needs contain only one thing, a console.

Context:

I wanted to resize and change some options on my rootfs.  So I made a tarball of / --one-file-system, recreated the partition and untarred the tarball (all these shenanigans using the Admin version of the Gentoo install CD on a USB key).

Problem:

On reboot, it the last line of console output before it hung was about USB device 1-1.4.  Comparing with the last successful boot, the next line should have been "udev starting".

Solution:

Rebooting into the installation CD and mounting the partition at /mnt/gentoo, I could see that /mnt/gentoo/dev contained a file "console".  Aha, not a character device node.  Replacing it fixed the problem - udev clearly needs a console before it starts.

Note: don't cut and paste the following - I've typed it from memory, not copied it from real life:

```
mount /dev/sda5 /mnt/gentoo

ls -l /mnt/gentoo/dev

-foobar--- 1 root root 220 Jan 28 16:48 console

rm /mnt/gentoo/dev/console

mknod -m 600 /mnt/gentoo/dev/console c 5 1
```

And now it boots.  Phew!

Why tar decided to copy console from /dev despite --one-file-system is a bit odd.

On thinking, it's not odd.  tar copied the files in the real file system, ignoring mounts, so it saw /dev/console.  Except it took its contents as a file, not its definition as a device node.

----------

## Hu

I suspect tar did not copy anything from /dev, and instead that file console was created because some program did udev >/dev/console expecting that such a redirect would open the device node console.  Instead, nothing was at that path, so output was redirected to a newly created file named console.

----------

## Goverp

Well, whatever the cause, /dev needs some things in it for udev to start.  In fact, for it to work properly, it's more than just /dev/console - I forget the message, but something else wasn't working right.  The modern solution is to select CONFIG_DEVTMPFS_MOUNT in the kernel config.  That leaves a populated /dev for udev to play with.

----------

