op 24-03-14 18:19, Andrey Borzenkov schreef:

В Mon, 24 Mar 2014 18:13:32 +0100 Jogchum Reitsma пишет:

...

Hi,

Iinstalled 13.3M0 on my "experiment disk" in my production system. One thing I changed in the suggested setup was that I placed the boot code on the root partition on that disk, instead of in the MBR of my first disk (which is part of the production disk set, so I don't want to fool around with that).

Intallation went without a glitch, but it won't boot, complaining that /dev/root cannot be found. I am presented with the choice to seek it on /dev/dsf2 (the root partition of the experiment disk), but refuses to respond to the keyboard (except for Ctrl-Alt-Del, which leads to a reboot...).

It is not quite clear - this happens when you boot 13.2 or you cannot boot at all now?

...

So I'm stuck here.

Any thoughts?

regards, Jogchum (Sent by accident to Andrey PM - sorry Andrey)

It happens when booting 13.2. 13.1, on the other disk set on the same computer boots and runs fine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

op 25-03-14 02:48, Neil Rickert schreef:

On Mon, 24 Mar 2014 18:13:32 +0100 Jogchum Reitsma wrote:

...

Intallation went without a glitch, but it won't boot, complaining that /dev/root cannot be found. I am presented with the choice to seek it on /dev/dsf2 (the root partition of the experiment disk), but refuses to respond to the keyboard (except for Ctrl-Alt-Del, which leads to a reboot...).

If you got that far, then I'm pretty sure that installing grub in the root partition was not part of the problem.

It looks to me as if there might be a driver missing from the "initrd" that is needed for the kernel to access the root file system. Any idea what driver that might be? Should be in the installation iso, am I right? Or perhaps you use encryption, and the lack of keyboard response prevents decrypting. I don't use encryption, so that shouldn't be the problem Make sure that the keyboard is plugged into a usb2 or usb1 port, not a usb3 port. There might be an additional driver needed for usb3 ports. This assumes a USB keyboard. It is not an usb, but a pc2-keyboard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-03-24 18:13 (GMT+0100) Jogchum Reitsma composed:

...

Iinstalled 13.3M0 on my "experiment disk" in my production system. One

A BIOS system, or GUID? BIOS

...

thing I changed in the suggested setup was that I placed the boot code on the root partition on that disk, instead of in the MBR of my first disk (which is part of the production disk set, so I don't want to fool around with that).

...

Intallation went without a glitch, but it won't boot, complaining that /dev/root cannot be found. I am presented with the choice to seek it on /dev/dsf2 (the root partition of the experiment disk), but refuses to respond to the keyboard (except for Ctrl-Alt-Del, which leads to a reboot...).

In my experience, not finding /dev/root means limited initrd content fails to match up correctly to the installation. If what you installed from was the M0 DVD iso, It was I suggest you try again, but with the boot.iso or installation kernel and initrd started from Grub, and do the installation from HTTP repo, which is how I do nearly all my installations. How do I do that? Up till now I just start the iso (from usb, before

op 25-03-14 03:47, Felix Miata schreef: that from DVD) and press install on the first menu...

Newer versions of kernel, installer and/or dracut may well avoid repeating the problem.

Before going that route, access the 13.2 grub menu file I can't find a grub menu file. There are two *menu.mod files, but these are binaries. and fstab Hmm - the fstab file has a totally different format than I know - I'm afraid I can't make sense of it. I can see the mount point names, but no idea to which disks or disk partition they are related:

UUID=d52d5c4d-d112-42dc-9b10-8a51333758ad swap swap defaults 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 / btrfs defaults 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /opt btrfs subvol=opt 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /srv btrfs subvol=srv 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /tmp btrfs subvol=tmp 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /usr/local btrfs subvol=usr/local 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/crash btrfs subvol=var/crash 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/lib/mailman btrfs subvol=var/lib/mailman 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/lib/named btrfs subvol=var/lib/named 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/lib/pgqsl btrfs subvol=var/lib/pgqsl 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/log btrfs subvol=var/log 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/opt btrfs subvol=var/opt 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/spool btrfs subvol=var/spool 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /var/tmp btrfs subvol=var/tmp 0 0 UUID=13775a63-5454-46fb-9519-77f6a5b1e1cc /home ext4 defaults 1 2

to ensure the root device specified makes sense, and an initrd actually exists.

initrd exists: mnt/sdf2-boot/boot # l totaal 39208 drwxr-xr-x 1 root root 566 25 mrt 16:17 ./ drwxr-xr-x 1 root root 166 22 mrt 22:27 ../ -rw-r--r-- 1 root root 512 22 mrt 22:34 backup_mbr lrwxrwxrwx 1 root root 1 22 mrt 22:29 boot -> ./ -rw-r--r-- 1 root root 1484 5 mrt 15:40 boot.readme -rw-r--r-- 1 root root 145160 10 mrt 09:23 config-3.14.0-rc5-1-desktop -rw-r--r-- 1 root root 0 22 mrt 22:31 do_purge_kernels drwxr-xr-x 1 root root 0 11 mrt 20:33 dracut/ drwxr-xr-x 1 root root 296 22 mrt 22:29 grub/ drwxr-xr-x 1 root root 168 22 mrt 22:35 grub2/ lrwxrwxrwx 1 root root 27 22 mrt 22:31 initrd -> initrd-3.14.0-rc5-1-desktop -rw------- 1 root root 24572510 22 mrt 22:34 initrd-3.14.0-rc5-1-desktop -rw-r--r-- 1 root root 620544 17 mrt 10:39 message -rw-r--r-- 1 root root 300863 10 mrt 10:29 symvers-3.14.0-rc5-1-desktop.gz -rw-r--r-- 1 root root 516 10 mrt 10:29 sysctl.conf-3.14.0-rc5-1-desktop -rw-r--r-- 1 root root 2796833 10 mrt 10:15 System.map-3.14.0-rc5-1-desktop -rw-r--r-- 1 root root 6294831 10 mrt 10:29 vmlinux-3.14.0-rc5-1-desktop.gz lrwxrwxrwx 1 root root 28 22 mrt 22:31 vmlinuz -> vmlinuz-3.14.0-rc5-1-desktop -rw-r--r-- 1 root root 5364136 10 mrt 11:55 vmlinuz-3.14.0-rc5-1-desktop

If there is no initrd, a chroot repair could be easier than starting over. If a BIOS system, ensuring resource enumeration hasn't caused a conflict between actual initrd content and what it should contain may provide a clue or solution to what happened. If a GUID system, nor further content from here.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

<...>

To find out where a UUID points one way is to compare UUID to the symlink in a long directory listing in /dev/disk/by-uuid/. There's also some sort of blockdev command I'm not familiar with that should do the same, IIRC. OK, the proper disk is used, I can see now.

Tried again with net-install, same result. For as far as I can see, it tries to find /dev/root at <disk-id>-part4, which is the swap-partition. It then asks if it should try -part2, which holds indeed the root file system, with /boot in it. But again it refuses to take my Y for an answer... Ctrl-Alt-Del is recognized fine again. /boot/grub2/grub.cfg exists, but it is a script, pretty useless for the average user. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

op 25-03-14 22:19, Felix Miata schreef:

You should borrow a USB keyboard as a possible workaround. Your PS/2 keyboard is directly without any adapters attached to the preferred lower(if over-under)/rightmost(if side-by-side)/violet port, right?

Yes, it is. I'll try a USB-keyboard tomorrow.

...

/boot/grub2/grub.cfg exists, but it is a script, pretty useless for the average user.

It looks and works like a script, but that's the complicated she-devil responsible for Grub's menu alright.

You do know that Grub2 is merely a default, not required, right? You could try another install and choose Grub Legacy instead, if indeed not a GUID system, maybe even if it is.

To test, grub2 should work too, of course. So I'll walk that path first. Then try grub legacy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-03-28 10:06 (GMT+0100) Jogchum Reitsma composed:

So I decided to copy backup_mbr to the disk, but apparently that wasn't a very good idea: the partitions on the disk are no longer recognized. As such no big deal - after all it's an experiment disk with no valuable data.

But - and I admit that it gets somewhat off-topic here - it seems a nice opportunity to see if the partition setup can be recovered.

I ran gpart on the disk, but gpart has no modules for ext4 or btrfs. I cannot find the modules on the internet. Does anyone here know if they exist, and if so, where to find them?

I have no idea, but that would not matter here. The only MBR partitioner ever used here, DFSee (not free, but with binaries for 5 platforms), will locate every PBR (regardless whether or not currently valid). From the location data it provides, each partition can be recreated. Maybe there is something free that can do similar. DFSee does have a 30 day free trial. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 25.03.2014 18:37, schrieb Felix Miata:

...

UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0

Can anyone explain why a BIOS system would need such separate partitions?

it's the same partition (look at those UUIDs, they are identical) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2014-03-25 22:03 (GMT+0100) Stefan Seyfried composed:

...

...

UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0 UUID=d89061ed-00fb-425b-a7de-bed6e920c6f2 /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0

...

Can anyone explain why a BIOS system would need such separate partitions?

it's the same partition (look at those UUIDs, they are identical)

And now I see there are only 3 different UUIDs in the OP's list, with about a dozen different mountpoints listed that all have the same UUID. Is that a normal btrfs characteristic? O_O -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org