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

61–70 of 81 posts

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

#61

Post by lukeschlather »

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.

While setting up a new laptop I tried to use it and I ended up having to force kill Disk Management after it was "shrinking" for a couple hours. I think the underlying command had succeeded but it just froze. I've never had that kind of experience with (G)Parted, and I think I still trust the Linux tools more...

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

#62

Post by kilburn »

pbhjpbhj wrote: post #59
kilburn wrote: post #58

Earlier quoted context omitted.

You can remount the root filesystem elsewhere, but not unmount it while it is still the rootfs. Your suggestion would work but it involves restarting nearly everything and having another partition with enough space to copy everything into. It can be done but is pretty hard in general, so gparted just doesn't support it. If you really want/need to do it, you can do so. Otherwise just use a livecd and make your life ea…

I assumed that the point was it's a remote situation and so mounting a liveUSB would be costly.

The question explicitly stated that booting another os wasn't an option, so you are right in this case.

However, you should avoid being in that situation entirely, which is nowadays very feasible: all modern servers include remote management facilities, and all sensible virtual server providers give you some way or another to boot from a network image (and get a console session through VNC).

If your provider doesn't give you these options you should definitely switch providers. Not having this option means that you are always one mistake away from total doom (server won't boot -> you will never ever be able to access it again).

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

#63

Post by nwallin »

andrewflnr wrote: post #60
xorcist wrote: post #30

Earlier quoted context omitted.

And this is how to shrink a mounted filesystem in Linux when you use btrfs: btrfs filesystem resize 4g / It's just not supported for ext4. You can grow an ext4 file system, even when it is your currently mounted root, just not shrink it. While it's great that NTFS does (now) support it few other file systems do because it's a relatively uncommon and quite risky. I certainly wouldn't shrink mounted filesystems even on…

You can totally shrink an ext4 filesystem.

Not without unmounting it first.

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

#65

Post by xxpor »

cliffy wrote: post #55
mirimir wrote: post #45

> This script does not have any provisions for exiting out of the new environment back into something sane. You will have to reboot when you're done. If you get anything wrong, your machine won't boot. Tough luck. So then "without rebooting" in the title is inaccurate, no? I haven't studied TFA carefully. But reinstalling running Linux systems via SSH is pretty routine, no? Using debian-installer with network-console…

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.

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

#66

Post by xorcist »

wtallis wrote: post #46
y4mi wrote: post #34

Earlier quoted context omitted.

> Does that also shrink the partition? Otherwise you're not comparing equivalent things... yes, it does. btfs is already the default in SUSE derivatives. It remains to be seen how the other distributions will handle it within the next ~3 yrs. its only just become stable enough to be usable in production.

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 btrfs sometimes are referred to as "layering violations". Other filesystems expect the logical volume manager to pool devices into logical block devices.)

So resizing an btrfs filesystem absolutely makes sense even in isolation.

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

#67

Post by Stratoscope »

simias wrote: post #22
vbezhenar wrote: post #12

Earlier quoted context omitted.

It's not trivial and also it's likely to be very poorly tested scenario. I would recreate FS even if it supports resize.

Thank you for making me double-check, you're right that ZFS can't shrink volumes but you can use resize2fs to shrink EXT2+ volumes offline relatively easily, see for instance https://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safe... for a LVM + EXT example. What makes you say that it's poorly tested exactly? Of course if you want to shrink the rootfs without rebooting you'll have to do it while mounted and I'm…

> Can Windows really let you shrink NTFS while mounted?

Yes, I have done it, even on the running system partition, and no reboot required. Just right click the partition in Disk Management and select Shrink. It will calculate the smallest size the partition can shrink to, and you can use that or any larger size.

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

#68

Post by fulafel »

Stratoscope wrote: post #67
simias wrote: post #22

Earlier quoted context omitted.

Thank you for making me double-check, you're right that ZFS can't shrink volumes but you can use resize2fs to shrink EXT2+ volumes offline relatively easily, see for instance https://blog.shadypixel.com/how-to-shrink-an-lvm-volume-safe... for a LVM + EXT example. What makes you say that it's poorly tested exactly? Of course if you want to shrink the rootfs without rebooting you'll have to do it while mounted and I'm…

> Can Windows really let you shrink NTFS while mounted? Yes, I have done it, even on the running system partition, and no reboot required. Just right click the partition in Disk Management and select Shrink. It will calculate the smallest size the partition can shrink to, and you can use that or any larger size.

The amount of shrinkage available seems to be semi-random though, you can't shrink away all of the free space.

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

#69

Post by Stratoscope »

fulafel wrote: post #68
Stratoscope wrote: post #67

Earlier quoted context omitted.

> Can Windows really let you shrink NTFS while mounted? Yes, I have done it, even on the running system partition, and no reboot required. Just right click the partition in Disk Management and select Shrink. It will calculate the smallest size the partition can shrink to, and you can use that or any larger size.

The amount of shrinkage available seems to be semi-random though, you can't shrink away all of the free space.

That will happen when there are unmovable files. There are a few tricks you can do to unlock some of these files, or you can use an external utility that you reboot into.

This article is from a vendor of such a utility, but it also describes how to unlock some of the unmovable files within Windows:

https://www.disk-partition.com/articles/shrink-volume-with-u...

Post reply on HN