[opensuse] Removing BTRFS from system
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. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* don fisher <hdf3@comcast.net> [09-10-18 17:43]:
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.
google provides several examples of converting from btrfs to ext4 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 -- 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-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 -- 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 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 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. 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. I can boot from another disk on the same machine, and the ext4 file system appears to function properly. Thanks. I can open a new thread if you think I should. Don -- 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 09/11/2018 01:53 PM, Carlos E. R. wrote:
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.
I needed to use the Yast2 boot to set the correct boot partition. The one was from the copied system. Now all works. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-09-10 5:41 p.m., 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 tell you how I did it but you won';t like this. To start with I use LVM, so it is easy for me to breate a new 'partition'. I created one I labelled 'ROOT4' /dev/mapper/vgmain-vROOT4 I can do this because have plenty to free space available in my LVM. You might see the same with a basic drive if you create it with a few spare partitions. Sadly, most people have a tendency to fill up their disks with partitions even though the partitions are sparsely used :-( Not a sensible strategy as it end up with lots of free space in unusable places and a tendency to patch thing with symlinks. Which won't work in this case. I looked at the actual space my old BtrFS RootFS used without the snapshots and set up the new partition to manage that. Unlike BtrFS, ext4 preallocates i-node space so you'll need to make sure you have enough i-nodes. This is simpler for me since I have a separate /tmp file system. If your /tmp is a part of your RootFS then you have a future unknown of the number of files and hence inodes. IIR there are also some security issues to do with having /tmp as part of the RootFS as well. I suppose thing gets back into the issue of what should and should not be on your faster drive.... Once ROOT4 was formatted I mounted it it on /mnt/disk and then user rsync to copy the old root file system across. Rsync is versatile. The fist thin is to make sure you don't copy any other FS. Use the "-x" option. make sure you exclude the snapshots. You can do some pruning here if you like. I set up a 40G partition for my ROOT4 and the algorithm gave me 2M5 inodes. That seemed a bit high. As it turned out I over-provisioned: I'm using about 25% of the data and 4% of the inodes. The I had to reset the values for a new grub and all that in the config files and build a new initrd. All that is automated :-) Why did I use Ext4? Well it is built into the kernel. I can load it without any modules. But as far as I'm concerned its a bloody awful FS. That division between inode space and data space goes back to the beginning of the 1970s as far as UNIX files systems go, and that tradition goes back further to the 1950s. With a Btree FS, which Ext4 claims to be, it is a stupid anachronism. No such division exists in BtrFS. Not in XFS, JSF or ReiserFS. Check their dates. What I really should have done is remake the kernel with ext4 as a module and JFS or XFS built in and made that to RootFS instead of ext4. But really: I've got better things to do with my time. Heck, if that was an option for me I'd use Reiser4 instead and build a kernel for that. -- 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 00.07, Anton Aylward wrote:
Why did I use Ext4? Well it is built into the kernel. I can load it without any modules. But as far as I'm concerned its a bloody awful FS. That division between inode space and data space goes back to the beginning of the 1970s as far as UNIX files systems go, and that tradition goes back further to the 1950s. With a Btree FS, which Ext4 claims to be, it is a stupid anachronism. No such division exists in BtrFS. Not in XFS, JSF or ReiserFS. Check their dates. What I really should have done is remake the kernel with ext4 as a module and JFS or XFS built in and made that to RootFS instead of ext4. But really: I've got better things to do with my time. Heck, if that was an option for me I'd use Reiser4 instead and build a kernel for that.
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 ;-) The fact is, I haven't had a problem with ext4 on / in a decade at least. -- 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
On 9/11/2018 6:31 AM, Anton Aylward wrote:
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?
um...I've been using it since before I was using SuSE. In the early days of it being on linux, I had a prob with disk corruption, but we are talking pre 2.0 kernel here as well,I think or very early 2.x series. Can't really say it was the fault of XFS given the lower stability, overall back then, but can't say it wasn't -- it was a new kid on the block back then. As for needing a separate partition for boot. I've always had a separate boot, because you don't want something like xfs_fsr running through that partition after lilo as looked where the kernels are on the disk. That said, you can now mark flags 'no-defrag' to skip them. Also, the need for it on /, /boot and /usr is minimal to non-existent. FWIW, all my partitions are xfs -- never had a problem with grub not working with xfs cuz I didn't use grub (lilo). lilo is pretty simplistic, but there is less to go wrong (like when grub started failing in conjunction with XFS because it wrote to a 'live' filesystem. So, it's supported acls and extended attrs from day 1, and work is ongoing to add deduplication. My only gripe has been that most utils didn't support acls and ext-attr backup/restore or copy, so was "limited"[sic?] to xfs_backup/restore, which is still a good & fast way to copy an xfs file system, however, tar, cp as well as rsync all understand extattrs and acls, so other options are available. Did I answer the question(s)? (too much? Dang.) -l -- 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 11/09/2018 14.16, L A Walsh wrote:
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:
(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):
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. -- 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 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
Le 12/09/2018 à 02:32, Anton Aylward a écrit :
Yes, this is the point I was trying to make about ext4 still being stuck in the old old model of resource preallocation.
yes, but this is only a problem on data partition, and it's pretty simple to change the file system there (rsync to external disk, reformat and back), not so simple in / probably reason why default on openSUSE is BTRFS on / and XFS on /home jdd -- http://dodin.org -- 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 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_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
This is from my /boot/config-4.18.7-1 which is downloaded unmodified from the kernel_Stable repository # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=y <======== CONFIG_EXT4_USE_FOR_EXT2=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_EXT4_ENCRYPTION=y CONFIG_EXT4_FS_ENCRYPTION=y # 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
CONFIG_XFS_FS=m <================= CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_ONLINE_SCRUB is not set # CONFIG_XFS_WARN is not set # CONFIG_XFS_DEBUG is not set CONFIG_VXFS_FS=m -- 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 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 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. -- 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 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
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
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- 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
* don fisher <hdf3@comcast.net> [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. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- 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 <hdf3@comcast.net> [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 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. -- 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 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 12/09/2018 19.31, don fisher wrote:
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 agree. It is just people reading too fast and not noticing everything. -- 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/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 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 ;-) -- 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/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 2018-09-13 10:57 a.m., L A Walsh wrote:
SMT usually means threaded.
Surface-mount technology ? Or do you mean Supply-Chain Management Training? No, I thought that term was AMD Ryzen specific. And you should be able to turn that off, certainly the ones I've played with with the laptops in BestBuy when I think about using using my USB install stick to put openSUSE Linux on one .... no, that would be unsociable <smirk> But I have booted them with a LiveUSB and once upon a time with a LiveCD. But if you mean 'multi-threaded CPU" in general, well that's another matter. We all have been booting those for many years. -- 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 Thu, 13 Sep 2018 07:57:47 -0700 L A Walsh <suse@tlinx.org> 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 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. -- 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 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
On 2018-09-12 6:48 p.m., don fisher wrote:
"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.
No, but why have you placed yourself in that situation when the rest of us seem able to not do that? -- 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
participants (8)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
don fisher -
jdd＠dodin.org -
Knurpht-openSUSE -
L A Walsh -
Patrick Shanahan