On 11/09/2018 00.11, Anton Aylward wrote:

On 2018-09-10 6:36 p.m., Carlos E. R. wrote:

...

On 10/09/2018 17.41, don fisher wrote:

...

Is there a way to remove BTRFS from a running opensuse system and convert to another file system, such as ext4? I did not see anything on line.

I can do it, but it is not trivial (the reverse is guru level). You need a rescue stick (use the opensuse xfce rescue image, at the live iso link), then do a full backup of the root partition to something else (excepting the snapshots), using rsync, format the root partition as ext4, mount it back, restore files, (edit *that* fstab), reinstall grub using yast (perhaps edit grub config to reflect filesytem change), reboot. You might use the home partition as destination for the backup.

OPTIONS="--archive --acls --xattrs --hard-links --sparse --stats --human-readable --checksum"

rsync $OPTIONS --exclude=/lost+found \ $FROM/ $DEST

I would suggest that OPTIONS include

"--one-file-system " don't cross filesystem boundaries

Yes, absolutely, you are right. It avoids having to manually exclude /home, and perhaps /dev, /proc, and /sys. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/09/2018 16.41, don fisher wrote:

On 09/10/2018 03:36 PM, Carlos E. R. wrote:

...

On 10/09/2018 17.41, don fisher wrote:

...

Is there a way to remove BTRFS from a running opensuse system and convert to another file system, such as ext4? I did not see anything on line.

I can do it, but it is not trivial (the reverse is guru level). You need a rescue stick (use the opensuse xfce rescue image, at the live iso link), then do a full backup of the root partition to something else (excepting the snapshots), using rsync, format the root partition as ext4, mount it back, restore files, (edit *that* fstab), reinstall grub using yast (perhaps edit grub config to reflect filesytem change), reboot. You might use the home partition as destination for the backup.

OPTIONS="--archive --acls --xattrs --hard-links --sparse --stats --human-readable --checksum"

    rsync $OPTIONS --exclude=/lost+found   \          $FROM/   $DEST

I tried this approach and it appears to work. I ran into a probably silly problem when I allowed the distribution installation media to generate my partition setup. It has been a long time since I dealt with MBRs etc, but the installation media generated a bios grub partition. Correct. Leave it, don't touch it. It is not /boot, it is different.

In the past I have always used the legacy 512B MBR. When booting I receive a "GRUB " printout and then nothing. Is there something obvious that I need to do? My BIOS is set for legacy boot. Is this correct? I can go to Yast2/Configuring the Boot Loader and write "Generic Boot Code to MBR" if this is the correct approach.

That's a possibility that normally doesn't harm, unless you use your own. Simply go into yast boot module, and change the timeout, one second up or down. That tells yast to write grub again. But make sure that all the settings are correct in YaST (it is a different partition now). Why Legacy bios mode?

I can boot from another disk on the same machine, and the ext4 file system appears to function properly. Thanks.

You have to boot another and chroot this one.

I can open a new thread if you think I should.

No, let's keep the entire process of migration in a single thread. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-09-11 9:19 a.m., Carlos E. R. wrote:

The fact is, I haven't had a problem with ext4 on / in a decade at least.

Similarly, I haven't had a problem with ReiserFS for the same or longer. Linda? Would you care to comment on XFS? -- 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

This is what happens when I try to answer something in the middle of the night. I forget to respond to things (and I still haven't had my coffee). On 9/11/2018 6:19 AM, Carlos E. R. wrote:

On 11/09/2018 00.07, Anton Aylward wrote:

...

Why did I use Ext4? Well it is built into the kernel. I can load it without any modules.

Oh? This is from my current config: # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=m CONFIG_EXT4_USE_FOR_EXT2=y CONFIG_EXT4_FS_POSIX_ACL=y # CONFIG_EXT4_FS_SECURITY is not set # CONFIG_EXT4_ENCRYPTION is not set # CONFIG_EXT4_DEBUG is not set What about the above config options indicate it is built into the kernel? CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y # CONFIG_XFS_ONLINE_SCRUB is not set # CONFIG_XFS_WARN is not set # CONFIG_XFS_DEBUG is not set # CONFIG_VXFS_FS is not set Well, as for my statement about ACL's being built in...um...it was the EXT_attrs that were built in. But acl support was builtin to the earliest designs for XFS.

...

(re: ext4)... But as far as I'm concerned its a bloody awful FS. That division between inode space and data space.

Sad to say, but that division is in XFS as well (from the mkfs.xfs manpage): This specifies the maximum percentage of space i the filesystem that can be allocated to inodes. The default value is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% for filesystems over 50TB.

You could use XFS instead. But then, you might need a separate /boot partition. However, I think that ext4 is easier to repair, more resilient and robust for "/". Just a baseless, gut feeling ;-)

I can't remember ever needing to repair root. /usr - about 2-3 times, but for those that can't run off of '/' and make repairs, that's likely a distinction that doesn't make a difference. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-09-11 4:44 p.m., Carlos E. R. wrote:

Ah, yes, but I understand on XFS inodes are dynamic, not fixed at format time.

Once I run a test creating many thousands of small files. btrfs was sluggish and finally crashed, ext4 coped till inodes spent, xfs coped well (till disk full of new inodes, IIRC), and reiserfs wanted more.

Yes, this is the point I was trying to make about ext4 still being stuck in the old old model of resource preallocation. A REAL Btree FS allocates resources dynamically ... all resources. Ext4 just uses Btree mechanisms to pool free blocks rather then the first-in-last-out queue model that the old UNIX V5,V6,V7 used and that was later inherited down the line. ReiserFS is remarkably efficient about packing all the small files it can. In a world where you have lots of smell scripts, that's wonderful. And it doens't do that at the cost of larger files. Too many systems, other FS, trade off one thing for another. You optimise for small files at the cost of large ones. The downside of ReiserFS is threading. Look at the man pages for ext4, ReiserFS, JFS, and XFS and compare the number of tuning opinions you can play with to 'optimise' the FS for one thing or another, or fail to take advantage of some feature. I mean, consider this from the ext4 man page: dir_nlink Normally, ext4 allows an inode to have no more than 65,000 hard links. If you have that many files in a directory then I think you have some design problem in your application. -- 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 11/09/2018 20.32, Anton Aylward wrote:

On 2018-09-11 4:44 p.m., Carlos E. R. wrote:

...

Ah, yes, but I understand on XFS inodes are dynamic, not fixed at format time.

Once I run a test creating many thousands of small files. btrfs was sluggish and finally crashed, ext4 coped till inodes spent, xfs coped well (till disk full of new inodes, IIRC), and reiserfs wanted more.

Yes, this is the point I was trying to make about ext4 still being stuck in the old old model of resource preallocation.

A REAL Btree FS allocates resources dynamically ... all resources. Ext4 just uses Btree mechanisms to pool free blocks rather then the first-in-last-out queue model that the old UNIX V5,V6,V7 used and that was later inherited down the line.

But a filesystem with fixed and known location and size structures is easier to repair in case of disaster. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/11/2018 5:17 PM, Anton Aylward wrote:

On 2018-09-11 2:16 p.m., L A Walsh wrote:

...

On 9/11/2018 6:19 AM, Carlos E. R. wrote:

...

On 11/09/2018 00.07, Anton Aylward wrote:

...

Why did I use Ext4? Well it is built into the kernel. I can load it without any modules.

---

Oh? This is from my current config: CONFIG_EXT4_FS=m

CONFIG_EXT4_FS=y <========

...

CONFIG_XFS_FS=y

CONFIG_XFS_FS=m <=================

Well no one is stopping you from changing that except yourself. If you were in the habit of building your own kernel, it would take almost no time at all -- just script all the manual stuff. I have 1 script were I tell it what version to download. The script looks at whats available locally, and downloads the patchfile to get to the desired patchlevel and applies the patch[es]. It then takes the closest versioned config and uses that to do a make-oldconfig. I usually like to see what was added, so I have it stop there. I have the makefile to build it and the modules, and another script to install the binaries, modules and rerun lilo. I have it in 3 steps because that's where I usually want to break and or look at things. If I didn't want that, I could have the whole thing in 1 script. I didn't write the version-downloader and patch script all at the beginning, but finally got tired of the manual, repetitive work. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/12/2018 06:01 AM, Anton Aylward wrote:

On 2018-09-11 9:06 p.m., L A Walsh wrote:

...

On 9/11/2018 5:17 PM, Anton Aylward wrote:

...

    Well no one is stopping you from changing that except yourself. If you were in the habit of building your own kernel, it would take almost no time at all -- just script all the manual stuff.

ROTFLMAO!

yes, many of us did that a century ago. The whole point of the precompiled repositories and the build System is so we don't have to do that. We don't have to install GCC and a lot more, we don't have to do all that.

Fine, so I have a kernel with a FS that I need to access my 2G /boot partition. Everything else is as a module. The less in the kernel, the smaller the initrd the faster the basic boot comes up. Oh, and I can patch/replace modules with a live kernel if I need to.

...

    I have 1 script were I tell it what version to download.

You probably have a use-case where you need to go though all of that. Most of us don't. heck, not everyone is even as obsessive as me about keeping up to date with Kernel_Stable; most people live with the distribution kernel (I have that around somewhere too).

I'm sure John or someone from Suse will tell us how the commercial system sticks with the distribution kernel and uses the module system to 'patch'.

As JDD points out, even with a ext4 kernel, the opensuse distribution defaults to Btrfs for / and XFS for /home.

It is possible some people who are commercial problem solvers might need to boot arbitrary kernels, but I imagine that they have 150G /boot and have never run /purge-kenels/ although they have run /zypper up --from kernel_stable/ every day, every hour, for the last ... ?decade? maybe people like them are an audience for your scripts.

But this thread? I asked you about XFS in relation to this thread.

Yes, Don, you can remove BtrFS and run Ext4 instead. Or you can run ResierFS, XFS or JFS. And, ah right, you have a SSD; there are a number of supposedly SSD-friendly file systems you could use.

I have not tried the experiment yet, but I have file two bug reports on the current release, 1105583, 1103981, neither of which has been resolved. I do not know what to do except to go to kernel.org and try a virgin kernel. I could also see if Fedora works, but that is a lot more work than the new kernel. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/12/18 2:57 PM, Knurpht-openSUSE wrote:

Op woensdag 12 september 2018 22:49:06 CEST schreef don fisher:

...

1105583 Takashi Iwai told you it's a WONTFIX, didn't he? Please Don, I don't mean no harm, but I had a look at the 1105583 b.o.o, and let me please suggest you stick to one thing at the time. From experience I can tell you that devs stop atm too many issues come up in one bugreport

I guess my command of the language is lacking:-( I stated one thing, a hang on boot. He replied with "The boot hang with the latest update kernel is likely a regression due to the recent security fixes and we're working on it". So it sounded like we were on the same page. I also stated that "The discussion on the Nvidia GP106 was my effort to explain why I was searching for later versions of kernels". Not offered as a new subject, just an explanation as to why I was trying different kernels. After my description of the GPU error, I stated that "I queried the nouveau authors and they claimed that the GP106 is supported and since my message was "unknown chipset", a later version of the kernel that is aware of GP106 support may be required. So all of the kernels I have tried have failed, except for the two mentioned above". The "WONTFIX" entry relates to this lack of GPU support which was NOT the subject of this bug report! The crash was, the explanation of GPU error was to show why I needed later kernels. His reply is below, and clearly further investigation is suggested in the "we do care" section. "For Leap 42.3 *KERNEL*, it's WONTFIX. For TW kernels (that's equivalent with OBS.Kernel:stable), of course, we do care". I do not know how to be more clear. I have a boot problem on later kernels, and this is why I needed later kernels. Why this thread? My threads always seem to spiral out of control! Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/12/18 4:01 PM, Patrick Shanahan wrote:

* don fisher [09-12-18 18:46]: [...]

...

Why this thread? My threads always seem to spiral out of control!

perhaps too much information probably not really "specifically" related to a "singular" problem. solving many problems at one time is usually a creation of another problem. pose one problem and the specifics to it alone and follow suggestions to solve. after solving it, begins another thread and repeat.

Again, I did not shift this thread. I did reply, to what I perceived as a criticism for building you own kernel, stating that I had unresolved issues and my request bug report for followup was NULL. I suggested I might try to build a virgin kernel to see what happened. That's all! The bug report addresses a single problem with crash on later default kernels, earlier kernels booted without incident. Pleas explain the comments to a "singular" problem. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/12/18 4:09 PM, Anton Aylward wrote:

On 2018-09-12 6:44 p.m., don fisher wrote:

...

I do not know how to be more clear. I have a boot problem on later kernels, and this is why I needed later kernels.

Why this thread? My threads always seem to spiral out of control!

You have a boot problem.

I don't know where you latest kernel problems emerging from security fixes come from. I've been booting kernels from kernel_Stable and am now on 4.18.7-1 with 42.3 and I've always done the vanilla mkinitrd with not fiddling with settings. I'm more conservative and won't move to 15 series until EOL for 42.3 gets closer. As it is, 42.3 is stable.

Yes, I'm using Intel drivers, but then again people like Patrick have observed the lack of problems with TW and nVidia.

Personally I don't think your boot problems focus on the latest or the not-latest kernel but on your boot process and possibly your kernel hacking.

Long term readers might recall that I have a habit of taking older hardware and making it run even with late model openSUSE. The WIntel conspiracy and the corporate tax system sets a lifetime for PCs and laptops, and I find great equipment in corporate closets or skips that are "PC Graveyards". My current monitor came from a skip and just needed capacitors replacing :-) My under-the-desk SQL server is a 21 year old laptop. I set it up and hav't need to do anything to it for two years now :-)

A lot of my equipment can't run modern Windows, some doesn't have the memory to do VM. But the Linux seems to be more trouble free for the people I've set up when they found they coudln't run later model Windows and didn't want new hardware, and they say it is more responsive and unlike Windows, the performance doesn't degrade over time.

What you might gather from this is that the 'latest', be it hardware or software' is often not a solution.

As a photographer, I live by the adage 'the camera you carry with you is better than the latest, most expensive gear. I carry a point-and-shoot in my shirt pocket. Professional photographers of my acquaintance tell me they do the same. The PC equivalent of that saying would be that the machine you have working is better than the latest gear with the bleeding edge kernel and drivers.

I think you are either plain jinked or that you are creating your own problems by dealing with complexity where none is needed.

My problem appears to be specific to running on the Alienware 13. All other platforms run without incident. Takashi Iwai stated in his response "The boot hang with the latest update kernel is likely a regression due to the recent security fixes and we're working on it" So it is nothing that I have done to the system. And this time at leas, this rant on my opening multiple subjects is not valid, in my opinion. I have a Canon 5dMK4, but am a bit disabled so never get out to use it:-( Also the reason I wanted the light Alienware 13. To be 20 again! Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/12/2018 4:09 PM, Anton Aylward wrote:

On 2018-09-12 6:44 p.m., don fisher wrote:

...

I do not know how to be more clear. I have a boot problem on later kernels, and this is why I needed later kernels.

Why this thread? My threads always seem to spiral out of control!

You have a boot problem.

Do you enable hyperthreads? He does. hyperthreads can expose the most insecure forms of the recent bugs. I don't run hyperthreads, because most of my applications don't run multiple threads that share enough context to benefit from the greater shared-cache needs of threading. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/13/2018 7:05 AM, Carlos E. R. wrote:

On 13/09/2018 07.24, L A Walsh wrote:

...

On 9/12/2018 4:09 PM, Anton Aylward wrote:

...

On 2018-09-12 6:44 p.m., don fisher wrote:

...

I do not know how to be more clear. I have a boot problem on later kernels, and this is why I needed later kernels.

Why this thread? My threads always seem to spiral out of control! You have a boot problem.

---

Do you enable hyperthreads? He does. hyperthreads can expose the most insecure forms of the recent bugs. I don't run hyperthreads, because most of my applications don't run multiple threads that share enough context to benefit from the greater shared-cache needs of threading.

He was writing about email threads ;-)

==== Sorta, he was talking about both. Certainly anton's response: 'you have a boot problem', wasn't about email threads, no? In the next note: On 9/12/2018 3:48 PM, don fisher wrote:

reading the background. I feel the bug report was valid, the first response being:

"We seem to have a regression with booting on a machine with SMT (due to the recent L1TF security issues)"

SMT usually means threaded. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 13 Sep 2018 07:57:47 -0700 L A Walsh wrote:

On 9/13/2018 7:05 AM, Carlos E. R. wrote:

...

On 13/09/2018 07.24, L A Walsh wrote:

...

On 9/12/2018 4:09 PM, Anton Aylward wrote:

...

On 2018-09-12 6:44 p.m., don fisher wrote:

...

I do not know how to be more clear. I have a boot problem on later kernels, and this is why I needed later kernels.

Why this thread? My threads always seem to spiral out of control! You have a boot problem.

---

Do you enable hyperthreads? He does. hyperthreads can expose the most insecure forms of the recent bugs. I don't run hyperthreads, because most of my applications don't run multiple threads that share enough context to benefit from the greater shared-cache needs of threading.

He was writing about email threads ;-)

==== Sorta, he was talking about both. Certainly anton's response: 'you have a boot problem', wasn't about email threads, no?

I agree with Carlos. Don wasn't talking about hyperthreading at all. He was only talking about email threads. Anton was simply trying to clarify what he thought was the fundamental topic that should be discussed in this mail thread.

In the next note: On 9/12/2018 3:48 PM, don fisher wrote:

...

reading the background. I feel the bug report was valid, the first response being:

"We seem to have a regression with booting on a machine with SMT (due to the recent L1TF security issues)"

SMT usually means threaded.

That may be true, but is irrelevant to Don's post. As in "Jinxed? (by paying too much attention to details?)" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/12/18 3:28 PM, Anton Aylward wrote:

On 2018-09-12 4:49 p.m., don fisher wrote:

...

...

I have not tried the experiment yet, but I have file two bug reports on the current release, 1105583, 1103981, neither of which has been resolved. I do not know what to do except to go to kernel.org and try a virgin kernel. I could also see if Fedora works, but that is a lot more work than the new kernel.

I keep getting the feeling, Don, that you make things more complicated than the rest of us do, and in doing so create a cascade of problems of your own.

There's a whole pile of "well it works for me" responses from the rest of, some of use don't bother even saying that rather than getting in a yes-but argument.

I don't now, Don, perhaps you're jinxed.

I would not bother with kernel.org when there is the kernel with the distribution and at Kernel_stable. We've been down this route before and it's a dead horse. Somehow you are creating a problem and then spiralling round adding more complexity and with it more obscurity. As Gertjan says, you can't seem to focus on just one thing at a time so list readers don't know where you're at.

Sometimes I think folks just comment, maybe because of me, without even reading the background. I feel the bug report was valid, the first response being: "We seem to have a regression with booting on a machine with SMT (due to the recent L1TF security issues)" So surely I am not making this up. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org