[SOLVED] Installing Arch on usb stick - login to emergency mode only

Archhotep · 2013-03-24 04:21:25

I have checked fstbe which is correct
block is in HOOKS line. Also added ext4 to MODULES
not but not least, i have used that usb for live distros and full installs. also portioned with gparted

most attractive errors in log are

kvm disabled in bios (i am installing only 32 bit version, booted to 32bit)
can not execute plymouth

any ideas

thanks in advance

Last edited by Archhotep (2013-03-25 13:19:28)

WonderWoofy · 2013-03-24 04:45:33

Archhotep wrote:

any ideas

The little explanation you give of your problem is extremely poor (at best), and you expect someone to be able to tell you what is wring with your system?

The errors that you indicate are "attractive" you would know are harmless with a single google a piece.

Please try harder, or you will get no help.

Trilby · 2013-03-24 04:50:26

The errors right before it drops you to the emergency shell would be the "attractive" ones.

I'm guessing its either A) no usb hook in mkinitcpio.conf, or B) no uuids in the bootloader.

Of course it could lots of other things, as was indicated above, you have not provided much information.

Archhotep · 2013-03-24 22:47:40

Sorry for not providing details, my fault. Here is the more info

I have followed the tutorial. I booted to a usb stick and installed on to another usb stick.
http://gotux.net/arch-linux/arch-linux- … tallation/
which worked pretty good for installing on hard disk.
Only change I did was /,home and boot all mounted to the partitions on usb stick.
installed the grub.

/etc/fstab looks fine and having all partitions of usb

on booting from the new usb stick (where i installed),
grub showed up fine
then printed loading initramfs
printed systemd-fsck /dev/sdb3 clean (that is / )
then printed kvm disabled by bios
wait for a long time
then printed Welcome to emergency mode

then printed
After logging in type journalctl -xb to view system logs
Enter root password for maintainance or hit CTRL+D to continue

I entered password which is accepted

I see the logs, here is the problems

Timedout waiting for device dev-sdc1.device.
Dependency failed for /boot

which was /boot when installing now it should be sdb1

/ is correctly detected bot nor /boot

looks like grub is fine, no entries of sdc

but fstab has, so i will change fstab and see what happens.

or I will boot to ram and o it, it should work

Archhotep · 2013-03-24 23:29:30

Aha!!!

System is up now, boots fine connected to wifi with nm.

Now I will be experimenting some desktop basics with window managers and panels without using complete desktop. That is the reason i installed on usb without disturbing my main setup.

Thanks very much all of you

WonderWoofy · 2013-03-24 23:57:02

So what did you do to fix this issue? Please clarify and then mark your thread as [Solved]. You may edit the first post in order to also modify the title.

Trilby · 2013-03-25 00:01:50

Well I can see what he didn't do. He didn't use UUIDs in his boot loader. So unless he changed that, what might have fixed this was temporary dumb luck on the order in which the drives are enumerated.

WonderWoofy · 2013-03-25 00:08:10

Trilby wrote:

Well I can see what he didn't do. He didn't use UUIDs in his boot loader. So unless he changed that, what might have fixed this was temporary dumb luck on the order in which the drives are enumerated.

Well, I see a reference to sdb and sdc, so at least he has a one in three change of getting it... maybe now we'll only get two thirds the number of threads from him.

DSpider · 2013-03-25 08:27:19

Archhotep wrote:

Sorry for not providing details, my fault. Here is the more info
I have followed the tutorial...
http://gotux.net/arch-linux/arch-linux- … tallation/

That's the problem right there. Not that there's anything wrong with the tutorial in particular (*see why at the bottom), but with each monthly release new stuff is added to the Beginners' Guide and the Installation Guide; stuff like notes, warnings, minor tweaks, etc.

* I stopped reading at "Config Kernel: mkinitcpio -p linux". That runs automatically when you install the base package group (the linux package in particular), so there's no reason to run it again if you haven't edited /etc/mkinitcpio.conf (e.g. if you haven't added the "block" hook). It just wastes a few more seconds.

Awebb · 2013-03-25 08:36:04

Is blocks in hooks enough? Is usb deprecated?

Archhotep · 2013-03-25 13:17:38

WonderWoofy wrote:

So what did you do to fix this issue? Please clarify and then mark your thread as [Solved]. You may edit the first post in order to also modify the title.

Trilby wrote:

Well I can see what he didn't do. He didn't use UUIDs in his boot loader. So unless he changed that, what might have fixed this was temporary dumb luck on the order in which the drives are enumerated.

No. UUIDs are there in the boot loader (I think) and grub was working fine and why the system is trying to boot at first place.

The problem is as follows.

I have booted through a bootable USB which was /dev/sdb
I have installed on to a different usb which was /dev/sdc during install

I have also created seperate partitions for boot and home. Here goes the problem otherwise it might have booted just fine and I might not have ever noticed the error. May be not, It might have failed later.

When i created /dev/fstab all UUIds and dev names (dev/sdcx) are correct.

I have done grub, build the iamage blah blah..

Now I restarted and removed first usb stick (which i was booted first). So when it boot this device becomes /dev/sdb not /dev/sdc. So it not able to mount the /boot, /home and /swap.

As grub uses only UUIDs (by default and I never changed any of that), it loaded the kernel. root file system is loaded as it is passed to the kernel as /dev/sdb by boot loader. But when kernel tries load other partitions /boot and /home from /dev/fstab which is referring to /dev/sdc fails.

This is what I have doe to fix
I replaced dev/sdcx to /dev/sdbx in /dev/fstab and every thing goes like charm.
I have booted 4/5 times and loaded video drivers/xorg-server, openbox/fluxbox and few other tint2/fbpanel midori,sonata, leafpad.
Now I am busy customizing openbox.

Trilby · 2013-03-25 13:21:59

It will continue working until you change what usb's are plugged in again. If you want a real solution use UUID in fstab.

Archhotep · 2013-03-25 13:25:04

Awebb wrote:

Is blocks in hooks enough? Is usb deprecated?

I tried usb, no change and while building image it complained that is deprecated.

If you are using latest arch iso (either through a cd/usb) you need not modify the HOOKS at all. the default one workd well and it includes block.
If there is any problem just use the HOOK commented as full image (no autodetect) which will be something like. Right now i don't remeber what is there in that line, I will post evening.

Archhotep · 2013-03-25 13:28:21

Trilby wrote:

It will continue working until you change what usb's are plugged in again. If you want a real solution use UUID in fstab.

I understand that. but both UUIDs and devices (/dev/sdX) are there in fstab if I am correct. I will check that in evening. if so did i make a mistake in generating fstab.
I have generated fstab with

genfstab -p /mnt >> /mnt/etc/fstab (does this happens if i forget -p).

as I have done this multiple times, I might have done some thing wrong. I will edit that file manually and removed /dev/sdx entries from that

Last edited by Archhotep (2013-03-25 13:34:32)

Trilby · 2013-03-25 13:37:48

I'm not sure what's in your fstab - but if they are both there and uncommented, you will likely get other issues. IIRC genfstab will generate both, but it comments the UUIDs, it's up to you to uncomment them (and comment/remove the block names like /dev/sdXn)

WonderWoofy · 2013-03-25 15:28:26

Archhotep wrote:

Trilby wrote:
It will continue working until you change what usb's are plugged in again. If you want a real solution use UUID in fstab.
I understand that. but both UUIDs and devices (/dev/sdX) are there in fstab if I am correct. I will check that in evening. if so did i make a mistake in generating fstab.
I have generated fstab with
genfstab -p /mnt >> /mnt/etc/fstab (does this happens if i forget -p).
as I have done this multiple times, I might have done some thing wrong. I will edit that file manually and removed /dev/sdx entries from that

Honestly, you are not very good at sharing what is actually in your configs. So as Trilby said above, no one really knows what is in your fstab, since you have not actually shared that with this thread.

As far as I can tell, when I run "genfstab -p /" on my running machine, letting the output just be dumped to stdout, it doesn't give me UUIDs anywhere. And from your statement it seems you haven't even actually checked.

What I have done in the past is used labels. For example if you are using ext2, ext3, or ext4, you could assign a label using "e2label". So lets say you label your rootfs (/) "usb_root". Now instead of using the unreliable /dev/sdXY format, you can use LABEL=usb_root in your fstab, and in the bootloader you can use root=LABEL=usb_root (or root=/dev/disk/by-label/usb_root).

I would also like to mention that this quote sucks:

Archhotep wrote:

No. UUIDs are there in the boot loader (I think) and grub was working fine and why the system is trying to boot at first place.

There are a number of people who are patiently trying to walk you through this issue (with quite a bit more hand holding that usually takes place around here), and you don't have the decency/appreciation to even take the time to confirm what you are actually using in the configs that everyone is telling you to check and/or change.

Trilby · 2013-03-25 15:39:03

While I've been adamantly suggesting using UUIDs, labels (as described above) would work just as well. Labels have the advantage of being sensible and intelligible when you look at them - I'm just more used to uuids. Either one though will work consistently, while block names will work only sporadically.

Archhotep · 2013-03-25 16:01:40

WonderWoofy wrote:

Archhotep wrote:
Trilby wrote:
It will continue working until you change what usb's are plugged in again. If you want a real solution use UUID in fstab.
I understand that. but both UUIDs and devices (/dev/sdX) are there in fstab if I am correct. I will check that in evening. if so did i make a mistake in generating fstab.
I have generated fstab with
genfstab -p /mnt >> /mnt/etc/fstab (does this happens if i forget -p).
as I have done this multiple times, I might have done some thing wrong. I will edit that file manually and removed /dev/sdx entries from that
Honestly, you are not very good at sharing what is actually in your configs. So as Trilby said above, no one really knows what is in your fstab, since you have not actually shared that with this thread.
As far as I can tell, when I run "genfstab -p /" on my running machine, letting the output just be dumped to stdout, it doesn't give me UUIDs anywhere. And from your statement it seems you haven't even actually checked.
What I have done in the past is used labels. For example if you are using ext2, ext3, or ext4, you could assign a label using "e2label". So lets say you label your rootfs (/) "usb_root". Now instead of using the unreliable /dev/sdXY format, you can use LABEL=usb_root in your fstab, and in the bootloader you can use root=LABEL=usb_root (or root=/dev/disk/by-label/usb_root).

I would also like to mention that this quote sucks:
Archhotep wrote:
No. UUIDs are there in the boot loader (I think) and grub was working fine and why the system is trying to boot at first place.
There are a number of people who are patiently trying to walk you through this issue (with quite a bit more hand holding that usually takes place around here), and you don't have the decency/appreciation to even take the time to confirm what you are actually using in the configs that everyone is telling you to check and/or change.

Sir,
I was a standard linux (i mean ubuntu etc) user until sometime back. I don't know exactly what should be there in /etc/fstab. I also do not know what information you might need to help me. If any one asked me the details about /etc/fstab etc might have provided. I have given what info what I felt was appropriate and enough. I do not have that machine with me when I was posting lat post, otherwise I might have posted. that laptop is at home. I already said thanks in my third post immediately after I solve the problem.
Sorry if I am wrong, and thatnk you once again for letting me about labels.
If I still have a question about /etc/fstab, i will post my fstab.

I don't know where to look to know that my boot loader is using uuid or dev. It would be great help.

Last edited by Archhotep (2013-03-25 16:06:11)

Archhotep · 2013-03-25 16:08:58

Trilby wrote:

While I've been adamantly suggesting using UUIDs, labels (as described above) would work just as well. Labels have the advantage of being sensible and intelligible when you look at them - I'm just more used to uuids. Either one though will work consistently, while block names will work only sporadically.

Thanks a lot.
I will check my fstab and comment out the device entries and keep the uuid entries.

Arch Linux

#1 2013-03-24 04:21:25

[SOLVED] Installing Arch on usb stick - login to emergency mode only

#2 2013-03-24 04:45:33

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#3 2013-03-24 04:50:26

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#4 2013-03-24 22:47:40

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#5 2013-03-24 23:29:30

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#6 2013-03-24 23:57:02

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#7 2013-03-25 00:01:50

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#8 2013-03-25 00:08:10

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#9 2013-03-25 08:27:19

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#10 2013-03-25 08:36:04

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#11 2013-03-25 13:17:38

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#12 2013-03-25 13:21:59

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#13 2013-03-25 13:25:04

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#14 2013-03-25 13:28:21

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#15 2013-03-25 13:37:48

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#16 2013-03-25 15:28:26

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#17 2013-03-25 15:39:03

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#18 2013-03-25 16:01:40

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

#19 2013-03-25 16:08:58

Re: [SOLVED] Installing Arch on usb stick - login to emergency mode only

Board footer