Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wipe and reinstall a running Linux system via SSH (2017)

github.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Wipe and reinstall a running Linux system via SSH (2017)

#71

Post by blibble »

mehrdadn wrote: post #3
saagarjha wrote: post #2

The Stack Overflow answer linked is horrifyingly delightful: https://unix.stackexchange.com/questions/226872/how-to-shrin...

I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows: diskpart select volume C: shrink desired=4096 I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.

I've rarely had this work successfully on Windows... normally after several hours it pops up an indecipherable error message

presumably because it couldn't make the filesystem as small as I asked for, for whatever reason

Re: Wipe and reinstall a running Linux system via SSH (2017)

#72

Post by oger »

nolok wrote: post #24
reitanqild wrote: post #20

Earlier quoted context omitted.

So you are saying the Synology guys stepped you through it? That would be amazing support. (My Synology just works so I don't know what the support is like.)

They asked a permission and for me to fill a form so that they could remote connect to my NAS, and after investigating gave me on the support chat/list thingy the commands that they thought would fix it but they wouldn't run them themselves. Ended up working (issue was that a power failure happened during a shr2 reshape, and while the lvm volume had recovered mdadm hadn't and was blocked in a failed reshape loop, sin…

Had some quite exceptional experiences with them as well. Good support for a decent product.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#73

Post by iforgotpassword »

nolok wrote: post #27
fps_doug wrote: post #5

Earlier quoted context omitted.

Yeah, admittedly if you don't know what's going on there it might feel pretty convoluted and "wtf am I doing here". OTOH, on Linux you could do this since forever, it's not been that long ago that Windows finally shipped tools to do so. Now actually, Windows seems even more convenient since you can easily shrink a FS that is online. On Linux I'm not even sure that is possible; maybe with btrfs but I never really need…

> it's not been that long ago that Windows finally shipped tools to do so I beg to differ, Computer management > Disk management has allowed you to do that in a visual and safe way since at least windows seven in 2009. God knows since how long the underlying cli commands have been available.

Iirc it couldn't resize mounted partitions (that was win8), and shrinking always just failed with no meaningful error message.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#74

Post by cliffy »

xxpor wrote: post #65
cliffy wrote: post #55

Earlier quoted context omitted.

Maybe kexec-ing into the new kernel would be feasible? I investigated this many years ago to see if it was, but I found scant information on compatibility requirements when using kexec to hand over execution to an arbitrary kernel. The problem seems really hard though. One issue that stands out to me is that even if you properly shutdown the old kernel, will all system devices be in a 'good enough' state to be reinit…

kexec is basically the same as a reboot, as far as userspace is concerned. Your sshd is going to go away.

Userspace sure, but what about underlying hardware? How will device drivers react if they come up and encounter hardware that is not coming out of a ACPI induced reboot? Will some devices and their corresponding drivers be OK? Or will the drivers panic when they encounter a device in a weird state?

I'm genuinely curious is all. At the time I was pursing this I decided it was going to get too complicated and that I had to live with a reboot.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#75

Post by wtallis »

xorcist wrote: post #66
wtallis wrote: post #46

Earlier quoted context omitted.

The btrfs resize command only changes the size of the filesystem. A fdisk or similar command is needed to adjust the partition size as well.

Well, the answer more like "it depends on what you want, exactly". In the specific example of btrfs there is an extra layer of indirection just like there is with ZFS. Filesystems live inside pools of devices, and when one is shrunk that leaves room for another one to grow. You wouldn't want to resize the physical volume or partition unless the device is shared with other types of filesystems. (This is why ZFS and bt…

What you describe is accurate for ZFS, but not for btrfs. Shrinking a btrfs filesystem with the resize command only makes sense if you are going to follow up by shrinking the partition or other underlying logical block device (eg lvm). btrfs does not have ZFS's concept of a device pool from which multiple filesystems can be allocated.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#76

Post by yellowapple »

cormacrelf wrote: post #18
mehrdadn wrote: post #3

Earlier quoted context omitted.

I love how the first comment praises it for being "straightforward". For reference, this is how you shrink a file system on Windows: diskpart select volume C: shrink desired=4096 I guess it's nice that the Linux version lets you move the partition as well (or "shrink from behind", so to speak), but damn, "straightforward" is not a word I would have used to describe it.

I love that this line sounds like an old sea shanty: for i in dev proc sys run; do mount --move /oldroot/$i /$i; done

I now want to make it my goal for every line of code I write to be singable as a shanty.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#77

Post by etaoins »

cliffy wrote: post #74
xxpor wrote: post #65

Earlier quoted context omitted.

kexec is basically the same as a reboot, as far as userspace is concerned. Your sshd is going to go away.

Userspace sure, but what about underlying hardware? How will device drivers react if they come up and encounter hardware that is not coming out of a ACPI induced reboot? Will some devices and their corresponding drivers be OK? Or will the drivers panic when they encounter a device in a weird state? I'm genuinely curious is all. At the time I was pursing this I decided it was going to get too complicated and that I ha…

This is a concern but it usually works for two reasons:

1. Most firmware is sufficiently broken that Linux drivers are already hardened against devices being brought up in arbitrary states.

2. kexec walks the device tree to shut down all devices before starting the new kernel. This usually gets devices closer to a startup state, or at least a smaller number of known shutdown states.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#78

Post by xorcist »

wtallis wrote: post #75
xorcist wrote: post #66

Earlier quoted context omitted.

Well, the answer more like "it depends on what you want, exactly". In the specific example of btrfs there is an extra layer of indirection just like there is with ZFS. Filesystems live inside pools of devices, and when one is shrunk that leaves room for another one to grow. You wouldn't want to resize the physical volume or partition unless the device is shared with other types of filesystems. (This is why ZFS and bt…

What you describe is accurate for ZFS, but not for btrfs. Shrinking a btrfs filesystem with the resize command only makes sense if you are going to follow up by shrinking the partition or other underlying logical block device (eg lvm). btrfs does not have ZFS's concept of a device pool from which multiple filesystems can be allocated.

It's close enough. A completely valid use case for shrinking a btrfs file system is to remove one of the physical volumes from it, of which there can be several. They can also be split into subvolumes, which is the canonical use case for partitioning your block storage.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#79

Post by mirimir »

xxpor wrote: post #65
cliffy wrote: post #55

Earlier quoted context omitted.

Maybe kexec-ing into the new kernel would be feasible? I investigated this many years ago to see if it was, but I found scant information on compatibility requirements when using kexec to hand over execution to an arbitrary kernel. The problem seems really hard though. One issue that stands out to me is that even if you properly shutdown the old kernel, will all system devices be in a 'good enough' state to be reinit…

kexec is basically the same as a reboot, as far as userspace is concerned. Your sshd is going to go away.

It's clever how one can restart sshd, after editing sshd_config, without losing the ssh connection. Very thoughtful, and counter-intuitive.

Re: Wipe and reinstall a running Linux system via SSH (2017)

#80

Post by wtallis »

xorcist wrote: post #78
wtallis wrote: post #75

Earlier quoted context omitted.

What you describe is accurate for ZFS, but not for btrfs. Shrinking a btrfs filesystem with the resize command only makes sense if you are going to follow up by shrinking the partition or other underlying logical block device (eg lvm). btrfs does not have ZFS's concept of a device pool from which multiple filesystems can be allocated.

It's close enough. A completely valid use case for shrinking a btrfs file system is to remove one of the physical volumes from it, of which there can be several. They can also be split into subvolumes, which is the canonical use case for partitioning your block storage.

Neither of those use cases involves the `btrfs filesystem resize` command. Removing a physical device is accomplished with `btrfs device remove`, and subvolumes don't have a capacity unless you enable the optional quota features (and even then, quota groups use thin provisioning, so setting a lower quota limit doesn't free up any space for anything else).
Post reply on HN