[opensuse] failed installation, system inaccessible
Attempted an upgrade from 12.3 to 13.2. As suggested in previous thread (on "upgrade"), I used gparted to shrink an NTFS partition and create a new ext4 boot partition. With the 13.2 DVD (which I had verified after burning), I imported the partition scheme, changed the boot partition to the newly created one, set that to format, and otherwise took the defaults. The installation proceeded through the "unpacking KDE images", then switched to a character screen. The last item on the screen is /etc/zypp/services.d / Then the red window comes up "An error occurred during the installation." If I again attempt the install the same thing happens. If I boot from the hard drive, it will load the 12.3 system, up to the login screen (which looks different from what was there before). I can enter name and passsowrd, but it says "login incorrect." Both for regular user and root. I had entered same username and password for the new 13.2 installation as for the 12.3. So it appeard to load, but I cannot log in. So (please help!), (a) how do I get access to my system again, and (b) how do I get 13.2 installed properly? I have limited(!) access to the system at this point, so if there is information needed from it, I'll need some detailed instructions as to how to get it. Many thanks (in advance) -- Fr David Ousley davidousley@verizon.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-26 00:39, Fr David Ousley wrote:
Attempted an upgrade from 12.3 to 13.2. As suggested in previous thread (on "upgrade"), I used gparted to shrink an NTFS partition and create a new ext4 boot partition. With the 13.2 DVD (which I had verified after burning), I imported the partition scheme, changed the boot partition to the newly created one, set that to format, and otherwise took the defaults.
Then what you did really was not an upgrade, but install fresh on top of the old one.
The installation proceeded through the "unpacking KDE images", then switched to a character screen. The last item on the screen is
/etc/zypp/services.d /
Then the red window comes up "An error occurred during the installation."
If I again attempt the install the same thing happens.
Oh, crumbs.
If I boot from the hard drive, it will load the 12.3 system, up to the login screen (which looks different from what was there before). I can enter name and passsowrd, but it says "login incorrect." Both for regular user and root. I had entered same username and password for the new 13.2 installation as for the 12.3. So it appeard to load, but I cannot log in.
I think that you may have set the root partition to not format. Is that so? Because nothing from the old 12.3 should remain, except users and fstab layout.
So (please help!), (a) how do I get access to my system again, and (b) how do I get 13.2 installed properly?
Maybe 13.2 install doesn't work right on your system... I would consider perhaps installing 13.1 instead... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2015-05-26 00:39, Fr David Ousley wrote:
Attempted an upgrade from 12.3 to 13.2. As suggested in previous thread (on "upgrade"), I used gparted to shrink an NTFS partition and create a new ext4 boot partition. With the 13.2 DVD (which I had verified after burning), I imported the partition scheme, changed the boot partition to the newly created one, set that to format, and otherwise took the defaults.
I fear there is a misunderstanding somewhere what do you call "boot partition"? first what is the size of the new partition? if more than 1Gb it's most certainly root / and not /boot (notice the / before boot) if it's really /boot, where is root? if you didn't use the old 12.3 partition, may be you still have it available :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-26 15:23, jdd wrote:
On 2015-05-26 00:39, Fr David Ousley wrote:
I fear there is a misunderstanding somewhere
what do you call "boot partition"?
From memory from a previous thread, it was a real /boot partition. But memory is the second thing to go, you know ;-) The output of this command, using a live system if the main one doesn't boot, would perhaps clarify things. lsblk --output NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Oh, crumbs.
I think that you may have set the root partition to not format. Is that so? Because nothing from the old 12.3 should remain, except users and fstab layout.
Thanks for your help. I have installed 13.2 to a new (and newly formatted) root partition. (There is also a separate and new boot partition -- 150 MB). Installation completes and system reboots. So your suggestions seems to have resolved that problem. Reboot hangs however at the Started filesystem check on /dev/disk/by-uuid ... After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist. It leaves me at a Dracut prompt. The rdosreport.txt file it mentions is empty. Booting recovery mode produces recurring lines : sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 > sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 > These lines repeat until Iforce a reboot with the power switch. sdb and sdc are the disks where swap and /home are located. So I have 13.2 installed but cannot boot into it. I tried redoing the installation formatting the swap partition. Does not change the results. Same results with booting the old 12.3 whether with or without the recovery mode. Thanks again (in advance) for bailing me out! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Fr David Ousley composed on 2015-05-26 15:58 (UTC-0400):
I have installed 13.2 to a new (and newly formatted) root partition. (There is also a separate and new boot partition -- 150 MB). Installation completes and system reboots. So your suggestions seems to have resolved that problem.
Reboot hangs however at the
Started filesystem check on /dev/disk/by-uuid ...
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist. It leaves me at a Dracut prompt. The rdosreport.txt file it mentions is empty.
Booting recovery mode produces recurring lines :
sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 > sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
These lines repeat until Iforce a reboot with the power switch.
sdb and sdc are the disks where swap and /home are located.
So I have 13.2 installed but cannot boot into it. I tried redoing the installation formatting the swap partition. Does not change the results. Same results with booting the old 12.3 whether with or without the recovery mode.
What you may have encountered here is some flummoxing among device names and UUIDs. One of the problems that using UUIDs instead of device names was supposed to solve was that of different kernels assigning different device names to HDs when SATA and PATA are mixed in the same system. That is more likely to become a problem in spite of that intent when you preserve some filesystems and format others. At 30GB, it seems rather safe to assume your sda is PATA and a tap root of the problem, while with so many in total, the rest are surely SATA. Unless you are expert at self management of fstab and volume management, I suggest you boot in rescue mode, gather up fstabs for both 13.2 and 12.3, do the same for your bootloader menu files (/boot/grub2/grub.cfg and/or /boot/grub/menu.lst), provide a blkid output for every volume, label everything clearly, and share it on susepaste.org or your own web space or equivalent, and let the collective wisdom of the list try to help. Because of your LVM involvment, I won't be able to be a material part of that collected wisdom. My original suspicion when I started writing this some hours before several interruptions blocked me finishing until now was as Carlos has suggested in the interim. Hopefully it will be that simple to solve. But I've seen a similar if not same reference about inability to mount swap before, and found the ultimate fix less simple than simply fixing or omitting the swap entry in fstab. To be able to use either one of 12.3 and 13.2 at will I'm sure will require both getting similar fixes at a minimum, but fixing either first should facilitate getting the other fixed more easily. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 09:49 PM, Felix Miata wrote:
Fr David Ousley composed on 2015-05-26 15:58 (UTC-0400):
I have installed 13.2 to a new (and newly formatted) root partition. (There is also a separate and new boot partition -- 150 MB). Installation completes and system reboots. So your suggestions seems to have resolved that problem.
Reboot hangs however at the
Started filesystem check on /dev/disk/by-uuid ...
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist. It leaves me at a Dracut prompt. The rdosreport.txt file it mentions is empty.
Booting recovery mode produces recurring lines :
sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 > sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
These lines repeat until Iforce a reboot with the power switch.
sdb and sdc are the disks where swap and /home are located.
What you may have encountered here is some flummoxing among device names and UUIDs. One of the problems that using UUIDs instead of device names was supposed to solve was that of different kernels assigning different device names to HDs when SATA and PATA are mixed in the same system. That is more likely to become a problem in spite of that intent when you preserve some filesystems and format others. At 30GB, it seems rather safe to assume your sda is PATA and a tap root of the problem, while with so many in total, the rest are surely SATA. Unless you are expert at self management of fstab and volume management, I suggest you boot in rescue mode, gather up fstabs for both 13.2 and 12.3, do the same for your bootloader menu files (/boot/grub2/grub.cfg and/or /boot/grub/menu.lst), provide a blkid output for every volume, label everything clearly, and share it on susepaste.org or your own web space or equivalent, and let the collective wisdom of the list try to help. Because of your LVM involvment, I won't be able to be a material part of that collected wisdom.
My original suspicion when I started writing this some hours before several interruptions blocked me finishing until now was as Carlos has suggested in the interim. Hopefully it will be that simple to solve. But I've seen a similar if not same reference about inability to mount swap before, and found the ultimate fix less simple than simply fixing or omitting the swap entry in fstab. To be able to use either one of 12.3 and 13.2 at will I'm sure will require both getting similar fixes at a minimum, but fixing either first should facilitate getting the other fixed more easily.
Using the rescue mode, I commented out the swap line in the fstab as Carlos suggested. As you suspected, the boot still hangs at the Started File System check ... I will go in tomorrow and try to collect the disk information you suggest. sda is an SSD drive, which came as a freebie and I haven't been using. sdb and sdc are SATA drives, mirrored in the BIOS. I'm wondering if it might be worth trying an installation without using the SSD at all, and see if that solves the problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/05/2015 2:45, Fr David Ousley wrote:
On 05/26/2015 09:49 PM, Felix Miata wrote:
help. Because of your LVM involvment, I won't be able to be a material part of that collected wisdom.
LVM? I forgot that part. I can't help if LVM is part of the equation. That's the main reason I don't use it: I don't know how to solve its problems. :-(
Using the rescue mode, I commented out the swap line in the fstab as Carlos suggested. As you suspected, the boot still hangs at the Started File System check ...
Oh, crumbs. :-(
I will go in tomorrow and try to collect the disk information you suggest. sda is an SSD drive, which came as a freebie and I haven't been using. sdb and sdc are SATA drives, mirrored in the BIOS. I'm wondering if it might be worth trying an installation without using the SSD at all, and see if that solves the problem.
Mirrored in the BIOS? Ouch, that's fake RAID. Another pebble in the shoe :-( It probably needs a driver, and if it is not included in the initrd archive used for booting, booting fails... -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W7) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 10:30 PM, Carlos E. R. wrote:
Mirrored in the BIOS? Ouch, that's fake RAID. Another pebble in the shoe :-(
Indeed. methodology when dealing with something like this is to go back to basics, regress as far as needed until it works all OK (as opposed to merely "it works" which satisfied newbies and neophytes) and then one by one add the additional components that contribute to the complex end point to determine which one is the one that destabilized. Yes its reductionist. Yes its pedantic Yes its extremely powerful and rigorous. Yes it takes humility and diligence ... But you want a solution or you want ego gratification?
It probably needs a driver, and if it is not included in the initrd archive used for booting, booting fails...
Which certainly applies if there is the device mapper, which may be needed if this is LVM or if this is encrypted. If the latter, more modules are needed in initrd, as I mentioned in an an earlier post. If you are doing encryption, they try without. It seems to be that whatever is demanding the mapper is part of the problem. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Fr David Ousley composed on 2015-05-26 20:45 (UTC-0400):
Using the rescue mode, I commented out the swap line in the fstab as Carlos suggested. As you suspected, the boot still hangs at the Started File System check ...
I will go in tomorrow and try to collect the disk information you suggest. sda is an SSD drive, which came as a freebie and I haven't been using. sdb and sdc are SATA drives, mirrored in the BIOS. I'm wondering if it might be worth trying an installation without using the SSD at all, and see if that solves the problem.
Apparently the /dev/mapper must be your BIOS RAID. That's designed for Windows. Your better bet will be backing up any data that isn't already backed up and deactivating BIOS RAID. Then fresh install, including wiping sdb and sdc, using Linux software RAID and EXT4, which YaST will do for you. Still better might be installing 13.2 to the SSD. That will leave sdb and sdc as is, which can be reconfigured if and when desired post-installation, plus giving better OS performance. Given the probability your problem is all rooted in BIOS RAID, providing the info I previously requested would probably be pointless if you are to go either of the above two routes. A third possibility that would require it is trying to repair the installed system to include proper BIOS RAID support (if that's even possible; with Grub2, I don't know). I can't help with that. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 05:02, Felix Miata wrote:
Fr David Ousley composed on 2015-05-26 20:45 (UTC-0400):
Apparently the /dev/mapper must be your BIOS RAID. That's designed for Windows. Your better bet will be backing up any data that isn't already backed up and deactivating BIOS RAID. Then fresh install, including wiping sdb and sdc, using Linux software RAID and EXT4, which YaST will do for you.
He has been using that layout since 9.3, he said, so they should still work. How, I don't know. Must be missing a module in initrd. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2015-05-27 05:06 (UTC+0200):
Felix Miata wrote:
Fr David Ousley composed on 2015-05-26 20:45 (UTC-0400):
Apparently the /dev/mapper must be your BIOS RAID. That's designed for Windows. Your better bet will be backing up any data that isn't already backed up and deactivating BIOS RAID. Then fresh install, including wiping sdb and sdc, using Linux software RAID and EXT4, which YaST will do for you.
He has been using that layout since 9.3, he said, so they should still work. How, I don't know. Must be missing a module in initrd.
(Assuming 9.3 is accurate) IIRC, BIOS RAID "support" way back when required some indirection (kernel? driver? DM?) that may have been obsoleted post-12.3. Assuming previous is 12.3 (as I remember reading), then it could be a Grub Legacy to Grub2 transition that YaST failed to competently execute. Could be this is something that got under- or no testing in TW between 12.3 and 13.2 release. We who use TW know to strongly prefer Linux RAID to BIOS RAID (as in entirely shun), but who who don't participate in pre-release testing know? -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 05:31, Felix Miata wrote:
Carlos E. R. composed on 2015-05-27 05:06 (UTC+0200):
He has been using that layout since 9.3, he said, so they should still work. How, I don't know. Must be missing a module in initrd.
(Assuming 9.3 is accurate) IIRC, BIOS RAID "support" way back when required some indirection (kernel? driver? DM?) that may have been obsoleted post-12.3.
Assuming previous is 12.3 (as I remember reading), then it could be a Grub Legacy to Grub2 transition that YaST failed to competently execute. Could be this is something that got under- or no testing in TW between 12.3 and 13.2 release. We who use TW know to strongly prefer Linux RAID to BIOS RAID (as in entirely shun), but who who don't participate in pre-release testing know?
Not grub, it is not related at all. Dracut is. I suppose (I have no personal experience) that you need to load some kernel module to support that fake raid, and very early in the process. It has to be included in the initrd. If you upgrade the machine, the settings would be carried over, and hopefully dracut would have inserted the old configs, if they were present. If you install fresh in the same place, then the installer has to detect the situation and add the modules to the list, somehow, somewhere. This, I think did not happen, and as you say, was not detected during betas or TW. Or, it could be as simple as the correct mapping device names be different now than they were on the previous release installed, if the settings in fstab were read by the installer, as I think he did (it is a tick box in the installer). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/26/2015 11:02 PM, Felix Miata wrote:
Still better might be installing 13.2 to the SSD. That will leave sdb and sdc as is, which can be reconfigured if and when desired post-installation, plus giving better OS performance.
This is exactly what I was trying to do. Shrank the NTFS partition; created /boot and / partitions (ext4) using gparted. In the opensuse installation, imported the old partition scheme, then removed the old /boot and / partitions, and added the new ones on the SSD, having the installer format them.
Given the probability your problem is all rooted in BIOS RAID, providing the info I previously requested would probably be pointless if you are to go either of the above two routes. A third possibility that would require it is trying to repair the installed system to include proper BIOS RAID support (if that's even possible; with Grub2, I don't know). I can't help with that.
FWIW, it is grub2. I was also wrong about 9.3 -- that was another machine. The original on this one was either 10.3 or 11.2, I think. Machine dates to 5/11. I agree that the best solution is to wipe the hard drives and start over. I would prefer (if it turns out to be possible) to get a working system back so that I can plan that reinstallation more thoroughly and do it when I have a good chunk of time. Thanks also for pointing me to the live rescue on the web site. I did not think to look under "derivatives" and a search for "live" did not find it. dao -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 06:22 AM, Fr David Ousley wrote:
This is exactly what I was trying to do. Shrank the NTFS partition; created /boot and / partitions (ext4) using gparted. In the opensuse installation, imported the old partition scheme, then removed the old /boot and / partitions, and added the new ones on the SSD, having the installer format them.
I don't think "exactly" because Felix was specifying ONLY. What he meant was disconnect (either in hardware, bios or in the appropriate part of the installer tell it to ignore) the other hardware, the RAID devices. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 09:22 AM, Anton Aylward wrote:
On 05/27/2015 06:22 AM, Fr David Ousley wrote:
This is exactly what I was trying to do. Shrank the NTFS partition; created /boot and / partitions (ext4) using gparted. In the opensuse installation, imported the old partition scheme, then removed the old /boot and / partitions, and added the new ones on the SSD, having the installer format them.
I don't think "exactly" because Felix was specifying ONLY.
What he meant was disconnect (either in hardware, bios or in the appropriate part of the installer tell it to ignore) the other hardware, the RAID devices.
Thanks for the clarification. Carlos earlier suggestion was install to the SSD while retaining the /home partition on the hard drives. I will disconnect the latter, and try to install to the SSD. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 17:36, Fr David Ousley wrote:
Thanks for the clarification. Carlos earlier suggestion was install to the SSD while retaining the /home partition on the hard drives. I will disconnect the latter, and try to install to the SSD.
You should also check what Andrei said. You could, for the moment, install on the SSD without a separate /home partition. Then, later, you might manage to get the bios raid working, and then add a big /home partition in there. Maybe you could do that now without installing anything. If I understand right your setup, you only need to remove the cables for the hard disks, then edit the fstab, which is on the SSD, and comment out the /home partition, or anything that was on the rotating disks. See if it boots. You will not be able to login as user, only as root (no home). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/27/2015 01:19 PM, Carlos E. R. wrote:
Maybe you could do that now without installing anything. If I understand right your setup, you only need to remove the cables for the hard disks, then edit the fstab, which is on the SSD, and comment out the /home partition, or anything that was on the rotating disks. See if it boots. You will not be able to login as user, only as root (no home).
Tried this: commented out all lines referring to the hard drives in fstab (on the 13.2 syetem installed on the SSD. Disconnected the SATA cables to the rotating disks. Rebooted. Same messages, ending with dracut prompt. Next (unless someone has a better suggestion), I will try to install exclusively to the SSD, with other disks disconnected. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Fr David Ousley composed on 2015-05-27 12:42 (UTC-0400):
commented out all lines referring to the hard drives in fstab (on the 13.2 syetem installed on the SSD. Disconnected the SATA cables to the rotating disks. Rebooted. Same messages, ending with dracut prompt.
Next (unless someone has a better suggestion), I will try to install exclusively to the SSD, with other disks disconnected.
In case it was not clear in any of the previous thread responses, recommendation to install to SSD as exclusive storage/targe media during installation includes a complete repartitioning of the SDD so that it is partitioned for exclusive use of Linux - no FAT or NTFS. I would not accept the YaST partitioning offer, because YaST will have no knowledge of your intent to add the other devices (sdb, sdc, as software RAID or otherwise) later for use as or within /home. As I always want a partition that *could* suffice as a separate /boot partition, this is how I would divide up a 30GB SDD for your use: Without desire to utilize LVM on the SSD: 400MB EXT2 primary (sda1, to mount as /boot) 400MB EXT2 primary (sda2, reserved for later use) 400MB EXT2 primary (sda3, reserved for later use) T.B.D. swap (sda5; size based upon installed RAM and anticpated need for swap on SSD) 600MB EXT4 (sda6; minimal temporary /home) T.B.D. EXT4 (sda7 for /; size=entire remainder of SSD) With desire to utilize LVM on the SSD: 400MB EXT2 primary (sda1, to mount as /boot) 400MB EXT2 primary (sda2, reserved for later use) 400MB EXT2 primary (sda3, reserved for later use) T.B.D. swap (sda5; size based upon installed RAM and anticpated need for swap on SSD) remainder of SSD for LVM (sda6, to be subdivided into logical EXT4 volume{s} mainly or exclusively as / by YaST) Others would probably simplify, but the above are intended as a form of "future-proof" accommodation of possible future events. A third option would leave swap entirely off of the SDD, creating it later on sdb and/or sdc, thus providing more space for / on the SSD. These suggestions can all be done by YaST, as most people do installing openSUSE, but if done here, the partitioning would be done using live media, or having the SSD installed in a different machine, in advance of booting the 13.2 installation media. Notes: 1-T.B.D. == to be decided/determined 2-EXT2 suggestion for the small primaries is simply about not wasting space on journaling, since /boot is so infrequently written to. 3-Given the smallish 30GB SSD size, I would skip use of LVM on it. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 02:49 PM, Felix Miata wrote:
In case it was not clear in any of the previous thread responses, recommendation to install to SSD as exclusive storage/targe media during installation includes a complete repartitioning of the SDD so that it is partitioned for exclusive use of Linux - no FAT or NTFS.
I installed 13.2 to the SSD with the other hard drives disconnected, and now have a bootable system -- many thanks! (Unfortunately I did not see Felix' suggestion about partitioning until after I had started it all -- that will come next time around.) I then plugged the hard drives back in and rebooted, and the old partitions appear -- no RAID. So for the moment, I want to just use one of them for the data, and will later set up software RAID. I would like to mount the old /home directory from the rotating disk in place of the new /home on the SSD. I was going to rename the new /home, and mount the "old" home, but it tells me that /home is busy and will not let me do that. What is the best way to get from here to there? fstab lists the other entries by UUID which I don't know for the old /home partition. Would it work to comment out the fstab entry for the new /home, and add a line for the old? Can this be done on a running system? If I do that, where do I get the UUID for the old /home partition (which I know to be /dev/sdb8? Thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Fr David Ousley composed on 2015-05-27 14:24 (UTC-0400):
I installed 13.2 to the SSD with the other hard drives disconnected, and now have a bootable system -- many thanks! (Unfortunately I did not see Felix' suggestion about partitioning until after I had started it all -- that will come next time around.)
I then plugged the hard drives back in and rebooted, and the old partitions appear -- no RAID. So for the moment, I want to just use one of them for the data, and will later set up software RAID. I would like to mount the old /home directory from the rotating disk in place of the new /home on the SSD. I was going to rename the new /home, and mount the "old" home, but it tells me that /home is busy and will not let me do that. What is the best way to get from here to there?
"Best" here is probably subject to both opinion and data we may not have....
fstab lists the other entries by UUID which I don't know for the old /home partition.
Not a problem, since mounting by UUID is a mounting option, not a mounting mandate.
Would it work to comment out the fstab entry for the new /home, and add a line for the old?
It should.
Can this be done on a running system?
To do on a running system requires making /home unbusy. As long as you are logged in as any ordinary user, it will remain busy. Thus if ordinary user logs out and only root is logged in, umounting /home should succeed.
If I do that, where do I get the UUID for the old /home partition (which I know to be /dev/sdb8?
Exactly what made you "know" this? /dev/sdb8 may not be "the" or a good way to proceed. If needed module(s) are not being loaded as and when necessary, correcting this will be necessary as well, probably a change to /etc/dracut.conf and a new initrd. Using UUID to add an entry to fstab is the harder route. You have options here. One is to make a new entry using /dev/sdb8 instead of UUID. Another is to mount by volume label, something you get to choose, and thus remember, and type, far more easily than a UUID. If the volume has no label, you can give it one. Also you can change an existing one. Three tools available to inquire of a filesystem's UUID and its LABEL are blkid tune2fs -l lsblk Tune2fs can be used to change an EXT2/3/4 volume label (-L) and/or UUID (-U) as well (see tune2fs man page). I'm sure YaST can be used to make these discoveries and changes as well. Before actually changing to using /dev/sda8 as /home (regardless of eventual fstab entry type) you need to test access to it, which may be blocked by its having been or being part of BIOS RAID. The easiest way is liable to be logging into X as root than then using the YaST2 partitioner. If it was here I'd simply experiment mounting manually. Based on your previous installation experience, it appears (a) needed kernel module(s) (*dm*) for access to BIOS RAID has not been and may still not be autoloading. Output from 'lsmod | grep dm' would be helpful to us for further progress, if you wish to proceed using BIOS RAID. OTOH, better to not continue using BIOS RAID if you have good backup of home that you can restore after repurposing sdb and sdc to software RAID ("repartitioning" both to make new software RAID device or devices). The gist here is you need to ensure of optimal availability of your rotating rust before trying to make fstab edits and retire the current /home partition on the SDD from service other than as a mount point. -- "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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 11:02 PM, Felix Miata wrote:
Still better might be installing 13.2 to the SSD. That will leave sdb and sdc as is, which can be reconfigured if and when desired post-installation, plus giving better OS performance.
I think that is a VERY GOOD IDEA. I think it is a good idea not only for the reasons Felix says but because it eliminates some of the complexity involved in the failing install. KISS. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 09:17 AM, Anton Aylward wrote:
On 05/26/2015 11:02 PM, Felix Miata wrote:
Still better might be installing 13.2 to the SSD. That will leave sdb and sdc as is, which can be reconfigured if and when desired post-installation, plus giving better OS performance.
I think that is a VERY GOOD IDEA.
I think it is a good idea not only for the reasons Felix says but because it eliminates some of the complexity involved in the failing install. KISS.
Agreed. This is what I attempted in the first place. The boot hangs on the file system check of the SSD. There is no encryptation nor LVM. I am trying to keep it simple, though I seemed to have failed at that! dao -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 08:07 AM, Fr David Ousley wrote:
On 05/27/2015 09:17 AM, Anton Aylward wrote:
On 05/26/2015 11:02 PM, Felix Miata wrote:
Still better might be installing 13.2 to the SSD. That will leave sdb and sdc as is, which can be reconfigured if and when desired post-installation, plus giving better OS performance.
I think that is a VERY GOOD IDEA.
I think it is a good idea not only for the reasons Felix says but because it eliminates some of the complexity involved in the failing install. KISS.
Agreed. This is what I attempted in the first place. The boot hangs on the file system check of the SSD.
There is no encryptation nor LVM.
I am trying to keep it simple, though I seemed to have failed at that!
Unless you've tried again ... the fact that your report included an error that involved the mapper ... KISS would involve disconnecting all except the SSD. Eliminate all extraneous variable and factors. Heck, you could try installing on another machine with JUST the SSD then putting the SSD on the first machine and seeing it boot there. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"? You've given no indication you are using LVM so what the "mapper"? I have had this error in the past when using LVM and the mapping has not been activated. I kow how to fix it with LVM but what I _think_ you are doing is using an encrypted swap. While I can see & understand reason for that in the absolute scheme of things, right now you want to get this system booting properly, so I would consider have an encrypted swap an unwarranted complication. The installer has the option to setup a dm-crypt volume using LUKS. This encrypts the contents of the entire partition. But dm-crypt need the mapper. FIRST It is, I suppose, possible to bring a system up without any swap if you have adequate memory and then activate the swap later. You might consider that. How would you do that? Well we've discussed in this forum many times the idea of editing the command line for boot, using 'e' at the menu prompt to get into the editor and them following the on-screen instructions. If you haven't set up swap as encrypted than that message about "mapper" is very strange. Personally I have boot and swap as primary partitions. Regular readers know that I use LVM. I can add another swap partition as a LVM Logical Volume and have that activated AFTER booting. Equally, I can also make that an encrypted partition. There is a lot of on-line documentation about encrypting a LV using LUKS/dm-crypt. SECOND It is very likely that your initrd does not have the modules needed to handle the mapper and dm-crypt. You will need * dm_mod * dm_crypt * sha256 See "man lsinitrd" FINALLY You mention "/dev/mapper/pdc..." What is the FULL string please. http://www.techrepublic.com/blog/linux-and-open-source/use-encrypted-filesys... Although this describes the process for Redhat/Anaconda the openSuse/Yast installer has a similar functionality. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 10:17 PM, Anton Aylward wrote:
On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"?
You've given no indication you are using LVM so what the "mapper"?
I am not using LVM. All partitions are ext4. Swap is not (to my knowledge) encrypted. When setting the partitions for the installation, encrypted is not checked. The names were assigned the first time I installed OpenSuse (9.3?) on this computer. /dev/mapper/pdc_djiegcc_part1 -- Wu\indows C /dev/mapper/pdc_djiegcc_part2 -- 1 kb, not used /dev/mapper/pdc_djiegcc_part5 -- the former /boot partition; not used in new installation /dev/mapper/pdc_djiegcc_part6 -- swap (2 GB) /dev/mapper/pdc_djiegcc_part7 -- / (20 GB) /dev/mapper/pdc_djiegcc_part8 -- /home (894.55 GB)
IFIRST
It is, I suppose, possible to bring a system up without any swap if you have adequate memory and then activate the swap later. You might consider that.
How would you do that?
Well we've discussed in this forum many times the idea of editing the command line for boot, using 'e' at the menu prompt to get into the editor and them following the on-screen instructions.
If you haven't set up swap as encrypted than that message about "mapper" is very strange.
Personally I have boot and swap as primary partitions. Regular readers know that I use LVM. I can add another swap partition as a LVM Logical Volume and have that activated AFTER booting. Equally, I can also make that an encrypted partition.
There is a lot of on-line documentation about encrypting a LV using LUKS/dm-crypt.
SECOND
It is very likely that your initrd does not have the modules needed to handle the mapper and dm-crypt.
You will need
* dm_mod * dm_crypt * sha256
See "man lsinitrd"
I'll check this.
http://www.techrepublic.com/blog/linux-and-open-source/use-encrypted-filesys... Although this describes the process for Redhat/Anaconda the openSuse/Yast installer has a similar functionality.
Thanks -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 09:18 PM, Fr David Ousley wrote:
On 05/26/2015 10:17 PM, Anton Aylward wrote:
On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"?
You've given no indication you are using LVM so what the "mapper"?
I am not using LVM. All partitions are ext4.
HA HA HA. very good. I use LVM. Some of my partitions are ext4. What file system (or swap) has nothing to do with it. LVM is just one use of the mapper, as I go on to point out.
Swap is not (to my knowledge) encrypted. When setting the partitions for the installation, encrypted is not checked.
Are ANY partitions encrypted?
The names were assigned the first time I installed OpenSuse (9.3?) on this computer.
/dev/mapper/pdc_djiegcc_part1 -- Wu\indows C /dev/mapper/pdc_djiegcc_part2 -- 1 kb, not used /dev/mapper/pdc_djiegcc_part5 -- the former /boot partition; not used in new installation /dev/mapper/pdc_djiegcc_part6 -- swap (2 GB) /dev/mapper/pdc_djiegcc_part7 -- / (20 GB) /dev/mapper/pdc_djiegcc_part8 -- /home (894.55 GB)
V.e.r.y i.n.t.e.r.e.s.t.n.g While LVM does date back to the time of 9.3 I'm inclined to think that as others have commented the use of the mapper is an artefact of the way you are using RAID. What is clear is the hang is when attempting to use the mapper, hence trying to access one of the above. So we get back to the matter of "why isn't mapper in the initrd?" As this thread has already mentioned, I would try install on ONLY the SSD. Disconnect the other drives so that the installer doesn't see them, so that they don't get included in the fstab so that they don't confuse the installer or you or us. Sorry, taking the short-cut of editing the fstab isn't the point, you still need a clean and reliable initrd that boots reliably. You want a basic working system that you can rely on and build from that. You do not want a system that just happens to accidentally work because the bailing wire and bad aids are holding it together for a while. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
You mention "/dev/mapper/pdc..."
What is the FULL string please.
Apologies -- in my previous email I listed all the /dev/mapper ... partitions, which arelisted on /dev/mapper/pdc_djiegcc, which duplicates /dev/sdb and /dev/sdc in the list of partitions. the last two are listed as type ST31500341AS. The first as DM RAIS pdc_djiegecc. I omitted the SSD: dev/sda, type: Kingston-SSDNOW -- /dev/sda1 -- system reserved, Windows D /dev/sda2 -- the new /boot (150 MB, ext4) /dev/sda3 -- the new / (25 BG +/-, ext4)
http://www.techrepublic.com/blog/linux-and-open-source/use-encrypted-filesys... Although this describes the process for Redhat/Anaconda the openSuse/Yast installer has a similar functionality.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 03:32, Fr David Ousley wrote:
You mention "/dev/mapper/pdc..."
What is the FULL string please.
Apologies -- in my previous email I listed all the /dev/mapper ... partitions, which arelisted on /dev/mapper/pdc_djiegcc, which duplicates /dev/sdb and /dev/sdc in the list of partitions. the last two are listed as type ST31500341AS. The first as DM RAIS pdc_djiegecc.
I suspect they are the fake raid devices... only a suspicion. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 05/26/2015 11:04 PM, Carlos E. R. wrote:
On 2015-05-27 03:32, Fr David Ousley wrote:
You mention "/dev/mapper/pdc..."
What is the FULL string please.
Apologies -- in my previous email I listed all the /dev/mapper ... partitions, which arelisted on /dev/mapper/pdc_djiegcc, which duplicates /dev/sdb and /dev/sdc in the list of partitions. the last two are listed as type ST31500341AS. The first as DM RAIS pdc_djiegecc.
I suspect they are the fake raid devices... only a suspicion.
Having eliminated actively using LVM, having eliminated using encryption, what is left? But yes, without support in the initrd (and system initialization etc...) the observed phenomena lewaves that as a most likely reason. As I say, as others say, install on just the SSD. Really JUST the ssd, disconnect that RAID stuff so as to eliminate any possibility of reference to it being seen by the installer or bing handled in the fstab or anything in initrd or dracut or whatever. When and ONLY when DAO has a stable and reliable system running on the SSD look to extending it to accommodate the RAID. Then, we can ask about the hardware, the bios settings and advise on setting up dracut to generate a new initrd. He will always have the older initrd to fall back on if the new one fails. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-05-27 15:48, Anton Aylward wrote:
On 05/26/2015 11:04 PM, Carlos E. R. wrote:
I suspect they are the fake raid devices... only a suspicion.
Having eliminated actively using LVM, having eliminated using encryption, what is left?
fake raid (dmraid). And if Andrei is right, the driver has been detected (thus the mapper thing), and it is a hardware issue.
As I say, as others say, install on just the SSD.
Maybe no need, it is already there. If I understand right, it is /home which is on the rotating disks. So comment out the line in fstab, remove the cable and reboot. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 27/05/2015 4:17, Anton Aylward wrote:
On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"?
You've given no indication you are using LVM so what the "mapper"?
Or fake raid, perhaps? He mentioned "bios mirror". Encrypted system? Oh, that would explain the LVM part. YaST sets it up that way. -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W7) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/26/2015 10:33 PM, Carlos E. R. wrote:
On 27/05/2015 4:17, Anton Aylward wrote:
On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"?
You've given no indication you are using LVM so what the "mapper"?
Or fake raid, perhaps? He mentioned "bios mirror".
My RAID is simple and as you mention, done by LINUX as a simple mirror. I've no experience with hardware RAID other than on Big Iron where its all implemented in the drive array (think: SAN) and the host sees just a single logical device. But yes: KISS -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Tue, 26 May 2015 22:17:57 -0400
Anton Aylward
On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"?
You've given no indication you are using LVM so what the "mapper"?
google dmraid -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/27/2015 12:18 AM, Andrei Borzenkov wrote:
В Tue, 26 May 2015 22:17:57 -0400 Anton Aylward
пишет: On 05/26/2015 03:58 PM, Fr David Ousley wrote:
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
WTF "Mapper"?
You've given no indication you are using LVM so what the "mapper"?
google dmraid
Thank you :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Tue, 26 May 2015 15:58:44 -0400
Fr David Ousley
After a while, this leaves the message that the swap partition (identified as /dev/mapper/pdc...) does not exist.
Do you have a Promise fake raid controller?
Booting recovery mode produces recurring lines :
sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 > sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
These lines repeat until Iforce a reboot with the power switch.
These messages come from kernel. If they are really "recurring" it would imply hard drives permanently disappear and are rediscovered again. It smells very much like a hardware issue.
sdb and sdc are the disks where swap and /home are located.
So I have 13.2 installed but cannot boot into it. I tried redoing the installation formatting the swap partition. Does not change the results. Same results with booting the old 12.3 whether with or without the recovery mode.
Which would make hardware issue even more probable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Andrei Borzenkov
-
Anton Aylward
-
Carlos E. R.
-
Felix Miata
-
Fr David Ousley
-
jdd