[opensuse] Problem with leap 15 upgrade
I started to perform an upgrade from 43.2 to Leap 15 and received an error warning: "Some partitions on the system on /dev/sdc2 are mounted by kernel-device name" I had mounted the partitions by UUID. Is UUID that what is meant by a kernel device name? Because I was under the impression that the UUID belonged to the device. Should that cause the system upgrade to fail? I get message Execution of Command ""[["?usr.sbin.grub2-mkconfig","-o","/boot/grubd/grub.cfg"]]" failed Error output: Generating grub configuration file... and more., Then: ERROR:failed to lookup rootid:inappropriate ioctl for device. Is this a problem with the use of UUIDs? The first warning suggests changing the "mount-by" method to any other method. Don't know which other one to pick. Using google it appears that UUID is the most recommended. But another link says that the it you recreate the partitions they will get different UUIDs. I looked in /dev/disk and see by-id, by-label, by-path and by UUID. I would use by-id, but am concerned that all of the devices may not be known. Like 4GB SSD drives. By-path appears vulnerable to the pci id changing if one moves the drive. I usually do not put labels on all of my partitions, so do not know how what by label would look like. What is the best approach? And is this my problem? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-30 03:32, don fisher wrote:
I started to perform an upgrade from 43.2 to Leap 15 and received an error warning:
"Some partitions on the system on /dev/sdc2 are mounted by kernel-device name"
I think this means referring to "/dev/sdc2" instead of uuid or label or such.
I had mounted the partitions by UUID. Is UUID that what is meant by a kernel device name? Because I was under the impression that the UUID belonged to the device. Should that cause the system upgrade to fail? I get message Execution of Command ""[["?usr.sbin.grub2-mkconfig","-o","/boot/grubd/grub.cfg"]]" failed Error output: Generating grub configuration file... and more., Then: ERROR:failed to lookup rootid:inappropriate ioctl for device.
I don't know if this is related or not.
I usually do not put labels on all of my partitions, so do not know how what by label would look like. What is the best approach?
A label is just a name you invent and assign to a partition. It is the method I prefer. Thus, my entry in fstab for home is: LABEL=c_home /home ext4 acl,user_xattr,norelatime,lazytime 1 2 It is very easy to see that a partition named "home" is the "/home" :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 05/29/2018 06:45 PM, Carlos E. R. wrote:
On 2018-05-30 03:32, don fisher wrote:
I started to perform an upgrade from 43.2 to Leap 15 and received an error warning:
"Some partitions on the system on /dev/sdc2 are mounted by kernel-device name"
I think this means referring to "/dev/sdc2" instead of uuid or label or such.
I had mounted the partitions by UUID. Is UUID that what is meant by a kernel device name? Because I was under the impression that the UUID belonged to the device. Should that cause the system upgrade to fail? I get message Execution of Command ""[["?usr.sbin.grub2-mkconfig","-o","/boot/grubd/grub.cfg"]]" failed Error output: Generating grub configuration file... and more., Then: ERROR:failed to lookup rootid:inappropriate ioctl for device.
I don't know if this is related or not.
I usually do not put labels on all of my partitions, so do not know how what by label would look like. What is the best approach?
A label is just a name you invent and assign to a partition. It is the method I prefer. Thus, my entry in fstab for home is:
LABEL=c_home /home ext4 acl,user_xattr,norelatime,lazytime 1 2
It is very easy to see that a partition named "home" is the "/home" :-)
Thanks. I will try to change the fstab and partition names. I did this upgrade from the distribution disk, which I failed to mention in my post. I was disappointed that it was not able to preserve my system, since I have booted it for a couple of years. Now I have to take the disk to another system and make the edits. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-30 04:58, don fisher wrote:
On 05/29/2018 06:45 PM, Carlos E. R. wrote:
On 2018-05-30 03:32, don fisher wrote:
Thanks. I will try to change the fstab and partition names. I did this upgrade from the distribution disk, which I failed to mention in my post. I was disappointed that it was not able to preserve my system, since I have booted it for a couple of years. Now I have to take the disk to another system and make the edits.
The upgrade process some years ago mandated not mounting by kernel-device name. If you did not upgrade that system in years, the issue hits you now. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
don fisher composed on 2018-05-29 18:32 (UTC-0700):
I started to perform an upgrade from 43.2 to Leap 15 and received an error warning:
"Some partitions on the system on /dev/sdc2 are mounted by kernel-device name"
Here's an example fstab that will cause that: /dev/sda1 /mnt/C ntfs-3g noatime,nofail,users,gid=1000,fmask=0111,dmask=0000,locale=en_US.UTF-8 0 0 LABEL=st750swapper swap swap defaults 0 0 LABEL=03linboot /realboot ext2 noatime,noacl 1 2 /dev/sda5 /mnt/D vfat user,nofail,fmask=0111,dmask=0000 0 0 LABEL=06root / ext4 noatime 1 1 LABEL=07tmp /tmp ext4 noatime 1 2 LABEL=08srv /srv ext4 noatime 1 2 LABEL=09usrlcl /usr/local ext4 noatime 1 2 LABEL=10home /home ext4 noatime 1 2 /dev/sda1 & /dev/sda5 are device names. All others are mounting by label.
I had mounted the partitions by UUID. Is UUID that what is meant by a kernel device name? Because I was under the impression that the UUID belonged to the device.
Partitions, disks and filesystems all get UUIDs assigned. Default UUID mounting is using the filesystem UUID (shown by the blkid command, which also shows the UUID for the partition). On my installations the first thing I do in the partitioning phase is change that default to by label.
Should that cause the system upgrade to fail?
It might if device names were used for mounting filesystems necessary for booting or operating system. In the above example, there are no such. Ignoring the error message allows the installation to proceed without non-trivial error.
The first warning suggests changing the "mount-by" method to any other method. Don't know which other one to pick. Using google it appears that UUID is the most recommended. But another link says that the it you recreate the partitions they will get different UUIDs.
They also will if they get reformatted instead of recreated.
...I usually do not put labels on all of my partitions, so do not know how what by label would look like. What is the best approach? And is this my problem?
With by label, you get to create something humanly memorable, instead of dependence on confounding strings like 61d7211e-ab41-2675-1dd5-caf2743fc5f2. The potential risk of by label occurs when your labeling choices get recycled, such as with cloning, but exercising a bit of care in label creation can avoid such trouble. e.g., make a trivial arbitrary disk name string part of each label, and make a habit of following each cloning operation immediately by a relabeling of each clone, as in the above example's swap partition. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (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/29/2018 08:59 PM, Felix Miata wrote:
don fisher composed on 2018-05-29 18:32 (UTC-0700):
I started to perform an upgrade from 43.2 to Leap 15 and received an error warning:
"Some partitions on the system on /dev/sdc2 are mounted by kernel-device name"
Here's an example fstab that will cause that:
/dev/sda1 /mnt/C ntfs-3g noatime,nofail,users,gid=1000,fmask=0111,dmask=0000,locale=en_US.UTF-8 0 0 LABEL=st750swapper swap swap defaults 0 0 LABEL=03linboot /realboot ext2 noatime,noacl 1 2 /dev/sda5 /mnt/D vfat user,nofail,fmask=0111,dmask=0000 0 0 LABEL=06root / ext4 noatime 1 1 LABEL=07tmp /tmp ext4 noatime 1 2 LABEL=08srv /srv ext4 noatime 1 2 LABEL=09usrlcl /usr/local ext4 noatime 1 2 LABEL=10home /home ext4 noatime 1 2
/dev/sda1 & /dev/sda5 are device names. All others are mounting by label.
I had mounted the partitions by UUID. Is UUID that what is meant by a kernel device name? Because I was under the impression that the UUID belonged to the device.
Partitions, disks and filesystems all get UUIDs assigned. Default UUID mounting is using the filesystem UUID (shown by the blkid command, which also shows the UUID for the partition). On my installations the first thing I do in the partitioning phase is change that default to by label.
Should that cause the system upgrade to fail?
It might if device names were used for mounting filesystems necessary for booting or operating system. In the above example, there are no such. Ignoring the error message allows the installation to proceed without non-trivial error.
The first warning suggests changing the "mount-by" method to any other method. Don't know which other one to pick. Using google it appears that UUID is the most recommended. But another link says that the it you recreate the partitions they will get different UUIDs.
They also will if they get reformatted instead of recreated.
...I usually do not put labels on all of my partitions, so do not know how what by label would look like. What is the best approach? And is this my problem?
With by label, you get to create something humanly memorable, instead of dependence on confounding strings like 61d7211e-ab41-2675-1dd5-caf2743fc5f2.
The potential risk of by label occurs when your labeling choices get recycled, such as with cloning, but exercising a bit of care in label creation can avoid such trouble. e.g., make a trivial arbitrary disk name string part of each label, and make a habit of following each cloning operation immediately by a relabeling of each clone, as in the above example's swap partition.
Could someone please inform me if there is some magic way to label partitions. A google search has yielded quite a collection: for FAT32: sudo mlabel -i /dev/sdxN ::"my_label" sudo fatlabel /dev/sdxN my_label for NTFS: sudo ntfslabel /dev/sdxN my_label for exFAT: sudo exfatlabel /dev/sdxN my_label for ext2/3/4: sudo e2label /dev/sdxN my_label for BTRFS: sudo btrfs filesystem label /dev/sdxN my_label for swap mkswap -L my _label <parttion> swaplabel -L my_label device for XFS xfs_admin -L "my_label" /dev/sdb1 Is there a simpler way? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2018-05-30 at 19:40 -0700, don fisher wrote:
Could someone please inform me if there is some magic way to label partitions. A google search has yielded quite a collection:
for FAT32: sudo mlabel -i /dev/sdxN ::"my_label" sudo fatlabel /dev/sdxN my_label for NTFS: sudo ntfslabel /dev/sdxN my_label for exFAT: sudo exfatlabel /dev/sdxN my_label for ext2/3/4: sudo e2label /dev/sdxN my_label for BTRFS: sudo btrfs filesystem label /dev/sdxN my_label for swap mkswap -L my _label <parttion> swaplabel -L my_label device for XFS xfs_admin -L "my_label" /dev/sdb1
Is there a simpler way?
Not much... The easiest is to remember to assign a name when you create or format the partition. YaST2 can do it, and so can gparted. The later can, IIRC, change the label on an existing filesystem. That is not all. There is also, on GPT partitions, partlabel and partuuid, two fields that can be written on the partition table. These, however, are not part of the filesystem, so that the method to write them does not depend on the type of partition. Only that this instant I do not remember how to write them, except perhaps, gparted. I know that I have assigned them. Time to go to sleep ;-) - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlsPYvAACgkQtTMYHG2NR9WSYgCfXgAiQ8ftNQtQJcoSCEld5/oz IxAAnjqP91Jgvgi6PRqAn2RbcMeO+NBa =9IYO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/30/2018 07:40 PM, don fisher wrote:
On 05/29/2018 08:59 PM, Felix Miata wrote:
don fisher composed on 2018-05-29 18:32 (UTC-0700):
I started to perform an upgrade from 43.2 to Leap 15 and received an error warning: "Some partitions on the system on /dev/sdc2 are mounted by kernel-device name" Here's an example fstab that will cause that:
/dev/sda1 /mnt/C ntfs-3g noatime,nofail,users,gid=1000,fmask=0111,dmask=0000,locale=en_US.UTF-8 0 0 LABEL=st750swapper swap swap defaults 0 0 LABEL=03linboot /realboot ext2 noatime,noacl 1 2 /dev/sda5 /mnt/D vfat user,nofail,fmask=0111,dmask=0000 0 0 LABEL=06root / ext4 noatime 1 1 LABEL=07tmp /tmp ext4 noatime 1 2 LABEL=08srv /srv ext4 noatime 1 2 LABEL=09usrlcl /usr/local ext4 noatime 1 2 LABEL=10home /home ext4 noatime 1 2
/dev/sda1 & /dev/sda5 are device names. All others are mounting by label.
I had mounted the partitions by UUID. Is UUID that what is meant by a kernel device name? Because I was under the impression that the UUID belonged to the device.
Partitions, disks and filesystems all get UUIDs assigned. Default UUID mounting is using the filesystem UUID (shown by the blkid command, which also shows the UUID for the partition). On my installations the first thing I do in the partitioning phase is change that default to by label.
Should that cause the system upgrade to fail?
It might if device names were used for mounting filesystems necessary for booting or operating system. In the above example, there are no such. Ignoring the error message allows the installation to proceed without non-trivial error.
The first warning suggests changing the "mount-by" method to any other method. Don't know which other one to pick. Using google it appears that UUID is the most recommended. But another link says that the it you recreate the partitions they will get different UUIDs. They also will if they get reformatted instead of recreated. ...I usually do not put labels on all of my partitions, so do not know how what by label would look like. What is the best approach? And is this my problem? With by label, you get to create something humanly memorable, instead of dependence on confounding strings like 61d7211e-ab41-2675-1dd5-caf2743fc5f2.
The potential risk of by label occurs when your labeling choices get recycled, such as with cloning, but exercising a bit of care in label creation can avoid such trouble. e.g., make a trivial arbitrary disk name string part of each label, and make a habit of following each cloning operation immediately by a relabeling of each clone, as in the above example's swap partition.
Could someone please inform me if there is some magic way to label partitions. A google search has yielded quite a collection:
for FAT32: sudo mlabel -i /dev/sdxN ::"my_label" sudo fatlabel /dev/sdxN my_label for NTFS: sudo ntfslabel /dev/sdxN my_label for exFAT: sudo exfatlabel /dev/sdxN my_label for ext2/3/4: sudo e2label /dev/sdxN my_label for BTRFS: sudo btrfs filesystem label /dev/sdxN my_label for swap mkswap -L my _label <parttion> swaplabel -L my_label device for XFS xfs_admin -L "my_label" /dev/sdb1
Is there a simpler way?
Don
I still receive an error message "failed to lookup rootid: Inappropriate ioctl for device" Can someone tell me what this means, what/where is rootid? When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 Caller: /usr/share/Yast2/lib/bootloader/udev_mapping.rb:42:in 'to_kernel_device" The "failed to lookup rootid: Inappropriate ioctl for device" sounds like a similar problem. Any ideas? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
don fisher composed on 2018-05-30 20:07 (UTC-0700):
I still receive an error message "failed to lookup rootid: Inappropriate ioctl for device" Can someone tell me what this means, what/where is rootid? When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 Caller: /usr/share/Yast2/lib/bootloader/udev_mapping.rb:42:in 'to_kernel_device"
The "failed to lookup rootid: Inappropriate ioctl for device" sounds like a similar problem.
Exactly where do you get these messages? What exactly did you do immediately before seeing them? I suspect you will not get an answer unless you report on bugzilla.opensuse.org with exact reproduction steps and description of what you perceive to be the problem. If YaST is producing these messages, you might get an answer asking on the [yast-devel] mailing list. My gut tells me this problem will go away if you limit your installation processes to having access to devices on no more than one storage bus, and better yet, no storage devices other than the installation target. IOW, if you are installing to USB, disable all other storage devices (e.g. sda, sdb, sdc, sdd & mmcblk*). If installing to sdb, unplug the power from sda, sdc, sdd & mmcblk* and unplug all USB storage devices. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (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/30/2018 09:04 PM, Felix Miata wrote:
don fisher composed on 2018-05-30 20:07 (UTC-0700):
I still receive an error message "failed to lookup rootid: Inappropriate ioctl for device" Can someone tell me what this means, what/where is rootid? When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 Caller: /usr/share/Yast2/lib/bootloader/udev_mapping.rb:42:in 'to_kernel_device"
The "failed to lookup rootid: Inappropriate ioctl for device" sounds like a similar problem.
Exactly where do you get these messages? What exactly did you do immediately before seeing them?
I suspect you will not get an answer unless you report on bugzilla.opensuse.org with exact reproduction steps and description of what you perceive to be the problem.
If YaST is producing these messages, you might get an answer asking on the [yast-devel] mailing list.
My gut tells me this problem will go away if you limit your installation processes to having access to devices on no more than one storage bus, and better yet, no storage devices other than the installation target. IOW, if you are installing to USB, disable all other storage devices (e.g. sda, sdb, sdc, sdd & mmcblk*). If installing to sdb, unplug the power from sda, sdc, sdd & mmcblk* and unplug all USB storage devices.
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes. No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post. I do assume they are coming from grub2. But that system no longer boots so I do not know what operations I can perform. Is there anything in the grub config files that could cause problems? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
31.05.2018 22:26, don fisher пишет:
On 05/30/2018 09:04 PM, Felix Miata wrote:
don fisher composed on 2018-05-30 20:07 (UTC-0700):
I still receive an error message "failed to lookup rootid: Inappropriate ioctl for device" Can someone tell me what this means, what/where is rootid? When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 Caller: /usr/share/Yast2/lib/bootloader/udev_mapping.rb:42:in 'to_kernel_device"
The "failed to lookup rootid: Inappropriate ioctl for device" sounds like a similar problem.
Exactly where do you get these messages? What exactly did you do immediately before seeing them?
I suspect you will not get an answer unless you report on bugzilla.opensuse.org with exact reproduction steps and description of what you perceive to be the problem.
If YaST is producing these messages, you might get an answer asking on the [yast-devel] mailing list.
My gut tells me this problem will go away if you limit your installation processes to having access to devices on no more than one storage bus, and better yet, no storage devices other than the installation target. IOW, if you are installing to USB, disable all other storage devices (e.g. sda, sdb, sdc, sdd & mmcblk*). If installing to sdb, unplug the power from sda, sdc, sdd & mmcblk* and unplug all USB storage devices.
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes.
You see this message before system reboots or after? You cannot miss BIOS screen when system goes to reboot, so you should know it.
No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post. I do assume they are coming from grub2.
They are very unlikely come from grub as grub does not run on top of Linux kernel and so cannot call any ioctl. Nor can I find this string anywhere in grub sources. Nor can I find string "rootid" anywhere I can think of. I *can* find string failed to lookup root id: %s (note extra space between "root" and "id") in btrfs utils. But that still does not match what you write.
But that system no longer boots so I do not know what operations I can perform. Is there anything in the grub config files that could cause problems?
So you already diagnosed it as grub problem?
Don
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/31/2018 12:40 PM, Andrei Borzenkov wrote:
31.05.2018 22:26, don fisher пишет:
On 05/30/2018 09:04 PM, Felix Miata wrote:
don fisher composed on 2018-05-30 20:07 (UTC-0700):
I still receive an error message "failed to lookup rootid: Inappropriate ioctl for device" Can someone tell me what this means, what/where is rootid? When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 Caller: /usr/share/Yast2/lib/bootloader/udev_mapping.rb:42:in 'to_kernel_device"
The "failed to lookup rootid: Inappropriate ioctl for device" sounds like a similar problem.
Exactly where do you get these messages? What exactly did you do immediately before seeing them?
I suspect you will not get an answer unless you report on bugzilla.opensuse.org with exact reproduction steps and description of what you perceive to be the problem.
If YaST is producing these messages, you might get an answer asking on the [yast-devel] mailing list.
My gut tells me this problem will go away if you limit your installation processes to having access to devices on no more than one storage bus, and better yet, no storage devices other than the installation target. IOW, if you are installing to USB, disable all other storage devices (e.g. sda, sdb, sdc, sdd & mmcblk*). If installing to sdb, unplug the power from sda, sdc, sdd & mmcblk* and unplug all USB storage devices.
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes.
You see this message before system reboots or after? You cannot miss BIOS screen when system goes to reboot, so you should know it.
No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post. I do assume they are coming from grub2.
They are very unlikely come from grub as grub does not run on top of Linux kernel and so cannot call any ioctl. Nor can I find this string anywhere in grub sources.
Nor can I find string "rootid" anywhere I can think of. I *can* find string
failed to lookup root id: %s
(note extra space between "root" and "id") in btrfs utils. But that still does not match what you write.
But that system no longer boots so I do not know what operations I can perform. Is there anything in the grub config files that could cause problems?
So you already diagnosed it as grub problem?
I will perform the upgrade from DVD again. Please tell me what I should look for, and what details you are looking for. Thanks, Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-31 21:26, don fisher wrote:
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes. No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post.
Where are those photos? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 05/31/2018 01:22 PM, Carlos E. R. wrote:
On 2018-05-31 21:26, don fisher wrote:
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes. No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post.
Where are those photos?
On my sd card. Also visible in digikam once I downloaded them. I know nothing about cutting and pasting photos. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-31 22:35, don fisher wrote:
On 05/31/2018 01:22 PM, Carlos E. R. wrote:
On 2018-05-31 21:26, don fisher wrote:
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes. No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post.
Where are those photos?
On my sd card. Also visible in digikam once I downloaded them. I know nothing about cutting and pasting photos.
Well, upload them somewhere so that we can see the errors. You can use "gimp" to cut a section or to compress to smaller size, and upload to susepaste for some limited time, then post the resulting URL here. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 05/31/2018 01:39 PM, Carlos E. R. wrote:
On 2018-05-31 22:35, don fisher wrote:
On 05/31/2018 01:22 PM, Carlos E. R. wrote:
On 2018-05-31 21:26, don fisher wrote:
I am attempting to perform an upgrade from 4.3 to 5. I see these messages when the system tries to reboot after the upgrade completes. No output, other than the screen messages, is available that I know of. So I take pictures with my little camera so I can include the output in my post.
Where are those photos?
On my sd card. Also visible in digikam once I downloaded them. I know nothing about cutting and pasting photos.
Well, upload them somewhere so that we can see the errors.
You can use "gimp" to cut a section or to compress to smaller size, and upload to susepaste for some limited time, then post the resulting URL here.
They are three jpeg files, each about 5 MB. I do not know about how to compress the images, or what the goals would be. I am guilty of coming from a research background, my last project was making videos of supernova explosions from simulations run on various supercomputers. A typical run would be at least 1TB. I have been chastised in the past for a couple of posts with 0.5MB data, which I had thought to be trivial. My laptop has 7TB of disk storage. Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, May 31, 2018 at 1:52 PM don fisher <hdf3@comcast.net> wrote:
Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be?
Hi Don, Just head over to http://paste.opensuse.org/ and under language select "Image file" (or hit the small Image link just above the box). Select one of the image files and hit the create button. It will redirect you to a page showing your photo, and a URL that you can paste here. Repeat a few times to get all of the photos. If it is too large it will tell you, but more likely if that were the case it would resize the image itself. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/31/2018 01:59 PM, Steve Susbauer wrote:
On Thu, May 31, 2018 at 1:52 PM don fisher <hdf3@comcast.net> wrote:
Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be?
Hi Don,
Just head over to http://paste.opensuse.org/ and under language select "Image file" (or hit the small Image link just above the box). Select one of the image files and hit the create button. It will redirect you to a page showing your photo, and a URL that you can paste here. Repeat a few times to get all of the photos.
If it is too large it will tell you, but more likely if that were the case it would resize the image itself.
Thanks, but even selecting an expiration date of on day, it claims me file is too large. Can I contribute a disk, or something, to get a larger tolerance? Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-31 22:59, Steve Susbauer wrote:
On Thu, May 31, 2018 at 1:52 PM don fisher <hdf3@comcast.net> wrote:
Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be?
Hi Don,
Just head over to http://paste.opensuse.org/ and under language select "Image file" (or hit the small Image link just above the box). Select one of the image files and hit the create button. It will redirect you to a page showing your photo, and a URL that you can paste here. Repeat a few times to get all of the photos.
If it is too large it will tell you, but more likely if that were the case it would resize the image itself.
Another option is to install and run command "susepaste". Example: susepaste -t "first photo" -n "Don F." -e 40320 file.jpg (see man page for exact explanation). This tries to upload file.jpg for a month. If it says "too big", a posibility is to upload for just a week: susepaste -t "first photo" -n "Don F." -e 10080 file.jpg Procedure to make a photo more compressed. Load "gimp". Use menu "file/open" to load the photo. On the photo that opens, use menu "file / export as". Choose a name. Click "export" button. A dialog will appear, similar to the photo I have attached to this email. Make sure the "show preview" tick is ticked. As you slide the rule right or left and stop you will see the "file size" to be calculated; also you will see the photo in the background to visibly lose quality as you move the slider to the left. Thus you can choose as bad a quality that makes the file to be small, yet it is still readable. ie, you choose the correct quality/size ratio. Then hit the "export" button in it. And then hit the "X" on the photo to close it: it will complain that it is not saved, ignore it (discard changes). Gimp complains unless you do not save in gimp own format, but in this case we know what we are doing and we want jpg. Repeat for all the photos, then upload them. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Hello, On Thu, 31 May 2018, don fisher wrote:
They are three jpeg files, each about 5 MB. I do not know about how to compress the images, or what the goals would be. I am guilty of coming from a [..] Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be?
Try this on the command line (you might have to install ImageMagick or GraphicsMagick to get the 'convert' tool): convert -geometry 1280x1280 IMG_NUMBER_ONE.jpg SMALL_IMG_NUMBER_ONE.png Do the same for the 2 other images. Then copy/move the SMALL_* images into /tmp/. Then, open up https://paste.opensuse.org in your favourite webbrowser. At the top, you see some menu and then a big frame with the title "Here you can create your paste: " There, right on the right edge of the line with that title, you'll see a rather innocuous "Image" link. Click on that. Then, you get a smaller form, with a "Browse..." button and besides that a "No file selected" text to the right of a bold "Your paste" caption, click on the "Browse"-button. Your browser should pop up a file-selection dialog, find your way to /tmp and add the first image. "Delete After" defaults to 1 Week, which should be good, so nothing else to do, so click on "Create", copy the URL you get so you can mail it here. Lather, rinse, repeat with the 2 other images. HTH, -dnh -- Clues seem to seep out of lusers faster than you can LART them back in. -- Simon Burr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/31/2018 02:25 PM, David Haller wrote:
Hello,
On Thu, 31 May 2018, don fisher wrote:
They are three jpeg files, each about 5 MB. I do not know about how to compress the images, or what the goals would be. I am guilty of coming from a [..] Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be?
Try this on the command line (you might have to install ImageMagick or GraphicsMagick to get the 'convert' tool):
convert -geometry 1280x1280 IMG_NUMBER_ONE.jpg SMALL_IMG_NUMBER_ONE.png
Do the same for the 2 other images. Then copy/move the SMALL_* images into /tmp/.
Then, open up https://paste.opensuse.org in your favourite webbrowser. At the top, you see some menu and then a big frame with the title
"Here you can create your paste: "
There, right on the right edge of the line with that title, you'll see a rather innocuous "Image" link. Click on that. Then, you get a smaller form, with a "Browse..." button and besides that a "No file selected" text to the right of a bold "Your paste" caption, click on the "Browse"-button. Your browser should pop up a file-selection dialog, find your way to /tmp and add the first image.
"Delete After" defaults to 1 Week, which should be good, so nothing else to do, so click on "Create", copy the URL you get so you can mail it here.
Lather, rinse, repeat with the 2 other images.
HTH, -dnh
Thanks very much. Had to go down to 1024x1024, but they are still readable. Let me know what you think. I can perform the upgrade again and make sure I get all of the images. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/31/2018 02:25 PM, David Haller wrote:
Hello,
On Thu, 31 May 2018, don fisher wrote:
They are three jpeg files, each about 5 MB. I do not know about how to compress the images, or what the goals would be. I am guilty of coming from a [..] Above is (probably too much) background as to why I need assistance/guidance in how to make the data available. My ISP makes it near impossible to make my disks available on the web. How does susepaste work, and can I load 15MB to that site without conflicts? If not, how small do they need to be?
Try this on the command line (you might have to install ImageMagick or GraphicsMagick to get the 'convert' tool):
convert -geometry 1280x1280 IMG_NUMBER_ONE.jpg SMALL_IMG_NUMBER_ONE.png
Do the same for the 2 other images. Then copy/move the SMALL_* images into /tmp/.
Then, open up https://paste.opensuse.org in your favourite webbrowser. At the top, you see some menu and then a big frame with the title
"Here you can create your paste: "
There, right on the right edge of the line with that title, you'll see a rather innocuous "Image" link. Click on that. Then, you get a smaller form, with a "Browse..." button and besides that a "No file selected" text to the right of a bold "Your paste" caption, click on the "Browse"-button. Your browser should pop up a file-selection dialog, find your way to /tmp and add the first image.
"Delete After" defaults to 1 Week, which should be good, so nothing else to do, so click on "Create", copy the URL you get so you can mail it here.
Lather, rinse, repeat with the 2 other images.
HTH, -dnh
My bad, forgot the URLs. https://paste.opensuse.org/55450908 https://paste.opensuse.org/78525363 https://paste.opensuse.org/43433048 Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-01 00:03, don fisher wrote:
My bad, forgot the URLs.
Well, this issue you solve by cancelling the upgrade, editing in fstab all /dev/sdcX entries so that they are by UUID, label, id, or path, (plus mkinitrd), restarting the system to verify it boots, and finally, trying again the upgrade procedure. I believe you already did this part. Possibly also try to redo grub configuration. I would start (in the non-upgraded machine state) run YaST boot configuration module, do at lest one trivial change, namely change one second up or down the timeout, which forces YaST to reinstall grub2.
This is a YaST internal bug, and the message says what to do with it. Very unfortunate. In the Bugzilla, hopefully someone will tell you how to do the upgrade, then.
Well, I don't know what this one means. It is calling grub2-mkconfig, so it is grub related. Andrei will know more about it. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
01.06.2018 01:03, don fisher пишет:
The error is from script /etc/grub.d/80_suse_btrfs_snapshot, which calls "btrfs inspect-internal rootid /". Apparently at the time of execution "/" is not btrfs. You should open bug report. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/2018 10:03 AM, Andrei Borzenkov wrote:
01.06.2018 01:03, don fisher пишет:
The error is from script /etc/grub.d/80_suse_btrfs_snapshot, which calls "btrfs inspect-internal rootid /". Apparently at the time of execution "/" is not btrfs. You should open bug report.
Could you send details on how to open such a bug report. I have made errors in the past and do not wish to compound the felony:-) Do I need to reference the photo, and if so, how do I get the photo expiration extended to cover whoever may respond to the bug report. Any other advice would be appreciated. Thanks, Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
01.06.2018 22:55, don fisher пишет:
On 06/01/2018 10:03 AM, Andrei Borzenkov wrote:
01.06.2018 01:03, don fisher пишет:
The error is from script /etc/grub.d/80_suse_btrfs_snapshot, which calls "btrfs inspect-internal rootid /". Apparently at the time of execution "/" is not btrfs. You should open bug report.
Could you send details on how to open such a bug report. I have made errors in the past and do not wish to compound the felony:-) Do I need to reference the photo, and if so, how do I get the photo expiration extended to cover whoever may respond to the bug report. Any other advice would be appreciated.
Attach (not reference) photo to bug report; show original /etc/fstab from 42.3 you update. I do not know how exactly scripts are called during installation so I cannot tell what information would be required here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/2018 09:27 PM, Andrei Borzenkov wrote:
01.06.2018 22:55, don fisher пишет:
On 06/01/2018 10:03 AM, Andrei Borzenkov wrote:
01.06.2018 01:03, don fisher пишет:
The error is from script /etc/grub.d/80_suse_btrfs_snapshot, which calls "btrfs inspect-internal rootid /". Apparently at the time of execution "/" is not btrfs. You should open bug report.
Could you send details on how to open such a bug report. I have made errors in the past and do not wish to compound the felony:-) Do I need to reference the photo, and if so, how do I get the photo expiration extended to cover whoever may respond to the bug report. Any other advice would be appreciated.
Attach (not reference) photo to bug report; show original /etc/fstab from 42.3 you update. I do not know how exactly scripts are called during installation so I cannot tell what information would be required here.
My system is a real mess. My grub.cfg is trashed, my Leap 15 grub.cfg file system still contains references to 43.2 files. I have to learn how to boot a rescue system and remake all of the grub 2 stuff. I am currently working on a 4TB disk, with partition 1 type bios_grub, and partition 2 type legacy_boot. I think that is all correct. Now to make sure grub is written to the bios_grub partition, and all the rest makes sense. thanks Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
don fisher composed on 2018-06-01 22:12 (UTC-0700):
My system is a real mess. My grub.cfg is trashed, my Leap 15 grub.cfg file system still contains references to 43.2 files. I have to learn how to boot a rescue system and remake all of the grub 2 stuff. I am currently working on a 4TB disk, with partition 1 type bios_grub, and partition 2 type legacy_boot. I think that is all correct. Now to make sure grub is written to the bios_grub partition, and all the rest makes sense.
If I had this PC and all the trouble you've been having, I'd restart with a fresh 15.0 install - AFTER disconnecting power to all storage devices except installation media and the installation target disk. Once everything on it seems OK I'd try adding the current sda only. Once that's debugged, if debugging is necessary, I'd add back the current sdc too. Finally with those three OK I'd add the current sdd. If 15.0 installation still failed in this manner. I'd install 42.3 in same manner, and after ensuring all seems right, do a zypper upgrade to 15.0. If either of these attempts at 15.0 failed, I'd create bug report(s): https://en.opensuse.org/openSUSE:Submitting_bug_reports Of course, if it was here, all partitioning would be complete, and all filesystems created, none of which would BTRFS, before beginning installation, using the non-guided expert partitioner, for nothing other than designating what to mount where. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (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 2018-06-01 21:55, don fisher wrote:
On 06/01/2018 10:03 AM, Andrei Borzenkov wrote:
01.06.2018 01:03, don fisher пишет:
The error is from script /etc/grub.d/80_suse_btrfs_snapshot, which calls "btrfs inspect-internal rootid /". Apparently at the time of execution "/" is not btrfs. You should open bug report.
Could you send details on how to open such a bug report. I have made errors in the past and do not wish to compound the felony:-) Do I need to reference the photo, and if so, how do I get the photo expiration extended to cover whoever may respond to the bug report. Any other advice would be appreciated.
Simply attach the photos to the report. <https://en.opensuse.org/openSUSE:Submitting_bug_reports> You need to run "save_y2logs" in a terminal. It will generate a compressed archive of the logs which you also have to attach to the report. Assuming the system boots and runs. If it doesn't, you have to do it from a rescue system. Start it, mount your 15.0 filesystem somewhere in /mnt, then: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev chroot /mnt and run your commands. save_y2logs Then, you can start yast in text mode, start the boot module, and correct the grub2 start of the failed 15.0 install. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2018-06-02 13:22 (UTC+0200):
Simply attach the photos to the report.
You need to run "save_y2logs" in a terminal. It will generate a compressed archive of the logs which you also have to attach to the report.
Assuming the system boots and runs.
If it doesn't, you have to do it from a rescue system. Start it, mount your 15.0 filesystem somewhere in /mnt, then:
in /mnt/somewhere/ your instructions will not work. Maybe you meant: filesystem somewhere, e.g. /mnt/, then
mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
chroot /mnt
and run your commands.
save_y2logs
If you don't give a fullpath filename to that command, you might not figure out where it went.
Then, you can start yast in text mode, start the boot module, and correct the grub2 start of the failed 15.0 install.
s/grub2 start/grub2 part/ maybe? -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (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 2018-06-02 13:35, Felix Miata wrote:
Carlos E. R. composed on 2018-06-02 13:22 (UTC+0200):
Simply attach the photos to the report.
You need to run "save_y2logs" in a terminal. It will generate a compressed archive of the logs which you also have to attach to the report.
Assuming the system boots and runs.
If it doesn't, you have to do it from a rescue system. Start it, mount your 15.0 filesystem somewhere in /mnt, then:
in /mnt/somewhere/ your instructions will not work. Maybe you meant:
filesystem somewhere, e.g. /mnt/, then
Yes, or somewhere under /mnt if it is in use. Doesn't matter. /foo is ok, too :-)
mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
chroot /mnt
and run your commands.
save_y2logs
If you don't give a fullpath filename to that command, you might not figure out where it went.
To /tmp, I think. It says where.
Then, you can start yast in text mode, start the boot module, and correct the grub2 start of the failed 15.0 install.
s/grub2 start/grub2 part/ maybe?
Yes, but if one is not fully familiar with grub, yast is preferred. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Le 31/05/2018 à 22:39, Carlos E. R. a écrit :
On 2018-05-31 22:35, don fisher wrote:
On my sd card. Also visible in digikam once I downloaded them. I know nothing about cutting and pasting photos.
You can use "gimp" to cut a section or to compress to smaller size, and upload to susepaste for some limited time, then post the resulting URL here.
digikam is much more froendly than gimp to cut and past photos :-) if you use kde, try "kim" to manage photos and mails jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Wed, 30 May 2018, don fisher wrote: [..]
When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 ^ That should probably be a 'S'
That id seems garbled. What's actually in /dev/disk/by-id/ and what does: hdparm -i /dev/sdXY report in the first line (the one beginning with Model=)? -dnh -- "Considering the number of wheels Microsoft has found reason to invent, one never ceases to be baffled by the minuscule number whose shape even vaguely resembles a circle". -- unknown, but _very_ sharp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
31.05.2018 10:18, David Haller пишет:
Hello,
On Wed, 30 May 2018, don fisher wrote: [..]
When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 ^ That should probably be a 'S'
No, this is really "1", it denotes NAA type for device identification that is used to build by-id path.
That id seems garbled. What's actually in /dev/disk/by-id/ and what does:
hdparm -i /dev/sdXY
report in the first line (the one beginning with Model=)?
-dnh
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 31 May 2018, Andrei Borzenkov wrote:
31.05.2018 10:18, David Haller ?????:
On Wed, 30 May 2018, don fisher wrote: [..]
When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 ^ That should probably be a 'S'
No, this is really "1", it denotes NAA type for device identification that is used to build by-id path.
And what would "NAA" be? I just got ata-<VENDOR>_<MODEL>_<SERIAL>[-part*] scsi-SATA_<VENDOR>_<MODEL>_<SERIAL>[-part*] and wwn_<WWN_ID>[-part*] in /dev/disk/by-id. Ok, I've no SAS disks. But the 840 series? And there's nothing in the kernel (4.16.x) either. -dnh -- How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence? -- Peter Flynn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
01.06.2018 00:37, David Haller пишет:
Hello,
On Thu, 31 May 2018, Andrei Borzenkov wrote:
31.05.2018 10:18, David Haller ?????:
On Wed, 30 May 2018, don fisher wrote: [..]
When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 ^ That should probably be a 'S'
No, this is really "1", it denotes NAA type for device identification that is used to build by-id path.
And what would "NAA" be?
You ask "what NAA means" or you ask "what type is in this case"?
I just got
And your distribution and version is ... ?
ata-<VENDOR>_<MODEL>_<SERIAL>[-part*] scsi-SATA_<VENDOR>_<MODEL>_<SERIAL>[-part*] and
So what? The rules that are installed on your system create this name for your specific devices. That does not mean that same must now happen on every other system out there. It is quite possible that rules have changed and cause problem on update, which would mean regression. This specific link should be created by 61-persistent-storage-compat.rules. File has changed between Leap 42 and Leap 15. If someone has system with both Leap 42 and Leap 15 and can demonstrate that Leap 15 no more creates this link, this should be reported as a bug (regression).
wwn_<WWN_ID>[-part*]
in /dev/disk/by-id. Ok, I've no SAS disks. But the 840 series? And there's nothing in the kernel (4.16.x) either.
-dnh
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-05-31 05:07, don fisher wrote:
On 05/30/2018 07:40 PM, don fisher wrote:
I still receive an error message "failed to lookup rootid: Inappropriate ioctl for device" Can someone tell me what this means, what/where is rootid?
Well, that's a different issue. No, I don't know what it means exactly.
When I upgraded to leap 14 I received a lot of problems because my disk, a Samsung 1TB SSD was not recognized. Details: Unknown udev device /dev/disk/by-id/scsi-1ATA_Samsung_SSD_840_EVO_1TB_SiD9NSAFB28745F-part2 Caller: /usr/share/Yast2/lib/bootloader/udev_mapping.rb:42:in 'to_kernel_device"
The "failed to lookup rootid: Inappropriate ioctl for device" sounds like a similar problem.
If the messages are still the same as in your first post, they seem related to grub or os-prober. I would then try in YaST disabling probe of other operating system in the boot module. os-prober tries to figure out every partition in the system, and some of those produce errors when probing. Like when it tries to see the contents of the extended partition container. And of course, wirte a bugzilla about it. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
don fisher composed on 2018-05-30 19:40 (UTC-0700):
Could someone please inform me if there is some magic way to label partitions. A google search has yielded quite a collection:
for FAT32: sudo mlabel -i /dev/sdxN ::"my_label" sudo fatlabel /dev/sdxN my_label for NTFS: sudo ntfslabel /dev/sdxN my_label for exFAT: sudo exfatlabel /dev/sdxN my_label for ext2/3/4: sudo e2label /dev/sdxN my_label for BTRFS: sudo btrfs filesystem label /dev/sdxN my_label for swap mkswap -L my _label <parttion> swaplabel -L my_label device for XFS xfs_admin -L "my_label" /dev/sdb1
Is there a simpler way?
Simplest is to assign them at format time via whatever switch or input field the applicable formatter offers. Cmdline utilities like mkfs.ext4 and mkswap provide a -L switch. I change them routinely because I clone routinely. For extX I use tune2fs -U -L, restoring unique UUIDs and LABELs simultaneously. blkid reminds of the existing UUID & LABEL on partitions of any type, a good habit to get into using right before adding or changing UUID and/or LABEL to help ensure correct device name is to be used. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (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
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
David Haller -
don fisher -
Felix Miata -
jdd＠dodin.org -
Steve Susbauer